Re: Geo in RDF (was Re: Censorship?)

Hi Stuart

Sorry for my late reply.

On 16/11/2010 12:21, Stuart Williams wrote:
> Hello Boris,
>
> On 15/11/2010 23:51, Boris Villazón Terrazas wrote:
>> Hi Stuart, all
>>
>> On 15/11/2010 15:26, Stuart Williams wrote:
>>> Hello Boris,
>>>
>>> On 13/11/2010 15:11, Boris Villazón Terrazas wrote:
>>>> I only want to point out our ongoing work in the context of the 
>>>> GeoLinkedData [1], in which  we are working with geospatial data. 
>>>> Basically, we are using geo:lat/geo:long style of giving position 
>>>> in WGS84 coordinates. A geospatial resource, for example a 
>>>> geoes:Provincia, has a geo:geometry, and this geo:geometry consists 
>>>> of a set of geo:points , and each geo:point consists of geo:lat and 
>>>> geo:long. You can find a figure describing this at [2].
>>> I've got a minor question wrt to the use of geoes:order in the 
>>> diagram at [2]. It seems to be giving the ordinal position of a 
>>> Point in a LineString. It seems to me that there isn't a single 
>>> value of geoes:order which applies to a given point... it depends on 
>>> what LineString the point is being included in.
>> We use the order for drawing the lines on the map, and we need to do 
>> it in the right order. So, first, line from Point(x1,y1) to Point 
>> (x2,y2), then line from Point(x2,y2) to Point(x3,y3) and so on.
>> That's why we use the geoes:order
> I think I understand the intention. My question really is how you use 
> the same point in multiple curves - for example where two regions 
> touch and share a common segment of their respective boundaries. For 
> example reveals a number of points with more than one value for 
> geoes:order:
>
>     select distinct ?point ?order1 ?order2  where
>     { ?point a <http://www.w3.org/2003/01/geo/wgs84_pos#Point>;
>     <http://geo.linkeddata.es/ontology/orden> ?order1 ;
>     <http://geo.linkeddata.es/ontology/orden> ?order2 .
>       FILTER(?order1 < ?order2)
>     } ORDER BY ?point ?order1 ?order2
>
> e.g.:
> http://geo.linkeddata.es/resource/wgs84/38.11124666521918_-2.519757266504941
>
> Maybe that's intentional, its just that order within a linestring 
> doesn't seem to me to be an invariant property of a point, more of its 
> 'use' in defining a curve.

Very good point, we realized this issue in the last few weeks.
We need to restructure the model.
>
>>>> A specific example, the resource Albacete Provincia at [3].
>>>> Also, we have a browser at [4].
>>>>
>>>> I think this is related with the discussion.
>>>> We can provide further information regarding the conversion from 
>>>> GML to RDF we performed.
>>>
>>> I think that the details of your conversion are fairly clear in your 
>>> presentation at http://www.slideshare.net/boricles/geo-upmv14boris
>> Basically, the information from the Spanish Geographical Institute 
>> are stored in Oracle 11 databases, and the geometry information in a 
>> blob column.
>> We use the Oracle STO Util package [X]  for transforming the blob 
>> column value into GML.
>> Then, we use GeoTools [Y] and Jena [Z] for converting GML into RDF 
>> following the model described in the diagram at [2]
>>>
>>> What I am looking for is a *widely* adopted practice, perferably 
>>> backed/endorsed by a defacto or de-jure standards organisation. I 
>>> don't think I have found such a beast except for the case of Point 
>>> positions expressed as WGS 84 lat/long in which case there is 
>>> widespread community practice in the use of the "Basic Geo (WGS84 
>>> lat/long) Vocabulary" [a].
>>> [a] http://www.w3.org/2003/01/geo/
>>>
>> Our geometry points are compliant to geo: 
>> http://www.w3.org/2003/01/geo/wgs84_pos#
> Yes, I can see that for points expressed in WGS 84. I happen to have 
> some data that expresses points as ETRS89 lat/long(i.e. with a datum 
> fixed to continental Europe). In truth for my application the 
> difference between ETRS89 and WGS 84 doesn't really matter - ~2.5cm 
> per year continental drift. However, ideally I would like to express 
> them as being ETRS89 which conveys (at least some level of) invariance 
> over time within Europe. Yes, being pragmatic, I can express them as 
> WGS 84 and maybe be as much as 25cm adrift by now - and in this 
> particular case that's good enough for most/all practical purposes... 
> but...
>>> For curves (LineStrings), surfaces(Polygons) and  Boxes (Envelopes), 
>>> the Geo OWL vocabulary at [b,c] which mirrors GeoRSS GML [d] seems 
>>> to me to come close to being something that a common practice might 
>>> develop around, however it does 'camp' in an opengis.org namespace 
>>> without obvious endorsement from the OGC (unless I missed finding 
>>> that, which is perfectly possible).
>>>
>>> [b] http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/#owl
>>> [c] 
>>> http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/W3C_XGR_Geo_files/geo_2007.owl
>>> [d] http://www.georss.org/gml#GeoRSS_GML
>>>
>> We have checked them, but at that time we prefer to follow the 
>> gml:LineString, however we can extend our model to include them.
> It looks to me like you are using WKT encodings form [1]
Yes, you are right.
>>
>>> I think Gannon was making a point about localized re-invention of 
>>> vocabulary either being inevitable or maybe accidental - either way 
>>> it mitigates against the widespread adoption of a common practice 
>>> and potentially linits the reuse of data assets published using a 
>>> particular local practice. It also mitigates against tooling, 
>>> developing to support such things as spatial-indexes in SPARQL 
>>> stores, because without the use of common vocabularies you loose the 
>>> triggers that would induce index building - and responsive UIs 
>>> seeking to display artefacts within spatial bounding boxes could 
>>> well do with the help a spatial index could give.
>> Why don't all of us  start to collect the experiences we have to 
>> publish and consume geoespatial linked data?
> Where I am at is that  I have data that I want to publish as RDF. 
> Currently its only point data, but in general I'd expect to have line 
> segments and polygons. The coordinates systems being used in the data 
> are ETRS89 and UK National Grid. Yes... I can convert to WGS 84 (in 
> some cases that is a time dependent conversion) - but I'd like to 
> respect the data's original form.

Ok, I see. So, you are suggesting do not convert the data from the 
original reference system, and keep the original one.


>
> What I don't see is firm guidance on how to publish anything other 
> than WGS84 point positions as RDF. Yes... I could follow one of a 
> number of [previously mentioned] emerging patterns and 
> 'it-would-be-nice' (tm) for there to be some convergence of practice. 
> I could make up my own scheme, but that would kind of miss the point 
> and only add to the problem.
I agree with you there is a clear need of best or common practices to 
publish geospatial information.

>
>> Thoughts? suggestions?
> I guess my ideal would be for guidance to emerge from OGC, ISO TC 211 
> and/or W3C.  That may be happening... but I don't have a good handle 
> on what activity (if any) is focussed on this topic.

Someone from the list has a suggestion about this.


Boris

>> Best
>>
>> Boris
>>
> BR
>
> Stuart
> --
>>
>> [X] SELECTTO_CHAR(SDO_UTIL.TO_GML311GEOMETRY(geometryColumn))
>>
>> AS Gml311Geometry
>>
>>       FROM "DB"."TABLE" c
>>
>>       WHEREc.Name='Arroyo'
>>
>> [Y] http://www.geotools.org/
>> [Z] http://jena.sourceforge.net/
>>>>
>>>>
>>>> geo: http://www.w3.org/2003/01/geo/wgs84_pos#
>>>> [1]: http://geo.linkeddata.es/
>>>> [2]: http://mccarthy.dia.fi.upm.es/challenge/example1.png
>>>> [3]: http://geo.linkeddata.es/page/resource/Provincia/Albacete
>>>> [4]: http://geo.linkeddata.es/browser/
>>>>
>>>
>>> BR
>>>
>>> Stuart
>> --
>> Boris Villazón-Terrazas
>> Ontology Engineering Group (OEG)
>> http://www.oeg-upm.net
>>
>> Departamento de Inteligencia Artificial
>> Facultad de Informática
>> Universidad Politécnica de Madrid
>> Campus de Montegancedo, s/n
>> Boadilla del Monte - 28660 Madrid, Spain 
>
>
> -- 
> Epimorphics Ltdwww.epimorphics.com
> Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
> Tel: 01275 399069
>
> Epimorphics Ltd. is a limited company registered in England (number 7016688)
> Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK