Closed aditisg17 closed 6 years ago
Good points. deo.distance is passed to the postgis ST_Distance function that states: For geometry type returns the minimum 2D Cartesian distance between two geometries in projected units (spatial ref units).
So we should specify the projection in the respective tables to ensure a consistent result.
I have two questions -
Since GeoJSON specifies WGS 84, and since GeoJSON is the suggested format in the SensorThingsAPI, I would suggest using that, since it means the database doesn't have to do any conversion.
I can update the liquibase database script to update the tables automatically, and users can change the database table manually with:
alter table "LOCATIONS" alter column "GEOM" type geometry(Geometry,4326) USING ST_Force2D(ST_SetSRID("GEOM", 4326));
The SensorThingsAPI standard does not specify the units of either geo.distance or geo.length. That might be an issue worth raising on https://github.com/opengeospatial/sensorthings
We now use 4326 as srid in the geometry columns. This relates to issue #18, that requests making this configurable.
What is the unit of measurement in geo.distance filter result?
Ideally, public.geometry_columns table should have a srid (FK from public.spatial_ref_sys table) specified for the SensorThings API tables "Locations", "DataStreams","Multi_DataStreams" and "Features". However, the value is currently '0'. In the absence of appropriate projection, it leaves the result ambiguous.