search

FraunhoferIOSB / FROST-Server

A Complete Server implementation of the OGC SensorThings API
https://fraunhoferiosb.github.io/FROST-Server/
GNU Lesser General Public License v3.0
194 stars 70 forks source link

GIS Projection/SRID not specified for Locations and other tables #12

Closed aditisg17 closed 6 years ago

aditisg17 commented 7 years ago

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.

hylkevds commented 7 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.

aditisg17 commented 7 years ago

I have two questions -

  1. What should then be the chosen SRID?
  2. Who is supposed to set it? If user, then how to set it?
hylkevds commented 7 years ago

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

hylkevds commented 6 years ago

We now use 4326 as srid in the geometry columns. This relates to issue #18, that requests making this configurable.