[Xastir-dev] TIGER/Line water polygons, or lack thereof

[Curt, WE7U]

On Wed, 20 Oct 2004, Tom Russo wrote:

> Since it does seem that ogr knows enough about tiger structure that ogr2ogr
> can assemble meaningful CompleteChain polyline files with appropriate
> attributes (i.e. it has merged information from several tables), perhaps
> the best way to get tiger polygons is to push back on GDAL/OGR development
> to do something similar with polygons.  All the data is there when the TIGER
> data is read in by OGR, it just doesn't assemble the polygons so they're
> readily accessible for drawing quickly.

Here's what went by on my screen this morning:


Curt, WE7U wrote:
> On Wed, 20 Oct 2004, Curt, WE7U wrote:
>
>
>>Is there a chance that OGR will support TIGER/Line polygons at
>>some
>>point?  For that particular file format it looks like I'll have to
>>do a lot of special coding just to get to the polygons, due to
>>TIGER
>>having represented them as polylines instead.  Seems OGR should
>>hide
>>the implementation details of various file formats from me, but in
>>this case it doesn't.

Curt,

There is no real plan to implement polygon assembly within the
TIGER/Line
driver.  I'm not really adverse to having this happen, but it is
critical
that it be done in a way that can be easily disabled as it was a
design
goal that the TIGER/Line code be able to defer polygon assembly to
later
stages in the FME processing pipeline when used in FME.  And Safe
Software
funded all the TIGER/Line work.

I don't forsee having the time to do tiger polygon assembly myself
within
the driver in the near future.  I have provided scripts
(assemblypolygon.py)
that shows how it can be done as a utility translation step.

> And while I'm at it, what's the expected timeframe for integrating
> the OGR API into the GDAL API?  Does it make sense for me to be
> writing to the OGR API right now?  Will the OGR API go away at
> GDAL
> integration time?

There is no established timeline for OGR being more tightly
integrated
into GDAL.  I would hope it would happen within a year, but that is
by
no means certain.

Most of the OGR API will remain but code dealing with the OGRDriver,
using
TestCapability() or possibly some interactions with the datasource
and layer
classes will change a bit.  All the stuff from OGRFeature down will
be
completely unchanged.

My goal is that most OGR applications can be migrated to the new API
with
little or no source changes.

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


--
Curt, WE7U			         http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"