RE: [SDWWG] CRS Issues, Issue-28

I agree with Kerry, Lars, Peter below.

I think allowing publishers to use an implied default CRS would lead to many misunderstandings for consumers (for data that pre-dates or doesn’t follow the best practice, or when WGS2024 or whatever comes along..), and we should aim to have publishers make the CRS explicit in the data or metadata.

To help consumers handle the cases where the CRS is not explicit, perhaps the requirement should be to provide guidance on which CRS to assume, and suggested methods to validate that assumption. In many cases the assumption could be WGS84 but this will depend on the data source, context, accuracy required etc.

(As another example of WGS84 not being safe to assume as the default: the working CRS for the UK offshore petroleum industry is ED50 east of and including 6 deg W ED50, and ETRF89 to the west of that line – the wonderfully named Thunderer Line. For consistency the industry uses an agreed set of transformations between ED50, ETRF89, OSGB36 and WGS84.  100s metres positional error in using the wrong CRS can be costly...)


From: Kerry Taylor []
Sent: 03 July 2015 14:49
To: SDW WG Public List
Subject: Re: [SDWWG] CRS Issues, Issue-28

I agree with Lars and Peter!  The notion of default is highly contextually dependent -- someone's sensible default is another's nightmare.

It seems to me that we are expecting ( at least where there is a geometry) spatial locations to to be described according to a vocabulary. Yes? Then all we need to do is to reuse the vocabulary namespace  ( which of course is also an http URI) as the identifier for a CRS.  This is just what the geo wgs84   does.

But won't this work very easily every time for everyone? every time wgs84:latitude is used the crs is explicit, and myfavourite:latitude or outofthisworld:somewhere is just as easy and well-defined.

The vocabulary itself can have as much or as little description of the CRS itself as is desired, minimally, it only needs to define the terms that are needed to describe a point in its model of space. but we could say more about what description should be given.

We could even consider adding terms like "near" into such a vocabulary as, potentially, the crs implies something about scale and resolution.  That is a question for another day.

If we agree on this, perhaps the same solution will also work for time.

This is a proposed solution, not a requirement which is the main question here.  But if this solution works then surely the requirement that CRS are mandatory becomes non- controversial, as if the best practice is followed  then by this solution it is not even possible to have a "default" crs.


On 2 Jul 2015, at 11:20 pm, "Svensson, Lars" <<>> wrote:
Just for the record:

+1 to the benefits of a default CRS, as long as any such default is well
documented and understood.

One problem with a default CRS is that if I publish data and don't specify a CRS (because the current default is correct for me) that works now. The moment some future WG decides that what we decided to be our default CRS is not accurate anymore and specifies a new default CRS, my data would be invalid (or at least partially incorrect) because it would be interpreted in context of the new default CRS. I understood from the comments yesterday that it is probably a corner case, so I won't push this any further.


Van: SDWWG [mailto:sdwwg-<>] Namens Ed
Parsons via SDWWG
Verzonden: donderdag 2 juli 2015 11:16
Aan: Peter Baumann; Bruce Bannerman; SDW WG Public List;<>
Onderwerp: Re: [SDWWG] CRS Issues [SEC=UNCLASSIFIED]

This issue addresses only how your reference the details of a CRS detailed at a
different location on the web. I think it is beyond our scope to define new
spatio-temporal CRS's.

As to the dangers of a default CRS, as long as any such default is well
documented and understood, there is great benefit. I look forward to continued
debate on this issue :-)


On Thu, 2 Jul 2015 at 09:55 Peter Baumann <<>>
+1 from my side, plus an extra issue:

it is pretty clear that today we need CRSs for height and time just as much as
we need it for Lat and Long. Technically IMHO this means we need to come up
CRSs being able to hold _all_ such axes. Having all these CRSs separate and
individual mechanisms is a nightmare. Therefore, I'd propose a

It must be possible in location information item (such as coordinates) to
express all spatio-temporal location information in one CRS. This implies that
CRSs can have a different number of dimensions, depending on the dimensions
captured (such as 1-D time, 2-D Lat/Long, 3-D Lat/Long/time or
or Lat/Long/Pressure, or 4-D Lat/Long/height/time).


On 07/01/15 23:34, Bruce Bannerman wrote:
Sorry that I was not able to participate in the call.

Two CRS issues:

_CRS Definition_

Most of the discussion to date on this thread appears to have related to just
horizontal CRS. Issues relating to both vertical and temporal CRS have also
been discussed in a number of emails.

Are these CRS also covered by 1. Below.

_Default CRS_

Issues relating to the assumption that data is based on a default CRS have
been raised from memory. For many use cases, this assumption can be quite
dangerous and can have unforeseen consequences.

See also my related post on 'misuse of spatial data'.

I'm trying to find some citable references that effectively illustrate the issue
of 'misuse', but have limited time. I'll keep going though, as this is an
important, but typically overlooked issue, as people just strive for a map as a
'pretty picture'.

I had sent around an example where an Austrian municipality publishes its
coordinates - without CRS. And the silently assumed CRS is not WGS84. So
locating this town under the assumption of WGS84 would lead you maybe into



From: Ed Parsons <<>>
Sent: Thursday, 2 July 2015 12:14 AM
To: SDW WG Public List;<>
Subject: CRS Issues

Thanks for you input everyone on the call today.. Here is where we stand on
the combined issues raised by Frans.

1)The CRS Definition

nts.html#CRSDefinition> currently in the UCR document should be rephrased.
This is what ISSUE-10<> is
about. The proposal for new wording is "There should be a recommended way
of referencing a CRS with a HTTP URI, and to get useful information about the
CRS when that URI is dereferenced."

Agreed and accepted slight modified wording removing "recommended".

2)In the course of discussing CRS requirements a new BP requirement was
introduced: Default
DefaultCRS>. No issues have been raised with regard to this requirement yet.

New issue created but not a new formal requirement.

3)In the course of discussing CRS requirements a possible new BP
requirement has come up. ISSUE-29 (Add a requirement for linking geometry to
CRS)<> was raised to enable
further discussion and/or decision-making.

Agreed a new requirement

4)Whether 'a recommend way' is the best expression to be used in
requirements is something that is discussed in the thread Use of the word
'standard' in the UCR document<


Agreed that the appropriate term should be "Advice", rather than
recommended way or standard, so the BP should offer Advice as needed.


Ed Parsons
Geospatial Technologist, Google
Mobile +44 (0)7825 382263<><> @edparsons

Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen<>
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)<>, mail:<>
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis
dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec
preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
Ed Parsons
Geospatial Technologist, Google
Mobile +44 (0)7825 382263<> @edparsons
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Received on Wednesday, 8 July 2015 10:48:54 UTC