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

So i think the requirement is clear... i agree with Frans that it probably
a good idea to have the requirement explicit. We can then tie the two
concerns as related.. and i would suggest its a requirement that
implementations reuse the same mechanism for both cases.

Lets us Byron's clear example as a Use Case if we feel we need something
more explicit?

Rob

On Tue, 6 Sep 2016, 7:21 AM Byron Cochrane <bcochrane@linz.govt.nz> wrote:

> 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> 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> 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> 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>
> 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>
> *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> 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>
> *Date: *Friday, 29 July 2016 11:14
> *To: *Jon Blower <sgs02jdb@reading.ac.uk>
> *Cc: *Chris Little <chris.little@metoffice.gov.uk>, SDW WG Public List <
> 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> 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>
> *Date: *Thursday, 28 July 2016 16:59
> *To: *Chris Little <chris.little@metoffice.gov.uk>, Jon Blower <
> sgs02jdb@reading.ac.uk>, SDW WG Public List <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>
> 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]
> *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>
> *Date: *Monday, 25 July 2016 16:19
> *To: *SDW WG Public List <public-sdw-wg@w3.org>
> *Subject: *UCR ISSUE-70: add a requirement for avoiding coordinate
> transformations?
> *Resent-From: *<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.
>