Changes between Version 2 and Version 3 of VirtualSpatialData
- Timestamp:
- Jan 27, 2009, 4:02:56 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
VirtualSpatialData
v2 v3 26 26 Windows is fairly easy to setup and test DSNs since the Data Source Manager does most of the work for you. However, one gotcha is that OGR seems to need a System DSN. User DSNs do not seem to work. If anyone can figure out why (permissions?) please update this. 27 27 28 ( ChipHankley - System DSNs are DEFINITELY the way to go on Windows boxes using IIS for web-based apps. This is because all web transactions use a "web-user" that is typically different from the person who is logged in. System DSNs are tied to the system, while User DSNs are tied to a user. For example if person A sets up a User DSN, person B will not have access to it when they're logged in. Consequently, the default web-user will never have access to a User DSN, unless the default web-user - set up in IIS - is the same as the person setting up the User DSN. Bottom line, avoid all of this by using System DSNs.)29 30 ( JenuAbraham - Setting up the ODBC system DSN for Windows 2003 with MS SQL Server.28 (!ChipHankley - System DSNs are DEFINITELY the way to go on Windows boxes using IIS for web-based apps. This is because all web transactions use a "web-user" that is typically different from the person who is logged in. System DSNs are tied to the system, while User DSNs are tied to a user. For example if person A sets up a User DSN, person B will not have access to it when they're logged in. Consequently, the default web-user will never have access to a User DSN, unless the default web-user - set up in IIS - is the same as the person setting up the User DSN. Bottom line, avoid all of this by using System DSNs.) 29 30 (!JenuAbraham - Setting up the ODBC system DSN for Windows 2003 with MS SQL Server. 31 31 32 32 Administrative tools -> DataSources(ODBC)-> System DSN -> Add -> SQL Server … … 63 63 If you have experience with alternatives to these or drivers for other common databases, pleas add them. 64 64 65 Test using ogrinfo 65 === Test using ogrinfo === 66 66 67 67 ogrinfo is a binary utility that can be built from the gdal source tree. Once you figure out how to build it, you can use it to test various aspects of an OGR datasource. Details on using ogrinfo can be found at: 68 68 69 http://www. remotesensing.org/gdal/ogr/ogr_utilities.html69 http://www.gdal.org/ogr/ogr_utilities.html 70 70 71 71 The options you will likely want to use are: 72 72 {{{ 73 73 $ ogrinfo ODBC:user/pass@DSN table 74 74 }}} 75 75 This tells ogrinfo to use an ODBC datasource named DSN with user name "user" and password "pass", and display all the features in the table called "table". Some notes on this. The username and password should be optional if the DSN is configured to include a user name and password, in which case you would write 'ogrinfo ODBC:DSN table' but I never got this to work correctly. The password can be empty, in which case you would use 'ogrinfo ODBC:user/@DSN table'. 76 76 … … 83 83 If you have trouble connecting to the ODBC datasource with OGR, you might want to use a direct ODBC client to verify that the ODBC datasource is working properly. For windows the WinSQL? product (http://www.indus-soft.com/SynametricsWebApp/WinSQL.jsp) is good, and the Lite version is free. On Unix the isql commandline client that comes with unixodbc should be OK. 84 84 85 Create a Virtual Data File 85 === Create a Virtual Data File === 86 86 87 87 A virtual data file can be used by OGR to create geometries for non-spatial data sources. For the purpose of this howto, we are working with ODBC data sources but it should work for any OGR data source (but it is only useful if it is a non-spatial source with point data). … … 89 89 The format of the virtual data file is described at 90 90 91 http://www. remotesensing.org/gdal/ogr/drv_vrt.html91 http://www.gdal.org/ogr/drv_vrt.html 92 92 93 93 A minimal virtual file could be: 94 94 {{{ 95 95 <OGRVRTDataSource> 96 96 <OGRVRTLayer name="mylayer"> … … 102 102 </OGRVRTLayer> 103 103 </OGRVRTDataSource> 104 104 }}} 105 105 This example assumes that there are columns in the database table called 'x' and 'y' and that these contain spatial locations in latlong projection WGS84 (epsg:4326) 106 106 … … 109 109 The <SrcLayer?> parameter is a table name. If you wish to join tables or select only certain columns, you can use an SQL statement by omitting <SrcLayer?> and including <SrcSQL?>select table.name, table.x, table.y from table</SrcSQL?> in its place. Note that in the GeometryField?, you may need to refer to the attributes x and y as table.x and table.y in this case. 110 110 111 Testing using ogrinfo 111 === Testing using ogrinfo === 112 112 113 113 To test an ovf file using ogrinfo, simply replace the driver with the path to the file, for instance: 114 114 {{{ 115 115 $ ogrinfo virtual.ovf 116 116 … … 120 120 using driver `VRT' successful. 121 121 1: virtual (Point) 122 122 }}} 123 123 ( The last line indicates the table inside the database you are accessing ) 124 124 125 125 To list the contents of a layer in the file, use: 126 126 {{{ 127 127 $ ogrinfo virtual.ovf mylayer. 128 128 … … 158 158 virtual.y(Real) = 40.4455 159 159 POINT (-74.01480000 40.44550000 0.000) 160 160 }}} 161 161 The difference from using ogrinfo directly on the ODBC datasource is that there is now a POINT geometry associated with the feature. 162 162 … … 164 164 If you see "ERROR 1: SetAttributeFilter?() not supported on ExecuteSQL?() results" within the above output while running the above command, then its possible that your mapserver wont run properly too. Check out OgrinfoError1 165 165 166 Creating a MapServer layer 166 === Creating a !MapServer layer === 167 167 168 168 The final step is to create a layer object in mapserver and have it use this virtual file as its datasource. A (very minimal) layer follows: 169 169 {{{ 170 170 LAYER 171 171 NAME "MyVirtualLayer" … … 190 190 END 191 191 END 192 193 Testing with MapServer 192 }}} 193 === Testing with !MapServer === 194 194 195 195 This is up to you ... hopefully you can do this if you've got this far ;) … … 209 209 1. Check if you have a symbol defination in your map file. 210 210 2. If NOT create one like below. (You dont have to use this, just keep it as a dummy defination). 211 211 {{{ 212 212 SYMBOL 213 213 NAME cir … … 218 218 END 219 219 END 220 220 }}} 221 221 Third tip: 222 222 … … 230 230 eg: x= -87.5456 y = 35.4565 (for some place in USA) 231 231 232 Dynamic Control of Virtual Sources 232 === Dynamic Control of Virtual Sources === 233 233 234 234 While the virtual configuration XML is normally maintained as a separate file referenced in the CONNECTION string of the layer, OGR also makes it possible to include the file's contents instead, inline in the mapfile. … … 239 239 240 240 and this string is the CONNECTION parameter in the mapfile: 241 241 {{{ 242 242 '<OGRVRTDataSource> 243 243 <OGRVRTLayer name="mylayer"> … … 249 249 </OGRVRTLayer> 250 250 </OGRVRTDataSource>' 251 251 }}} 252 252 the result is that the SQL returns all records from table with a date in 2003. 253 253
