[Geomoose-users] Services abstraction, what's the status of this?

Wed Jun 12 14:13:14 PDT 2013

Not exactly.  We are still in the planning stages with regard to feature editing.  All we know for sure is that we will see a demand for it.  We haven't yet tried the WFS-T approach (another item on my to-do list).  We don't have GeoServer implemented at this time.  As you've seen from me in the past, we are not allowed to have PostGIS (per IT department policy).  So those are my major restrictions.  

So with that in mind, I would entertain different options for feature editing which would work within my stipulations.  Conceivably, we could use WFS-T with our ESRI back end, although they sometimes seem to have their own version of "open standards" and "interoperability".

-----Original Message-----
From: geomoose-users-bounces at lists.osgeo.org [mailto:geomoose-users-bounces at lists.osgeo.org] On Behalf Of Eli Adam
Sent: Wednesday, June 12, 2013 5:07 PM
To: James Klassen
Cc: geomoose-users at lists.osgeo.org
Subject: Re: [Geomoose-users] Services abstraction, what's the status of this?

Bob and Bob,

Are there reasons that you don't want to do editing with WFS-T?
http://www.geomoose.org/docs/vector_layers/geoserver_setup.html

Eli

On Wed, Jun 12, 2013 at 1:39 PM, James Klassen <klassen.js at gmail.com> wrote:
> Also, most of the items you listed are more appropriate as extensions 
> than services at least in so far as they interact with GeoMoose.
>
> As an aside, some things that are now services may be moved into 
> JavaScript within GeoMoose if feasible.  Modern browsers are much 
> better than the situation was in 2006.  So things like printing, 
> select, identify, etc. may be doable in the browser and backed by 
> WMS/WFS rather than needing direct server side help.  This greatly 
> simplifies the security model on the server and also helps people who 
> want to do incremental updates as it uncouples GeoMoose version from 
> MapServer version and allows things like multiple MapServer versions, 
> a mix of MapServer and GeoServer (or others) and having layers sourced from different servers altogether (cloud like).
>
> On Jun 12, 2013 3:31 PM, "James Klassen" <klassen.js at gmail.com> wrote:
>>
>> The short answer is users are encouraged to write their own services 
>> conforming to the GeoMoose service API to do whatever tasks are 
>> necessary in whatever environment best fulfills their needs.
>>
>> The GeoMoose project currently maintains some services in PHP.  I 
>> have implemented custom services (simultaneously compatible with 
>> multiple versions GeoMoose and other software) in Perl, Python, Ruby 
>> (CGI and Rails), and C over the years.
>>
>> There was talk at FOSS4G-NA and at the last PSC meeting about 
>> reworking the services that are included as part of the demo.  The 
>> primary reason is to remove some artificial limitation based around accessing local mapfiles.
>> This work would likely not be done in PHP.  However, this doesn't 
>> mean PHP services will stop working.  There is a published API for 
>> how GeoMoose interacts with services and there are no plans to break 
>> backwards compatibility with that API.
>>
>> Note, however, future demos (essentially a configuration) may be 
>> based on future default services, which may change some file layouts.
>>
>> On Jun 12, 2013 2:41 PM, "Basques, Bob (CI-StPaul)"
>> <bob.basques at ci.stpaul.mn.us> wrote:
>>>
>>> Bob,
>>>
>>>
>>>
>>> Both would be supported, and more, Jim has indicated PYTHON as an 
>>> option as well.
>>>
>>>
>>>
>>> bobb
>>>
>>>
>>>
>>>
>>>
>>> From: Bistrais, Bob [mailto:Bob.Bistrais at maine.gov]
>>> Sent: Wednesday, June 12, 2013 2:22 PM
>>> To: Basques, Bob (CI-StPaul); geomoose-users at lists.osgeo.org
>>> Subject: RE: Services abstraction, what's the status of this?
>>>
>>>
>>>
>>> I'm a PHP user.  Since we have a number of applications built on 
>>> GeoMoose/PHP, I'm concerned- would I need to convert everything to 
>>> Perl in future upgrades, or do you mean that PHP AND Perl would be 
>>> supported for services?
>>>
>>>
>>>
>>> Certainly interested in the feature editing piece.  AVL is neat but 
>>> I think my anticipated needs would require feature editing more.
>>>
>>>
>>>
>>> From: geomoose-users-bounces at lists.osgeo.org
>>> [mailto:geomoose-users-bounces at lists.osgeo.org] On Behalf Of 
>>> Basques, Bob
>>> (CI-StPaul)
>>> Sent: Wednesday, June 12, 2013 3:00 PM
>>> To: geomoose-users at lists.osgeo.org
>>> Subject: [Geomoose-users] Services abstraction, what's the status of 
>>> this?
>>>
>>>
>>>
>>> All,
>>>
>>>
>>>
>>> So, I'm setting up a new install of GeoMoose (among other things, 
>>> read
>>> on) and wondering about where the services abstraction ideas are 
>>> currently at?  While I know PHP is popular, I much prefer PERL for 
>>> the services side of things.
>>>
>>>
>>>
>>> I would like to use PERL in place of PHP for example.  I just want 
>>> the option of using another language.  I know this has been talked 
>>> about in the recent past and I guess I'm looking harder at it now.
>>>
>>>
>>>
>>> So,
>>>
>>> *          Where in the release cycle is this capability at?
>>>
>>> *          Should I (we) progress this internally first and then just
>>> pass back to GeoMoose as a pass fail sort of endeavor for inclusion 
>>> in GeoMoose, or . . .
>>>
>>> *          Put out a spec and ask for bids here?, or . . . ???
>>>
>>>
>>>
>>> I also have some more stuff coming down the line, but figured I 
>>> would start with the above first to get a conversation going here.
>>>
>>>
>>>
>>> --------------
>>>
>>>
>>>
>>> Future stuff:
>>>
>>> *          Feature updating (PUSH) from a service.  (IE. GPS point
>>> Tracking, and Weather overlays)
>>>
>>> *          Alternate map Views (spawning service from GeoMoose) for
>>> OpenLayers and 3D(HTML5) constructs, and other reporting packages . . .
>>>
>>> *          Old timey (City of Saint Paul) Popup capabilities (some of the
>>> GeoMoose developers know what I'm talking about here) or something 
>>> very close.
>>>
>>> *          Addition of a optional service side (server component)
>>> construct for handling of feature editing in GeoMoose.  I know this 
>>> is a whole new side of things, and it can become it's own thing if 
>>> need be, project wise.  I haven't started this here yet, but it's 
>>> next after AVL has settled down. See next item
>>>
>>> *          Addition of a AVL (location tracking) service (server
>>> component).  I actually have this well on it's way already and am 
>>> wondering about how to integrate it with GeoMoose as well as put the 
>>> project out as OpenSource, and with GeoMoose or on it's own as a 
>>> companion piece.  Does it make and sense to put it under the 
>>> GeoMoose project umbrella, or should it be it's own  thing?  My vote is to add it to GeoMoose in some form.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Geomoose-users mailing list
>>> Geomoose-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>
_______________________________________________
Geomoose-users mailing list
Geomoose-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geomoose-users