- On one side are the properties (matching the
_umap_options), and on the other, the geojson data (the Features key). - Each feature is composed of three keys: -
- geometry: the actual geo object -
- properties: the data associated with it -
- style: just styling information which goes with it, if any. +
- geometry: the actual geo object +
- properties: the data associated with it +
- style: just styling information which goes with it, if any.
Real-time collaboration : the different approaches
Behind the “real-time collaboration” name, we have :
-
-
- Streaming of the changes to the clients: when you’re working with other persons on the same map, you can see their edits at the moment they happen. -
- Concurrent changes: some changes can happen on the same data concurrently. In such a case, we need to merge them together and be able to +
- The streaming of the changes to the clients: when you’re working with other persons on the same map, you can see their edits at the moment they happen. +
- The ability to handle concurrent changes: some changes can happen on the same data concurrently. In such a case, we need to merge them together and be able to
- Offline editing: in some cases, one needs to map data but doesn’t have access to a network. Changes happen on a local device and is then synced with other devices / the server ;
Keep in mind these notes are just food for toughs, and that other approaches might be discovered on the way
@@ -336,7 +336,15 @@ poster="https://nuage.b.delire.party/s/kpP9ijfqabmKxnr"> type="video/mp4"> -And, that’s all for this week!
+It’s very rough, but the point was mainly to see how the library can be used, and what the API looks like. I’ve found that :
+-
+
- The
patchesobject that’s being sent to thehandle.onsubscribers is very chatty: it contains all the changes, and I have to filter it to get what I want.
+ - I was expecting the objects to be sent on one go, but it’s creating an operation for each change. For instance, setting a new object to a key will result in multiple events, as it will firstly create the object, and the populate it. +
- Here I need to keep track of all the edits, but I’m not sure how that will work out with for instance the offline use-case (or with limited connectivity). That’s what I’m going to find out next week, I guess :-) +
- The team behind Automerge is very welcoming, and was prompt to answer me when needed. +
- There seem to be another API
Automerge.getHistory(), andAutomerge.diff()to get a patch between the different docs, which might prove more helpful than getting all the small patches.
+
We’ll figure that out next week, I guess!