[Mapserver-dev] Re: OGR Layers

[Steve Lime]

Other drivers ALWAYS ignore FILTERITEM. There is no provision to default
to the MapServer processor. I think that might get really confusing. 

Could the MapServer OGR driver be made smarter so that OGR sources with
SQL support (e.g. Oracle Spatial) behave like any other database driver
while those that don't behave like shapefiles? I rather see a change
like that than having to update all the other drivers for consistent
behavior. Seems like that would be pretty easy to document and would be
consistent with the way it works now. 

Steve

>>> Daniel Morissette <morissette at dmsolutions.ca> 09/30/03 8:45 AM >>>
Frank Warmerdam wrote:
> 
> I noticed that the OGR layer in mapserver doesn't seem to have any way
of
> passing an attribute query down to the OGR driver other than doing the
> request as an OGR SQL query.  What do you think of the idea of
treating
> the FILTER as an OGR attribute query if FILTERITEM isn't set, and
treating
> it as a mapserver-side filter if FILTERITEM is set?
> 

I can see why it could be nice to have OGR perform the filter sometimes,

but I'm not very comfortable with using FILTERITEM to control that.  Do 
you know if any of the other data sources (PostGIS, SDE, Oracle) support

this way of passing down the filter and how they do it?  We should 
probably implement things the same way in OGR as in the PostGIS/SDE
drivers.

I'm a bit worried that we would create confusion if the expression was 
handled differently when FILTERITEM isn't set.  AFAIK everywhere else in

MapServer the FILTERITEM/CLASSITEM/etc is optional when you use logical 
expressions (it is ignored) and then MapServer scans the expression 
itself to find the fields that it needs to read.  With that change, OGR 
would become an exception to this and I'm worried that someone could set

or unset FILTERITEM by accident and then would not understand why their 
expression doesn't work the same way as before.  (Until they go and read

the docs of course but that shouldn't be required in a consistent
system.)

I'll forward this to mapserver-dev to see what Steve and others think.

Daniel
-- 
------------------------------------------------------------
  Daniel Morissette               morissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------

_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev