Handling height/elevation

[SiBell]

Probably worth clarifying how we want to handle height/elevation, particularly useful if we start collecting data from drones, or from several floors of a building.

Would we follow the GeoJSON format? For example here's the top of big ben:

"geometry": {
    "type": "Point",
    "coordinates": [-0.124573, 51.500705, 96]
}

So the coordinates array contains the longitude, then latitude, both in WGS84 datum, followed by the height in meters.

I can't imagine there's much desire to somehow incorporate the height above sea level?

P.s. if anyone has any tips for handing locations and elevation in a PostgreSQL database I'm all ears. Currently debating if it's worth using PostGIS's POINTZ, or if I just stick to geography(POINT,4269) and store the elevation in a separate column if required.

[SiBell]

To be honest, this fits into a bigger conversation about how we want to format location data.

e.g. a GeoJSON approach:

"geometry": {
    "type": "Point",
    "coordinates": [-0.124573, 51.500705, 96]
}

Or a schema.org approach:

{
  "@context": "http://schema.org",
  "@type": "Place",
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": "40.75",
    "longitude": "73.98"
  },
  "name": "Empire State Building"
}

Or some other approach. Plenty of examples here.

[lukeshope]

My personal preference would be for GeoJSON over the GeoCoordinates approach. The advantage being we could give the geometry its own IRI, and have collections that contained those geometries (might have to be a GeometryCollection rather than a MultiPoint given the way the data is structured), to allow us to have GeoJSON addresses people could use directly in their GIS or other software.

However, when we start thinking about geometries providing context, such as a road, things get more complex. Ideally we'd have different levels of detail like in CityJSON for this, but I think that's too complex and too far for our current needs.

I wonder if the best way forward might be to mandate providing a bounding box centroid (dcat:centroid?) for all platforms, but implementations would be free to provide any other geometry as they see fit. I can see lamp posts being relatively simple, but what if the platform was say a building, and the measurement was average internal temperature?

[SiBell]

Happy to go with GeoJSON. Looks like PostGIS comes with a few handy functions to make this a bit easier on the backend such as ST_GeomFromGeoJSON to convert GeoJSON to PostGIS's geometry type, and ST_Centroid for calculating the centroid.

I assume by using GeoJSON we're not forced to include a properties object? e.g:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [125.6, 10.1]
  },
  "properties": {
    "name": "Dinagat Islands"
  }
}

Just having geometry and type is enough? e.g:

{
  "@type": ["sosa:Platform", "geojson:feature"]
  "@id": "lamp-post-number-5",
  "name": "Lamp post number 5"
  "geometry": {
    "type": "Point",
    "coordinates": [125.6, 10.1]
  }
}

[lukeshope]

Happy to go with that approach.

RFC7946 suggests the properties property is mandatory, but can be null (or presumably empty).

Alternatively, if we want to make sure we serve valid GeoJSON that has attributes for use in GIS... we could I think use property nesting to remove properties and bump everything to its parent during JSON-LD expansion.

[SiBell]

Sound fine to me, although I think I'd need to see an example.