Re: UCR issue: phrasing of CRS requirement(s)

Describing CRS attributes is a "can of worms" for is, I would rather we
just point to the EPSG repository for simplicity. Perhaps we could in the
BP point out a few well used CRS and their EPSG descriptions.

Ed

Ed Parsons
Geospatial Technologist, Google

Mobile: +44 (0)7825 382263
www.edparsons.com @edparsons
On 27 May 2015 13:49, "Frans Knibbe" <frans.knibbe@geodan.nl> wrote:

> Hello all,
>
> It is nice to see a good discussion with lots of outside references and
> proposals for meeting the requirements. But I would like to get back to the
> issue of phrasing the requirements.
>
> Linda was right in noting that the requirement for a default or canonical
> has not been listed in the UCR document yet. I will add it. It will be very
> interesting to see if we can succeed in finding such a CRS. But that is
> something that will become clear when we work on the Best Practices.
>
> As for the phrasing of the CRS requirement, I would like to propose the
> following:
>
> "There should be a standard for publishing data about coordinate reference
> systems (CRS). It should be applicable to any 2D or 3D CRS, not only
> geographical reference systems. CRS descriptions should be referencable by
> HTTP URIs."
>
> I think that given the context of this WG (spatial data on the web), the
> requirement that things should be referencable goes without saying, but I
> have made it explicit nonetheless.
>
> I should note that when put this way, there is no requirement for having a
> registry of CRSs - anyone can publish a CRS defintion anywhere.
>
> Would it be sensible to add some information about what kind of data we
> would expect when a CRS is described? There could be a need for having
> complete descriptions that allow automatic coordinate transformation. Or we
> could try to list a few CRS attributes that we consider essential for
> common usage (like axis order, units, whether it is spherical or flat
> plane, spatial coverage....)
>
> Greetings,
> Frans
>
>
> 2015-05-26 21:12 GMT+02:00 Krzysztof Janowicz <janowicz@ucsb.edu>:
>
>> Krzysztof, why is Java such a hot bed of linked data?!?
>>>
>>
>> Good question. If you look at the detailed map here
>> http://stko.geog.ucsb.edu/pictures/lstd_map.png you will see massive
>> data errors. Based on our 14+ million sample, it looks like about 10% of
>> all linked geographic data has some issues related to it. In many cases
>> those issues were systematic and we notified the data providers, e.g.,
>> DBpedia. For instance, the dense block-like areas in China are in fact
>> places from the US east coast. I will look into the data from Java and will
>> let you know if I find something interesting.
>>
>> Anyway, the systematic list of errors may turn out to be useful for our
>> sdw group as it illustrates what typically goes wrong.
>>
>> Best,
>> Krzysztof
>>
>>
>>
>>
>> On 05/18/2015 07:39 AM, Kerry.Taylor@csiro.au wrote:
>>
>>> WGS84 is certainly widely used for linked data in practice, probably
>>> heavily influenced by this http://www.w3.org/2003/01/geo/, commonly
>>> called "geo".
>>>
>>> Oddly, perhaps, schema.org seems not to care about CRS at all:
>>> http://schema.org/GeoCoordinates
>>>
>>> Can we take inspiration from the former one  (geo)  and admit
>>> alternative CRSs that must be identified by virtue of the ontology (and
>>> therefore namespace, assuming a 1-1 relationship) that is used?  We could
>>> perhaps develop a couple ourselves (perhaps a WGS84-like one, and another
>>> for a relative 3D system), and then allow any other to be used by virtue of
>>> reference to the intended vocabulary (as our best practice advice)?
>>>
>>> Maybe this is a cop-out but it is a way of dealing with the common cases
>>> blindly, yet requiring a CRS to be implicitly identified, and also enabling
>>> the use of more complex or niche CRS whenever needed. We won't stop people
>>> making mistakes, whatever we do.
>>>
>>> This could do for  *referencing* a  CRS without ever needing a
>>> "default". For the *description" of a CRS, I would vote to defer that to
>>> the OGC by its existing methods, and I see no reason why that description
>>> needs to have a linked data representation,  beyond an ontology that
>>> permits its use.
>>>
>>>
>>>
>>>
>>> Krzysztof, why is Java such a hot bed of linked data?!?
>>>
>>> Kerry
>>>
>>>
>>>  -----Original Message-----
>>>> From: Svensson, Lars [mailto:L.Svensson@dnb.de]
>>>> Sent: Monday, 18 May 2015 9:44 PM
>>>> To: Ed Parsons; janowicz@ucsb.edu
>>>> Cc: SDW WG Public List
>>>> Subject: RE: UCR issue: phrasing of CRS requirement(s)
>>>>
>>>> On Monday, May 18, 2015 12:24 PM, Ed Parsons wrote:
>>>>
>>>>  In most cases I don't think they actually do mean WGS84 as in the
>>>>> ellipsoid and datum.
>>>>>
>>>>> I would guess it is usually shorthand for the the full spatial
>>>>> reference system defined by EPSG4326 or more likely on the web
>>>>> EPSG:3857
>>>>>
>>>> My fear is that in some cases the data providers don't really know what
>>>> their coordinates mean in terms of ellipsoid, datum and reference
>>>> system. They have some coordinates taken from geonames, Wikipedia or
>>>> some other source and haven’t really thought of that (geographic)
>>>> coordinates are not just coordinates but that there is a context to
>>>> that, too. To what extent we can assume that they mean CRS84, I don't
>>>> know.
>>>>
>>>> So I think I'm on the same page as Linda on this.
>>>>
>>>> Best,
>>>>
>>>> Lars
>>>>
>>>>  On 16 May 2015 at 04:02, Krzysztof Janowicz <janowicz@ucsb.edu>
>>>>>
>>>> wrote:
>>>>
>>>>> right, so how can they be sure they mean WGS84?
>>>>>
>>>>> Here is a funny example how this can go wrong and went wrong in the
>>>>>
>>>> past:
>>>>
>>>>> http://stko.geog.ucsb.edu/location_linked_data (See the Copernicus
>>>>> crater)
>>>>>
>>>>> Best,
>>>>> Krzysztof
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 05/15/2015 04: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.
>>>>> 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
>>>>> www.geodan.nl
>>>>> disclaimer
>>>>>
>>>>>
>>>>> --
>>>>> 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)
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Krzysztof Janowicz
>>>>>
>>>>> Geography Department, University of California, Santa Barbara
>>>>> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>>>>>
>>>>> Email: jano@geog.ucsb.edu
>>>>> Webpage: http://geog.ucsb.edu/~jano/
>>>>> Semantic Web Journal: http://www.semantic-web-journal.net
>>>>>
>>>>
>>
>> --
>> Krzysztof Janowicz
>>
>> Geography Department, University of California, Santa Barbara
>> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>>
>> Email: jano@geog.ucsb.edu
>> Webpage: http://geog.ucsb.edu/~jano/
>> Semantic Web Journal: http://www.semantic-web-journal.net
>>
>>
>>
>
>
> --
> 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>
>
>