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

Re: CRS Issues [SEC=UNCLASSIFIED]

From: Ed Parsons <eparsons@google.com>
Date: Thu, 02 Jul 2015 09:16:18 +0000
Message-ID: <CAHrFjcmSSHsY+hLimR6-B0gpjetnQhpqemkrE-3wyT-CLoeS5g@mail.gmail.com>
To: Peter Baumann <p.baumann@jacobs-university.de>, Bruce Bannerman <B.Bannerman@bom.gov.au>, SDW WG Public List <public-sdw-wg@w3.org>, "sdwwg@lists.opengeospatial.org" <SDWWG@lists.opengeospatial.org>
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 :-)


Ed


On Thu, 2 Jul 2015 at 09:55 Peter Baumann <p.baumann@jacobs-university.de>
wrote:

> +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 with
> CRSs being able to hold _all_ such axes. Having all these CRSs separate
> and with
> individual mechanisms is a nightmare. Therefore, I'd propose a
>
> Requirement:
> 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
> Lat/Long/height
> or Lat/Long/Pressure, or 4-D Lat/Long/height/time).
>
> Furthermore:
>
> 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
> the
> ocean.
>
> -Peter
>
> >
> > Bruce
> >
> >
> >
> > ________________________________
> > From: Ed Parsons <eparsons@google.com>
> > Sent: Thursday, 2 July 2015 12:14 AM
> > To: SDW WG Public List; sdwwg@lists.opengeospatial.org
> > 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 requirement<
> http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#CRSDefinition>
> currently in the UCR document should be rephrased. This is what ISSUE-10<
> https://www.w3.org/2015/spatial/track/issues/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 CRS<
> http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#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)<https://www.w3.org/2015/spatial/track/issues/29> 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<
> https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0211.html>.
> >
> > Agreed that the appropriate term should be "Advice", rather than
> recommended way or standard, so the BP should offer Advice as needed.
> >
> >
> > Ed
> >
> >
> > --
> > Ed Parsons
> > Geospatial Technologist, Google
> > Mobile +44 (0)7825 382263
> > www.edparsons.com<http://www.edparsons.com> @edparsons
> >
>
> --
> Dr. Peter Baumann
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
>    mail: p.baumann@jacobs-university.de
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>    www.rasdaman.com, mail: baumann@rasdaman.com
>    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
www.edparsons.com @edparsons
Received on Thursday, 2 July 2015 09:17:02 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 September 2016 12:03:04 UTC