Versioning the uMap internal format

[yohanboniface]

uMap internally uses geojson to store data. While the structure is stable, the keys change from time to time. Some are added, some are removed, some are renamed, some may change their type. So the uMap client does a lot of "duck typing" to remain backward compatible (is there a key X so let's use it, otherwise is there a Y then use that one, etc.). To clean this kind of code, we discussed the opportunity to version the format, and have a migration layer able to pass from a version to another. So the client would always deal with the latest format, and pass it to some helper when it is given an old version. This version would also be used for full umap backups.

Some notes:

• we certainly cannot get totally rid of backward compatibility code in the JS client, give some key can be used in URL query string, so stored out of our control
• while the uMap backup is a single full file, internally the data is split:
  • map metadata are on DB, and are a JSON object (nested)
  • datalayer metadata are on DB (cf #1335), and are a JSON object (nested)
  • datalayer data are on disk and are a valid FeatureCollection
• the umap full backup is a "collection of FeatureCollection", but this case is not handled by the GeoJSON spec AFAIK, so we "invented" a type: "umap", with a layers: [list of FeatureCollection] key; while trying to version our format, let's try to see if there is a more GeoJSON standard way of storing a list of FeatureCollection

[yohanboniface]

cf #1335 cf #174

[yohanboniface]

the umap full backup is a "collection of FeatureCollection", but this case is not handled by the GeoJSON spec AFAIK, so we "invented" a type: "umap", with a layers: [list of FeatureCollection] key; while trying to version our format, let's try to see if there is a more GeoJSON standard way of storing a list of FeatureCollection

@sgillies hey! :) To you have any advice on this specific point ? Basically, here is how our "umap" export looks like:

{
    "type": "umap",
    "properties": {"some map": "metadata"},
    "geometry": {
        "type": "Point",
        "coordinates": ["the", "map", "default", "center"]
    },
    "layers": [
        {
            "type": "FeatureCollection",
            "_umap_options": {"some layer": "metadata"},
            "features": [{
                "properties": {"some": "props"},
                "geometry": {"some": "geom"}
            }]
        },
        {
            "type": "FeatureCollection",
            "_umap_options": {"some layer": "metadata"},
            "features": [{
                "properties": {"some": "props"},
                "geometry": {"some": "geom"}
            }]
        },
    ]
}

As you see, this mimics a sort of "Collection of collections" type as it could exist in GeoJSON, but it does not AFAIK.

My goal would be to maximise the portability of those data. Eg. someone wants to reimport uMap export in QGis, or the other way around, and retrieve as much as possible of the original structure: data are split into layers, maybe some styling are kept, etc.

Thanks in advance for your input on this :)