- From: Ed Parsons <eparsons@google.com>
- Date: Thu, 02 Jul 2015 09:16:18 +0000
- 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>
- Message-ID: <CAHrFjcmSSHsY+hLimR6-B0gpjetnQhpqemkrE-3wyT-CLoeS5g@mail.gmail.com>
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