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

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