[mapserver-users] GetFeatureInfo request against an OGR virtual data source

[Robert Sanson]

Hi Frank
 
Fantastic! I do have a unique integer id on the database table "apiary_id". Including the line <FID>apiary_id</FID> in my .ovf file solved the problem.
 
Many thanks,
 
Robert Sanson

>>> Frank Warmerdam <warmerdam at pobox.com> 20/05/2008 11:53 a.m. >>>

Robert Sanson wrote:
> Dear List
>  
> I have set up Mapserver map file configured as a WMS service. One of my 
> layers is a OGR point data source drawing its coodinates from x,y fields 
> in a SQL-Server database via ODBC. The x,y coordinates are in NZ Map 
> Grid projection (EPSG:27200) but all my other layers are NZ Transverse 
> Mercator (EPSG:2193).
>  
> My top level SRS is defined as EPSG:2193 (NZTM).
>  
> The particular OGR data source is therefore being projected to 
> EPSG:2193, which it seems to be doing properly.
>  
> The layers in the map are displaying correctly, using a number of 
> different clients - OpenLayers, uDig, ArcMap.
>  
> Now, my problem is that sending the following GetFeatureInfo request 
> from OpenLayers: (also tested manually via a Browser URL):
>  
> http://10.65.192.1/cgi-bin/gsswms.exe?service=WMS&version=1.1.1&request=GetFeatureInfo&LAYERS=apiaries_dev&QUERY_layers=apiaries_dev&FORMAT=image/png&INFO_FORMAT=gml&SRS=EPSG:2193&BBOX=1478229.486251,5375153.051004,1482462.817299,5379386.382051&WIDTH=512&HEIGHT=512&X=341&Y=19&STYLES 
> <http://10.65.192.1/cgi-bin/gsswms.exe?service=WMS&version=1.1.1&request=GetFeatureInfo&LAYERS=apiaries_dev&QUERY_layers=apiaries_dev&FORMAT=image/png&INFO_FORMAT=gml&SRS=EPSG:2193&BBOX=1478229.486251,5375153.051004,1482462.817299,5379386.382051&WIDTH=512&HEIGHT=512&X=341&Y=19&STYLES>=
>  
> returns the first record in the database table, regardless of the BBOX 
> and location parameters, which are all in terms of EPSG:2193 (NZTM).
>  
> Can MapServer back project the GetFeatureInfo request from EPSG:2193 
> into valid NZMG (EPSG:27200) coordinates in order to request the correct 
> feature details via OGR?

Robert,

The problem is (likely) due to the lack of a persistent feature id when
reading from ODBC.  This doesn't negatively impact drawing but completely
fouls up MapServer's two pass query mechanism.

If you have an integer field on the source table that is a unique id,
you will likely be able to mark it as the feature id using the
FID element in the VRT file.  But I'm not sure if that is enough, since
when the VRT asks the ODBC layer for a particular feature by fid,
the ODBC driver will still do the wrong thing.

I see there is also a secret configure option in the ODBC driver for
selecting a field as an FID.  So, if your unique integer id field
was called "id", adding the following within your map should force
the OGR ODBC driver to use it:

   CONFIG "ODBC_OGR_FID" "id"

Generally speaking doing MapServer queries against OGR feature
datasources without persistent feature ids is problematic and
should be avoided if practical.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users



------------------------------------------------------------------
The contents of this email are confidential to AsureQuality. If you have received this communication in error please notify the sender immediately and delete the message and any attachments. The opinions expressed in this email are not necessarily those of AsureQuality. This message has been scanned for known viruses before delivery. AsureQuality supports the Unsolicited Electronic Messages Act 2007. If you do not wish to receive similar communications in future, please notify the sender of this message.
------------------------------------------------------------------


This message has been scanned for malware by SurfControl plc. www.surfcontrol.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20080520/e5f92a7a/attachment.htm>