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

Eli Adam eadam at co.lincoln.or.us
Thu Jun 13 09:34:38 PDT 2013 

Exchanges based on a standard is a good direction.

RFC-5, http://www.geomoose.org/rfc/rfc-5.html, addresses some of this
and uses WFS.  Andrew or Brian might have more of a status update on
that.

Eli

On Thu, Jun 13, 2013 at 12:38 AM, ItacaSoft <itacasoft at gmail.com> wrote:
> Hello,
> I took the suggestion of James and I'm developing my own flavor of API in
> Delphi + TatukGIS.
> My 2 cents about the "Service abstraction" matter: I strongly believe that
> the ability to write server side extensions and API in whatever language
> could be a definitive plus for GeoMoose.
> For this to work better, I suggest to use more standard protocols for the
> API. For instance, the API and the javascript side should exchange feature
> data using GML or GeoJson or other standard/widely used protocol, so that
> one can save valuable time using libraries - both commercial (e.g.:
> TatukGIS, Esri) and open source (e.g.: SharpMap) - that already are able to
> parse and manage this data.
> Using standard protocol whenever possible should also help to diffuse the
> use of the GeoMoose project.
>
> Fabrizio
>
>
> On Wed, Jun 12, 2013 at 11:26 PM, Eli Adam <eadam at co.lincoln.or.us> wrote:
>>
>> On Wed, Jun 12, 2013 at 2:13 PM, Bistrais, Bob <Bob.Bistrais at maine.gov>
>> wrote:
>> > 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.
>>
>> Ah, right.  I recently noticed that the FeatureServer website has been
>> polished up, http://featureserver.org/ and that SpatialLite is now a
>> supported WFS-T backend.  This could be convenient for mobile or
>> offline connections as well.
>>
>> >
>> > 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".
>>
>> My understanding is that sometimes the ESRI defaults don't make it
>> easy to implement OGC standards well, but that there is a way to
>> eventually do it (sometimes with hurdles or non-intuitive
>> requirements).  The OGC has a listing here,
>> http://www.opengeospatial.org/resource/products/details/?pid=868
>>
>> HTH, Eli
>>
>> >
>> >
>> > -----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
>> >
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>
>

More information about the Geomoose-users mailing list