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

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

From: Little, Chris <chris.little@metoffice.gov.uk>
Date: Tue, 26 Jul 2016 16:10:24 +0000
To: Jon Blower <j.d.blower@reading.ac.uk>, Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <3DAD8A5A545D7644A066C4F2E82072883E22879D@EXXCMPD1DAG4.cmpd1.metoffice.gov.uk>
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”).


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

Received on Tuesday, 26 July 2016 16:11:08 UTC

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