[geomoose-psc] Layer Events and Editing

Wed Apr 15 06:02:19 PDT 2020

Good Morning,

I haven’t run across a use case yet needing editing in GeoMoose.  My general sense is with the ease of setting up PostGIS, AGOL, ESRI Enterprise Geodatabase most are using one of those options on the backend.  From my own work I have been typically seeing one of two ways to do editing from a web app.  Leaflet with a custom API to write to a database or AGOL app writing to ESRI feature services thru REST API.

This is just my two cents but agree with Jim it would be interesting to see what the broader audience thinks. Although I would worry they might not understand all of the work it would take to implement something like this and just say yes they want it.

Brian

        Brian Fischer
Project Manager - GIS | Vice President
Houston Engineering, Inc.
O 763.493.4522 | D 763.493.6664 | C 763.229.2734
        [cid:hei_d562a228-8e53-424d-8c69-43b1a222b74e.png]      7550 Meridian Circle North, Suite 120
Maple Grove, MN • 55369
www.houstoneng.com<http://www.houstoneng.com/>
Follow us: Facebook<https://www.facebook.com/houstoneng> | Twitter<https://twitter.com/houstoneng> | LinkedIn<https://www.linkedin.com/company/houston-engineering-inc.> | YouTube<https://www.youtube.com/user/HoustonEngInc>

This entire message (including all forwards and replies) and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret, work-product, attorney-client or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

From: geomoose-psc <geomoose-psc-bounces at lists.osgeo.org> On Behalf Of Jim Klassen
Sent: Tuesday, April 14, 2020 11:51 PM
To: geomoose-psc at lists.osgeo.org
Subject: Re: [geomoose-psc] Layer Events and Editing

[External Email]
________________________________
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<http://damonoehlman.github.io/talk-spatial-couch-intro/-/#slide-0>
[2] https://gdal.org/drivers/vector/couchdb.html#vector-couchdb<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<mailto:geomoose-psc at lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/geomoose-psc<https://lists.osgeo.org/mailman/listinfo/geomoose-psc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20200415/4cdab208/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hei_d562a228-8e53-424d-8c69-43b1a222b74e.png
Type: image/png
Size: 986 bytes
Desc: hei_d562a228-8e53-424d-8c69-43b1a222b74e.png
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20200415/4cdab208/attachment-0001.png>