On 11/3/05, listuser HH <[EMAIL PROTECTED]> wrote: > About the performance etc. I can't give you a hint, sorry - but you get the > geometry diplayed. I think very important is the amount of features which you > will display. I only used it for some single features and this worked good. > Perhaps Frank Warmerdam can tell a bit more also for the con's on the usage > of WKT in OGR.
Folks, Generally speaking table access via ODBC is not doing spatial indexing, and so it can be slow to pull a few rows out of a big table for drawing a small local region. However, I am in the midst of some changes to the ODBC driver to support spatial indexing, and translation of WKT and WKB without going through the OGR VRT driver. This work is now in CVS and would make it so you could use a datasource name like: ODBC:mydsn,tablename(wkt_geometry) This would mean open DSN mydsn, and access only the table named "tablename". Use the column "wkt_geometry" as the geometry. It will be parsed as WKB if the column is BLOB or WKT otherwise. Also, the new spatial indexing support provides for fast spatial queries if the table has columns named "xmin", "xmax", "ymin" and "ymax" with the geometric extents of the geometry for that row. These columns should be indexed for optimal efficiency. Anyone interested in trying this out should grab the CVS snapshot of GDAL/OGR. I would add that using a "select" statement in an OGR VRT file is a very flexible approach in terms of what you can do, but it also has some downsides in terms of performance - especially when used with the current query support in mapserver which requires refetches by feature id when working with the query results. This issue does not affect rendering though. Best regards, -- ---------------------------------------+-------------------------------------- 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 | Geospatial Programmer for Rent
