<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
It might be worthwhile to ask this question to the broader audience
on geomoose-users.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://damonoehlman.github.io/talk-spatial-couch-intro/-/#slide-0">http://damonoehlman.github.io/talk-spatial-couch-intro/-/#slide-0</a><br>
[2] <a class="moz-txt-link-freetext" href="https://gdal.org/drivers/vector/couchdb.html#vector-couchdb">https://gdal.org/drivers/vector/couchdb.html#vector-couchdb</a><br>
<br>
<div class="moz-cite-prefix">On 4/14/20 10:19 PM, Dan Little wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABqPoBbvoj+nPRmEVmLZoRjpxmFQfj4aHVo5pt4+SbS8SYUy8A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hey Folks!</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div>2. There's not been a priority put on editing in GM3.
That's been for a few reasons:</div>
<div> 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.</div>
<div> 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.</div>
<div> 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.</div>
<div> 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.</div>
<div><br>
</div>
<div>I'm interested in hearing feedback. Who really had done
what? What are the actual needs?<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
geomoose-psc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:geomoose-psc@lists.osgeo.org">geomoose-psc@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/geomoose-psc">https://lists.osgeo.org/mailman/listinfo/geomoose-psc</a></pre>
</blockquote>
<br>
</body>
</html>