RE: UCR ISSUE-70: add a requirement for avoiding coordinate transformations? [SEC=UNCLASSIFIED]

In our organisation, the Linz Data Service (LDS) generally deliveries all of our data in at least two different coordinate systems: WGS 84 (EPSG:4326) and New Zealand Transverse Mercator (NZTM).  The first support the use of these data in general mapping tools (Google Maps, OSM) the second supports most New Zealand centric systems.

Cheers,
Byron

From: Frans Knibbe [mailto:frans.knibbe@geodan.nl]
Sent: Tuesday, 6 September 2016 1:21 a.m.
To: Rob Atkinson
Cc: Bruce Bannerman; SDW WG Public List
Subject: Re: UCR ISSUE-70: add a requirement for avoiding coordinate transformations? [SEC=UNCLASSIFIED]

Hello Rob,

Indeed the UCR does not need cited practices, but the general idea is that the requirements listed there are based on the use cases that are in the same document. So if we identify a requirement that geometric data should have multiple CRSs, that requirement should in some way follow from at least one use case.

The examples you mention seem to be cases where it makes sense to use multiple CRSs, for consumer convenience. I imagine the BP document will recommend that data publishers use multiple CRSs, to meet the proposed requirement for avoiding coordinate transformations, and to meet the general good practice of allowing multiple consumer perspectives of web data. But if there are cases where publishing data with multiple CRSs is a hard rule that must be complied with it would be good to have them in the UCR document. And that would probably mean we have to formulate another requirement in the UCR doc, e.g. 'it must be possible to publish geometric data with multiple CRSs'.

Regards,
Frans

On 5 September 2016 at 14:40, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:

"I did not know that in some case multiple coordinate systems are required. Could you refer to a source for that? Perhaps it is a good idea to have such a requirement find a place in the list of use cases in the UC&R document."

My understanding is that the UCR doesnt need a cited practice - like BP might - so i'll just point out a few cases

Linear references (much discussed) have been pointed out to be a special case of multiple CRS.  A seat within a stadium might have a local map reference (J4) as well as a geographic location of the stadium.

Using "what 3 words" as a reference is just another case.

Technical data such as land survey often has its official data in terms of bearings and distances, since the precision required means such data has to be relative to a reference point that is likely to move with time due to plate tectonics :-)

And practice within the UK is to use Ordnance Survey references - and I suspect its a legal requirement for many cases (here's an example https://www.gov.uk/guidance/reservoirs-owner-and-operator-requirements) - but its still useful to have GPS equivalents.  I'm sure most jurisdictions have something similar.

Cheers
Rob

On Mon, 5 Sep 2016 at 19:35 Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:
Hi Rob,

In the current proposal (see the original thread<https://lists.w3.org/Archives/Public/public-sdw-wg/2016Sep/0067.html>) the main requirement is now a single sentence. It comes with an explanatory note:

Requirement: Data consumers should be helped in avoiding coordinate transformations when spatial data from multiple sources are combined.

NOTE:
When geometric data from different sources have no shared Coordinate Reference System (CRS), a data consumer will have to transform the coordinates of at least one data source to another CRS to spatially combine the data. Such a transformation takes time and could introduce errors in the output, so it is preferable to avoid it. Having multiple CRSs to choose from and different data publishers using common CRSs can help in avoiding coordinate transformations.

Is that OK with you?

I did not know that in some case multiple coordinate systems are required. Could you refer to a source for that? Perhaps it is a good idea to have such a requirement find a place in the list of use cases in the UC&R document.

Greetings,
Frans









On 5 September 2016 at 01:24, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:

I think you need to at least split the rationale (2nd sentence) from the requirement.

I would add a comment (not in the requirement itself) that in some cases multiple coordinate systems are in fact required and must include the highest fidelity version using CRS understood by the primary target audience, and a generally accessible CRS relevant to the widest possible community, WGS84 if relevant.

Rob

On Mon, 5 Sep 2016 at 07:05 Bruce Bannerman <B.Bannerman@bom.gov.au<mailto:B.Bannerman@bom.gov.au>> wrote:
Hi Frans,

I'm confused on this wording.

Does this mean that the CRS of all of the data sources to be combined should be ignored?

Bruce
________________________________
From: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
Sent: Thursday, 1 September 2016 1:52:48 AM
To: SDW WG Public List
Subject: Re: UCR ISSUE-70: add a requirement for avoiding coordinate transformations?

OK, time to take this a bit further. Here is a complete proposal for a new requirement. I hope it can make it to the version of the UC&R document that will be evaluated at and before TPAC.

Requirement: Data consumers should be helped in avoiding coordinate transformations when spatial data from multiple sources are combined.
When geometric data from different sources have no shared Coordinate Reference System (CRS), a data consumer will have to transform the coordinates of at least one data source to another CRS to spatially combine the data. Such a transformation takes time and could introduce errors in the output, so it is preferable to avoid it.

Related deliverable(s): Best Practices, Coverage in Linked Data

Related use cases:

Consuming Geographical Data In A Web Application
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#ConsumingGeographicalDataInAWebApplication>
Harvesting Local Search Content<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#HarvestingLocalSearchContent>
Enabling Publication, Discovery And Analysis Of Spatiotemporal Data In The Humanities<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#EnablingPublicationDiscoveryAndAnalysisOfSpatiotemporalDataInTheHumanities>
Using Spatial Data During Emergency Response Operations
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#UsingSpatialDataDuringEmergencyResponseOperations>
Combining Spatial RDF Data For Integrated Querying In A Triplestore<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#CombiningSpatialRDFDataForIntegratedQueryingInATriplestore>
Dutch Base Registry<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DutchBaseRegistry>
Bushfire Response Coordination Centre
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#BushfireResponseCoordinationCentre>
Marine Observations - Data Consumers<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MarineObservationsDataConsumers>
Crop Yield Estimation Using Multiple Satellites<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#CropYieldEstimationUsingMultipleSatellites>

Are there objections to putting it in the UC&R doc this way? If not, I will do it next week.

Thanks,
Frans




On 31 July 2016 at 10:53, Jon Blower <j.d.blower@reading.ac.uk<mailto:j.d.blower@reading.ac.uk>> wrote:
Hi Frank,

Fair enough, understood. My concern was that the original requirement might be a bit too vague, and implementers may be confused about what it really means in terms of implementation. But I don’t feel strongly about it – if others prefer your wording then it’s fine with me.

Best wishes,
Jon

From: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
Date: Friday, 29 July 2016 11:14
To: Jon Blower <sgs02jdb@reading.ac.uk<mailto:sgs02jdb@reading.ac.uk>>
Cc: Chris Little <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>>, SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>

Subject: Re: UCR ISSUE-70: add a requirement for avoiding coordinate transformations?

Hi Jon,

I try to phrase the requirements in such a way that meeting them is not steered in any direction, and to allow creative freedom in solving the problem. Of course in this case providing data with multiple CRSs meets the requirement, but I assume our deliverable editors are smart enough to be aware of that option. However, in this case having some kind of generally applicable common CRS and recommending its use could also be viewed as a solution to the problem. And perhaps there are more options...

Regards,
Frans



On 29 July 2016 at 11:59, Jon Blower <j.d.blower@reading.ac.uk<mailto:j.d.blower@reading.ac.uk>> wrote:
Hi Frans,

That seems reasonable to me. Another alternative might be to make it more specific:

“Data providers should provide their data in multiple coordinate reference systems, to assist consumers in using their data without further transformation”

Best wishes,
Jon

From: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
Date: Thursday, 28 July 2016 16:59
To: Chris Little <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>>, Jon Blower <sgs02jdb@reading.ac.uk<mailto:sgs02jdb@reading.ac.uk>>, SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>

Subject: Re: UCR ISSUE-70: add a requirement for avoiding coordinate transformations?

Thank you Jon and Chris, for confirming the sensibility of the candidate requirement.

Let's take it a step further and think about how the requirement could take form. Here is a proposal:

Requirement: "Data consumers should be helped in avoiding coordinate transformations when spatial data from multiple sources are combined"
Related delirables: Best Practices, Coverage in Linked Data

Could this work?

Regards,
Frans



On 26 July 2016 at 18:10, Little, Chris <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>> wrote:
Hi Frans,

Just to expand on your bullet point:

 *   more?
Surely, one class of requirements is to perform calculations on data to make realistic valid comparisons. E.g. areas, distances, bearings, stats. Not just visualisations on a map.

HTH, Chris

From: Jon Blower [mailto:j.d.blower@reading.ac.uk<mailto:j.d.blower@reading.ac.uk>]
Sent: Monday, July 25, 2016 4:39 PM
To: Frans Knibbe; SDW WG Public List
Subject: Re: UCR ISSUE-70: add a requirement for avoiding coordinate transformations?

Hi Frans,

Just to add a data point to this. In the Climate and Forecast conventions for NetCDF, it’s considered good practice to provide lat-lon coordinates even if the data are on a projected grid. (In other words, you should provide the projected coordinates, the projection parameters *and* the transformed lat-lon coordinates.)

The reason for this is that most client tools for NetCDF will understand lat-lon but won’t understand many map projections (although that situation is changing). There was some debate about this recommendation, because the information is redundant, but was thought to be sufficiently useful to allow the “no redundancy” rule to be bent.

It’s also worth pointing out that CF-NetCDF has a history in global simulation data, in which precise georeferencing is not a top priority (hence the “lat-lon” I’m talking about is actually a spherical lat-lon, not even WGS84). But recently there has been a shift towards using CF-NetCDF for “properly georeferenced” data, which has caused some lively debate!

So, in conclusion, I would say that your recommendation is sensible and has precedent. It’s probably worth highlighting the implications of the recommendation (i.e. the redundancy and the need to check consistency of the different expressions of the data).

In the coverage world, if we want to provide information with more than one CRS, that will probably mean we need to model them as different coverages, but link them somehow (maybe with an equivalent of “seeAlso”).

Cheers,
Jon

From: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
Date: Monday, 25 July 2016 16:19
To: SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Subject: UCR ISSUE-70: add a requirement for avoiding coordinate transformations?
Resent-From: <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Resent-Date: Monday, 25 July 2016 16:20

Hello all,

This message is to make a thread dedicated to ISSUE-70<https://www.w3.org/2015/spatial/track/issues/70>

The need to perform coordinate transformations occurs when spatial data (geometries and coverages) from different sources need to be combined and the data use different coordinate reference systems.

There can be several reasons for wanting to combine spatial data from different sources:

 *   visualisation in a desktop app or web app
 *   storage in a data store that is configured for a single CRS
 *   federated SPARQL queries
 *   more?
Coordinate transformations take time and could introduce errors in the output, so it is preferable to avoid them. A requirement could call for recommendations for publishing spatial data on the web in such a way that there is less chance of data consumers having to perform coordinate transformations.

Questions I would like to put to you:

 *   Is this a sensible requirement?
 *   To which deliverables should the requirement be related? Best Practices and Coverages too?
 *   Does the requirement follow from other use cases besides Combining Spatial RDF Data For Integrated Querying In A Triplestore<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#CombiningSpatialRDFDataForIntegratedQueryingInATriplestore>?
Regards,
Frans







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