You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any thoughts on adding a custom CRS dynamically to a Virtuoso instance through a dereferenceable URI like this one for epsg:3395?
I ask because much of the spatial data I use, it would require potentially a custom CRS per reference image as each image has (potentially) a different scaling per dimension. I can use a known Cartesian CRS in the WKT literals and then use units:GridSpacing in the spatial functions and get the right numbers out (#1320) in Virtuoso, but I don't like that my GeoSPARQL feature collection isn't self-described completely. I know I can add a custom CRS via [#1323], but its onerous for numerous custom CRSs. CRS Ontology perhaps might be helpful in the future for an all-RDF, OGC-complaint solution.
The text was updated successfully, but these errors were encountered:
@ebremer To be clear, are you saying that rather than statically using the DB.DBA.PROJ4_LOAD_SYS_SRIDS() procedure in #1323, you want to be able to dynamically pass the CRS as a URI, e.g., epsg:3395, on the fly?
Any thoughts on adding a custom CRS dynamically to a Virtuoso instance through a dereferenceable URI like this one for epsg:3395?
I ask because much of the spatial data I use, it would require potentially a custom CRS per reference image as each image has (potentially) a different scaling per dimension. I can use a known Cartesian CRS in the WKT literals and then use units:GridSpacing in the spatial functions and get the right numbers out (#1320) in Virtuoso, but I don't like that my GeoSPARQL feature collection isn't self-described completely. I know I can add a custom CRS via [#1323], but its onerous for numerous custom CRSs. CRS Ontology perhaps might be helpful in the future for an all-RDF, OGC-complaint solution.
The text was updated successfully, but these errors were encountered: