- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Thu, 01 Sep 2016 06:54:41 +0000
- To: Simon.Cox@csiro.au, frans.knibbe@geodan.nl, jlieberman@tumblingwalls.com
- Cc: eparsons@google.com, public-sdw-wg@w3.org
- Message-ID: <CADtUq_3wHbryF9YdcPPv3_R+CO_x1EE5Q1LVzPgOCkTKvWbLPQ@mail.gmail.com>
All. Very useful conversation so far about linear referencing, but nothing yet on the topic of spatial relations - see the second half of the email I used to start this thread [1]. I really need some help on this too. Thanks. Jeremy [1]: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0210.html On Thu, 1 Sep 2016 at 07:51, Jeremy Tandy <jeremy.tandy@gmail.com> wrote: > @simon ... > > > But if you want to compare different properties along a linear feature, > it makes sense to use linear referencing > > for example, in a borehole? This is especially true where you can't > provide a geographic coordinate because you're not sure where the borehole > actually goes to any degree of accuracy. > > So ... > > I think that we're saying that LR should be avoided (by converting LR > measurements into more general coordinates) except in some special cases > where: > > 1) you want to describe sets of things along a linear element in a network > - such as in hydrology or samples from a borehole - and it is more > important to describe the relative positions of those things along the > linear element > > 2) you can't (or don't want to) express the location in geographic > coordinates to a satisfactory level of precision - for example, in a > geological survey that uses chainage (distance) between two points. > > In both of these cases, it seems sensible to describe the position using a > 1-dimensional CRS (or LRS). > > On Wed, 31 Aug 2016 at 23:55, <Simon.Cox@csiro.au> wrote: > >> Ø … it’s a best practice not to use linear referencing … >> >> … because it makes it difficult to combine with data that uses a >> different CRS. >> >> But if you want to compare different properties along a linear feature, >> it makes sense to use linear referencing. >> >> >> >> *From:* Joshua Lieberman [mailto:jlieberman@tumblingwalls.com] >> *Sent:* Thursday, 1 September 2016 1:48 AM >> *To:* Frans Knibbe <frans.knibbe@geodan.nl> >> *Cc:* Jeremy Tandy <jeremy.tandy@gmail.com>; Cox, Simon (L&W, Clayton) >> <Simon.Cox@csiro.au>; Ed Parsons <eparsons@google.com>; SDW WG Public >> List <public-sdw-wg@w3.org> >> >> >> *Subject:* Re: Request for help: BP 9 "How to describe relative >> positions" >> >> >> >> Well, my opinion is that it’s a best practice not to use linear >> referencing, but that’s only my opinion, and I’ve been persuaded that a >> spatial ontology should accommodate it. >> >> >> >> Josh >> >> >> >> On Aug 31, 2016, at 11:08 AM, Frans Knibbe <frans.knibbe@geodan.nl> >> wrote: >> >> >> >> >> >> >> >> On 31 August 2016 at 15:19, Joshua Lieberman < >> jlieberman@tumblingwalls.com> wrote: >> >> Yes, but it’s a sort of derived CRS (LRS) that references one or two >> other feature geometries (curve +/- origin point) in their own CRS, adding >> a unit of measure. >> >> >> >> So you agree that there is no need to elaborate on LR in the BP if the >> spatial ontology (new version of GeoSPARQL) that we are working on offers >> sufficient hooks to work with LR? That would probably be a relief for the >> BP editors. >> >> >> >> I think some recursiveness is hard to avoid in CRS defintions. Coordinate >> systems are based on datums and datums are based on ellipsoids... >> Eventually everything in the universe needs to be located in terms of some >> arbitrary reference system. >> >> >> >> Regards, >> >> Frans >> >> >> >> >> >> There is another way of looking at linear reference measurements, which >> is that they are observations made directly on a linear feature. In many >> cases, it is a compact way of recording where some additional measurement >> has been made, such as a water level, that eventually gets converted to a >> linear reference point based on an LRS, and from there to an (x,y) point. >> Both should be possible, depending on the usage. >> >> >> >> Josh >> >> >> >> >> >> On Aug 31, 2016, at 8:54 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote: >> >> >> >> I wonder if Linear Referencing can be seen as a version of the mo >> >> re general case of expression location in terms of a well defined CRS. >> For 3D data, we use two numbers (latitude and longitude) to place a >> location on a funnily shaped 3D geometry (a model of the surface of the >> Earth). In LR, we use a single number to place locations on a funnily >> shaped 2D geometry (e.g. a model of a road or a river). We can use >> topological relationships to make assertions about those locations and to >> filter data: Is there an essential difference between asking whether two >> polygons on Earth touch each other or if two sections of road touch each >> other? >> >> >> >> Now if our spatial ontology allows the definition of any kind of CRS in >> two or three dimensions, and clearly associating that CRS with geometry, >> and the use of topological relationships, then it could very well be that >> there is no need to make special arrangements for LR. >> >> >> >> I do think that organisations that naturally work with LR data, e.g. >> organisations in the transportation sector, should be able to publish their >> data on the web and let them be used by whomever it pleases. >> >> >> >> Regards, >> >> Frans >> >> >> >> >> >> On 31 August 2016 at 13:42, Jeremy Tandy <jeremy.tandy@gmail.com> wrote: >> >> I take from the discussion so far: >> >> * GML 3.3 does LR by defining a CRS >> * LR is pretty specialised >> * General GIS tooling does not typically support it; although specific >> domains may (e.g. transport networks, hydrology, geology, navigation) >> >> I think that @eparsons is inferring that LR is too niche to be considered >> a "best practice" for spatial data on the web; if data publishers _do_ use >> LR in their systems, then they should publish the information using a >> geometry that is computed from their domain-specific specialised tools. >> >> That would certainly give me less to write :-) ... but before concluding >> this particular topic I'd like to see consensus from the group. >> >> So ... >> >> PROPOSAL: Linear Referencing is too niche to be considered a "best >> practice" for spatial data on the web; if data publishers _do_ use LR in >> their systems, then they should publish the information using a geometry >> that is computed from their domain-specific specialised tools. >> >> Voting please: >> +0 (I lack the hands on experience to judge) >> >> >> Finally, I also note that I still need help on the "spatial relations" >> topic that was second in my original email. More help required please. >> >> >> Jeremy >> >> >> >> On Wed, 31 Aug 2016 at 12:18, Joshua Lieberman < >> jlieberman@tumblingwalls.com> wrote: >> >> It's also a part of stream hydrology, which is mainly there is a version >> of it in sdwgeo. >> >> >> >> Josh >> >> Joshua Lieberman, Ph.D. >> >> Principal, Tumbling Walls Consultancy >> >> Tel/Direct: +1 617-431-6431 >> >> jlieberman@tumblingwalls.com >> >> >> On Aug 31, 2016, at 06:23, <Simon.Cox@csiro.au> <Simon.Cox@csiro.au> >> wrote: >> >> Well you do see it in navigation systems. Time & distance. >> >> >> >> *From:* Ed Parsons [mailto:eparsons@google.com <eparsons@google.com>] >> *Sent:* Wednesday, 31 August 2016 7:49 PM >> *To:* Jeremy Tandy <jeremy.tandy@gmail.com>; SDW WG Public List < >> public-sdw-wg@w3.org> >> *Subject:* Re: Request for help: BP 9 "How to describe relative >> positions" >> >> >> >> I still question the need to include linear referencing, it's another >> very specialised way to model spatial data and one which is not widely seen >> on the web ? >> >> >> >> ed >> >> >> >> >> >> On Wed, 31 Aug 2016 at 10:26 Jeremy Tandy <jeremy.tandy@gmail.com> wrote: >> >> Hi- >> >> >> >> BP doc section § 10.5.1 "Describing location" [1] is where we intend to >> provide all the guidance that explains how you should encode location >> information in a web-friendly way. >> >> >> >> This includes BP 8 "Provide geometries on the Web in a usable way" [2] >> and BP 9 "How to describe relative positions" [3]. >> >> >> >> (I think it's likely that we will also need a BP to help people choose >> the right CRS too ...) >> >> >> >> We editors envisage BP 9 covering: >> >> >> >> (1) Linear referencing >> >> (2) Use of spatial relations [4] >> >> >> >> ... >> >> >> >> (1) >> >> From a quick scan, I see that ISO 19148:2012 covers the topic of Linear >> Referencing. I don't have access to the ISO document itself, so I've not >> been able to read the standard ... but reviewing the UML model (accessible >> here [5]) it seems VERY complicated. >> >> >> >> I also note that the INSPIRE Generic Network Model has a simpler >> implementation of Linear Referencing. >> >> >> >> Questions: >> >> a) are we limited to GML implementations for Linear Referencing? >> >> b) has anyone converted the GML Application Schemas from ISO 19148 and >> INSPIRE GNM into other formats ... particularly an RDF / OWL ontology? >> >> c) are there any other mechanisms in use for Linear Referencing? e.g. can >> LR be done with GeoJSON? >> >> d) are people really using ISO 19148:2012 given it's complexity? >> >> >> >> INSPIRE's Transport Network specification v3.2 §10.3 "Linear Referencing" >> states: >> >> >> >> “In general it is expected that linear referencing will be used to model >> the relationships of objects that are associated with an network, but where >> the position of those associated objects is not known (or required) to a >> very high level of absolute accuracy ~ better than 1-3m at local level >> (e.g. traffic accidents, planned works, restrictions). >> >> >> >> Where absolute accuracy is required (e.g. the location of drain covers, >> excavations, line side signalling equipment, masts etc) such objects should >> be reused, and referenced, if they already exist e.g. as topographic >> features.” >> >> >> >> This seems like the basis of some guidance about when one might use >> Linear Referencing. >> >> >> >> What I need (please!) are some worked examples for Linear Referencing of >> a point along a linear feature and for Linear Referencing of a length along >> a linear feature. In the flooding scenario, this might be: >> >> * Location of flotsam / debris (point) blocking a drainage channel that >> needs to manually cleared >> >> * Location of a flooded section (length) of a road >> >> >> >> (2) >> >> We also want to demonstrate how spatial relations are used. There are >> obvious examples of topological relationships such as "this administrative >> unit _touches_ that administrative unit" (or contains etc.). >> >> >> >> I recall that we were going to get the set of topological relationships >> added to the IANA Link Relations registry [7]. I am not even sure which set >> of topological relations we should be recommending? GeoSPARQL has me >> somewhat confused with "Simple Features Relation", "Egenhofer Relation" and >> "RCC8 Relation". Then there's D9-EIM too ... >> >> >> >> Can someone provide me some worked examples using the preferred set of >> topological relationships? >> >> >> >> We also need to illustrate use of _directional_ (e.g. "left", "in front >> of" and "astern") and _distance_ relations (e.g. "at", "nearby" and "far >> away"). I don't know of any formalised vocabulary for expressing these >> things. If there is one, should we be seeking to add these to the IANA Link >> Relations registry too? >> >> >> >> Again, worked examples requested! If you can related them to an urban >> environment / flooding scenario all the better. (e.g. someone might assert >> "the flooding is near my house") >> >> >> >> Finally, we also need to show people how to express "fuzzy" spatial >> things. Examples we have elsewhere in the BP doc are "the American West" >> and "Renaissance Italy". These are spatial things were there is not general >> agreement about the exact geographic extent, so it is not possible to use a >> geometry to describe it. What is the best way to describe things like this? >> Should we use spatial relations e.g. "downtown" _contains_ city districts >> A, C, D, and G (because "everyone" agrees this) - but we're not saying it's >> exact geometry because it's a colloquial term used by citizens of our >> fictional Nieuwhaven. >> >> >> >> Again, I'd like to see a worked example. >> >> >> >> ... >> >> >> >> There's a lot of questions wrapped up in this email. I'm looking for help >> to resolve them ... preferably with someone in the WG taking the lead to >> coordinate a response. >> >> >> >> I'm also aware that we need to avoid an RDF bias, so it would be good to >> have examples in other formats too. >> >> >> >> Volunteers, please step forward! >> >> >> >> Thanks in advance. Jeremy >> >> >> >> [1]: http://w3c.github.io/sdw/bp/#bp-expr-geo >> >> [2]: http://w3c.github.io/sdw/bp/#describe-geometry >> >> [3]: http://w3c.github.io/sdw/bp/#relative-position >> >> [4]: http://w3c.github.io/sdw/bp/#spatial-relations >> >> [5]: https://github.com/ISO-TC211/HMMG >> >> [6]: >> http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_TN_v3.2.pdf >> >> >> [7]: http://www.iana.org/assignments/link-relations/link-relations.xhtml >> >> >> -- >> >> *Ed Parsons *FRGS >> Geospatial Technologist, Google >> >> Google Voice +44 (0)20 7881 4501 >> www.edparsons.com @edparsons >> >> >> >> >> >> >> >> >> >
Received on Thursday, 1 September 2016 06:55:34 UTC