[ZMapServer-Developers] Re: [ZMapServer-Users] Need help with PCL/ZCO Query

[Chris H. <ch...@op...>]

On Fri, 28 Jan 2005, Sean Gillies wrote:

> Forwarding this to the developers list ... comments at bottom.
Cool.  Brief comment from me below as well.

> 
> On Jan 27, 2005, at 2:57 PM, Chris Holmes wrote:
> 
> >> Etienne,
> >>
> >> You should allow_class(Query) instead of IQuery.  And make sure to
> >> restart, although I am sure you are doing that.
> >>
> >> Please keep in mind that I am evaluating a couple possible query
> >> interfaces for ZCO which will extend PCL like the ZCO.MapRenderer
> >> extends the underlying PCL functionality.  One possibility is for this
> >> query interface to behave like the Python DB API.  Another possibility
> >> is for the queries to act more like the OGC's GetFeatureInfo request.
> >> Currently, I am leaning towards this second way.
> >
> > I would definitely recommend the OGC approach, but if you're thinking  
> > of
> > OGC style I would recommend GetFeature of WFS instead of  
> > GetFeatureInfo of
> > WMS.  GetFeatureInfo was sort of added to provide some additional info  
> > for
> > WMS, whereas the GetFeature query is the central part of the WFS.  It
> > allows complex filters, handles, maxFeatures, specific properties, ect.
> > See
> > http://svn.refractions.net/geotools/geotools/trunk/gt/module/main/src/ 
> > org/geotools/data/Query.java
> > for how we did it in GeoTools (GeoAPI is quite similar I am sure).  Or
> > http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd which contains the  
> > xml
> > schema for a Query (which gt2 was modeled upon, though it currently
> > contains a few additions, like coordinate systems stuff, which will be  
> > in
> > 1.1 I am pretty sure).
> >
> > best regards, and keep up the great work
> >
> > Chris
> >
> 
> Chris,
> 
> I'm convinced to take the GetFeature route and have spent some time  
> today outlining a Python-ic way of expressing query filters that will  
> be a lot like the rule filter expressions under  
> cartography.mapping.Rule and ZCO.Style.  This means that a filter would  
> be a string and simple usage would be something like this
> 
>      shape = spatial.Polygon(...)
>      filter = 'f.the_geom.intersects(shape)'
>      names = ['*']                                         # all  
> attributes
>      results = layer.query(names, filter, maxfeatures=-1)  # no limit
>      for result in results:
>          ...
> 
> There are some cases where the filter would be evaluated in Python, and  
> for the cases that the layer pointed to some external WFS or a PostGIS  
> database I think the filter expression should be munged to XML or SQL.   
This is definitely the way we do it in geotools as well, and we've been 
extremely happy with it.  I still don't know exactly how mapscript works, 
if they have a filter model at all, but if you're not doing it already you 
should pass the filters to GEOS.  David Blasby is looking into generating 
GEOS code automatically from JTS, so geotools and your python filters 
would be using more or less the same code.  

> This would mean using the Python parser on the filter strings ... I'll  
> have to consider whether we are not better off with Filter objects.   
> I'll take a closer look at GeoTools2 over the weekend.  
We went with Filter objects.  I'd like to redo a few things, but we have
had good results with a visitor pattern.  It's nice because you can keep
the code that encodes to SQL or to WFS, or to XML (so you can serialize as
an ogc filter) separate.  You also may check out the SQLUnpacker (not well
named, as it does more than unpack sql, and it was one of my first
geotools (and professional programming) classes ever, so it could be a lot
more useable).  When passing a Filter expression to SQL or WFS oftentimes
it won't be able to process all filters.  But if you have a complex OR
filter you may be able to split the filter up to do some preprocessing in
the backend SQL (or WFS) so you don't have to load all features into
python.  The SQLUnpacker will recursively figure out if the filter can be
split up into pre and post-processing filters.  I don't know that I'm
explaining well, or making clear why this might be needed.  But ask
questions if you don't understand, I'm more than happy to hear the lessons
we learned.  But the filter package with these classes is available at: 
http://svn.refractions.net/geotools/geotools/trunk/gt/module/main/src/org/geotools/filter/

> Thanks for the  input!
My pleasure - you're doing great work, I think it's going to quite well.  
And I'm pretty positive my company will eventually be using it, as we are 
now moving solidly into wiki and plone space, and will want GeoServer 
integration and fun maps.  I'm sorry that I personally can't play more 
yet.

best regards,

Chris

> 
> cheers,
> Sean
> 
> --
> Sean Gillies
> sgillies at frii dot com
> http://users.frii.com/sgillies
> 

--