[gdal-dev] Shapefiles & AVL files
hobu.inc at gmail.com
Mon Nov 2 11:07:30 EST 2009
On Nov 2, 2009, at 8:36 AM, David Staveley wrote:
> Hi there,
> I'm new to gdal/ogr, so please be kind.
> I was using ogr2ogr to convert some geological shapefiles to kml,
> and found I was just getting the geological areas outlined in red as
> a result, in other words, it wasn't reading the ArcView Legend (AVL)
> files. Undeterred, I wrote some code to read the AVL files and
> modify the resulting KML directly, which worked fine.
> I was wondering if it would be considered useful to have this
> functionality in ogr2ogr, or whether AVL files are considered old
> hat now the files formats have changed for later versions of
> ArcView? Is anyone working on this already? My code only picks out
> the colours so far, but I could expand it to read the other AVL codes.
> I was reading through the code and the documentation for the
> "Feature Style" classes, but they seem little used so far. Is this
> because it is new, or because styles are seen as not important for
> the software?
I think it would be interesting to be able to ingest the AVL files
into the Feature Styling stuff where it's applicable. Specific code
for taking AVL to KML probably doesn't fit all that well within OGR
unless it was first going up to the generic Feature Styling APIs.
Also, it is very likely that the Feature Styling APIs need to be
expanded upon to support more of the things you would want to carry
forward from AVL.
> I also saw some developer guidelines that say this :
> "GDAL strives to be widely portable to 32bit and 64bit computing
> environments. It accomplishes this in a number of ways - avoid
> compiler specific directives, avoiding new, but perhaps not widely
> available aspects of C++, and most importantly by abstracting
> platform specific operations in CPL functions in the gdal/port
> Whilst it doesn't say it explicitely, does this mean that the use of
> the STL is frowned upon? Would I have to convert my code from using
> STL for it to be useful to the project?
I would say that STL is somewhat frown upon in "public" areas of the
code, which means areas of the code that aren't self-contained
drivers. A patch written in STL still isn't precluded from being
applied, however, especially if it is doing simple and well-supported
More information about the gdal-dev