Re: Request for help: BP 9 "How to describe relative positions"

I've just read the email thread on ISSUE 70 [1] and see how discussion on
LR is related. Simply put, we're suggesting making life easy for data
consumers by removing the need for them to do the conversion from LRS to
CRS.

Jeremy

[1]: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jul/0246.html

On Thu, 1 Sep 2016 at 22:01 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:

> So ...
>
> In the main we want to drive people toward using cartesian/geographic
> coordinates to describe things; as @simon said, it makes it easier to
> combine with other data.
>
> There are a number of cases where it is convenient to express a location
> using distance / time along a linear feature (e.g. for mile-markers / view
> points / close encounters with a bear along a hiking trail) ... and others
> where only LR can provide sufficient precision when expressing location
> (e.g. location of a sample extraction along a borehole; you only really
> know where the borehole collar is located, the rest might be computed using
> data from accelerometers but it's less than exact).
>
> LR mechanisms are often domain / system specific; which means that
> location expressed using LR is difficult for a broader community to use.
>
> If a data publisher is able to, they should provide an API that converts
> from the LR location to geographic / cartesian coordinates (e.g. using the
> capabilities of their GIS system) - or additionally provide the location
> information in geographic / cartesian coordinates.
>
> Note that use of LR is going to prevent use of the most commonly used
> formats like GeoJSON because they just don't support geometry expressed in
> anything other than WGS84 / EPSG:4326.
>
> I think @jonblower expressed the potential quite well:
>
> > The “best practice” in woolly terms might be this: Publish in LR if you
> that’s useful, but it really helps clients if you can provide a version of
> the data in a more commonly-used Cartesian/geographic/whatever CRS. If this
> isn’t possible or desirable, or if there are caveats, then explain this to
> clients.
> >
> > In my mind at least the BP at a high level is about improving
> communications between communities – we may not have a perfect technical
> solution yet but we can make some improvements by trying to adapt to the
> needs of communities outside our own.
>
> @eparsons commented that:
>
> > we are trying to illustrate best practice.. I think we are someway away
> from being able to do this here.. unless of course we can point to where
> data published using linear referencing is used by a community on the web
>
> I suggest that we don't try to tell people _how_ to do LR as there isn't
> (to my knowledge at least) a generally accepted practice to do this. Given
> that @josh said:
>
> > I’ve been persuaded that a spatial ontology should accommodate [LR]
>
> ... a generally accepted practice for LR may emerge in the future. But
> that's beyond the scope of the BP doc - except as a non-normative Note that
> could refer interested readers to the spatial ontology that @josh refers to.
>
> Thoughts please?
>
> Jeremy
>
> On Thu, 1 Sep 2016 at 14:07 Joshua Lieberman <jlieberman@tumblingwalls.com>
> wrote:
>
>> Actually, people do often measure along paths. I’d forgotten, but
>> distances in trail descriptions are often measured with an odometer wheel
>> since available maps don’t necessarily account for the length of all the
>> local twists and turns and GPS may not work well in the woods. In such
>> cases, the linear references are experiential, but may not correspond to an
>> available path geometry. I should have thought of this since I once got
>> into a bit of trouble for underestimating from a map the length of a trail
>> that my wife and I walked. 15 miles later, she was not pleased.
>>
>> Josh
>>
>>
>>
>> On Sep 1, 2016, at 7:50 AM, Joshua Lieberman <
>> jlieberman@tumblingwalls.com> wrote:
>>
>> Ed,
>>
>> There is a  more common use where people publish on the Web trip
>> descriptions in which something occurs or is seen at "Mile 7.2" for
>> example, or it should take 150 minutes to walk there. No one is chaining
>> along a path for 7 miles and the route is generally recorded in GPS or map
>> coordinates but it's really a way of identifying and describing events and
>> their order more than anything else. The path feature and distance serve as
>> the identifier, while a path geometry and origin reference (aka LRS)
>> conversion back and forth from 2/3D coordinates. So, using LR for events
>> along the path of some activity or process, in combination with 2/3D
>> coordinates, might be the best practice we're grasping for, that doesn't
>> usually need to rise to the level of a location observation with the the
>> additional linked elements that the latter would involve.
>>
>> Josh
>>
>> Joshua Lieberman, Ph.D.
>> Principal, Tumbling Walls Consultancy
>> Tel/Direct: +1 617-431-6431
>> jlieberman@tumblingwalls.com
>>
>> On Sep 1, 2016, at 06:23, Ed Parsons <eparsons@google.com> wrote:
>>
>> Remember we are trying to illustrate best practice.. I think we are
>> someway away from being able to do this here.. unless of course we can
>> point to where data published using linear referencing is used by a
>> community on the web ?
>>
>> Ed
>>
>> On Thu, 1 Sep 2016, 10:51 Byron Cochrane, <bcochrane@linz.govt.nz> wrote:
>>
>>> Yes I agree it is a common practice.  That is why I suggested avoiding
>>> the term "fringe case" to describe this.
>>>
>>> However, if you want to do spatial analysis or combine these data with
>>> other data, the linear references need to be converted to x y z values in a
>>> stated CRS.
>>>
>>> Perhaps this is the type of guidance we need?
>>>
>>> Cheers,
>>> Byron
>>> ________________________________________
>>> From: Simon.Cox@csiro.au [Simon.Cox@csiro.au]
>>> Sent: Thursday, September 01, 2016 7:56 PM
>>> To: jeremy.tandy@gmail.com; frans.knibbe@geodan.nl;
>>> jlieberman@tumblingwalls.com
>>> Cc: eparsons@google.com; public-sdw-wg@w3.org
>>> Subject: RE: Request for help: BP 9 "How to describe relative positions"
>>>
>>> Or flightline, sounding, along a river, or even a walking tour …
>>> Plotting multiple variables along a trajectory is very common in
>>> practice.
>>>
>>> From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
>>> Sent: Thursday, 1 September 2016 4:51 PM
>>> To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>;
>>> frans.knibbe@geodan.nl; jlieberman@tumblingwalls.com
>>> Cc: eparsons@google.com; public-sdw-wg@w3.org
>>> Subject: Re: Request for help: BP 9 "How to describe relative positions"
>>>
>>> @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<mailto:
>>> 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<mailto:
>>> jlieberman@tumblingwalls.com>]
>>> Sent: Thursday, 1 September 2016 1:48 AM
>>> To: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
>>> Cc: Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>;
>>> Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>;
>>> Ed Parsons <eparsons@google.com<mailto:eparsons@google.com>>; SDW WG
>>> Public List <public-sdw-wg@w3.org<mailto: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
>>> <mailto:frans.knibbe@geodan.nl>> wrote:
>>>
>>>
>>>
>>> On 31 August 2016 at 15:19, Joshua Lieberman <
>>> jlieberman@tumblingwalls.com<mailto: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
>>> <mailto: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<mailto:
>>> 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<mailto: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<tel:%2B1%20617-431-6431
>>> <%2B1%20617-431-6431>>
>>> jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>
>>>
>>> On Aug 31, 2016, at 06:23, <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>
>>> <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
>>> Well you do see it in navigation systems. Time & distance.
>>>
>>> From: Ed Parsons [mailto:eparsons@google.com]
>>> Sent: Wednesday, 31 August 2016 7:49 PM
>>> To: Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>;
>>> SDW WG Public List <public-sdw-wg@w3.org<mailto: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
>>> <mailto: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<tel:%2B44%20%280%2920%207881%204501
>>> <%2B44%20%280%2920%207881%204501>>
>>> www.edparsons.com<http://www.edparsons.com/> @edparsons
>>>
>>>
>>>
>>>
>>>
>>> This message contains information, which may be in confidence and may be
>>> subject to legal privilege. If you are not the intended recipient, you must
>>> not peruse, use, disseminate, distribute or copy this message. If you have
>>> received this message in error, please notify us immediately (Phone 0800
>>> 665 463 or info@linz.govt.nz) and destroy the original message. LINZ
>>> accepts no responsibility for changes to this email, or for any
>>> attachments, after its transmission from LINZ. Thank You.
>>>
>> --
>>
>> *Ed Parsons *FRGS
>> Geospatial Technologist, Google
>>
>> Google Voice +44 (0)20 7881 4501
>> www.edparsons.com @edparsons
>>
>>
>>