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

[Jim Klassen]

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