W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

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

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Fri, 2 Sep 2016 16:05:33 +0200
Message-ID: <CAFVDz43-_6ZshX4qXu=Tp5iH=mLpHcKR5t3P0hvn8FnhTCpucA@mail.gmail.com>
To: Jon Blower <j.d.blower@reading.ac.uk>
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Ok, here is a revised proposal based on Jon's comments. I have added the
possible solutions as examples and I have placed the whole explanatory text
in a note, in line with the general style of requirements being a single
line with possibly an additional note or list of examples.

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

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


Regards,
Frans

On 2 September 2016 at 15:24, Jon Blower <j.d.blower@reading.ac.uk> wrote:

> Hi Frans,
>
>
>
> It might be just me, and I certainly don’t feel strongly about this, but I
> was just left with a feeling of “dangling” at the end of the text, and I
> wasn’t sure if the “call to action” was clear. Personally I would be happy
> with a wording that is essentially the same as yours, but suggested one or
> two possible approaches – providing it’s clear that we’re not prescribing
> these as the only solutions.
>
>
>
> Best wishes,
> Jon
>
>
>
> *From: *Frans Knibbe <frans.knibbe@geodan.nl>
> *Date: *Friday, 2 September 2016 14:08
> *To: *Jon Blower <sgs02jdb@reading.ac.uk>
> *Cc: *SDW WG Public List <public-sdw-wg@w3.org>
>
> *Subject: *Re: UCR ISSUE-70: add a requirement for avoiding coordinate
> transformations?
>
>
>
> Hi Jon,
>
>
>
> I did try to elaborate the requirement a bit to clarify what is meant. You
> don't think it is enough? It seems to me that at least the people that need
> to try to meet this requirement, i.e. our BP and Coverage people, will
> understand what it is about.
>
>
>
> In this case, I think there could be more than one way to meet the
> requirement:
>
>    1. Provide as many CRSs as possible
>    2. Provide data with a very general CRS
>
> But as a matter of principle I would not want to assume that the solutions
> that I can think of are the only possibilities. That said, I don't think it
> will hurt much if we mention a possible solution as an example, relying on
> the power of independent thought of the deliverable editors.
>
>
>
> Regards,
>
> Frans
>
>
>
> On 1 September 2016 at 13:30, Jon Blower <j.d.blower@reading.ac.uk> wrote:
>
> Hi Frans,
>
>
>
> I think this looks good in principle. My only doubt is that I’m not sure
> people will know what it is getting at. I know that you don’t want to
> prescribe a particular solution, and in general I think that’s a good goal.
> But in this case, is there any logical conclusion to this other than for
> data providers to provide data in multiple CRSs? What other action could
> someone take to implement this?
>
>
>
> If there is only one logical conclusion from this recommendation then we
> might as well state it explicitly IMHO, even if only as an example.
>
>
>
> Cheers,
> Jon
>
>
>
>
>
>
>
> *From: *Frans Knibbe <frans.knibbe@geodan.nl>
> *Date: *Wednesday, 31 August 2016 16:52
> *To: *SDW WG Public List <public-sdw-wg@w3.org>
> *Subject: *Re: UCR ISSUE-70: add a requirement for avoiding coordinate
> transformations?
> *Resent-From: *<public-sdw-wg@w3.org>
> *Resent-Date: *Wednesday, 31 August 2016 16:53
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
Received on Friday, 2 September 2016 14:06:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:25 UTC