Closed redmer closed 7 months ago
I would not say that this is implied necessarily.
Since the GeoJSON literal can only be in one CRS, I believe there is nothing stopping you from adding the GeoJSON literal when other literals are in a different SRS. I believe we also have no SHACL shape marking this as false. However, I think we would recommend to separate geo:Geometries assigned to Features by SRS. The difference here is that implementers should know that the GeoJSON literal is WGS84 by default and they would need to treat it as such under any circumstances.
But also for clarity in the knowledge graph it would be a plus to separate it into a WGS84 geometry and a Different-CRS geometry, also given that there will be the geo:inSRS property in the future.
@nicholascar @mperry455 do you see this the same way?
I agree with @situx here: implement separate geo:Geometry
objects for the same geo:Feature
, one using GeoJSON and the other using WKT or whatever.
Great! Thanks for explanation, that means that I'm doing the right thing in rdf-geopackage. Feel free to close.
Then I will do just that. Closing...
It's great to see that GeoJSON can be serialized into GeoSPARQL with v1.1, ideal for less-geo-aware consuming applications.
As GeoJSON is always (§ A.3.4.2) in WGS 84, I'd like to check my understanding of the specification.
geo:Geometry
is in only one single SRS.I think that means (for rdf-geopackage) that:
geo:asGeoJSON
and in WGS 84 withgeo:asWKT
, then thegeo:Feature
may have just a singlegeo:Geometry
having two serializations.geo:asGeoJSON
and in EPSG:28992 (or any other SRS different from WGS 84) withgeo:asWKT
, then thegeo:Feature
must have two differentgeo:Geometry
s, one per serialization.