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

Re: [SDWWG] CRS Issues, Issue-28

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Wed, 22 Jul 2015 18:17:23 +0200
Message-ID: <CAFVDz415Y0Pd270=kJzRgCVXsPEF1an2V9N04Oa9U2rvygz8_Q@mail.gmail.com>
To: Simon Cox <Simon.Cox@csiro.au>
Cc: Ed Parsons <eparsons@google.com>, "Heaven, Rachel E." <reh@bgs.ac.uk>, SDW WG Public List <public-sdw-wg@w3.org>, Kerry Taylor <Kerry.Taylor@acm.org>, "Svensson, Lars" <L.Svensson@dnb.de>, Peter Baumann <p.baumann@jacobs-university.de>
2015-07-22 1:16 GMT+02:00 <Simon.Cox@csiro.au>:

>  I agree – in fact I suggest it is more or less essential that we
> recognize that there is a lot of geospatial data out there without an
> explicit CRS, for which some default must be interpolated, and the only
> plausible option is the one used by most consumer GPS devices.
>

What about other GNSS systems? To my knowledge, GLONASS and Galileo (BeiDou
probably too) use other CRSs than the GPS.

And does this mean that the purpose of a default CRS should be to assign a
CRS to data that already have been published? Things could go horribly
wrong in that case. I was thinking the default CRS is a construct mainly
for data that have yet to be published and that use some kind of vocabulary
that assumes a default CRS.


> If we don’t acknowledge this, we will exclude almost all GeoJSON services,
> for example. Whatever we think of the merits of the situation, that horse
> has probably already bolted.
>

Is GeoJSON a problem? Doesn't the specification itself say that CRS84 is
its default CRS?


>
>
> My comment was intended to steer people away from inventing a new model
> for describing CRS. It is a solved problem, so we just don’t need to spend
> time on that.
>

I think it could be needed, if only to accommodate non-geographical
coordinate reference systems and historical data.


> Furthermore, we also know that it is not possible to simplify CRS
> description further – axis names (semantics), axis order, units, datums,
> ellipsoid are all required (in order to support coordinate transformation,
> which is necessary for data comprehension and fusion).
>

Sometimes things like datums and ellipsoids just are not known and will be
very hard to derive from context. Coordinates like that could still be
useful. The main usabilty hit will be in precision, I think.

Regards,
Frans


>
> I agree with Kerry that it _*might*_ be useful to have a new encoding –
> compatible with semantic web technologies, to support some reasoning, but
> this should be a relatively trivial exercise. And also that, regardless of
> whether a new encoding is developed, for most applications the CRS
> identifier is enough, providing it is taken from a trusted source.
>
>
>
> Simon
>
>
>
> *From:* Ed Parsons [mailto:eparsons@google.com]
> *Sent:* Tuesday, 21 July 2015 8:53 PM
> *To:* Cox, Simon (L&W, Highett); frans.knibbe@geodan.nl; reh@bgs.ac.uk;
> public-sdw-wg@w3.org; Kerry.Taylor@acm.org; L.Svensson@dnb.de;
> p.baumann@jacobs-university.de
> *Subject:* Re: [SDWWG] CRS Issues, Issue-28
>
>
>
> For the vast majority of web users the intricacies of geodesy, the choice
> of datum and even project systems are not relevant, they want to take
> existing content and publish it in a way that maximises it's exposure and
> therefore it's use. App developers both mobile and web represent the other
> side of this process again wanting access to geospatial content from
> potentially multiple sources without writing more code that is necessary.
>
>
>
> We need to be able to replicate the simplicity of developing app's within
> the popular mobile platforms where adding location to apps is trivial
> because of the extensive use of simple defaults for data sharing between
> the underlying platform and apps, and between apps themselves.
>
>
>
> Ed
>
>
>
>
>
> On Tue, 21 Jul 2015 at 02:30 <Simon.Cox@csiro.au> wrote:
>
>  Frans – simplification is a noble idea, but there is a non-zero amount
> of complexity which must be managed. It is a question of who sees it. You
> make it easier on users only by pushing more work onto providers, or vice
> versa, but the work cannot be wished away.
>
>
>
> CRS definition is not trivial, and we should not pretend that it is. For
> example, reference systems are meaningless without datums. Geodesy is a
> significant discipline in its own right, and experience shows that
> grappling with the relationship between coordinates and coordinate
> reference systems is the thing that trips up geospatial newcomers most
> spectacularly.
>
>
>
> If you want to make it easy on users and even web developers, then you
> have to nail down all the options. That is unlikely to mean a simple
> definition. It is might mean a complex service with a simple API.
>
>
>
> Simon
>
>
>
> *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl]
> *Sent:* Tuesday, 21 July 2015 1:26 AM
> *To:* Heaven, Rachel E.; SDW WG Public List; Kerry Taylor; Svensson,
> Lars; Peter Baumann
>
>
> *Subject:* Re: [SDWWG] CRS Issues, Issue-28
>
>
>
> Hello,
>
>
>
> Not about the phrasing of the default CRS
> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DefaultCRS> requirement,
> but a thought on what a solution might look like:
>
>
>
> Would it help if there was a vocabulary that defines a very simple CRS,
> composed of latitude, longitude and elevation, without any reference to
> datums and such? Such definitions of longitude and latitude would be even
> more simple than the corresponding properties in the basic geo vocabulary
> <http://www.w3.org/2003/01/geo/wgs84_pos>, because that vocabulary
> assumes WGS84.
>
>
>
> Perhaps then longitudes and latitudes with WGS84 or ETRS89 or whatever
> datums could be seen as specialisations of the general concept of longitude
> and latitude. I think that in many current publications of (point)
> geometries that is exactly what is happening: there is a longitude and a
> latitude, but there is no idea of which specific geodetic CRS they are
> related to. It's just longitude and latitude. Probably that is also the way
> historic locations from before the age of geodesy should be handled.
> Longtitude and latitude were recorded before geodetic datums were invented.
>
>
>
> And perhaps such a simple set of definitions could also function well as a default
> CRS
> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DefaultCRS>
> .
>
>
>
> A logical consequence would be that there is a limit to the accuracy of
> the lon/lat numbers. For high precision coordinates one should make use of
> a more fully specified CRS (WGS84, ETRS89 or even a dynamic CRS). But still
> coordinates that are just longitude and latitude are useful for various
> purposes and could be made to be interoperable with more thoroughly defined
> geometries.
>
>
>
> Regards,
>
> Frans
>
>
>
> 2015-07-08 12:48 GMT+02:00 Heaven, Rachel E. <reh@bgs.ac.uk>:
>
>  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...)
>
>
>
> Rachel
>
>
>
>
>
> *From:* Kerry Taylor [mailto:Kerry.Taylor@acm.org]
> *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  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#
> <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
>
>     ------------------------------
>
> 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.
>  ------------------------------
>
>
>
>
>
> --
>
> Frans Knibbe
>
> Geodan
>
> President Kennedylaan 1
>
> 1079 MB Amsterdam (NL)
>
>
>
> T +31 (0)20 - 5711 347
>
> E frans.knibbe@geodan.nl
>
> www.geodan.nl
>
> disclaimer <http://www.geodan.nl/disclaimer>
>
>
>
>  --
>
>
> *Ed Parsons *Geospatial Technologist, Google
>
> Mobile +44 (0)7825 382263
> www.edparsons.com @edparsons
>



-- 
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl
disclaimer <http://www.geodan.nl/disclaimer>
Received on Wednesday, 22 July 2015 16:17:54 UTC

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