Listers, As promised, here's the summary of what I learned from my recent adventures in projection land. The problem was an approximately 300 ft east-west mismatch between GIS street files provided by a large public agency, and environmental hazard site locations provided by a commercial data supplier. The street files used the State Plane CA Zone V NAD83 projection, while the hazard sites were in Lat/Long "unprojected". Chuck Peer, a surveyor with the LA County Public Works Department pointed me towards an excellent source of independent control points at http://www.ngs.noaa.gov/datasheet.html. They have a fantastic searchable database of surveyed control points and you can even download the data in SDTS format (which thanks to Bill Thoen we may be able to use fairly soon). Using these control points I was able to determine that the GIS street files were correctly positioned. By experimenting with various projections I found out that when a file created in Lat/Long "Unprojected" (CoordSys 1,0) is opened, it (usually) seems to adopt the Map Window's current projection, which is determined by the projection of the first "Projected" table opened. You can see this for yourself by doing the following. Create 3 new tables each containing a single point with the exact same coordinates (I used -118.5, 34.5), and each with a different projection: Lat/Long unprojected, Lat/Long NAD27 for Continental US, and Lat/Long NAD83. Open up two tiled map windows, the first with the NAD27 table, the second with the NAD83 table. Then open the unprojected table into each of the open windows. The unprojected point will drop directly onto BOTH pre-existing points, even though -118.5/34.5 NAD27 is not the same point on the earth's surface as -118.5, 34.5 NAD83. I think the lesson here is never to use the Lat/Long "Unprojected" projection. W. Kent Treichel suggested using a double save routine (save as NAD27 then again as NAD83) to convert Lat/Long "unprojected" files to something useful. This works because the first Save As doesn't actually reproject the data, it just gives it a fixed projection. The second Save As reprojects the data to NAD83. Doing this to the hazard site files corrected the systematic offset problem. We were still left with a rather poor fit to the actual parcels on our base maps, but that seems to be due to the limitations and inaccuracies of geocoding to TIGER or other street files. Lesson 2 seems to be that geocoding in this way may be fine for demographic/marketing studies, but not for scientific or engineering purposes. I still don't know exactly why the Lat/Long "unprojected" files were offset from our base maps, regardless of what order we opened the files in. Still, the problem is more or less solved and I'm quite a bit the wiser about MI. Thanks to everyone who contributed suggestions. Hope this helps, _____________________________ Tim Warman Geologist & GIS Specialist Richard C. Slade & Associates North Hollywood, CA (818) 506-0418 ---------------------------------------------------------------------- To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
