[geomoose-psc] Layer Events and Editing

Eli Adam eadam at co.lincoln.or.us
Wed Apr 15 15:52:50 PDT 2020


I think that editing is a great feature, one that previously
distinguished GeoMoose as one of the more full-complete options.  It
is also a niche need,  maybe 10% of "online GIS" users need editing.
We happen to be in that 10% that needs editing (or to find an
alternative like QGIS).  Brian, from your experience, what percent of
users generally need editing or could improve their processes with
editing?

(B.) On Geoserver, we should let people worry about their own install
footprint.  If they want to edit, then maybe they'll also go the
GeoServer for WMS, etc route.  It can be a good option and if you're
already running a java environment, the prefered one as well.  Being
an OGC standard is another benefit here in that we can implement the
standard and then people can put whatever they want on the other side.
GeoServer may be a lot but it could be the right choice for many
people.  TinyOWS may or may not work for people, not having had
much/any attention for some time.  It does still seem to be widely
used.  I think that deegree is an option too.

(C.) "Rolling our own" has benefits both ways.  If going this way,
going along with something already working (and separately maintained)
has some benefits.  Jim's CouchDB suggestion has some appeal in this
regard.  Jim, that presentation is a little out of date.  Do you know
of more current things or if this is commonly in use this way?
Rolling our own (or selecting one pre-rolled option) puts more
responsibility on selecting that option.  Abstracting that choice away
with WFS-T is nice but we do have to be bound by the realities of
available implementations.

(D.) WFS-T... is usually overkill when you just want to share a layer
between a few GeoMoose users.  Yes, usually it is overkill.  But
overkill prevents having to define the terms of "share a layer between
a few GeoMoose users."  Tanya's use case might be on the periphery of
a simple "share layers" but is well within WFS-T.

I like WFS-T for being able to test with clients like QGIS but realize
until/unless WFS-T gains more implementations or attention, we may
have to look at other things.

I think Jim's very simple use case is very useful; "here's a spatial
feature, something needs to be done in this area."  And good point
that much of the functionality on the client end is already there.

Brent, that's interesting to hear that TinyOWS is good in use, even if
light on documentation.  You've got a lot of experience with this type
of editing and tested the previous versions very thoroughly.

Best regards, Eli

On Wed, Apr 15, 2020 at 9:06 AM Brent Fraser <bfraser at geoanalytic.com> wrote:
>
> Hi Dan!
>
>  WFST is not a hard requirement, I just like using standards so I can mix
> and match clients and servers to find the bet combination.  On the server
> side we use PostGIS with django for most things; not sure how CouchDB would
> fit in...
>
>  Brent
>
>
>
>  -------- Original Message --------
> > From: "Dan Little" <theduckylittle at gmail.com>
> > Sent: April 15, 2020 9:50 AM
> > To: "Brent Fraser" <bfraser at geoanalytic.com>
> > Cc: "GeoMOOSE PSC" <geomoose-psc at lists.osgeo.org>
> > Subject: Re: [geomoose-psc] Layer Events and Editing
> >
> > 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
> > >
> > >
> > >
>
>
> _______________________________________________
> geomoose-psc mailing list
> geomoose-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geomoose-psc


More information about the geomoose-psc mailing list