[geomoose-psc] Layer Events and Editing

[TC Haddad]

I have a sub-set use case where several folks I've worked with have a need
for just attribute editing / updating.

I've wondered about support for a geopackage on the backend and a simple
form to that backend that would allow attribute updates to specific fields
without monkeying with the geometry storage. Doing it right in the table
view would be elegant, but not required.

These users are pretty low key with not a lot of issues with simultaneous
connections, although I could see that that would be an area to look into
further.



On Tue, Apr 14, 2020 at 8:19 PM Dan Little <theduckylittle at gmail.com> 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/20200415/f3c20a74/attachment.html>