[geomoose-psc] Layer Events and Editing

[Jim Klassen]

It might be worthwhile to ask this question to the broader audience on geomoose-users.

I personally don't have any answers.  I never got into GeoMoose for editing because while the 2.x editor worked enough as a generic editor, I couldn't come up with a good way to handle the business rules/constraints required to maintain integrity in my production datasets.  I found dealing in a user friendly way with issues such as concurrent editors/conflicting edits, relationships with other tables, and/or with enforcing topology required either very careful table structure (which isn't always possible due to compatibility with other systems) or a more special case editor that was more aware of the specific data structure.  The other option of just having the database reject the change without giving the user real time feedback about if their edit was valid or even a good way to send a message back afterwards about why an edit was rejected is just a recipe for frustrated users.  This isn't a GeoMoose only problem though, many GIS editing packages have the same faults where 
they make many assumptions that aren't generally true of relational databases.

The closest I got to something was using it as a generic way to record comments/markup on the map to alert someone that a dataset might need to be updated (as opposed to directly editing the underlying dataset).

The other thing I'd like to point out is GeoMoose 3.x does have an editor of sorts.  A user can download a layer (the Drawing and Markup layer in the demo, but should be configurable with other vector layers too) as KML or GeoJSON.  They can also upload that KML/GeoJSON back into GeoMoose.  It just saves the changes to the client instead of back to the web server.  I would guess an easy path for us would be to extend this to GET/PUT GeoJSON from/to a URL (and leave it up to the web server what it does with it).  An existing server implementation that could potentially work with this is CouchDB [1] which is also supported by GDAL/OGR for reading and writing [2].  However, a minimal useful subset of that is a pretty standard REST style API which should be easy to implement in several languages/server architectures.

[1] http://damonoehlman.github.io/talk-spatial-couch-intro/-/#slide-0
[2] https://gdal.org/drivers/vector/couchdb.html#vector-couchdb

On 4/14/20 10:19 PM, Dan Little wrote:
> Hey Folks!
>
> Some of you may follow the shenanigans of the development team on GitHub but I know not everyone does! We've been working through a lot of great improvements in the last two months and as that work has evolved I've been thinking about the state of editing.
>
> 1. Unlike GeoMoose 2.X, 3.X did not include any out of the box editing capability. GM2.X used a subset of WFS-T in combination with either TinyOWS or GeoServer. The each had their quirks but it did, for the most part, work.
> 2. There's not been a priority put on editing in GM3. That's been for a few reasons:
>   A. There hasn't been a lot of dedicated funding for such. The bulk of GeoMoose development is done under two situations: volunteer and sponsored. There hasn't been a sponsored version of the development and none of the develoeprs uses GeoMoose for editing.
>   B. The state of current servers isn't great. GeoServer is actively developed but it's a lot to install and manage to simply be the WFS-T server. You could use GeoServer to serve all the WMS services as well but it's not an ask we've been willing to put on users. TinyOWS has not had a commit or a dedicated maintainer in a very long time. It's hard to recommend something that does not have a known amount of support.
>  C. "Rolling our own" has always been an idea but that's fraught with potential maintenance disasters as well. Other services have their own API's for editing but targeting a single API as the basis for editing support in GeoMoose breaks our goal of being flexible and standards compliant.
>   D. WFS-T, the actual standard, can be cumbersome. Like many standards WFS-T is pretty feature-complete. It handles all geometry-types, honours property data-types, all the fun of editing state, projections, and the rest of the nitty-gritty. But all of that is usually overkill when you just want to share a layer between a few GeoMoose users.
>
> I'm interested in hearing feedback. Who really had done what? What are the actual needs?
>
> _______________________________________________
> geomoose-psc mailing list
> geomoose-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geomoose-psc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20200414/def0fca7/attachment.html>