Skipping to part two - spanning UTM zones. There are a number of question you need to answer regarding your need for spatial accuracy (how you intend to use the data). There is not a simple answer without knowing more of your requirements.
It is possible to store data from different coordinate systems / zones in a single database table such as in Oracle or using SpatialWare and also SDE. There are several "costs" that should be considered. a) Whenever data is extracted the system must interrogate the coordinate system within the geometry and if required perform a transformation. Depending upon the client a second transformation may occur to transform to the current map window coordinate system. While automatic we are talking CPU cycles. b) Data administration is a bit more complex in that multiple coordinate systems are contained in a single table. The ramifications must be considered when performing geometry editing tasks. The other approach to this problem is to store data in a single coordinate system (LAT LONG WGS84 for example) and convert to the desired UTM zone as data is extracted (In Mapinfo if you set up the map window first with the desired coordinate system for that session then all subsequent data will be transformed upon display). This means taking the source data and transforming it to a "common" coordinate system. Of course there are consideration if you maintain the geometry and have to perform many transformations, or editing tasks that require higher degrees of accuracy (say third order control or better). If you are using source data such as from MapInfo or GDT based upon 1:100,000 or 1:24000 map accuracy then this may not be an issue as your spatial accuracy (resolution) is quite low (40' for 1:24000). Remember any time you transform there are rounding error consideration as well as the transformation model accuracy, this should always be considered in respect to the accuracy of the data collection methods. At 1:100000 your accuracy is within 165' - what's a few feet going to mean? This works for data where the spatial accuracy is not the driving concern. If you need to locate a property boundary, pole location, etc, within a few feet accuracy this won't do, and don't even consider it when using real property descriptions. Also note that if you select a single UTM zone as your "origin" zone (say zone 11) as you move into adjacent zones (east or west) the accuracy of the data is decreased due to the transformation model. Going into the middle of one adjacent zone (say zone 12) might result in acceptable measurement results. But transforming data from two zones away (say zone 13 or 14) would result in significant distortion. This is often a problem for local governments where they span two state plane coordinate zones. They are forced to maintain "source data" in the correct zone coordinates, but will merge the two into a single set of tables (files) by transforming the one zone into the other. For most purposes this will be acceptable. But all editing is performed on the original files / zone coordinates to maintain accuracy. -----Original Message----- From: Frank Aaron (TX/EUS) [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 09:34 AM To: [EMAIL PROTECTED] Subject: MI-L GIS Data Manipulation Tool Recommendations Hi All, Does anyone know of a tool that would allow one to "extract" a defined area from a "larger" Map Database (i.e., Elevation, Clutter and Tiger Vectors) and create a smaller one (retaining the Map Projection, etc.)? I was also hoping that someone might be able to recommend a tool that might be able to merge map databases for neighboring UTM Zones into a single database (preserving their unique map projections). TIA, Frank Aaron, MSc. Physics, MSEE Sr Wireless Systems Engineer, Professional Services Ericsson USA Global Services North America Tel: (972) 583-0112 Fax: (972) 583-1807 Mobile: (972) 679-9291 mail to: [EMAIL PROTECTED] --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 9782
