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

The one exception to this I can think of is classification of CRS’, particularly going into non-geocentric varieties. It can often be useful to learn what are “similar” CRS’ / projections / datums / geodes / etc. and that isn’t very easy right now.

-Josh

> On May 18, 2015, at 5:56 PM, <Simon.Cox@csiro.au> <Simon.Cox@csiro.au> wrote:
> 
>> 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.
>  
> Thanks Kerry - that's essentially the way I see it, if by "linked data representation" you are implying RDF. I would like to ask those people advocating a new CRS encoding in RDF, what this would be useful for? The main use for a CRS _description_ (as opposed to denotation) is to support _coordinate transformation_, which is a very mathematical operation. Not really what RDF is good at. I can't think of a compelling _reasoning_ application for CRS. Let's not get carried away with RDF applications. There are boundaries past which reasoning/RDF are not the main application, so we should try not to step over them. 
> 
> Simon
> 
> 
> -----Original Message-----
> From: Kerry.Taylor@csiro.au [mailto:Kerry.Taylor@csiro.au] 
> Sent: Tuesday, 19 May 2015 12:40 AM
> To: L.Svensson@dnb.de; eparsons@google.com; janowicz@ucsb.edu
> Cc: public-sdw-wg@w3.org
> Subject: [ExternalEmail] RE: UCR issue: phrasing of CRS requirement(s)
> 
> 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
>

Received on Monday, 18 May 2015 22:02:10 UTC