Last week, I’ve been lucky to start working on uMap, an open-source map-making tool to create and share customizable maps, based on Open Street Map data.
My goal is to add real-time collaboration to uMap, but we first want to be sure to understand the issue correctly. There are multiple ways to solve this, so one part of the journey is to understand the problem properly (then, we’ll be able to chose the right path forward).
Part of the work is documenting it, so expect to see some blog posts around this in the future.
-Also, this is made possible via the generous help of ScopyLeft, so thanks to them!
I’ve started by installing uMap on my machine, made it work and read the codebase. uMap is written in Python and Django, and using old school Javascript, specifically using the Leaflet library for SIG-related interface.
Installing uMap was simple. On a mac:
@@ -99,12 +98,12 @@ the current code base.The data is split in multiple layers. At the time of writing, concurrent writes to the same layers are not possible, as one edit would potentially overwrite the other one. It’s possible to have concurrent edits on different layers, though.
-When a change occurs, each DataLayer is sent by the client to the server.
When a change occurs, each DataLayer is sent by the client to the server.
HTTP 422 (Unprocessable Entity) status is returned, which makes it possible to detect conflicts. The users are prompted about it, and asked if they want to overwrite the changes.{datalayer.pk}_{timestamp}.geojson. A history of the last changes is preserved (The default settings preserves the last 10 revisions).{datalayer.pk}_{timestamp}.geojson. A history of the last changes is preserved (The default settings preserves the last 10 revisions).Each layer consists of:
@@ -195,7 +194,7 @@ features we want.o If the target location specifies an object member that does exist, that member’s value is replaced.
-It seems to bad for us, as in our case this will happen each time a new feature is added to the feature collection.
+It seems too bad for us, as this will happen each time a new feature is added to the feature collection.
It’s not working out of the box, but we could probably hack something together by having all features defined by a unique id, and send this to the server. We wouldn’t be using vanilla geojson files though, but adding some complexity on top of it.
At this point, I’ve left this here and went to experiment with the other ideas. After all, the goal here is not (yet) to have something functional, but to clarify how the different options would play off.