2

We have a current system that uses a combination of SAFE FME and PostGIS data (raster and feature) to create download packages for mobile clients. The clients are typically offline web technology (e.g. Leaflet on mobile or tablets, or electron (uses Chromium and node JS) [Some are QGIS and other desktop map software, but that is not our focus here]

There are a number of drawbacks to the system, I won't list all (you can) but the chief one is that we have no clear way of pushing differential updates, or receiving back-haul data from the clients (currency, audit, as well as simple user generated GeoJSON overlay).

We believe that instead of delivering self-contained static packages (ala OGC GeoPackages) - we should provide a dynamic evergreen refresh version of the data. This could be done if we insert a GeoDataBase (in between the PostGIS and the clients) that can sync both on the host (to stage and manage the centralized store) and "child DB" which resides on each client. We have a couple of ideas (see below) but all have their drawbacks. If anyone any solutions we are unfamiliar with, or suggestions to deal with the problems we have identified - we would love to hear that.

Assume:

  1. client is using Web-style Map client: Leaflet or Mapbox GL
  2. client needs read to raster tiles and read/write geoJson feature data stored in a local (offline) database
  3. When client comes online, it needs to sync to a master DB which will reconcile changes and multicast new raster and vector data connected clients.
  4. The database can be fully segmented, so that no two users are writing to the same area (i.e. it is a multiple readers, and single writer problem)

One potential solution could be to use a CouchDB as the master, and PouchDB as the client DB (e.g. leaf-pouch client ) the issue here would be that leaflet-pouch does not seem to support raster tiles.

Alternatively, use Leaflet.TileLayerCached but that seems to be just for raster caches.

Another thought would be to go with Pouch GeoPackage and use the new OGC GeoPackage standard, but one would have to build the sync software from scratch, as well as choose the master DB technology (Probably something compatible with FME so that FME could read/write the source DB and create the GeoPackage diff)

Is there another approach we are missing?

  • Its an interesting question, but there are a lot of options, and this is going to result in opinions, rather than a single "right" answer. That makes it a bad fit for gis.SE. Can you try a more focused question? – BradHards Jun 12 '17 at 0:26
  • 1
    It's an interesting balance. On one hand I agree, open ended opinion pieces is not needed. On the other hand I do not want to close out of the box solutions we have not thought about. Nor can we say too much about the problem. How about adding more constraints and preferred solution attributes? – Dr.YSG Jun 12 '17 at 0:52
  • As long as there is a single correct answer, you're fine. Another option would be to turn this into a community wiki. – BradHards Jun 12 '17 at 7:19
  • About the reconciling changes part: twitter.com/codinghorror/status/506010907021828096 – ghybs Jun 12 '17 at 10:15
  • Good point. Of course I am not looking to do a generalized GIT style DVCS. This well constrained problem which makes the reconciliation much easier. – Dr.YSG Jun 12 '17 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.