It is currently pretty straight-forward to add a map layer with GeoJSON data. Working with their properties however, can be a different story, as each dataset might come with their own definitions.
Each GeoJSON feature can have a "properties" object attached, which can contain any regular JSON data. See official spec.
Much of GeoJSON’s popularity derives from its simplicity, which makes it easy to implement, read, and share. So, like every other format, it has its limits.
GeoJSON features have properties, which are JSON. Properties can use any of the JSON datatypes: numbers, strings, booleans, null, arrays, and objects. JSON doesn’t support every data type: for instance, date values are supported by Shapefiles, but not in JSON.
GeoJSON doesn’t have a construct for styling features or specifying popup content like title & description. There are folk conventions for this, like simplestyle-spec and Leaflet’s Path properties, but these aren’t and won’t be part of the spec. Most geo formats don’t have styling support included either - KML stands out as prioritizing styling.
...
So there is no official format for properties. This becomes limiting / cumbersome if we want to apply custom styling to the icons, and / or have a popup box with additional info, using the provided raw GeoJSON. We'd probably have to adapt the javascript individually for each layer.
At some point, importing each GeoJSON feature into its own database row might therefore become beneficial. Each dataset would still require its own import script, but properties can be connected to a standardized set of database keys (title, description, icon, color, etc). This will also open up new possibilities, such as linking to detail pages of locations or using the data outside of the map (in grid overviews, tables, etc).
So the question becomes: if, when and how are we going to import GeoJSON into the database?
It is currently pretty straight-forward to add a map layer with GeoJSON data. Working with their properties however, can be a different story, as each dataset might come with their own definitions.
Each GeoJSON feature can have a "properties" object attached, which can contain any regular JSON data. See official spec.
And from this article:
So there is no official format for properties. This becomes limiting / cumbersome if we want to apply custom styling to the icons, and / or have a popup box with additional info, using the provided raw GeoJSON. We'd probably have to adapt the javascript individually for each layer.
At some point, importing each GeoJSON feature into its own database row might therefore become beneficial. Each dataset would still require its own import script, but properties can be connected to a standardized set of database keys (title, description, icon, color, etc). This will also open up new possibilities, such as linking to detail pages of locations or using the data outside of the map (in grid overviews, tables, etc).
So the question becomes: if, when and how are we going to import GeoJSON into the database?