Re: [SDWWG] CRS Issues, Issue-28

I agree completely about the importance of context, but we may ( after much
heated debate I'm sure) choose to restrict the context to mainstream
applications of simple geospatial content on this planet, e.g. those use
cases currently using WGS84 based CRS's. A default here would make sense ?

Ed

On Fri, 3 Jul 2015 at 14:54 Kerry Taylor <Kerry.Taylor@acm.org> wrote:

> 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  http://www.w3.org/2003/01/geo/   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.
>
> Kerry
>
>
>
> On 2 Jul 2015, at 11:20 pm, "Svensson, Lars" <L.Svensson@dnb.de> 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.
>
> /Lars
>
>
> Van: SDWWG [mailto:sdwwg-
>
> bounces+l.vandenbrink=geonovum.nl@lists.opengeospatial.org] Namens Ed
>
> Parsons via SDWWG
>
> Verzonden: donderdag 2 juli 2015 11:16
>
> Aan: Peter Baumann; Bruce Bannerman; SDW WG Public List;
>
> sdwwg@lists.opengeospatial.org
>
> 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 :-)
>
>
>
> 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/SDWUseCasesAndRequireme
>
> nts.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
>
> --


*Ed Parsons* Geospatial Technologist, Google

Mobile +44 (0)7825 382263
www.edparsons.com @edparsons