(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  "<tt>DD: MESSAGE"  The copy I had cc'd to my self was equally canibalized.)<br> <br> I am working on a nation-wide project at usmapserver.com which includes TIGER roads data along with other nation-wide basemap data.<br> <br> 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.<br> <br> 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')<br> <br> Performance in drawing the TIGER data is killing me:<br> 100 seconds... 1000 seconds ... ridiculous!<br> <br> All data are stored in
 PostGIS.  All spatial indexes are built.  Databases recently vacuumed. <br> <br> I am thus led to the hypothesis that it is the issue of the undefined SRID which is causing the performance breakdown.<br> <br> (Are the data being re-projected on the fly... only to be projected to the exact same lat-longs?)<br> <br> 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.<br> <br> However,  simply changing this line in the MAP file from<br> <br> </tt><tt>DATA "the_geom FROM roads USING SRID=32767" to<br> </tt><tt>DATA "the_geom FROM roads USING SRID=4326"<br> <br> fails (unsurprisingly) with the following message:<br> -ERROR:  Operation on two geometries with different SRIDs<br> <br> Thus, I have inititated the following:<br> <br> pgsql-> UPDATE roads SET the_geom = SetSRID(the_geom,4326);<br> <br> 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.<br> <br> I will report back when the process is complete and discuss whether this eliminates the performance nightmare.<br> <br> In the meantime, however, any feedback (positive or negative) on the above would be appreciated.<br> <br> Thank you.<br> <br> Steve Walker<br> Middle Fork Geographic Information Services<br> walker AT mfgis.com<br> <br> <br> <br> <br> </tt><BR><BR>Steve Walker<br>Middle Fork Geographic Information Services<br>PO Box 2157<br>Bellingham, WA  98227<br>steve@mfgis.com<p>
                <hr size=1>Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. <a href="http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com"> Great rates starting at 1¢/min.