Hi Frank, thank you very much for your help!
With the line CONFIG "PGSQL_OGR_FID" "fieldname" in the Map section everything works very well. But now I've still got one more question, just an understanding one. I've got testet the "Virtual Spatial Data" with a MySQL Database a few days ago and there everything works well without a line like that. Where could be the reason? Best Regards Christian -------- Original-Nachricht -------- Betreff: Re: [UMN_MAPSERVER-USERS] Problem with Mapserver Virtual Spatial Data (ogr) Datum: Thu, 18 May 2006 16:55:40 -0400 Von: Frank Warmerdam <[EMAIL PROTECTED]> An: [email protected] > Christian Wilmes wrote: > > Hello, > > > > first of all sorry for cross posting, but I've got no idea where I have > to > > search the mistake so I post it to the GDAL and the Mapserver > Mailinglist. > > > > I'm trying to publish a WFS-Server. The Data (only Point-Data) are in a > > PostgreSQL-Database (no PostGIS!). So the connection to the data is over > > "Virtual Spatial Data". The getCapabilities and DescribeFeatureType > request > > both work very well. Only the GML-Document getting with the getFeature > > request is not correct. The number of features in the GML-Document are > > correct too every time, but the features are not in the Bounding Box. > The > > features in the GML-Document are always the feature which are on the top > of > > the table they come from. Only the number of feature is correct. The MBR > > (Minimum Boundig Rectangle) on the top of the GML-Document amasingly the > > correct one. So it don't fit to the features in the document. Testing > the > > connection with "ogrinfo" and a Boundig-Box is working correct. If I'm > > trying to make a WMS-Server with the same Data and the same OGR-file it > > works very well. > > Christian, > > I believe the problem is that OGR is not successfully identifying a column > in the table to use as a "feature id". For WFS queries the results are > fetched in two passes for various historical reasons. The first pass > results in a fetch of the feature ids of the features, and the second > pass fetches features by id. Unfortunately, if OGR cannot select a good > unique feature id column, then it assigns them serially. The first pass > has the spatial query "in place" so the resulting fids are 1, 2, 3, etc. > But the second pass does not have the spatial filter in place, so it ends > up returning the wrong features. > > Ideally you would ensure you have a single integer column setup as a > primary index for your postgres table. If that is the case it *should* > get used as the fid. > > If not, you may be able to include the following line in your MAP file > (in the MAP section, not the layer): > > CONFIG "PGSQL_OGR_FID=fieldname" > > to indicate what fieldname should get used as FID. This should be > available with GDAL/OGR 1.3.2. > > PS. the much talked about one-pass-query would resolve this problem. > > Good luck, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > [EMAIL PROTECTED] > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | President OSGF, http://osgeo.org -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
