Hi Flavio,
even with a depth of between 6 and 10 I get no matches.
D:\bart\FWTools1.3.6\bin>shptree D:\bart\dtb\dtb_subset\dtb2000_sym.shp 10
creating index of new LSB format
D:\bart\FWTools1.3.6\bin>ogrinfo D:\bart\dtb\dtb_subset\dtb2000_sym.shp
dtb2000_sym -spat 60000 400000 90000 410000
INFO: Open of `D:\bart\dtb\dtb_subset\dtb2000_sym.shp'
using driver `ESRI Shapefile' successful.
Layer name: dtb2000_sym
Geometry: 3D Point
Feature Count: 0
Extent: (50000.000000, 390000.000000) - (99997.706000, 419998.443000)
Layer SRS WKT:
PROJCS["Rijksdriehoekstelsel_New",
GEOGCS["GCS_Amersfoort",
DATUM["Amersfoort",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Double_Stereographic"],
PARAMETER["False_Easting",155000.0],
PARAMETER["False_Northing",463000.0],
PARAMETER["Central_Meridian",5.38763888888889],
PARAMETER["Scale_Factor",0.9999079],
PARAMETER["Latitude_Of_Origin",52.15616055555555],
UNIT["Meter",1.0]]
CTE: String (8.0)
If I delete the qix file all is fine:
D:\bart\FWTools1.3.6\bin>del D:\bart\dtb\dtb_subset\dtb2000_sym.qix
D:\bart\FWTools1.3.6\bin>ogrinfo D:\bart\dtb\dtb_subset\dtb2000_sym.shp
dtb2000_
sym -spat 60000 400000 90000 410000
INFO: Open of `D:\bart\dtb\dtb_subset\dtb2000_sym.shp'
using driver `ESRI Shapefile' successful.
Layer name: dtb2000_sym
Geometry: 3D Point
Feature Count: 39100
Extent: (50000.000000, 390000.000000) - (99997.706000, 419998.443000)
Layer SRS WKT:
PROJCS["Rijksdriehoekstelsel_New",
GEOGCS["GCS_Amersfoort",
DATUM["Amersfoort",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Double_Stereographic"],
PARAMETER["False_Easting",155000.0],
PARAMETER["False_Northing",463000.0],
PARAMETER["Central_Meridian",5.38763888888889],
PARAMETER["Scale_Factor",0.9999079],
PARAMETER["Latitude_Of_Origin",52.15616055555555],
UNIT["Meter",1.0]]
CTE: String (8.0)
OGRFeature(dtb2000_sym):4665
CTE (String) = B0307
POINT (85063.820000000007 407501.06300000002 8.6)
OGRFeature(dtb2000_sym):4666
CTE (String) = B0307
POINT (85056.664000000004 407494.31300000002 8.6)
OGRFeature(dtb2000_sym):4667
CTE (String) = B0307
POINT (85060.241999999998 407497.68800000002 8.6)
I've opened up the following bug:
http://trac.osgeo.org/gdal/ticket/1790
Best regards,
Bart
On 9/4/07, Flavio Hendry <[EMAIL PROTECTED]> wrote:
>
> Hi Bart
>
> Read this? (I had even MapServer crashing when using default on points):
>
> http://umn.mapserver.ch/MapServer/en/shapetree.htm, on the bottom:
>
> SYNTAX: shptree <shpfile> [<depth>]
>
> <depth> (optional) is the maximum depth of the index to create, default
> is 0 meaning that shptree will calculate automatically the default depth
> (calculated so, that a quadtree cell contains 8 shapes). Do not use the
> default depth with point files, here a depth between 6 and 10 works fine.
>
> Mit freundlichem Gruss / Best Regards
> Flavio Hendry
>
> ----------------------------------------------------------------
> TYDAC Web-Site: http://www.tydac.ch
> TYDAC MapServer: http://www.mapserver.ch
> ----------------------------------------------------------------
> ############ Mit freundlichen Gruessen / Kind Regards
> ############ mailto:[EMAIL PROTECTED]
> ############ TYDAC AG - http://www.tydac.ch
> #### #### Geographic Information Solutions
> #### #### Luternauweg 12 -- CH-3006 Bern
> ############ Tel +41 (0)31 368 0180 - Fax +41 (0)31 368 1860
> ----------------------------------------------------------------
>
>
> -----Original Message-----
> From: Bart van den Eijnden <[EMAIL PROTECTED]>
> To: MAPSERVER-USERS@LISTS.UMN.EDU
> Date: Mon, 3 Sep 2007 17:21:46 +0200
> Subject: [UMN_MAPSERVER-USERS] strange problem with quadtree index
>
> > Hi list,
> >
> > I have a 3D POINT shapefile dataset, and if I do a query using
> > Mapserver (or
> > ogrinfo for that matter) when the shapefile has a quadtree index file
> > associated (level 4), it does not find any features within the box.
> >
> > If I delete the qix file, it correctly finds all the features in the
> > box,
> > but ofcourse performance is poor.
> >
> > Any pointers on this problem? Or is the dataset needed to find out
> > the cause
> > of such an issue (it's quite big unfortunately)?
> >
> > Best regards,
> > Bart
>
>
>
