definition of geojson schema

[Marc-Antoine Brenac]

Hi everyone,

I'll start by thanking everybody working and the project, offering valuable data for aeronautical purpose, even when official organisation fail to produce easily sharable data.

I'm very happy by the road openAIP is taking, and would like to offer some help and orientation on this.

Regarding the GeoJSON output, which is for me the better bet for interoperability, I noticed some things that could be explained or better done.

Geojson allow for an "id" member for each feature, but you currently produce & provide  several of them : id, properties._id, propoerties.batchId, properties.importId

I didn't find any explanation for any of them (even in the REST API reference), Which one is unmutable and may be use for reference between file updates ?

As for the coordinates, GeoJSON specs allow for a third item reprensenting the elevation in meter above WGS84 reference, using this would be a huge step to 3D reprensentation (think DeckGL layer over Mapbox for exemple).

If the Schema for geojson is not fixed yet, I'll be glad to give my two cents, and way not participate in the implementation.

See you,

[Stephan Besser]

Hi Marc,

thanks for the feedback. Currently the feature ID is a simple incrementing integer that is only unique within the given GeoJSON file export. Each feature carries a property "_id" which is the unique database identifier for the source database document. This value is immutable and will never change for each document (feature). 

The "batchId" and "importId" properties are internally used for migration purposes thus they are not documented. They will be removed as soon as openaip has successfully migrated to version 2 on release day. 

Deck.gl looks very interesting and I'll evaluate it. Seems like a perfect fit to show 3D airspaces. Do you have any experience with the combination mapbox/deck-gl? 

Regarding GeoJSON and elevation data: The elevation data is encased within the "properties" prop of each feature object. This is because the GeoJSON we export is not used to draw the map tiles on openaip. Map tiles are powered by a binary data/layers that is highly tailored to give the best possible map experience. 

What recommendations do you have regarding the GeoJSON format?

Cheers,

Stephan 

[Marc-Antoine Brenac]

Hi Stephan,

Thanks for your response. I'm gonna use `properties._id` as a reference for my app.

Concerning the GeoJSON format, I'll recommend to stick as close as possible to the original AIXM format/data. The issue with an aggregator like openAIP is the trust we can put in the data as they are processed from the different sources (in this mater publishing the sources and source code for the mapping will be beneficial).

My first impression, was that I'll be responsible for the data I supply to my users (even with a bold disclaimer), hence my reluctance of using openAIP (I was on the road of implementing everything from AIXM data...).

For the GeoJSON, I'll only recommend to

- fix the `id` member with an immutable reference (openAIP reference _id or, better, original AIXM reference id),

- use the third coordinate reference as elevation (not for airspaces as the got floor and ceiling) in WGS84 projection

- elevation value, if in WGS84, should keep the geoid undulation value with the reference (AIXM `valGeoidUndulation` properties) if not the stored, height can only be used by reference to a GPS location value and  not with real world elevation (WGS84 elevations are not equal to Mean Sea Level values).

- airport name should only be the name, not the label you use in your tiles (maybe a label property could be provided)

- remove unnecessary data : import id, createdBy, updatedBy, ...

- remove duplicate data (eg; channel and frequency)

- `value` should be an Integer or a Float for frequencies, not a String

- use clear strings and not integer for `type`, `unit`, `referenceDatum` (making easier/quicker to use the data)

- provide a schema for the properties : as https://json-schema.org/ (or make use of the REST API documentation)

- bonus : provide line-oriented geojson (https://stevage.github.io/ndgeojson/) and/or whole coverage files (all objects, all countries)

As for the 3D rendering, DeckGL works great with Mapbox/Maplibre, it respects the chosen projection (maybe not every projection that mapbox-gl allows), I implemented it in my VueJS Mapbox wrapper (work in progress : https://github.com/treville-sasu/vue-mapx). I don't know if you may use your MBTiles easily as it consume values as vectors or GeoJSON features (you could check for a combination of  MapboxLayer & MVTLayer).

That it for my two cents ! Tell me if I can be of any help. Your work is very valuable for the airmen community.

Best regards,

[Stephan Besser]

Hi Marc,

thanks for the feedback. When we started with v2 development AIXM was considered to be used as the default export format. Due to interoperability and usability/ease-of-use we decided against it and for JSON. Nonetheless, we might add AIXM as an additional export format in the not-so-far future. As a side note, I added the ND-GEOJSON as a new export format type. Our export files simply offer the current dataset in different formats including mostly all metadata that is available. Thats the reason we have fields like createdAt etc in there.

What would be a nice to have addition would be to have additional metadata on geoid heigth and height above ellipsoid available for all point feature. I'll put that on the list :D

Cheers,

Stephan