[Mapserver-dev] Query efficiency

[Chris G. Nicholas]

I think people should keep in mind two clear requirements when discussing queries: 

a) the ability of MMS to act as an OGC WFS.

b) The ability of mapscript applications to easily interact with the underlying datasources, perhaps beyond merely presenting them as html to browsers.

I can attest that is is very unclear how a mapscript application can actually perform logic using queries: We are finding it far easier to draw maps using the Java/SWIG interfaces, but for queries to extract layer connection information from the underlying MapFile, and then just go "direct" to PostGIS in order to get full-blown java.sql.ResultSet objects. 

Chris

-----Original Message-----
From:	Steve Lime [mailto:steve.lime at dnr.state.mn.us]
Sent:	Wed 3/3/2004 12:50 PM
To:	mapserver-dev at lists.gis.umn.edu; dblasby at refractions.net
Cc:	
Subject:	Re: [Mapserver-dev] Query efficiency
Your basic understanding is right on.

There are several reasons querys are different than draws. The basic
one is
that drawing was the easiest place to start when doing the work to
integrate
a variety of data sources. Fundamentally the selection work (really
these are
bounding box queries) necessary for drawing is very simple easily
supported
by all data sources. The same is not true for queries. Early versions
of PostGIS
may not have even supported true polygon intersection tests. The other
complicating factor has been that query results are not used for
anything until
after a query is complete. When drawing you basically read a feature
and then
render it. That's not possible with queries. Templates enter the
picture afterwords
and sometimes one layers result set may supercede anothers. I look at
it like
I do labeling. You need the big picture to decide how to proceed.

I see two ways to fix things:

1) Add a query API that mimics the current layer api. All datasources
could then
choose to implement a specific version of each query function, other
could fall back
on the current method. We'd need an abstract queryinfo stucture similar
in concept
to the layerinfo structure.

2) Store the retrieved features apart from the database (Note that we
coniciously
have made a decision like this already by using MapServer expressions.
Filters are
one way around that.) and hit those for subsequent passes through the
result
set instead of the database.

Steve

>>> David Blasby <dblasby at refractions.net> 3/3/2004 1:42:45 PM >>>
I dont want to be too controversial, but I dont like the current query

behaviour.  (This is from the PostGIS/database perspective; it looks 
good for shapefiles)

For example, if we have a database of Points (say apartments, golf 
courses, parks, and police stations).

You do a query for police stations.  The database will get a query 
something like this:

SELECT geom_point, id FROM mypoints WHERE type ='police station';

Lets say it gets 3 points back - id=56, id=98, id=127.

It then makes these type of requests from the database (they're
actually 
more complex, but...):

SELECT geom_point, id, type FROM mypoints WHERE id =56;
SELECT geom_point, id, type FROM mypoints WHERE id =98;
SELECT geom_point, id, type FROM mypoints WHERE id =127;

 From the shapefile perspective, the first query reads through the DBF

file, and the latter set of queries are very fast grabs (based on row 
id) from the .shp and .dbf files.

Perhaps someone could tell me why there's a difference between the 
normal (i.e. for drawing) requests and query requests.  It would make 
many of the datastores much simplier and maintainable.

I'm still a little fuzzy on the entire query system, so I could be
wrong 
on the above,
dave
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu 
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev