I've noticed similarly strange behavior when running a query on inline OVF data
(also with PHP mapscript - details below). My virtual layer reads from a table
with a multi-column primary key in a MySQL database. I get three types of
funky behavior with this:
1) If I don't specify an <FID> in my inline OVF, querying works as expeced
until I call $layer->close() - Apache reports "premature end of script headers"
only when I try to close the queried layer.
2) If I change my primary key to an auto-numbered field and set <FID>id<FID>
(where id is my auto-numbered field), I get "Unable to identify field 'id'".
3) If I set <FID>some_other_field</FID> then everything works as expected -
even if the values in some_other_field are not unique.
Any ideas?
Tim
Details:
MapServer 4.6.1
GDAL/OGR 1.2.6
PHP 5.0.5
Mapfile snipit (this is the only version that works):
CONNECTION "<OGRVRTDataSource>
<OGRVRTLayer name='survey_locations'>
<SrcDataSource>MySQL:DB,user=user,password=pass,tables=geog</SrcDataSource>
<SrcLayer>geog</SrcLayer>
<GeometryType>wkbPoint</GeometryType>
<LayerSRS>WGS84</LayerSRS>
<GeometryField encoding='PointFromColumns'
x='lon' y='lat'/>
<FID>non_unique_field</FID>
</OGRVRTLayer>
</OGRVRTDataSource>"
CONNECTIONTYPE OGR
mysql> describe geog;
+----------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+----------------+
| id | int(11) | | PRI | NULL | auto_increment |
| regionid | char(3) | | MUL | | |
| geogid | int(8) | | | 0 | |
| geog | varchar(100) | YES | | NULL | |
| lat | float | YES | | NULL | |
| lon | float | YES | | NULL | |
+----------+--------------+------+-----+---------+----------------+
________________________________
From: UMN MapServer Users List [mailto:[EMAIL PROTECTED] On Behalf Of
Pagurek,Debbie [NCR]
Sent: Monday, February 27, 2006 1:32 PM
To: [email protected]
Subject: Re: [UMN_MAPSERVER-USERS] Strange Query Error
Tim,
I haven't tested this, but I think I might have an answer for you. I
found an old post that indicated that the OVF file that points to a Microsoft
Access database should contain
<FID>yourUniqueIdColumn</FID>
in order to indicate what the primary key or unique field is.
I'm curious to know if this works, so please reply to me and the list!
Debbie Pagurek
-----Original Message-----
From: UMN MapServer Users List [mailto:[EMAIL PROTECTED] On Behalf Of
Pascoe,Tim [Burlington]
Sent: Wednesday, February 15, 2006 9:12 AM
To: [email protected]
Subject: [UMN_MAPSERVER-USERS] Strange Query Error
Sorry for the cross-post, but I'm unsure of where this problem
may be occurring. I have a mapserver installation running in IIS, on a
Windows2000 machine. A little while ago, I upgraded all the components to:
PHP 5.0.5.5
Mapserver 4.6
Mapscript 4.6.1
Chameleon 2.0
GDAL 1.3
I am using OGR to create a virtual layer of points, and then
filter this layer using an SLD generated on the fly, based on user input. This
all worked perfectly before the upgrade. Everything seems to work fine now, the
layers filter properly, and display the way they should. However, if a point is
queried, the data returned in the Chameleon query window is for the first
record in the recordset returned for the virtual layer, unfiltered, every time;
no matter what point is selected.
I know of one other person experiencing exactly this behavior,
and that installation has the latest versions of all software, with the same
problem. Anyone have any ideas?
Any help is appreciated,
Timothy Pascoe
Environment Canada / Environnement Canada
Canada Centre for Inland Waters / Centre Canadien des Eaux
Intérieures
867 Lakeshore Road / 867, chemin Lakeshore
Burlington, Ontario / Burlington (Ontario)
L7R 4A6
Tel/Tél: (905) 336-6239
Fax/Téléc: (905) 336-4699
E-mail/C. élec: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Government of Canada/Gouvernement du Canada
This e-mail represents the opinions and views solely held by
its author and in no manner may be considered as representing those of his/her
employer.
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.1.0/269 - Release Date: 2/24/2006
