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

> 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

Received on Tuesday, 26 May 2015 19:12:53 UTC