[Mapserver-dev] Query efficiency

Steve Lime steve.lime at dnr.state.mn.us
Wed Mar 3 17:51:59 EST 2004

I'll put MapServer for the sake of MapServer before the others, your
points are certainly valid. WFS could only benefit from work in this
area, regardless of approach. MapScript is another matter. It could
certainly benefit by behaving more like common query APIs. The recent
join work to this approach and I think it worked well. Is it worth the
effort though. In my opinion it's perfectly valid to rely on additional
interfaces when using MapScript. That's part of the attraction of
languages like PHP and Perl in the first place.


>>> "Chris G. Nicholas" <cgn at globexplorer.com> 03/03/04 3:19 PM >>>
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

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


-----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
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
a variety of data sources. Fundamentally the selection work (really
these are
bounding box queries) necessary for drawing is very simple easily
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
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
set instead of the database.


>>> 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
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
on the above,
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu 
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu

More information about the mapserver-dev mailing list