AW: VS: [mapserver-users] Mapserver search performance

[Eichner, Andreas - SID-NLKM]

Hi. The first thing to note: editing a DBF with Excel  Co. seems to be
a _really_ bad idea. Those who tried that got Shapes wired to wrong
attribute lines. So DBF, SHP, SHX and QIX files have to be used as a
whole or will usually end up in a corrupted dataset. I would suggest
ogr2ogr from the GDAL suite. It's fast, reliable, can do joins and is
aware of the mentioned dependencies.
Please note that such a fileset can only provide a spatial index via a
QIX file. This is OK if you only want to filter by BBOX. If you want to
filter by attribute all lines of the DBF still need to be scanned. In
such cases it's wise to use ogr2ogr to split the data in pre-filtered
sets.
Using a more sophisticated database like PostGIS or SpatialLite can help
you implement more complex scenarios. Since MapServer has no native
driver for SpatialLite it's probably not as fast as it is supposed to
be. This mostly depends on OGRs implementation.

Greetings

 Is there a DBF editor out
 there that can be used to import the fields from any external data
 source into the shapefile attribute DBF without affecting the
 structure? I looked for a lot but they do not have the capability of
 doing a JOIN based on a common field and pulling data into the
 shapefile DBF automatically.
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

AW: VS: [mapserver-users] Mapserver search performance

[Eichner, Andreas - SID-NLKM]

Hi,

AFAIK dBase files don't provide an index themselves and there's no other
way to provide one. shptree only creates an spatial index. Therefore
only queries like 'does this geometry touch/intersect/lie within a given
rectangle'can be accelerated.

 I tried the shptree tool but did not see any performance improvement.

So this becomes clear: By doing a JOIN MapServer basically runs a loop:
for each geometry that matches search withing external data for a line
matching the join condition.

 Could it be because all of this information that I require is coming
 from an external DBF file that I join to the layer/shape's DBF? Will
 including all these fields/information in the shape's DBF file itself
 help?

I'm pretty sure that this would help, since this would avoid the
(unaccelerated) join. With a database like PostgreSQL/PostGIS or SQlite
it's basically the same problem: if you don't create an appropriate
index for the join condition, this becomes an costly operation. Although
those columns are usually primary and foreign key columns with
appropriate index and the join condition is usually a simple equality
match.
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users