[Geomoose-users] unifying select.php, query.php and identify.php

Tue Nov 20 09:52:18 PST 2012

Overall I like it.

The idea behind the GeoMoose service model is that it should be easy to adapt to existing systems (either directly (mapbook only), via a simple translator script, or by a simple extension of the existing app).  With that in mind, I would recommend that the classes be namespaced somehow.  I don't know about PHP, but there are a number of frameworks that I could see being used in Python and Ruby where "Service" et.al. would be conflicting names.  

(The class names and implementation don't necessarily have to be the same everywhere, so it doesn't really matter to me personally which names are picked for the PHP version.)

On Nov 20, 2012, at 10:52 AM, Andrew Sheppard wrote:

> Thanks for the feedback, how about this plan:
> 
> - Start by creating a simple "Service" base class with default dispatch(), parseRequest(), execute() and sendResponse() methods.
> - Extend this class with a "FeatureService" subclass, containing a more complex sendResponse() that supports multiple modes for returning lists of features to the client (text list, map image, vectors, optional server-side persistence).
> - Refactor select.php, query.php and identify.php to become subclasses of FeatureService, moving the existing query processing code in each service into custom parseRequest() and execute() methods.
> - Finally, the remaining services could be refactored to extend either FeatureService or the base Service class where appropriate.
> 
> The new classes will need to be in PHP for compatibility with the existing service code, but I would be interested in working together on writing a high level API description that could be ported to other languages (e.g. Python, Ruby, Perl).  This will be similar to the existing services documentation but be more explicit about the different steps in parsing, executing, and responding to a request.  If there is interest we could ultimately include the base service classes in each language as part of the standard GeoMOOSE codebase.
> 
> Should I start a page on the wiki to work out the definitions of these classes and methods?
> 
> S. Andrew Sheppard
> GIS/Web Developer
> Houston Engineering, Inc.
> 
> -----Original Message-----
> From: Jim Klassen [mailto:klassen.js at gmail.com] 
> Sent: Tuesday, October 23, 2012 10:26 PM
> To: Brian Fischer
> Cc: Andrew Sheppard; GeoMOOSE Users List
> Subject: Re: [Geomoose-users] unifying select.php, query.php and identify.php
> 
> On Oct 23, 2012, at 9:55 PM, Brian Fischer wrote:
> 
>> Jim, just a comment to your last point.  I think this documentation is already started with http://www.geomoose.org/developer/services.html#services-understanding.  It probably could be re-written a bit with a  tutorial approach but I think most of the content is already there.
> 
> Cool.  I've been all over the docs recently, but can't remember what all is in there and what is up to date.
> 
>> 
>> I think what really needs more documentation and an updated doc is this stuff.  http://www.geomoose.org/docs/services.html#services-protocol  I don't think allof these options are valid in GM 2.6 and there are probably some new ones.  What people really need to know is how to send stuff from GeoMoose to the services and how to format the results so GeoMoose can display them in a useful manner.
> 
> Fully agree.  If I get a chance I will look at this, but don't let that stop anyone else who may beat me to it.  I am starting to think there is a lot of cool stuff in GeoMoose that people don't know about because the docs aren't as complete as they could be.
> 
>> 
>> Brian Fischer, CFM
>> Principal | GIS Project Manager 
>> Houston Engineering, Inc.
>> O 763.493.4522 | D 763.493.6664 | M 763.229.2734
>> 
>> -----Original Message-----
>> From: geomoose-users-bounces at lists.osgeo.org [mailto:geomoose-users-bounces at lists.osgeo.org] On Behalf Of Jim Klassen
>> Sent: Tuesday, October 23, 2012 11:37 AM
>> To: Andrew Sheppard
>> Cc: GeoMOOSE Users List
>> Subject: Re: [Geomoose-users] unifying select.php, query.php and identify.php
>> 
>> In terms of functionality and maintainability, I think your proposal is a move in the right direction.
>> 
>> How does this handle identify mode?  Add centroids to query results?
>> 
>> I know this is already being violated, but I would think separating the PHP files meant only as libraries and the PHP files meant to be called from the web would be a good idea.  Maybe making a php/libs (or whatever is common in PHP land).
>> 
>> On a more general level... Do we need to retain (or create) a simpler service for the sake of an example of the minimum it takes to write a service?  This could be done in more of a tutorial form than in production code.  I worry that as the codebase gets more sophisticated, that we might make the initial learning curve too steep for newcomers unless we consciously keep a simplified "these are the steps that need to happen" version around.
>> 
>> On Oct 23, 2012, at 11:07 AM, Andrew Sheppard wrote:
>> 
>>> Hi all,
>>> 
>>> I would like to propose unifying some common features in select, query, and identify into a shared module to facilitate feature re-use and simplify maintenance.  For example, identify could benefit from the highlighting provided in select, and query could benefit from select's buffering and (potential) vector interaction capabilities*.  This refactoring will also simplify any long-term transition to another scripting language (e.g. Python.)
>>> 
>>> At some point, the entire service workflow could be abstracted into a fully generalized "Service" class.  However, for now I am only interested in unifying the output loop in each of the three services - leaving the input parsing and query processing unique to each service.  In spite of the similarities, each of the services has a slightly different way of producing output:
>>> 
>>> *identify* produces a list of results and centroid coordinates.  No geometries are provided for highlighting or buffering.
>>> 
>>> *query* produces a list of results with full feature coordinates for zooming, as well as an on-the-fly geometry layer for highlighting results.  The layer is not saved on the server, to avoid filling up the disk with large query result sets.  This means buffering is not readily available.
>>> 
>>> *select* produces a list of results, and a semi-persistent geometry layer that can be used by the server for follow-up requests (e.g. buffering).  As I mentioned previously, it was relatively straightforward to add WFS support to this layer to support full vector interactivity on the client.
>>> 
>>> I would like to move the output routines from query and select into a separate "output.php", so that all three services can take advantage of one of two output modes:
>>> - a query-style in-memory highlight layer, or
>>> - a select-style semi-permanent layer with support for buffering and vector interaction
>>> 
>>> Are there any important caveats I should keep in mind?
>>> 
>>> (* See http://osgeo-org.1560.n6.nabble.com/Geomoose-users-utilize-wfs-for-select-service-tt4984390.html)
>>> 
>>> S. Andrew Sheppard
>>> GIS/Web Developer
>>> Houston Engineering, Inc. 
>>> _______________________________________________
>>> 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
> 