[Gdal-dev] OGR: SDTS Elevation

[Frank Warmerdam]

Curt, WE7U wrote:
> USGS SDTS-format DLG vector contours have field names labeled
> "ELEVATION".  Some maps have these in meters, others are in feet.
> The difference appears to be whether they have an AHPT layer (feet)
> or an AHPR layer (meters).
> 
> What is the proper (fast!) way to determine which I have?
> 
> Must I run through all the layer names once to determine this?
> 
> Should I use GetLayerByName() to see which layer is present first,
> then use that to decide whether to draw "ft" or "m" after the
> elevation label?
 >
 > Will any of this slow me down due to accessing layers more than
 > once, or is this info cached in the driver so that I'm not really
 > taking a hit?

Curt,

Using GetLayerByName() should be fast.  The layer list is created and
maintained in memory at datasource open time, so it isn't expensive
to do a GetLayerByName() (basically a linear scan of the layer list
with a string compare for each till a match is found).

Of course, you should try to do this only once per redraw/layer
not for every feature.

> I'm not sure whether the driver is combining SDTS elements together
> into OGR layers so that I get elevation and vectors together in the
> layers that I'm drawing, or whether I'm drawing layers as they're
> being read from file.  Depending on how that is done it might make a
> difference in the techniques to use to determine how to draw things
> quickly at the OGR API level.

I think that the features for each layer are just created from records
in the .DDF file but I am not sure.  It has been quite a while since
I worked in depth on the SDTS vector driver.

> I'm using the "C" interface.  Speed is very important to us:  This
> is a tracking application and we can load a lot of maps at a time to
> cover an area, plus if we're tracking a moving object we can be
> reloading maps constantly.  The spatial filtering does appear to be
> helping so far to keep things fast.

To be honest, if speed is of the essence and memory is of little concern
you would be best copying the features into an OGR memory layer or even
reading the data into your own memory structures keeping only the elements
critical to you (toss unused attributes for instance).  While I try not to
do too many stupidly slow things in OGR the basic model is to re-read from
disk for each pass through the features, and generally spatial and
attribute queries are applied by reading all features and then testing the
features to see if they fit the criteria.  Furthermore, OGR has no mechanism
for reading cached read-only features so each pass through requires, at the
very least, creation of the OGRFeature from scratch.

OGR is intended to be reasonably fast by comparison to other translators,
but without a real objective of render-speed.  GDAL on the other hand uses
agressive caching and block orientation to try and be essentially fast
enough for slow rendering (ie. a few renders per second as opposed to
60hz rendering which pretty much needs something like keeping the imagery
loaded on a video card).

PS. OGR is also quite weak on returning metadata such as units for fields.
When I overhaul OGR to use the GDAL driver model, I hope to carry info like
units information around in a more normalized manner as I do for the elevation
units of SDTS DEMs.  No ETA on this though.

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    | Geospatial Programmer for Rent