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

Hi -

as BP editor (& working group participant) I support this requirement in
principle - but am unable to contribute to suitable wording as I am trying
to focus on the BP doc :-)

Jeremy

On Thu, 1 Sep 2016 at 12:32 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
>
>
>
>
>
>
>
>
>