- From: Peter Baumann <p.baumann@jacobs-university.de>
- Date: Fri, 15 May 2015 15:50:45 +0200
- To: matthew perry <matthew.perry@oracle.com>, <public-sdw-wg@w3.org>
- Message-ID: <5555F9B5.8080607@jacobs-university.de>
Matt-
I see, so the axis order problem seems to have gone, which is great.
Somehow I do not understand why providing a CRS is a burden - the application
composing RDF does not have to show it to the user on the other side of the
screen glass, but can silently add a triple.
But that is not so much my issue anyway. Once such a convention is in place and
followed it will work. I am concerned about data that do not (yet) adhere to the
default, and there is no way for a machine to detect this. Without such a
default a reasonser could detect that "CRS is unknown" and maybe even deduce it
then from context in some cases ("this dataset is from Europe, so it is lkely
ETRS89. The topic talks about Monaco, and the coordinates, interpreted as ETRS89
point there, so I assume CRS=ETRS89").
-Peter
On 05/15/15 15:42, matthew perry wrote:
> Peter,
>
> Let me rephrase that statement to "the vast majority of spatial data available
> *as RDF* on the web uses WGS 84."
>
> For the axis order problem, W3C basic geo encodes latitude and longitude as
> separate properties, so there is no issue there. GeoSPARQL covers it with the
> next requirement:
>
> /Req 12 Coordinate tuples within geo:wktLiterals shall be interpreted using
> the axis order defined in the spatial reference system used//./
>
> I think one of the key aspects here is that the default is needed only when a
> CRS is not explicitly specified. This in no way prevents expert users from
> publishing data with any CRS they want, but non-expert users can publish
> lat-long point data from their smartphone without needing to understand the
> difference between NAD83 and WGS84.
>
> Cheers,
> Matt
>
>
> On 5/15/2015 9:26 AM, Peter Baumann wrote:
>>
>>
>> On 05/15/15 14:41, matthew perry wrote:
>>> With OGC GeoSPARQL, we had the same discussion about a default CRS and chose
>>> to define WGS84 long-lat as the default. The main motivation being that we
>>> wanted to keep things simple for the non-expert user and the fact that the
>>> vast majority of spatial data on the web is encoded with this CRS.
>>
>> not sure about this.
>> For example, ETRS89 is used widely in Europe. Here an example for coordinates
>> on a web page where only a few clicks later you learn that the CRS is ETRS89:
>> http://www.unterpremstaetten.at/cms/index.php/unsere-gemeinde/geografische-laenge-und-breite.html
>>
>> ...and what about time? elevation? It is fun talking to ocean experts about
>> what "mean sea level" is.
>>
>> BTW, earlier in this thread the Lat/Long vs Long/Lat issue (ie, axis order in
>> coordinates) has been mentioned. Recent specs, like the OGC Coverage model
>> [09-146r2] don't have that any more because they explicitly specify axis
>> order. An opportunity for W3C to get it right from the start and benefit from
>> learning curves made.
>>
>> cheers,
>> Peter
>>
>>
>>
>>> Most of the ogc:wktLiteral data I have seen on the web has used the default
>>> CRS (i.e., there is no explicit CRS given). W3C Basic Geo vocabulary also
>>> assumes WGS84.
>>>
>>> Cheers,
>>> Matt
>>>
>>> *wtkLiteral definition:*/
>>> Req 10 All RDFS Literals of type geo:wktLiteral shall consist of an optional
>>> URI identifying the coordinate reference system followed by Simple Features
>>> Well Known Text (WKT) describing a geometric value. Valid geo:wktLiterals
>>> are formed by concatenating a valid, absolute URI as defined in [RFC 2396],
>>> one or more spaces (Unicode U+0020 character) as a separator, and a WKT
>>> string as defined in Simple Features [ISO 19125-1].//
>>> //
>>> //For geo:wktLiterals, the beginning URI identifies the spatial reference
>>> system for the geometry. The OGC maintains a set of CRS URIs under the
>>> http://www.opengis.net/def/crs/ namespace. This leading spatial reference
>>> system URI is optional. In the absence of a leading spatial reference system
>>> URI, the following spatial reference system URI will be assumed:
>>> <http://www.opengis.net/def/crs/OGC/1.3/CRS84> This URI denotes WGS 84
>>> longitude-latitude.//
>>> //
>>> //Req 11 The URI <http://www.opengis.net/def/crs/OGC/1.3/CRS84> shall be
>>> assumed as the spatial reference system for geo:wktLiterals that do not
>>> specify an explicit spatial reference system URI.//
>>> /
>>>
>>> On 5/15/2015 8:03 AM, Joshua Lieberman wrote:
>>>> The vivid discussion that Linda references really had only one conclusion,
>>>> that is to tell the truth about the coordinate reference system being used
>>>> and make sure others can find out what it is. There will continue to be an
>>>> issue as long as geodesy insists on {lat, long} from history and the Web
>>>> insists on {long, lat} from computer graphics (at least it didn't get
>>>> fixated on {long, (-lat)}). I don't even think that we can assume that CRS
>>>> descriptions can all be the same when dealing with the possibility of
>>>> non-geocentric, non-inertial, and non-orthogonal systems.
>>>>
>>>> Positioning technology is also reaching the accuracy where datums are
>>>> becoming significantly time or even event dependent (e.g. before and after
>>>> fault movement in an earthquake). That said, 90% of current spatial data is
>>>> probably stored in WGS84 {long, lat} with whatever geoid was being used by
>>>> the GPS that day. So we should make that as simple yet transparent as
>>>> possible to convey.
>>>>
>>>> All we have to do is standardize honesty.
>>>>
>>>> Josh
>>>>
>>>> Joshua Lieberman, Ph.D.
>>>> Interoperability Engineering Without Barriers
>>>> jlieberman*at*tumblingwalls*dot*com
>>>> +1 (617) 431-6431
>>>>
>>>> On May 15, 2015, at 07:37, Ashok Malhotra <ashok.malhotra@oracle.com
>>>> <mailto:ashok.malhotra@oracle.com>> wrote:
>>>>
>>>>> Or you could add metadata indicating which coordinate system was used.
>>>>> All the best, Ashok
>>>>>
>>>>> On 5/15/2015 7:27 AM, Peter Baumann wrote:
>>>>>> right, so how can they be sure they mean WGS84? if I copy-past
>>>>>> coordinates from web info about Germany then in the past this used to be
>>>>>> Gauss-Krüger, and several strips = sub-systems. Now let's talk about
>>>>>> height and SI vs imperial units etc - what default could we agree on?
>>>>>>
>>>>>> With a default, all coordinate info out there on the Web (flat,
>>>>>> height/depth, time, pressure, ...) will often be interpreted wrongly.
>>>>>> IMHO we should rather encourage, for m2m communication, that we achieve
>>>>>> informational completeness.
>>>>>>
>>>>>> my 2 cents,
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> On 05/15/15 13:21, Linda van den Brink wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OK, that could be the consensus within OGC, but the GeoJSON spec does
>>>>>>> describe a default CRS and I can understand this very well. Non-experts,
>>>>>>> i.e. people from outside the geospatial domain who are using or want to
>>>>>>> use geospatial data, often have no idea that there even **are** multiple
>>>>>>> coordinate reference systems.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Linda
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Van:*Peter Baumann [mailto:p.baumann@jacobs-university.de]
>>>>>>> *Verzonden:* vrijdag 15 mei 2015 13:01
>>>>>>> *Aan:* Linda van den Brink; Frans Knibbe; SDW WG (public-sdw-wg@w3.org)
>>>>>>> *Onderwerp:* Re: UCR issue: phrasing of CRS requirement(s)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> FYI, there has been a vivid discussion in OGC on default CRSs on the
>>>>>>> occasion of JSON coming up with such an idea, and OGC very much and
>>>>>>> strongly agreed that this is not a good idea.
>>>>>>>
>>>>>>> In general, a coordinate tuple should have exactly one CRS referenced
>>>>>>> which may include
>>>>>>> - spatial horizontal (such as Lat/Long)
>>>>>>> - time (possibly using different calendars)
>>>>>>> - elevation
>>>>>>> - anything else (eg, atmospheric sciences like to use pressure as a
>>>>>>> proxy for height)
>>>>>>> - finally, planetary CRSs are more and more coming into play as well.
>>>>>>> I sense that this is very much in alignment with the ideas that we are
>>>>>>> discussing here.
>>>>>>>
>>>>>>> OTOH, it is indeed important to have one common mechanism of describing
>>>>>>> CRSs. As mentioned earlier, OGC has such mechanisms in place through CRS
>>>>>>> WKT plus the CRS Name Type Specification (maybe quite misleading in its
>>>>>>> title, it allows to describe CRSs by composing them from other ones,
>>>>>>> such as flatland + time, flatland + pressure, flatland + depth, flatland
>>>>>>> + geological time).
>>>>>>>
>>>>>>> So definitely supporting Linda's observation on referencing vs describing.
>>>>>>>
>>>>>>> -Peter
>>>>>>>
>>>>>>>
>>>>>>> On 05/15/15 09:40, Linda van den Brink wrote:
>>>>>>>
>>>>>>> Hi Frans,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I noticed that a requirement related to this is in the spreadsheet
>>>>>>> but not (yet?) in the UCR document. It is this requirement:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> “There should be a default CRS that is assumed when nog CRS is
>>>>>>> specified” (s/nog/no)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> WGS84/lat lng is the de facto standard CRS for spatial data on the
>>>>>>> web. Both publishing and using spatial data on the web should be
>>>>>>> easy for non-experts, so this requirement of having a default CRS
>>>>>>> makes a lot of sense to me. The most common cases become more easy
>>>>>>> that way. I think this should be added to par. 5.6 of the UCR.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In this light (i.e. usability for non-expert users), the best
>>>>>>> practice should have information about how data owners should
>>>>>>> describe, how users can recognize and what tools they can use to
>>>>>>> transform non-WGS84 coordinate systems to the coordinate system they
>>>>>>> need.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> A second point I’d like to make is that CRS should be suitable also
>>>>>>> for non-geographical reference systems (for non-Earth oriented
>>>>>>> applications).I think this is covered by 5.14, but the text of that
>>>>>>> paragraph is not completely clear to me. )“Standards for spatial
>>>>>>> data on the web should be independent on the reference systems that
>>>>>>> are used for data.”)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Finally, to answer the question in the issue, as I read it, req A is
>>>>>>> not replaceable by req B. Req A is about **referencing** a CRS,
>>>>>>> while req B is about **describing** a CRS – i.e. the description you
>>>>>>> get about the CRS when you dereference a CRS reference.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Linda
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Van:*Frans Knibbe [mailto:frans.knibbe@geodan.nl]
>>>>>>> *Verzonden:* woensdag 13 mei 2015 14:20
>>>>>>> *Aan:* SDW WG Public List
>>>>>>> *Onderwerp:* UCR issue: phrasing of CRS requirement(s)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I have raised an issue for the UCR document: ISSUE-10
>>>>>>> <http://www.w3.org/2015/spatial/track/issues/10>.
>>>>>>>
>>>>>>> All help in getting this issue resolved is very welcome.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Frans
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Frans Knibbe
>>>>>>>
>>>>>>> Geodan
>>>>>>>
>>>>>>> President Kennedylaan 1
>>>>>>>
>>>>>>> 1079 MB Amsterdam (NL)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> T +31 (0)20 - 5711 347
>>>>>>>
>>>>>>> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
>>>>>>>
>>>>>>> www.geodan.nl <http://www.geodan.nl>
>>>>>>>
>>>>>>> disclaimer <http://www.geodan.nl/disclaimer>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Dr. Peter Baumann
>>>>>>> - Professor of Computer Science, Jacobs University Bremen
>>>>>>> www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>>>>>> mail: p.baumann@jacobs-university.de <mailto: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 <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto: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)
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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)
>>>>>>
>>>>>>
>>>>>
>>>
>>
>> --
>> 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)
>>
>>
>
--
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)
Received on Friday, 15 May 2015 13:52:08 UTC