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

whilst I agree with this summary, it again raises the issue of attributes
of spatial properties.

in these cases illustrated he LR will be the most accurate location - and
therefore cartesian coords will be estimates derived from it.

So I think its fine to recommend providing equivalent data using a CRS but
critical that an estimate of the accuracy is provided (even if its just a
link to the linear feature representation directly or via a custom LRS)
 and the source LR position can be identified. This requires use of
canonical properties so these elements can be actually identified.

Are such properties direct (reuse of a specific vocabulary) or indirect
(requiring a client to access and interpret subProperty axioms?) -
personally I dont think forcing clients to use OWL logic is a sustainable
BP, however useful it is to underpin the back end of systems.

Rob


On Fri, 2 Sep 2016 at 07:12 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:

> 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
>>>
>>>
>>>