[geomoose-psc] Layer Events and Editing

Wed Apr 15 06:12:38 PDT 2020

I'm starting this out at the PSC level before expanding to -users. If we go
to look at a broader audience then I'd like to have one or maybe two
direction ideas to get feedback on rather than a general concept. Which is
why I wanted to start with the smaller audience of the PSC in order to get
a feel for what people think we can and should do.

On Wed, Apr 15, 2020 at 8:08 AM Brian Fischer <bfischer at houstoneng.com>
wrote:

> 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
>    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
> [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
>
>
> _______________________________________________
> 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/20200415/acef4dbf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hei_d562a228-8e53-424d-8c69-43b1a222b74e.png
Type: image/png
Size: 986 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20200415/acef4dbf/attachment.png>