Use GeoSPARQL for the representation of shapes

[ocorcho]

I would really find it easier to use GeoSPARQL for the representation of shapes like polygons or polylines, instead of gtfs:Shape, which is rather ad-hoc and coming directly from GTFS. This would ensure that GeoSPARQL aware visualisation tools can actually present information more easily.

[rtroncy]

+1

[pietercolpaert]

Interesting idea and thanks for opening an issue for the discussion that was still needed here: https://github.com/OpenTransport/vocabulary/blob/master/gtfs/spec.md#gtfsshape

apologies for my ignorance: GeoSPARQL is a query language, how can it be used for shapes? Could you refer me towards towards some online resources?

[ocorcho]

It's not only a query language, but can be also used to represent the data itself. A very simple example from our LocaliData API on a postal code:

@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .
<http://datos.localidata.com/recurso/territorio/CodigoPostal/28004>
    dct:identifier      "28004" ;
    geosparql:hasGeometry  <http://datos.localidata.com/recurso/territorio/CodigoPostal/28004/Geometry/WGS84> , <http://datos.localidata.com/recurso/territorio/CodigoPostal/28004/Geometry/EPSG23030> ;
    geosparql:sfTouches    <http://datos.localidata.com/recurso/territorio/CodigoPostal/28013> , <http://datos.localidata.com/recurso/territorio/CodigoPostal/28014> , <http://datos.localidata.com/recurso/territorio/Provincia/Madrid/Municipio/madrid/Distrito/04> , <http://datos.localidata.com/recurso/territorio/CodigoPostal/28015> , <http://datos.localidata.com/recurso/territorio/CodigoPostal/28010> , <http://datos.localidata.com/recurso/territorio/CodigoPostal/28001> , <http://datos.localidata.com/recurso/territorio/Provincia/Madrid/Municipio/madrid/Distrito/04/Barrio/1> , <http://datos.localidata.com/recurso/territorio/CodigoPostal/28046> .
<http://datos.localidata.com/recurso/territorio/CodigoPostal/28010/Geometry/WGS84>
    geosparql:asWKT  "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POLYGON ((-3.697712239976624 40.438211496892087,-3.697011737824315 40.438076157570222,-3.696221665009141 40.438100063454307,-3.695635453579538 40.438051756157833,-3.694483951426189 40.438003785704552,-3.692824532028161 40.437936016795419,-3.691421516894201 40.437883298678933,-3.691172753333192 40.438054023214328,-3.690336710189202 40.436720348463282,-3.690161244738889 40.436495320158471,-3.689314435788195 40.435226647122363,-3.689418522860785 40.435118004106158,-3.68942017523028 40.434629451484412,-3.689117707793985 40.434134986057259,-3.689277035182089 40.433688784791421,-3.688899847478632 40.43300924170066,-3.689270135617338 40.431824336145169,-3.689783565484295 40.431413599324436,-3.68964638500963 40.43063011714294,-3.689840363478512 40.42941843150934,-3.689940143734525 40.429159822232108,-3.69017792851756 40.428328923101517,-3.69008265545457 40.428040560236489,-3.690237141162692 40.427875492609587,-3.690510329925656 40.426939825418025,-3.690517190220707 40.426622551213519,-3.690698121547886 40.426428210821129,-3.690975894746424 40.425808293278919,-3.691268895547483 40.425897860699187,-3.691402249804022 40.425815785571345,-3.692284718189417 40.426186658891993,-3.693735294839725 40.426910383012228,-3.694897363609713 40.427585267016944,-3.694916754105258 40.427675444230502,-3.694943614626503 40.427774042223291,-3.695019026812011 40.427925959547835,-3.69521475815332 40.428042493285695,-3.695408397531313 40.428187055229039,-3.695465134757717 40.428219554159597,-3.695725880250277 40.428208931302557,-3.696107169928698 40.428240154658802,-3.696496909767541 40.428093415788332,-3.696883554829589 40.428170896682367,-3.697037063059764 40.428147157020085,-3.697249940383324 40.42825293356556,-3.697820278238662 40.428374624475161,-3.698038489688293 40.428344383953423,-3.698395194676748 40.428467720307466,-3.699145193801553 40.428613942345443,-3.699346895961412 40.428622480811697,-3.699659991343104 40.428739413150922,-3.700177323990486 40.428829395469442,-3.70040508177484 40.428817265462662,-3.700599017955455 40.428928821682582,-3.701622698231492 40.429197064819313,-3.701767573039327 40.429429425556343,-3.702166090479451 40.429484928585318,-3.702426304064891 40.429400161224464,-3.702640134333171 40.429336806527502,-3.70332941993993 40.429445702245467,-3.703534800790724 40.42940083405783,-3.703720868896753 40.429508448249337,-3.704441442434744 40.429612692852224,-3.704580175459969 40.429576136938785,-3.704685540016914 40.429651111100164,-3.705083668552301 40.429715192832141,-3.70504996773247 40.429821814438661,-3.705179231817183 40.429976215471328,-3.705251761886051 40.430036682329366,-3.705234102807205 40.430198499263781,-3.705273268550032 40.430283673896263,-3.705105438765406 40.430413013496086,-3.704821966385787 40.431240037449328,-3.704859345820632 40.431425782439781,-3.704670497552493 40.431619020066591,-3.704221849897287 40.432958609604562,-3.704054877846776 40.433239280480585,-3.703632486696329 40.433340025040238,-3.703798746055162 40.433703173118936,-3.703734723385971 40.433792563744312,-3.703791014319143 40.433980656914244,-3.70397958158573 40.434097722827509,-3.703974808093754 40.434819862245391,-3.704052753822751 40.434901452446226,-3.70404962124582 40.435026465681503,-3.703919102527986 40.43509726245712,-3.703909147382073 40.435899167572288,-3.703974574812346 40.436035178486243,-3.703944867681809 40.43616342916458,-3.703920289580111 40.436967509642813,-3.703948848902102 40.437163027263345,-3.703821239595585 40.437366803818527,-3.703777846386986 40.438461313404432,-3.702556796249816 40.438400730730528,-3.701003423160412 40.438347289533347,-3.700120336119322 40.438312429078984,-3.699263707135919 40.438271450548534,-3.698461865344064 40.438239594007058,-3.697712239976624 40.438211496892087))"^^geosparql:wktLiteral .

[rtroncy]

@pietercolpaert GeoSPARQL is both a query language (geo extension of SPARQL) and a vocabulary for representing geospatial data in RDF (such as coordinate systems, shapes, etc.). It is actually the basis of the new joint W3C - OGC working group that will start to work at the end of the year.

[pietercolpaert]

Ok, seems like a must-have.

How about doing it in the same way as localidata and using only these predicates geosparql:asWKT, geosparql:hasGeometry → pointing to a URI of WGS84?

If I implement this in the mapping scripts at https://github.com/OpenTransport/gtfs-csv2rdf, are you going to set-up a visualization suite? Would be a great demonstrator for this vocabulary!

[rtroncy]

@pietercolpaert ... you should use LOV more often :-) Preferred namespace for geosparql is gsp, see also the LOV description.

There are plenty of visualization suite available, see the work from @gatemezing, from @boricles with Map4RDF, etc.

[pietercolpaert]

@rtroncy Ha, LOV is actually one of my most visited sites in chrome so don't worry ;). I used geosparql as in the example given by @ocorcho

[pietercolpaert]

Still a problem I have with this: GTFS defines e.g., a distance traveled property to a shapepoint, to indicate the total distance that has been traveled up to that point. When using gsp:asWKT, we cannot annotate separate points anymore. Any suggestions?