TIGER - SRID 4326, 4269, & 32767 Performance Issues

Steve Walker klawsteve at YAHOO.COM
Tue Jul 25 18:39:52 EDT 2006


(RE-Posting, and Re-writing.  The LISTSERV web interface ate my first posting telling me it had already been posted.  and returned only the text  "DD: MESSAGE"  The copy I had cc'd to my self was equally canibalized.)
 
 I am working on a nation-wide project at usmapserver.com which includes TIGER roads data along with other nation-wide basemap data.
 
 All data included (with the exception of TIGER) are stored in geographic-WGS84 coordinates.  In the MAP file they are properly tagged with SRID=4326.
 
 It also includes nation-wide TIGER data.  Officially, TIGER data are stored in geographic-NAD83 coordinates (SRID=4269) (there are exceptions in minor outlying US posessions).  However, *my* TIGER data are referenced to SRID=32767 (which I believe means 'undefined')
 
 Performance in drawing the TIGER data is killing me:
 100 seconds... 1000 seconds ... ridiculous!
 
 All data are stored in PostGIS.  All spatial indexes are built.  Databases recently vacuumed. 
 
 I am thus led to the hypothesis that it is the issue of the undefined SRID which is causing the performance breakdown.
 
 (Are the data being re-projected on the fly... only to be projected to the exact same lat-longs?)
 
 I am willing to ignore the differences between NAD83 and WGS84 and assign the SRID=4326 to the TIGER data so that *ALL* layers in my MAP file will reference the SAME SRID.
 
 However,  simply changing this line in the MAP file from
 
 DATA "the_geom FROM roads USING SRID=32767" to
 DATA "the_geom FROM roads USING SRID=4326"
 
 fails (unsurprisingly) with the following message:
 -ERROR:  Operation on two geometries with different SRIDs
 
 Thus, I have inititated the following:
 
 pgsql-> UPDATE roads SET the_geom = SetSRID(the_geom,4326);
 
 and expect this to churn away for a very long time.  I have tested this on a small subset of the data however and believe it solves the problem.
 
 I will report back when the process is complete and discuss whether this eliminates the performance nightmare.
 
 In the meantime, however, any feedback (positive or negative) on the above would be appreciated.
 
 Thank you.
 
 Steve Walker
 Middle Fork Geographic Information Services
 walker AT mfgis.com
 
 
 
 
 

Steve Walker
Middle Fork Geographic Information Services
PO Box 2157
Bellingham, WA  98227
steve at mfgis.com
 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20060725/a00c1ede/attachment.html


More information about the mapserver-users mailing list