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

[Martin, Daniel A]

Sorry, I made a mistake in my previous email.  Where I said:

However, when I view California in MapServer, California 
alone is in a different location than the same layer in 
MapServer where OGR is used to retrieve the data.

The first mention of MapServer should read MapInfo, like so:

However, when I view California in MapInfo, California 
alone is in a different location than the same layer in 
MapServer where OGR is used to retrieve the data.

-Dan


> -----Original Message-----
> From: gdal-dev-bounces at xserve.flids.com 
> [mailto:gdal-dev-bounces at xserve.flids.com] On Behalf Of 
> Martin, Daniel A
> Sent: Thursday, February 03, 2005 9:59 AM
> To: warmerdam at pobox.com
> Cc: gdal-dev at remotesensing.org
> Subject: RE: [Gdal-dev] Problems with ogr2ogr and TIGER line 
> data - California is a bit off
> 
> > As Ed mentions, you should check into whether there is anything odd 
> > about the lineage of your California TIGER data.
> >  Are you working from raw TIGER data from the Census bureau?  
> > All from the same year?
> 
> Yes, I create the entire country out of the same year at one 
> time.  I have run this against new TIGER data as it comes out 
> every year.  I have independent layers for each year.  I 
> checked and all years exhibit the same problem I'm 
> describing.  So unless raw TIGER data has been wrong in 
> California for years...
> 
> > The TIGER data is all distributed in NAD83 decimal degrees.  
> > There isn't much that can go wrong with from a projection point of 
> > view.
> > 
> > What coordinate system are you writing out your tab files in? 
> >  Also just the original NAD83 or are you transforming to 
> state plane?  
> > There might be ways the state plane definitions could be messed up.
> 
> I guess I don't know.  I'm not doing anything special.  I 
> download the files from the Census TIGER website, and then run:
> 
> ogr2ogr -f "MapInfo File" mydatadir
> 
> I'm doing absolutely nothing else to the data.
>  
> > Also, TAB format scales locations to integers based on a 
> min/max range 
> > that is supposed to be computed based on the coordinate 
> system.  The 
> > default for geographic coordinates systems should be a -180 to 180 
> > plane and should be fine.
> > But if you accidentally got a projected bounding box the resolution 
> > would likely be really crappy.  This shouldn't be a 
> systematic offset 
> > though, just sort of random perturbation so I doubt this is 
> the issue.
> 
> I'm not reprojecting.  I'm pulling the output of ogr2ogr 
> straight into MapInfo, and also straight into MapServer 
> without touching it.
> 
> > 
> > My suggestion is to use ogrinfo on a known feature from 
> TIGER and in 
> > your TAB file to see if the coordinate match.  If they do, 
> then it is 
> > likely the problem is the original tiger data.
> >  If they don't match it is something about the translation, 
> perhaps in 
> > the TAB code.
> 
> I'm not sure I have any idea how to do that.  I will try.
> 
> > 
> > If you are reprojecting the problem might be the coordinate system. 
> > 
> > You might want to try converting one to mid/mif and see if 
> you get the 
> > same issues.
> 
> When I view any state other than California, it is located in 
> MapInfo identical to how it is located in MapServer.  
> However, when I view California in MapServer, California 
> alone is in a different location than the same layer in 
> MapServer where OGR is used to retrieve the data.
> 
> My point being, now we have two distinct situations where OGR 
> is producing inconsistencies in California with TAB files.  
> Once in the ogr2ogr conversion, and then on the rendering 
> into MapServer.
> 
> Thanks for your time.
> 
> -Dan
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at xserve.flids.com
> http://xserve.flids.com/mailman/listinfo/gdal-dev
>