[geomoose-psc] Layer Events and Editing

[Dan Little]

Brent,

Jim and I are backchanneling on his suggestion of CouchDB. It has an easy
Install on all server platforms, a good backup strategy, and ogr drivers
that can move the data to/from PG and Shapefile.

It would also play nice in GM3 since we can just throw GeoJson objects
around. Would something along that line work for you? Or is WFST a hard
requirement? Or direct editing of PG?

Cheers!


On Wed, Apr 15, 2020, 10:32 Brent Fraser <bfraser at geoanalytic.com> wrote:

> Hi All,
>
>  Over the years I've done two implementations using GeoMoose and feature
> editing.  The first based on GM 1.6 and it's custom protocol, the second
> with GM 2.4 (then a later upgrade to 2.6 and WFS-T).  Lack of feature
> editing has prevented me from doing much with GeoMoose 3.x.
>
>  I'm currently reviewing Leaflet with respect to WFS-T.  Leaflet uses a
> "plugin" architecture so it is implemented by
> https://github.com/Flexberry/Leaflet-WFST.  Maybe we could leverage some
> of
> that code (likely not).
>
>  As for the server side, I think TinyOWS is ok, but I do wish it was
> better
> documented.  Personally I think there should be a Python version of a
> WFS-T
> server with the ability to choose the type of database back-end.
>
>  Best Regards,
>  Brent Fraser
>
>
>
>  -------- Original Message --------
> > From: "Dan Little" <theduckylittle at gmail.com>
> > Sent: April 14, 2020 9:19 PM
> > To: "GeoMOOSE PSC" <geomoose-psc at lists.osgeo.org>
> > Subject: [geomoose-psc] Layer Events and Editing
> >
> > 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/5ca24f5c/attachment-0001.html>