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

[Jim Klassen]

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