<div dir="auto">Brent,<div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Cheers!</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 15, 2020, 10:32 Brent Fraser <<a href="mailto:bfraser@geoanalytic.com">bfraser@geoanalytic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
 Over the years I've done two implementations using GeoMoose and feature <br>
editing.  The first based on GM 1.6 and it's custom protocol, the second <br>
with GM 2.4 (then a later upgrade to 2.6 and WFS-T).  Lack of feature <br>
editing has prevented me from doing much with GeoMoose 3.x.<br>
<br>
 I'm currently reviewing Leaflet with respect to WFS-T.  Leaflet uses a <br>
"plugin" architecture so it is implemented by <br>
<a href="https://github.com/Flexberry/Leaflet-WFST" rel="noreferrer noreferrer" target="_blank">https://github.com/Flexberry/Leaflet-WFST</a>.  Maybe we could leverage some of <br>
that code (likely not).<br>
<br>
 As for the server side, I think TinyOWS is ok, but I do wish it was better <br>
documented.  Personally I think there should be a Python version of a WFS-T <br>
server with the ability to choose the type of database back-end.<br>
<br>
 Best Regards,<br>
 Brent Fraser<br>
<br>
<br>
<br>
 -------- Original Message --------<br>
> From: "Dan Little" <<a href="mailto:theduckylittle@gmail.com" target="_blank" rel="noreferrer">theduckylittle@gmail.com</a>><br>
> Sent: April 14, 2020 9:19 PM<br>
> To: "GeoMOOSE PSC" <<a href="mailto:geomoose-psc@lists.osgeo.org" target="_blank" rel="noreferrer">geomoose-psc@lists.osgeo.org</a>><br>
> Subject: [geomoose-psc] Layer Events and Editing<br>
><br>
> Hey Folks!<br>
><br>
> Some of you may follow the shenanigans of the development team on GitHub<br>
> but I know not everyone does! We've been working through a lot of great<br>
> improvements in the last two months and as that work has evolved I've <br>
been<br>
> thinking about the state of editing.<br>
><br>
> 1. Unlike GeoMoose 2.X, 3.X did not include any out of the box editing<br>
> capability. GM2.X used a subset of WFS-T in combination with either <br>
TinyOWS<br>
> or GeoServer. The each had their quirks but it did, for the most part, <br>
work.<br>
> 2. There's not been a priority put on editing in GM3. That's been for a <br>
few<br>
> reasons:<br>
> A. There hasn't been a lot of dedicated funding for such. The bulk of<br>
> GeoMoose development is done under two situations: volunteer and <br>
sponsored.<br>
> There hasn't been a sponsored version of the development and none of the<br>
> develoeprs uses GeoMoose for editing.<br>
> B. The state of current servers isn't great. GeoServer is actively<br>
> developed but it's a lot to install and manage to simply be the WFS-T<br>
> server. You could use GeoServer to serve all the WMS services as well <br>
but<br>
> it's not an ask we've been willing to put on users. TinyOWS has not had <br>
a<br>
> commit or a dedicated maintainer in a very long time. It's hard to<br>
> recommend something that does not have a known amount of support.<br>
> C. "Rolling our own" has always been an idea but that's fraught with<br>
> potential maintenance disasters as well. Other services have their own<br>
> API's for editing but targeting a single API as the basis for editing<br>
> support in GeoMoose breaks our goal of being flexible and standards<br>
> compliant.<br>
> D. WFS-T, the actual standard, can be cumbersome. Like many standards<br>
> WFS-T is pretty feature-complete. It handles all geometry-types, honours<br>
> property data-types, all the fun of editing state, projections, and the<br>
> rest of the nitty-gritty. But all of that is usually overkill when you <br>
just<br>
> want to share a layer between a few GeoMoose users.<br>
><br>
> I'm interested in hearing feedback. Who really had done what? What are <br>
the<br>
> actual needs?<br>
> _______________________________________________ geomoose-psc mailing list <br>
<a href="mailto:geomoose-psc@lists.osgeo.org" target="_blank" rel="noreferrer">geomoose-psc@lists.osgeo.org</a> <br>
<a href="https://lists.osgeo.org/mailman/listinfo/geomoose-psc" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geomoose-psc</a><br>
<br>
<br>
</blockquote></div>