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

[Basques, Bob (CI-StPaul)]

Andrew,

I think you might want to look at the generalized "Service" class a little harder up front.  Your idea seems to be a rather big change in things, so I'm wondering about the feasibility of setting up the generalized approach up front as an additional way into queries for the near term, and building on the side (so to speak) while marking the previous methods for deprecation at the point of being superseded by the completion of the new process(es).  I think you may end up rebuilding everything again once you think more on the "Service" class idea.

This also leave room for others to think about how to contribute other language support (my favorite is PERL) along side of the query connector build out.  I also think there are some who might be interested in adding Ruby support as well.  Documentation can also be brought along in parallel.

Just trying to convey some ideas about looking at the implications a little harder.  Don't let this get in the way of your moving forward with your ideas, which I hardily support BTW.

Bobb


>>  -----Original Message-----
>>  From: geomoose-users-bounces at lists.osgeo.org [mailto:geomoose-
>>  users-bounces at lists.osgeo.org] On Behalf Of Andrew Sheppard
>>  Sent: Tuesday, October 23, 2012 11:07 AM
>>  To: GeoMOOSE Users List
>>  Subject: [Geomoose-users] unifying select.php, query.php and
>>  identify.php
>>  
>>  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