This make it possible to synchronize datalayers before their creation on
the server, allowing at the same time to solve issues related to them
not being saved (e.g. duplication of geometries)
We use the DataLayer._referenceVersion to track if a DataLayer has been
saved on the server.
After a save, the _referenceVersion is synched with other peers.
To pass the reference version from the server to the frontend, we have two
options:
- use a header
- populate the `options.version` field
In the case of a GET on a Datalayer, we could not use the `options` scenario
because:
- the value in the file is not up to date (it was the value the client has
before the save)
- the python cannot change it on the fly, as the file is served by nginx
So we decided to keep using a header. But on the map view, we load all
datalayers metadatas in the map options, so here we cannot use the header
scenario, so in this specific case we had to populate `options._referenceVersion`.
At the same time, we also changed:
- Umap.options.umap_id => Umap.id
- DataLayer.umap_id => Datalayer.id
- fixed the version number returned by DataLayer.version_metadata
Here is the initial issue:
- when using defaultView=latest (means latest element of the default layer)
- when map loads, we find the element, call getCenter to center the map on it
- but Polygon/Polyline needs the element to be already on the map to call
this method (at least because the map CRS is needed)
So while trying to fix that issue, I also found that using a centroid for
a complex geometry was not very friendly: the map zoom on a part of this
geometry, while it seems to be that it's better to have a full view of it.
Now that we highlight the selected element, it's also easier to get which
element is focused when there are a lot close one to the others.
This allows to known the full datalayer behaviour without needing
to load all the data, including the zoom from and to (new settings),
but also the color for example.
This will help also understanding datalayers usage and making
stats.
But no data migration is provided, it's retrocompatible (data
migration in OSM FR servers would be huge, so let's see if it's
really needed).
