|
|
|
|
|
|
|
|
| Re: [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3608 is a reply to message #3601] |
Wed, 30 April 2025 11:51   |
Mathias Vanden Auweele
Messages: 129
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
So there are several ways to do this. I'm going to focus on the geometric coordinate. But the same can be done for the screen coordinates.
Currently, this would be a data sample using the current ontology:
bnd:_gps01 a rtm:GeometricPositioningSystem ;
rdfs:label "EPSG:25832 - ETRS89 / UTM zone 32N"@en ;
railml3:hasCrsDefinition "EPSG:25832" ;
time:hasBeginning bnd:_timeinstant_2000-01-01 ;
time:hasEnd bnd:_timeinstant_9999-01-01 .
bnd:_spotlocation_1 a rtm:SpotLocation
rtm:onNetElement bnd:_netelement_1 ;
rtm:hasApplicationDirection "reverse" ;
rtm:hasIntrinsicCoordinate 0.1 ;
rtm:hasGeometricCoordinate bnd:_geometric_coordinate_1 .
bnd:_coordinate_1 a rtm:GeometricCoordinate ;
rtm:hasXCoordinate 111111 ;
rtm:hasYCoordinate 222222 ;
rtm:hasZCoordinate 333333 ;
rtm:refersToPositioningSystem bnd:_gps01 .
If we define in the ontology:
rtm:SpotLocation rdf:type owl:Class ;
rdfs:subClassOf [...], gsp:Feature
[...] .
rtm:hasGeometricCoordinate rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf gsp:hasGeometry, [...] ;
[...] .
We can use geosparql in our knowledge graph like this:
bnd:_spotlocation_1 a rtm:SpotLocation
rtm:onNetElement bnd:_netelement_1 ;
rtm:hasApplicationDirection "reverse" ;
rtm:hasIntrinsicCoordinate 0.1 ;
rtm:hasGeometricCoordinate bnd:_geometric_coordinate_1 .
bnd:_geometric_coordinate_1 a gsp:Geometry ;
gsp:hasSerialization "<http://www.opengis.net/def/crs/EPSG/0/25832> POINT(111111, 222222, 333333)^^geo:wktLiteral";
But it also opens up all the properties related to geosparql that would enhance the information available on the coordinate, such as defining SpatialAccuracy.
The advantages:
- integration with standardized and industry state of the art ontology
- geometric functions are immediately available to work with the coordinates in most SPARQL implementations
- geosparql geometries are by standard implemented in viewers such as Yasgui https://yasgui.triply.cc/
- less ontology to maintain
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3987 is a reply to message #3608] |
Tue, 05 May 2026 10:14 |
Larissa Zhuchyi
Messages: 104
Registered: November 2022
|
Senior Member |
|
|
Dear Mathias
Although
Quote:reusing established ontologies is a best practice in ontology development
it seems to me that modelling of RTM is stronger than geosparql in relation to having a separate attribute for each value (x, y, z and positioning system reference).
Moreover based on the examples available at https://wiki3.railml.org/wiki/Geographic_positioning_of_func tional_infrastructure it seems that modelling of geosparql is rather closer to the one of gml than RTM.
As for the statements
Quote:standardized and industry state of the art ... available to work with the coordinates in ... implementations ... by standard implemented in viewers
RTM is an established standard on its own used by railVivid, railOscope and other tools mentioned at https://www.railml.org/en/software.
Let us discuss this once again on the May ontology working group considering points mentioned above.
Sincerely,
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3999 is a reply to message #3987] |
Thu, 07 May 2026 21:58 |
Mathias Vanden Auweele
Messages: 129
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
geo:hasSerialization is a superProperty that has subProperties asWKT, asGML, asGeoJSON, asKML and asDGGS. So GML is also available if you like.
I don't consider the ability to split in X,Y an Z coordinates a "stronger" way of modelling. These coordinates can also be specified in the serialization.
Quote:RTM is an established standard on its own used by railVivid, railOscope and other tools mentioned at https://www.railml.org/en/software.
You are here referring to the railML XML format. That is something different than the railML ontology. If I create an RDF file that has those rtm:goemetricCoordinates then no single software from your list will be able to understand it.
While Geosparql is supported by many. Here's one that's currently open on my browser tabs: https://shorter.matdata.eu/16
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Members
Search
Help
Login
Home
