Layer Events and Editing

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Layer Events and Editing

Dan Little-2
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

James Klassen
It might be worthwhile to ask this question to the broader audience on geomoose-users.

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.

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).

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.

[1] http://damonoehlman.github.io/talk-spatial-couch-intro/-/#slide-0
[2] https://gdal.org/drivers/vector/couchdb.html#vector-couchdb

On 4/14/20 10:19 PM, Dan Little 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc


_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Brian Fischer

Good Morning,

 

I haven’t run across a use case yet needing editing in GeoMoose.  My general sense is with the ease of setting up PostGIS, AGOL, ESRI Enterprise Geodatabase most are using one of those options on the backend.  From my own work I have been typically seeing one of two ways to do editing from a web app.  Leaflet with a custom API to write to a database or AGOL app writing to ESRI feature services thru REST API.

 

This is just my two cents but agree with Jim it would be interesting to see what the broader audience thinks. Although I would worry they might not understand all of the work it would take to implement something like this and just say yes they want it.

 

Brian

 

  Brian Fischer
Project Manager - GIS | Vice President
Houston Engineering, Inc.
O 763.493.4522 | D 763.493.6664 | C 763.229.2734
   7550 Meridian Circle North, Suite 120
Maple Grove, MN • 55369
www.houstoneng.com 
Follow us: Facebook | Twitter | LinkedIn | YouTube

This entire message (including all forwards and replies) and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret, work-product, attorney-client or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

 

 

 

From: geomoose-psc <[hidden email]> On Behalf Of Jim Klassen
Sent: Tuesday, April 14, 2020 11:51 PM
To: [hidden email]
Subject: Re: [geomoose-psc] Layer Events and Editing

 

[External Email]


It might be worthwhile to ask this question to the broader audience on geomoose-users.

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.

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).

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.

[1] http://damonoehlman.github.io/talk-spatial-couch-intro/-/#slide-0
[2] https://gdal.org/drivers/vector/couchdb.html#vector-couchdb

On 4/14/20 10:19 PM, Dan Little 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc

 


_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Dan Little-2
I'm starting this out at the PSC level before expanding to -users. If we go to look at a broader audience then I'd like to have one or maybe two direction ideas to get feedback on rather than a general concept. Which is why I wanted to start with the smaller audience of the PSC in order to get a feel for what people think we can and should do.

On Wed, Apr 15, 2020 at 8:08 AM Brian Fischer <[hidden email]> wrote:

Good Morning,

 

I haven’t run across a use case yet needing editing in GeoMoose.  My general sense is with the ease of setting up PostGIS, AGOL, ESRI Enterprise Geodatabase most are using one of those options on the backend.  From my own work I have been typically seeing one of two ways to do editing from a web app.  Leaflet with a custom API to write to a database or AGOL app writing to ESRI feature services thru REST API.

 

This is just my two cents but agree with Jim it would be interesting to see what the broader audience thinks. Although I would worry they might not understand all of the work it would take to implement something like this and just say yes they want it.

 

Brian

 

  Brian Fischer
Project Manager - GIS | Vice President
Houston Engineering, Inc.
O 763.493.4522 | D 763.493.6664 | C 763.229.2734
   7550 Meridian Circle North, Suite 120
Maple Grove, MN • 55369
www.houstoneng.com 
Follow us: Facebook | Twitter | LinkedIn | YouTube

This entire message (including all forwards and replies) and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret, work-product, attorney-client or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

 

 

 

From: geomoose-psc <[hidden email]> On Behalf Of Jim Klassen
Sent: Tuesday, April 14, 2020 11:51 PM
To: [hidden email]
Subject: Re: [geomoose-psc] Layer Events and Editing

 

[External Email]


It might be worthwhile to ask this question to the broader audience on geomoose-users.

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.

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).

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.

[1] http://damonoehlman.github.io/talk-spatial-couch-intro/-/#slide-0
[2] https://gdal.org/drivers/vector/couchdb.html#vector-couchdb

On 4/14/20 10:19 PM, Dan Little 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc

 

_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Brent Fraser
In reply to this post by Dan Little-2
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" <[hidden email]>
> Sent: April 14, 2020 9:19 PM
> To: "GeoMOOSE PSC" <[hidden email]>
> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc


_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Dan Little-2
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 <[hidden email]> 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" <[hidden email]>
> Sent: April 14, 2020 9:19 PM
> To: "GeoMOOSE PSC" <[hidden email]>
> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc



_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Brent Fraser
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" <[hidden email]>
> Sent: April 15, 2020 9:50 AM
> To: "Brent Fraser" <[hidden email]>
> Cc: "GeoMOOSE PSC" <[hidden email]>
> 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 <[hidden email]>
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" <[hidden email]>
> > > Sent: April 14, 2020 9:19 PM
> > > To: "GeoMOOSE PSC" <[hidden email]>
> > > 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
> > [hidden email]
> > https://lists.osgeo.org/mailman/listinfo/geomoose-psc
> >
> >
> >


_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

TC Haddad
In reply to this post by Dan Little-2

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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Eli Adam
In reply to this post by Brent Fraser
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 <[hidden email]> 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" <[hidden email]>
> > Sent: April 15, 2020 9:50 AM
> > To: "Brent Fraser" <[hidden email]>
> > Cc: "GeoMOOSE PSC" <[hidden email]>
> > 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 <[hidden email]>
> 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" <[hidden email]>
> > > > Sent: April 14, 2020 9:19 PM
> > > > To: "GeoMOOSE PSC" <[hidden email]>
> > > > 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
> > > [hidden email]
> > > https://lists.osgeo.org/mailman/listinfo/geomoose-psc
> > >
> > >
> > >
>
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Eli Adam
On Wed, Apr 15, 2020 at 3:52 PM Eli Adam <[hidden email]> wrote:

>
> 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.
>

P.S. I'm excited that editing might be in the works!  Either of the
routes being suggested could work too.

> Best regards, Eli
>
> On Wed, Apr 15, 2020 at 9:06 AM Brent Fraser <[hidden email]> 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" <[hidden email]>
> > > Sent: April 15, 2020 9:50 AM
> > > To: "Brent Fraser" <[hidden email]>
> > > Cc: "GeoMOOSE PSC" <[hidden email]>
> > > 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 <[hidden email]>
> > 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" <[hidden email]>
> > > > > Sent: April 14, 2020 9:19 PM
> > > > > To: "GeoMOOSE PSC" <[hidden email]>
> > > > > 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
> > > > [hidden email]
> > > > https://lists.osgeo.org/mailman/listinfo/geomoose-psc
> > > >
> > > >
> > > >
> >
> >
> > _______________________________________________
> > geomoose-psc mailing list
> > [hidden email]
> > https://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|

Re: Layer Events and Editing

Brent Fraser
In reply to this post by Dan Little-2
 
 -------- Original Message --------
> From: "Dan Little" <[hidden email]>
> Sent: April 14, 2020 9:19 PM
> To: "GeoMOOSE PSC" <[hidden email]>
> Subject: [geomoose-psc] Layer Events and Editing
>

> 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.
 
 For those interested the "Roll your own" approach, I ran across
 uMap (https://umap.openstreetmap.fr/en/) an Open Source project
 with feature editing and saving. There was a note on using
 https://github.com/umap-project/Leaflet.Storage.  I haven't located
 the protocol doc yet (if any exists) but I did monitor the client /server
 conversation while creating features on their demo site.  Looks
 fairly straightforward.
 
 Best Regards,
 Brent Fraser


_______________________________________________
geomoose-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geomoose-psc