[Gdal-dev] Problems with ogr2ogr and TIGER line data - Californiais a bit off

[Ed McNierney]

Where exactly did you get this California data set, and what
projection/datum documentation came with it?  Various distributors of
TIGER data, especially state governments, have massaged the data to
various state plane projections.  Any information you have about the
source would be helpful; in addition, how is the input projection being
described to ogr2ogr?

 

-          Ed

 

Ed McNierney

TopoZone.com

 

________________________________

From: gdal-dev-bounces at xserve.flids.com
[mailto:gdal-dev-bounces at xserve.flids.com] On Behalf Of Martin, Daniel A
Sent: Wednesday, February 02, 2005 5:09 PM
To: gdal-dev at remotesensing.org
Subject: [Gdal-dev] Problems with ogr2ogr and TIGER line data -
Californiais a bit off

 

I've been using ogr2ogr for some time (Windows binary from OpenEV_FW) to
convert the entire TIGER line data from the census into workable MapInfo
TAB street layers.  Something we recently noticed is that our resulting
streets in California are off by a about 1/10th of a mile.  Nothing
terrible, but enough to make them unusable for our purposes.  I went to
check my old files to see if the problem is new, but I found it in the
files I was creating about two years ago.  I've done very little work in
California, so I've never noticed it before.

 

I started to think this was a projection issue.  So, I started checking
other states throughout the country.  I've not checked them all, but all
the other states I have checked are absolutely dead on.  This includes
states from all corners (Washington, New York, Florida) and in the
middle of the country (Missouri, Illinois).  But California appears to
be the only one that is incorrect.  This also appears to affect all of
California, and isn't isolated to one small part.

 

As a control, I've used several of our internal data layers that I'm
quite confident in, and the Microsoft Terraserver WMS layer.
Terraserver makes it really easy to see when streets are off.

 

Another oddity is that this effect is lessened if the layer is loaded
into MapServer (versus MapInfo), I'm guessing since MapServer uses OGR.
The data is still out of place in MapServer, but not quite as much.
We've tested the data in multiple versions of MapInfo just to be sure
that wasn't part of the problem.

 

Any ideas on why this would happen?  I'm using the basic command line
options for ogr2ogr.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20050202/7438cec4/attachment.html