CONTACT MI
  Resellers
  Consultants
  MicroImages
  About MI
  Visiting
  Prices
  Send Email
  Reseller Resources

SHOWROOM
  Gallery
  Technical Guides
  New Features
  Testimonials
  Reviews
  World Languages

   View in PDF format

The land use vector object was interpreted from imagery and had polygons and islands smaller than 1 hectare.  The national boundary was digitized in TNTmips and was very detailed and complex and used as a template that occurred in all 8 vector objects. The village, district, and provincial boundaries were all three derived from the same orginal vector object by additional digitizing.  The Land Use object was not only the most complex but was derived in such a fashion from automated image interpretation so as to have boundaries that nearly duplicated those of other layers such as the Land Units objects.  Using RV6.9 about 30 conflation errors of several related types were tracked down by adding tests that report the geographic position were the geometric problem occurs.  The validate process in PV6.9 and RV7.0 was then modified to detect, identify, and resolve these various classes of errors.      

What if I still have it?

As part of this effort to make vector validation more robust, a variety of new error and warning messages were added.  The most valuable are those that report the coordinates of the position of a topological problem area.  Should such a message occur you can zoom in at that exact coordinate position in the Spatial Data Editor and see if the complication can be manually edited.  For this reason in RV7.0 all error messages in every process are now automatically written into the session log (see below), this log can be sent to MicroImages, along with the vector object to insure that any new type of conflation problem is detected, eliminated, and does not occur again.  

Remember you may have to zoom in an excessive amount to a scale of 0 and perhaps way beyond to even see the offending feature. In the testing documented above, it was found to be very useful to extract new vector objects for progressively smaller areas around the reported error position.  Eventually this means that validate runs up to the error point in seconds or the error simply disappears, which may help you locate the problem feature and also provides a very small vector object to use to send the problem to MicroImages. 

Tracking Process Performance.

Progress Windows.

The progress bar in the status window in all processes now displays elapsed time for each step in the process.  From this you can glance at a complex process and determine how long a process has been running at a given step.  At the end of the process the progress bar displays the total elapsed time for the entire process.

Session Logs.

How Are They Titled?
A session log is now automatically created for all TNT processes.  The name of the session log is YYYYMMDD.log where YYYY is the 4-digit year, MM is the 2-digit month and DD is the 2-digit day of the month.  Thus, the log file created if you use your TNT product on the date on this MEMO will be named 20041117.log.  All processes you run on the date used for this file name are logged sequentially in this same log file.  The TNT products will create up to 10 daily log files using this naming convention.  These are not consecutively dated unless you use your TNT product for 10 consecutive days.  Whenever you start your 11th daily session of your TNT product, the oldest dated *.log file will be automatically deleted unless you have renamed it to keep it.  A portion of a session log is listed on an accompanying color plate entitled Session Log Files.

Where Are They Located?
The location of the session log is dependent on the platform and user environment and security settings. 

Mac OS X.  Under Mac OS X various diagnostic log files and log folders such as the DiskUtility.log and the CrashReported folder are placed automatically in your user Library/Logs folder.  The TNT products automatically create a MicroImages folder in this Log folder and place the TNT *.log session log files (for example, 20041117.log) in this log folder.  The Mac OS X Console log application is used to view, analyze, and print the contents of any *.log file in this folder.  Any of the 10 TNT session logs can be automatically opened in this log application program by double clicking on them.

Windows.  The default location created for these TNT session log files for Windows XP is in a MicroImages directory automatically created in your “My Documents” directory.  For other versions of Windows please search for files with the extension of *.log.

Linux/Unix.  The default location created for these TNT session log files for various Linux flavors is in userhomedirectory/.MicroImages

What Do They Contain?
The session log file contains date/time information regarding when the process and critical libraries were built.  Also recorded are all the messages displayed in progress windows, as well as all displayed error messages.  

Each of the key steps matching those displayed in the status window is recorded in the session logs.  If the process fails to complete, then the last step recorded will indicate that the process failed in the next step.  Providing this session log to MicroImages’ support staff with your error report will assist them in diagnosing the error condition you are experiencing.

The cumulative time from the beginning of each step is also recorded for the step when it is complete.  The complete elapsed time is also recorded for the process.  Of more interest is the additional entry of the incremental time to complete each step in the process.  It will indicate where a process seems to be too slow and can be included as part of your inquiry about this to MicroImages’ support staff. 

Additional reference information may be recorded in the session log by various processes for diagnostic purposes, which is not displayed to you during the use of a process.  It is anticipated that gradually more and more diagnostic information will be recorded in these session logs to help you monitor and perfect your operational procedures and MicroImages diagnose where processes need further optimization or to help you help us diagnose errors.

New Coordinate Reference System (CRS). 

Background.

The Starting Point.

MicroImages uses Claudius Ptolemy (circa 100 to 170 AD) as an “inspirational figure" as he is credited with inventing the idea that the curved earth could be represented by projecting it onto a flat surface.  What he conceived of has now proliferated into a myriad of different ways to represent and record coordinates on a “sort of bumpy spheroid” and then ways to project them onto a flat surface.  Over the intervening 1900 years scientists, mathematicians, and even politicians have been arguing over new approaches and which system is best.  Even something as accepted today as the location of the prime meridian was contested for long periods between nations seeking to maintain control of it and their maps derived from it.  Today there are almost as many ideas about which system is best as there are geodesists defining how to do it.    

Where the Early Initiative Came From.   

First nations with empires introduced some level of standardization within their colonies and their maps. The breakup of empires in the first half of the 20th century halted this trend. Starting in the 1920s, oil companies took the initial initiative to collect and collate information about these systems.  Today locating on-shore and off-shore well locations accurately worldwide requires dealing with many different national and local map projection and datum definitions.  As a result, they had and still have a huge economic incentive for collecting together information about the many Coordinate Reference Systems (CRSs) in use and then using it to accurately convert between all these CRSs.  Military applications did not provide early leadership in this area since they simply wanted to enforce a single standard CRS, such as UTM, and only wanted to move one way—from any external materials and information they can acquire into their standard CRS.  They also are not willing to share information in and about their most accurate CRS and transformations for international public uses.

Requirements for Accuracy in Geospatial Systems Keep Increasing.

Today striving for highly accurate global scale precision in global Coordinate Reference Systems (CRSs) can be the basis for completely automated flight and safe landings of a commercial aircraft or a pilotless drone.  Equally accurate requirements for precision in a local CRS can serve as a basis for legally defining property ownership boundaries rather than the traditional angles and lengths survey.  Lincoln, NE and Lancaster County that it dominates now use a special Transverse Mercator CRS to minimize local errors and increase coordinate accuracy, and this is the trend for urban areas around the world.

These varied requirements for high accuracy and recorded precision were not part of the university research and early commercial applications of image processing or GIS 20 to 30 years ago.  

GPS first appeared with limited availability in the late 1980s. Even at that late date, measuring more accurate positions of ground coordinates by any other means for the control of imagery was tedious and prohibitively expensive.  The initial GPS public resolution of 100 meters was poor, equipment was expensive, and thus it had little immediate impact on the precision required in computer mapping and image processing, which could easily handle this level of precision and its immediate potential for improvement.       

Landsat satellite imagery also became readily available in the same time framework.  Its initial coarse 80- then 30-meter ground resolution, coupled with the limited ability to georeference and orthorectify it, fit nicely with the available GPS accuracy and the accuracy of then prevalent computer analysis systems.

Computer hardware of this time period, desktop or workstation, was also limited in storage, display, and computational capability to handle the precision and magnitude of these kinds of data sources. 

Geodata was scarce and of coarse accuracy.  Composite viewing of mixed image and map layers was minimal due to the absence of on-the-fly map projection conversions.  The idea of georeferencing and the concept of managing scale for map and image data was not common in image processing systems.  

When map coordinates were used in GIS systems, common map projections were used and were accurate enough to be applied over wide areas. Accuracy requiring datum conversions was not required and inadequate computer power was available anyway. 

Gradual improvements in these areas coupled with improved geospatial software on minicomputers and soon desktops lead to the ideas of the 1990s.  Producing orthoimages and image maps from satellite and aerial imagery began with accuracies in the 10s of meters.  DEMs became available for this purpose and for 3D displays.  Accurate infrastructure and property ownership data began to appear.  GIS data and digital map data (for example, U.S. Census Bureau TIGER maps) became widely available requiring updates.  Fusing images of varying resolution began.  These and many other applications depended upon and demanded increased accuracy in the coordinates and conversions being used.

These are some of the factors that influenced the design of the Coordinate Reference System (CRS) structure, service, and interface built into the 1980s ancestors of the TNT products and the contemporary models of other current commercial geospatial analysis products.  Until the onset of the 21^st century, the evolution of these early approaches had permitted them to be maintained and patched to keep pace with CRS accuracy and use until quite recently.  Standardization in the exchange of CRS information between products was not of concern until recent, standardized geodata exchange formats became popular and other technical users began to demand it and improved accuracies (auto industry, web applications, and so on).      

Today the goal is all-electronic in-car navigation, hand-held GPS map display position units, highly accurate survey units, and many more.  Only in rugged field conditions does paper remain the optimal media.  Electronic uses are permitting instant changes / conversions in composite and 3D viewing, feature position coordinate readouts, combinations of materials in different reference systems, and so on.  

MicroImages’ Previous Coordinate System Framework.

Managing image and map materials in a georeferenced form so that they could be merged was the very first objective and product goal in the design of the structure of the experimental predecessors of TNTmips in the late 1970s, well before its commercialization as TNTmips in 1986.  In that time framework, the goal was to produce paper image maps: printed images that matched the boundaries, scale, and content of associated printed maps.  These early 1980s experimental products were color printed maps of Landsat imagery georeferenced, warped, and clipped to match a companion USGS 1:24,000 scale topographic map.  Before very long, paper published maps were being scanned and overlaid as transparent images or overlaid by the available USGS Digital Line Graph digitized line features and then printed.  But PCs were large, slow, and limited in distribution and no large capacity standard distribution media (which means, the CD) was available to consider wide scale electronic use of such material. During these early years, goals were map-centric and oriented toward producing physical map products.  

This early map-oriented start subsequently meant that TNT was the first commercial desktop product to handle map projection changes transparently, whereas today all professional systems are expected to do this and low-cost units convert data and inputs (for example, GPS) to a common Coordinate Reference System (CRS). Today in the TNT products we might start an application by mosaicking a large number of orthoimages in one or more CRS, add many geometry feature overlay layers in various other CRSs, and expect them to accurately fit to each other to the meter, foot, or even less (for example, the enclosed Lincoln Property Viewer TNTatlas).

Introducing New Terminology.

Until recently the term map projection was convenient and was applied to this objective. Today the application of geospatial systems to produce physical maps is not their major use.  Therefore thinking of these requirements to represent coordinates and features as using a map projection physically bound into that map is on its way out.  We no longer think of geospatial information as something we carry around in a physical form and, thus, in a fixed map projection.  It is data in a geospatial analysis system, database system, or other digital form stored with a 3D Coordinate Reference System (CRS).  We expect it to be accurate and usable in that CRS or when transformed into whatever CRS is requested or appropriate.  If it is older or in some other datum, we expect this to be transparently converted with accuracy.  

Today the concept that your image, map, and combined geospatial data is in a map projection can be misleading as it conjures up the idea of a physical map.  Today this information can be thought of as existing and represented in a specific global CRS and be accurately convertible in real time to some other global or local Coordinate Reference System. Tomorrow’s end users of geospatial data no longer require or request map coordinates.  Today’s end user of geodata expects a pleasant voice to tell them to turn right now at this corner for the nearest gas station, and that the road will be there. In the next 20 years they will expect the car to do this automatically.  “Road maps and map projections, weren’t those things that they used back in the late 1900s?” 

Adapting To These New Requirements for Standardization, Accuracy, and Speed.

Change requires change!  Capabilities of hardware and our expectations for a professional geospatial analysis system have changed greatly in these 20 to 30 years.  That’s what keeps it interesting and challenging.  To keep pace, the early design and adjustments to managing Coordinate Reference Systems (CRSs) in the TNT products required a major overhaul undertaken a year ago even before the release of V6.9.  TNT products and the associated interface had to be modified in the way they handle all these projected materials and adhere to accepted standards.  You might think, “but I am working only in the United States,” or “Japan,” or …   In fact, the requirements for more accurate earth surface coordinates in these nations are some of those that require a new approach.  Higher resolution images, more precise GPS coordinates, new high precision datums, the use of empirically derived datums, new local and city projections, secret projections, and other evolving requirements in every nation require changes and standardization in the way CRSs are managed.  RV7.0 introduces a completely new subsystem for managing standard and private CRSs into the TNT products while providing for increased accuracy and speed.  This new conceptual CRS approach is also discussed and illustrated in the accompanying color plate entitled Spatial Referencing in TNT.

ISO 19111:2003 Standard.

Purpose.

Geodesists, surveyors, physical geographers, and other related scientists have devised a wide variety of map projections and Coordinate Reference Systems.  Many of these can be easily transposed to a local area to provide an accurate local fit. Others are designed for regional or global applications. Often their selection depends upon the size and shape of the area they will be used in.  

Recently the Open Geospatial Consortium (OGC) took the initiative to collect and standardize the definition of elements (not the actual values) needed to describe as many Spatial Reference Systems as possible.  These are documented in their document OGC 03-073r1 entitled Topic 2: Spatial Referencing by Coordinates and located at www.opengeospatial.org/specs/.  

In 2003 the OGC was able to get these definitions adopted as ISO standard 19111:2003 entitled Spatial Referencing by Coordinates.  The ISO, or International Organization for Standardization, is a network of institutions from 146 nations organizing, testing, and publishing worldwide standards.  The complete contents of this ISO standard containing all its coordinate reference system definitions can be purchased from www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26016&ICS1=35.

Abstract of ISO 19111:2003 is as follows:

“ISO 19111:2003 defines the conceptual schema for the description of spatial referencing by coordinates.  It describes the minimum data required to define one-, two-, and three-dimensional coordinate reference systems.  It allows additional descriptive information to be provided.  It also describes the information required to change coordinate values from one coordinate reference system to another.

“ISO 19111:2003 is applicable to producers and users of geographic information.  Although it is applicable to digital geographic data, its principles can be extended to many other forms of geographic data such as maps, charts, and text documents.”

Geospatial analysis systems adhering to ISO 19111:2003 can identify the spatial reference system and standard definitions of the elements used to describe the geodata files, tables, layouts, web content, and so on created by any other system.  For this purpose, version RV7.0 of the TNT products now defines spatial reference systems according to this standard. 

Definitions.

This ISO standards document also provides some definitions of the standard terms used in connection with discussing spatial reference systems. These are now the terms that will be used to refer to these concepts and new features in the TNT products.

Coordinate Reference System.
A coordinate system that is related to the real world by a datum (for geodetic and vertical datums, it will be related to the Earth).

Coordinate System.
Set of mathematical rules for specifying how coordinates are to be assigned to points.

Coordinate Conversion.
Change of coordinates, based on a one-to-one relationship, from one coordinate reference system to anther based on the same datum.  Example: between geodetic and Cartesian coordinate systems or between geodetic coordinates and projected coordinates, or changes of units as from radians to degrees or feet to meters.  (A coordinate conversion uses parameters that have constant values.)

Coordinate Transformation.
Change of coordinates from one coordinate reference system to anther coordinate reference system based on a different datum through a one-to-one relationship.  (A coordinate transformation uses parameters that are derived empirically by a set of points with known coordinates in both coordinate reference systems.)

Datum.
Parameter or set of parameters that serve as a reference or basis for the calculation of other parameters.  (A datum defines the position of the origin, the scale, and the orientation of the coordinate system.)

Map Projection.
Coordinate conversion from a geodetic coordinate system to a plane.

Projected Coordinate System.
Two-dimensional coordinate system resulting from a map projection.

Geodetic Coordinate System and Ellipsoidal Coordinate System.
Coordinate System in which position is specified by geodetic latitude, geodetic longitude and (in the three dimensional case) ellipsoidal height.

EPSG Geodetic Parameters.

From the ISO abstract you learn that adopting 19111 standardizes how each Coordinate Reference System (CRS) is defined and the elements needed for this to transform it to other CRSs.  It standardizes how each CRS is to be identified (name, units of measure, datum, …) and what geodetic parameters are needed to use it (position of origin such as central meridian and latitude, unit of measure, scale factor, …).  It does not standardize in any way how this information and the necessary values for these parameters are referenced or stored.  This is left up to each geospatial analysis system.  It also does not provide any values for these geodetic parameters.  

Geodesists and mathematicians derive, propose, and adopt geodetic parameters for existing and new map projections, datums, CRSs, and transformations.  From these are derived the required numeric values for the elements defined for the spatial reference systems by ISO 19111.  Someone then needs to decide if these derivations are useful and correct and provide them in an organized form and readable format for use with the definitions in ISO 19111.   There also has to be a mechanism for correcting and changing parameters to adjust their precision and to add new ones.  

Early US petroleum exploration and drilling activities had the vast North American continent available to them.  They had the good fortune to find coordinated multi-national mapping programs and a coordinated strategy concurrently being put into place.  However, early European national and private petroleum companies found that even in their own nations and neighbors they had to deal with problems of differing, secret Coordinate Reference Systems (CRSs), datums, and levels of cooperation.  To compete with large multinational companies, this situation gradually led them to a cooperative spirit with regard to assembling and sharing this information.  Eventually these efforts gave rise in 1986 to the European Petroleum Survey Group (EPSG) to collect, maintain, and provide these geodetic parameters for thousands of CRSs.  As a result, the widely accepted standard source for the numeric values used for each ISO standard spatial reference system is the European Petroleum Survey Group (EPSG) database.  From their website at www.epsg.org the mission statement and objectives of the EPSG in this area are stated as follows.

“The European Petroleum Survey Group (EPSG) was formed in 1986.  It comprises specialist surveyors, geodesists and cartographers from Oil Companies based in Europe and having international operations. Meetings are held twice yearly to discuss survey and positioning topics within those areas of oil industry business where cooperation is generally agreed to be mutually beneficial. 

“A geodesy working group maintains a relational database of EPSG geodetic parameters.

“The EPSG aims to help member companies, and where relevant others, by the dissemination of information. The information will improve oil industry survey practices and procedures, will contribute to increased efficiency, enhanced quality, improved safety of operations and to the protection of the environment.

“Through its membership of specialist professionals, the EPSG is qualified to offer collective expert advice to member companies within the fields of geodesy, surveying, positioning and cartography where they relate to oil exploration, development and production operations.”

“EPSG, through its geodesy working group, maintains and publishes a data set of parameters for coordinate reference system and coordinate transformation description. The data is supported through formulae given in Guidance Note number 7. The EPSG Geodetic Parameters have been included as reference data in the GeoTIFF data exchange specifications, in the Iris21 data model and in Epicentre (the POSC data model). The parameters are maintained in an MS Access relational database and may be downloaded from this site.”

RV7.0 of the TNT products now uses the current EPSG V6.6 geodesy parameters released 20 October 2004 for this purpose.  Provisions for integrating their 6 month updates into your TNT products are discussed below.  Since the ISO definitions are standard and the parameters are found in this common source, the Coordinate Reference System, datum, map projection, and other characteristics can be established in the TNT products for geodata provided from geospatial analysis systems that have adopted these same standards.

Expectations in Using a Standard Coordinate Reference System (CRS).

Standardization of Information.

It is up to the developer of a geospatial software product to determine how the standard ISO definitions and associated EPSG geodetic parameters are stored, accessed, and used. All MicroImages’ TNT products, Oracle’s Spatial Layers, and GeoTIFF files use these ISO definitions and EPSG geodetic parameters.  If, as is the current trend and case in these products, each of their georeferenced files provides access to the identity of its ISO 19111 Coordinate Reference System (CRS), any other compliant geospatial system can use the same CRS for its activities with that file.  This assumes of course that each system can read and interpret the data content in that file.  For example, MicroImages autolink to, or import of, a GeoTIFF file finds and uses this standard CRS information.  It similarly includes the proper CRS information in the proper place in an exported GeoTIFF.  If, as is also the trend, the geodetic parameters in EPSG are incorporated in, kept up-to-date, and used within each system, then the TNT products are using the same geodetic parameters and CRS used for coordinate system, map projection, and related spatial activities on that file whether it is internal, linked, imported, or returned from some server.

Identical Results are Still Not Guaranteed.

Even though these standards are in place and correctly used to define a particular Coordinate Reference System (CRS), the internal accuracy of the use of this coordinate system will vary slightly between systems.  For example, unless the CRS of a linked GeoTIFF file is identical to the desired projection of the composite view, it may be converted as used to match the reference CRS of the TNT view using a fast but approximate affine transformation.  Another system may use some other transformation or approach to rapidly adjust for differences in the CRS layers in a composite view, thus achieving varying success in matching the geodata layers in the view.  On the other hand, coordinate readouts of a point in TNT have a high level of precision as these values are derived by using the geodetic-based transformation of that point for each layer.  Conversions of geodata between CRSs may be slightly different in each system at the highest precision depending exactly on its implementation of map projection and transformation equations in that system.

New TNT Spatial Referencing (SR) Service.

Implementation.

MicroImages stores the ISO Coordinate Reference System (CRS) definitions and associated EPSG geodetic parameters in XML in a reference file (spatref.xml).  Since this is XML, it could be used in other non-TNT programs. 

A built in software module called the TNT Spatial Reference (SR) service accesses and uses the contents of this reference file in every TNT process in any TNT product and is automatically available for use in your SML script or your program developed with the TNTsdk.  It will also subsequently be used by the TNTserver.

Also included in this SR service’s reference file are the additional Coordinate Reference Systems (CRSs) and geodetic parameters accumulated by MicroImages over the past 20 years. These earlier definitions and associated parameters are retained from V6.9 and, along with new CRSs from the EPSG database, make up a collection of TNT “predefined CRSs.”  These predefined CRSs and “private CRSs” that you defined for your private use are also used by the new Spatial Reference (SR) service. Provision has also been made for the SR service to use new and also private CRSs not included in the ISO/EPSG standard approach. Thus, this SR service permits you to mix and move your geodata between these standard predefined and private CRSs.  It also provides the framework for the potential addition of other CRSs, such as those that are geocentric and gravity-related.  For example, at the moment MicroImages is experimenting with the use of celestial CRSs (ascension, declination, …) and their associated parameters.

 Access to Extensive New Collection of CRSs.

The incorporation of the ISO standard and EPSG database into the TNT products has added thousands of new CRSs.  These consist of predefined combinations of coordinate systems and datums, combinations that you mate together, and conversions between CRSs.  As a result it is much more likely that you will find the CRS you require already predefined and directly available to select for use in a TNT process.  If not, then you can select the coordinate system and datum projection separately to define a CRS and the TNT Spatial Reference service will combine them together for all your subsequent uses of this CRS.

Accurate Datum to Datum Transformations.

New datums are not often created.  Considerable effort and new scientific advances in measuring and representing the shape of the earth are required for change in this area.  For example, today these geodetic measurements require new and more precise satellite systems.  Then there is the necessity of getting worldwide acceptance of the new datum, which means getting wide scale acknowledgement that it is needed.  So new datums are infrequently encountered except in narrow, scientific endeavors for special purposes or for nationalist reasons.

However, periodically new datums have been adopted because they more accurately describe the shape of the earth.  The precision and relative accuracy of the measurements of coordinates in a CRS can be increased if a more accurate datum is used.  For these and other reasons, you will find new geodata sources (for example, new high resolution orthoimagery) use a newer datum than some older geodata you need to use as well (for example, older maps).  Achieving accurate coordinates and results in your project requires that all computational activities on your geodata refer to it using a common datum.

V6.9 of the TNT products automatically converted coordinates from other datums to the WGS84 (World Geodetic System 1984) datum when the objects being combined were in different datums.  Then, if required, a reverse conversion was used from WGS84 to get coordinates and the combined results using the new datum. The same procedure was used when an object was deliberately converted between CRSs using two different datums, neither of which was WGS84. WGS84 as a common datum has been popular since 1984 when it was introduced for use with satellite imagery and orthophotos. Due to its popularity, there are many coordinate transformations to and from it.  Thus, using it as a common datum for all geodata is a widely accepted approach, especially in low-cost products where maintaining accuracy to 1 meter or better was not needed when converting from datum to datum and had not yet become an issue. 

RV7.0 no longer necessarily uses the WGS84 datum as an intermediate step when converting between two other datums.  The new Spatial Reference (SR) service uses the accurate transformations associated with the respective CRSs for direct coordinate conversion between datums such as ED50 to ETRS89, Tokyo to JGD2000, and AGD66 to GDA94.  Provision has also been made in the standard CRS structure for adding more direct conversion transformations as the EPSG and other geodesists define them.  This direct datum to datum conversion of coordinate systems not only increases the accuracy, but is faster since the two previous transformations (one into WGS84 and one out of WGS84) are replaced by one direct transformation if it has been defined. Geodesists and/or mathematicians can also disagree on the best transformation between datums and then publish and promote alternatives.  As a result the new SR service lets you choose which to use if one or more coordinate transformation is available for the pair of CRSs.  If the needed datum transformation(s) are not available, then WGS84 is used as an intermediate as in V6.9.

Maintains Native Measurement Units.

A Coordinate Reference System (CRS) definition specifies the measurement units used for its coordinate axes and associated computations.  The new Spatial Reference (SR) service now imports or creates geodata objects in the native measurement units defined by its CRS.  Coordinates of georeference points are no longer automatically converted to meters when stored with the object as was the case in V6.9.  RV7.0 uses the native coordinates matching the CRS.

6 Month Updates.

Every 6 months EPSG issues Microsoft Access tables to update their geodetic parameters to refine their precision and to define new Coordinate Reference Systems (CRSs), associated datums, and transformations.  MicroImages will acquire this EPSG database and integrate its additions into the spatref.xml resource file.  Every weekly patch issued for the TNT products includes the latest spatref.xml resource file to update the CRSs available to the Spatial Reference (SR) service.  In this manner, any new EPSG additions and changes and the new CRSs you request MicroImages to add will be immediately available in the weekly patch for the current version of the TNT product.

These EPSG updates and new Coordinate Reference System (CRS) additions will not be incorporated into the spatref.xml file and patches for earlier versions of the TNT products (for example, no changes to the spatref.xml file for PV7.0 after RV7.1 is officially released).   The easiest way to keep up with the changes in the CRSs used by MicroImages and other systems using the ISO/EPSG standard is to maintain a current subscription and use the current TNT products.

New Interface.

Coordinate Reference System Window.
All TNT RV7.0 processes use the new TNT Spatial Reference (SR) service for object to object, screen to object, linking, import, export, and any other geodata changes requiring a Coordinate Reference System (CRS), coordinate conversion and transformation, and map projection operations.  As a result all processes now use this new tabbed interface for selection / setup to control these operations.  This new uniformity coupled with these thousands of new choices and combinations require a new user interface.  This interface must also permit you to define, name, and save private Coordinate Reference Systems (CRSs) and selected datum transformations.  For this purpose a new Coordinate Reference System window with tabbed panels replaces the existing Map Projection / Coordinate System window.  This window is illustrated and its tabbed panels described in the accompanying color plate entitled Coordinate Reference System Window.  The material covered in this and the 3 following color plates on this topic will be assembled and expanded into a new tutorial reference booklet on Coordinate Reference Systems since the current tutorial booklet on Map Projections is temporarily out-of-date.  

All these new capabilities and options for TNT Coordinate Reference Systems come at a price.  You will have to learn to use this new and unfamiliar user interface to select and control these new operations.  At first this window and its operation will appear more complicated as by necessity it has to be designed to deal with many new options to control the new TNT Spatial Reference (SR) service.  Its use will take some patience and getting used to.  MicroImages is interested in hearing your suggestions for its improvement and simplification of this activity keeping in mind that it must still cover all these many objectives.

Predefined Tabbed Panel.
The first and default tabbed panel in this window is labeled Predefined.  It provides a hierarchical tree structure that you can use to navigate to any one of the thousands of predefined Coordinate Reference Systems (CRSs).  The main categories of this structure are Recent, Global and Regional, and National and Local.  The Recent grouping will contain the last 10 CRSs you have used with the most recent at the top.  If you constantly use the same CRS, you will only need to reselect it each time from this list.  If you are looking for another CRS, you will need to traverse into this geographically structured hierarchy until you can find and select it.  This and additional options for setting up other CRSs using this tabbed panel are explained and illustrated on the accompanying color plate entitled Predefined Coordinate Reference Systems.

Datum Tabbed Panel.
When you select a complete predefined Coordinate Reference System (CRS) from the first tabbed panel, it has a datum already associated with it.  However, you may wish to change to some other datum.  In addition, the Predefined list also includes global and regional Coordinate Systems (such as UTM zones or latitude / longitude coordinates) that can be used with any datum and thus require you to select the datum you wish to use to create your CRS.  The datum tabbed panel presents a scrolling list of the available datums.  The datum automatically associated with the CRS or that you previously selected for this CRS is automatically highlighted in this list.  Use this list to select any datum you wish to use in the CRS.

If the datum you have selected has direct transformations to other datums available, you will be asked to select one from a new list shown in this same panel.  If the new target datum is not on the list, the transformation will not be direct and will be a two step operation using the WGS84 datum as an intermediary.  These datum selection operations are illustrated in the accompanying color plate entitled Predefined Coordinate Systems Requiring Datum Selection.

Create a Private Coordinate Reference System.

Encountering new datums is infrequent, but just the opposite is true for Coordinate Reference Systems (CRSs) and/or their definitions.  You could easily create a new CRS for your site, especially if it’s large, such as a major hydroelectric project or even a city-wide high precision GPS vehicle tracking network.  You could do this by choosing a CRS and altering the geodetic parameters to center it on your site.  Frequently you will find that someone for some reason has already done this and you must deal with geodata that cannot be selected from the thousands of combinations presented by the new TNT Spatial Reference (SR) service.  The accompanying color plate entitled Custom Coordinate Reference System Setup illustrates how this is done using the new CRS interface.  (Note, it was decided to call these Private, not Custom CRSs after this color plate was printed so private = custom.)  You can also deal with these situations by getting your CRS added to the TNT SR service via the next weekly patch discussed above.

Published Additions.
Some of the 93 counties in Nebraska have a locally centered Transverse Mercator Coordinate Reference System (CRS).  City/county officials and the surveyors who work in these counties may use it routinely, especially if they have major urban areas such as Lincoln City and Lancaster County combinations.  Rural Nebraska counties may not need that local accuracy and use the generic large UTM zone or each state’s state-wide CRS system called the State Plane CRS.  If you encounter these kinds of local conditions, it is best to get their CRS incorporated directly into the TNT product.  This is also the best approach if this new CRS will be widely used in your geographical area.  Adding a new CRS to the definitions used by the TNT products is easy via the patch procedure if you provide the required parameters in sufficient accuracy.  You should also provide some sample data points with paired coordinates for testing our implementation of any new CRS.  These are used to test the implementation (parameters and coding) by using them with the new CRS in the TNT Map Calculator since it uses the common TNT Spatial Reference (SR) service.

Private Additions.
The second alternative is to create, name, and save your own private Coordinate Reference System (CRS).  You might choose this route because no one but you would be interested in using this CRS.  Or, you might choose this method because the organization you are working for or with does not want this CRS to be publicly available.  Once you have set up and named a private CRS, it will appear for selection in a new major category named Saved on the Predefined tabbed panel.  The steps in adding private Coordinate Reference Systems are illustrated in the accompanying color plate entitled Custom Coordinate Reference System Setup.  Private CRSs that you set up this way are defined and saved in a separate XML reference file (savedcrs.xml) that is not changed or overwritten when you patch or update your TNT product.

Adding a private Coordinate Reference System (CRS) and corresponding parameters for use in the TNT Spatial Reference (SR) service does not violate the concept of adhering to ISO standardization.  You still need these projections to deal with your local and special situations within the TNT products.

Backward Incompatibility of New Coordinate Reference Systems.

Minor inconvenience of backward incompatibility is not new. 
To avoid producing an irresolvable error in the operation of V6.9, Project Files are marked by RV7.0 as unusable and backward incompatible if they contain an object using a new feature unknown to V6.9.  This same procedure has been used in previous releases.  For example a Project File created in V6.9 in a TNTatlas was marked as unusable in some earlier versions if you specified in the TNTatlas wizard that only the Software Access Key used to create it could gain access to objects in that Project File.  If you attempt to use such a Project File or one containing such an object in an earlier incompatible TNT version, it is then not recognized as a Project File and can not be selected in that older version.  In the past this has seldom been a problem since it was obvious to you that you were using a new feature and that the object would not be backward compatible with earlier TNT releases.  You simply kept that object in its own separate Project File from any other objects, restricted its use to the current version, or did not use the feature.

But temporarily of more significance.  
RV7.0 provides 3 new features that if used with an object will make that Project File unusable in any earlier version: using label frames and leader lines in a CAD object; georeferencing a manifold object; and selecting a previously undefined Coordinate Reference System (CRS) for any object.  The first 2 pose no special problem as it is obvious that these are not usable in an earlier version of the TNT products, are new and special features, and they are easily isolated to their own Project File if you intend to move any associated objects back and forth to an earlier version.  However, the CRS is used for every geodata object in the TNT products.  This, coupled with the many new CRSs added in RV7.0, creates circumstances in which this backward incompatibility is more likely to occur and, thus, mark that Project File as backward incompatible.  This might occur because you are using both V6.9 and RV7.0 on the same machine, have several TNT licenses at different versions, or supply a Project File to someone else with an earlier license.

All the Coordinate Reference Systems (CRSs) used in objects in V6.9 are recognized and usable in RV7.0.  Correspondingly all the CRSs available in V6.9 are still available in RV7.0 and, if selected for an object in RV7.0, it and its Project File can still be used in V6.9.  However, no provisions were made in V6.9 or earlier versions of the TNT products to even recognize that an unknown new CRS available in RV7.0 has been used in an object.  As a result, V6.9 and earlier can not even inform you that a new CRS has been detected and the Project File can not be selected. 

At the bottom of the Coordinate Reference System Window to help you avoid this situation you are presented with a means to tell the TNT Spatial Reference (SR) service how to deal with this condition every time the SR service is used in any process. It permits you to select this global “Compatibility with TNT version 6.9 and earlier” from 3 options.

Warn if not usable.  This is the initial default and every time you choose a Coordinate Reference System unknown to V6.9 you will be warned that the new object and Project File it is in will not be usable in V6.9 or earlier.  If you are working primarily in RV7.0 and seldom use Project Files in earlier versions, then this may be your best choice.

Required.  This setting will prevent you from selecting any new Coordinate Reference System that is not available for use in V6.9 and earlier.  If you are frequently moving Projects Files between RV7.0 and earlier versions for some reason, you should use this setting.

Not checked.  Use this setting if you do not have any earlier version of your TNT product installed and do not intend to do so.

Will become insignificant again in future releases.

About this point you are asking, if only one object in a Project File uses a new feature, such as an unknown new Coordinate Reference System, why does this make the entire file backward incompatible?  Previously this never posed an issue for you or MicroImages with earlier versions for the reasons already noted.  In part this was also due to the fact that before the current efficient TNT patching system and your access to it by a broadband connection, you were less inclined to maintain and use two versions of your TNT products (for example, The Tried and True and Something New).  Thus, no provision was incorporated in any earlier version of the TNT product to record with the object the minimal version that is needed to use the object. 

Recording the version of the TNT product that created or modified a geodata object has been added to RV7.0 for future use.  For example, if DV7.1 or RV7.1 adds a new feature to an object making it unusable in V7.0 or earlier, this restriction will be understood and applied by V7.0 at the object level, and not the Project File level.  Thus, adding an object with new features restricting it for use in the current or new versions, would mark only that object in the file as incompatible for the earlier versions.  V7.0, and future versions, can then recognize this, deny access to that object only, and tell you that the object’s use is not permitted in the older version you are running due to new features.  However, it will not be able to tell you what new feature you have used to create this condition since they are unknown at the time that the earlier version of the TNT product was created.  But, V6.9 exists and has no ability to recognize this object level version tracking system added to RV7.0.  Altering V6.9 for this purpose via a patch would be complicated and risky.  After a couple of additional new releases, this will no longer be a problem at the Project File level and any new Coordinate Reference System can be used without these complications.

And forward compatibility is ensured.
As you have come to expect, great effort is expended in ensuring forward compatibility of your TNT object and Project Files to protect your investment in data creation and its analysis.  As in the past, RV7.0 of the TNT products maintains forward compatibility for all your existing Project Files created with earlier versions.  As new procedures and features are added to the TNT products, the associated processes continue to recognize and use older Project Files and objects created earlier.  Modifying these earlier objects in a new version may automatically update them to support their use with improved performance in newer versions unless you deliberately prevent this from happening for backward compatibility.  For example, pyramid layers are added to raster objects and optimization applied to vector objects automatically to improve these objects performance for both display and analysis.  

Miscellaneous.

At the request of various clients, the following new projection methods are available:

• General Oblique Mercator for various locations,

• Krovak Oblique Conic Conformal for the Czech Republic and Slovakia,

• Lambert Conformal Conic single standard parallel for SE Asia,

• Transverse Mercator South oriented for South Africa,

• Bonne, and others.

A high-accuracy grid method has been added for converting between Tokyo and JDG2000 datums.

Shape Objects.

The concept of the use of a shape object in a TNT Project File was first introduced in RV6.9 as a work in progress that continues in RV7.0. The design of a shape object is database-centric, that is, it has the easy maintenance of a complex database structure as its principal goal.  Primitive graphical data elements (points, lines, arcs, …) are treated as fields in the tables.  The relationship and information about how these primitive elements are assembled into features is maintained in the database structure.  

Why Not Use a Vector Object?

A vector object must maintain very rigorous topological relationships to enable advanced spatial analysis.  It can be thought of as designed to be area- or topology-centric.  Maintaining attributes for these features in an external linked database can be difficult especially when that database must be secure and/or controlled by others.  This is easier to accomplish if the attributes and other database structures are in TNT’s internal relational database format, but this may not meet your project’s requirements.  

Why Not Use a CAD Object?

CAD objects, usually imported from external CAD files or captured as sketches, have no topological features and can be very complex in graphical content with many lines and polygons constantly crisscrossing and in very close proximity.  The CAD object has been designed to be graphics-centric.  CAD files and, thus, CAD objects maintain no concept of area in a geographic sense. Very complex relationships between elements can also occur in an external CAD file and any associated database.  These can be difficult to preserve when converted into a vector object as they create complex topology due to the many overlapping features and rendered blocks, which in turn create cumbersome relational database structures.   A CAD object is closer to a shape object than a vector object but is designed to optimize its graphical structure, geometry, and contents and not its relational database structure.  

Why Use a Shape Object?

When fully implemented and supported, this database-centric design of a shape object is most effective for use with geodata layers whose extensive attribute data is being maintained in external databases (for example, Oracle, DB2, MySQL, and others).  In these cases, the graphical elements can be maintained in the shape object without topology while the tabular material can remain in the external database or is imported into the shape object for use in the TNT internal relational database structure.  Alternatively, all the original tabular and associated graphical elements can be retained in their original external structure and a link, or wrapper, automatically created when they are selected for use as a layer in a TNT view or as input to an analysis process.  This is the initial use of the shape object to support the efficient and direct use of database-centric geodata structures of other systems such as Oracle Spatial Layers, ESRI shapefiles,  MapInfo TAB files, and others.

Linking to a shapefile in V6.9 treated it as a CAD object and had to take the time to set up all the database associations between the elements and the records.  The shell of a shape object was introduced in RV6.9 to provide for the direct link and use of Oracle Spatial Layers.  RV7.0 uses this same shape object concept to provide a faster and more flexible link to a shapfile. This new link file contains a description of how the shapefile is to be interpreted to make it respond as a shape object to the TNT processes.  It also provides the basis for storing information to enhance the use of the shapefile to provide features not originally supported by the shapefile. Several of these are provided by the new, fast link to shapefiles and are discussed in the section just below entitled Direct Display of ESRI Shapefiles.

©MicroImages, Inc. 2010 Published in the United States of America
11th Floor - Sharp Tower, 206 South 13th Street, Lincoln NE 68508-2010   USA
Business & Sales: (402)477-9554  Support: (402)477-9562  Fax: (402)477-9559
Business info@microimages.com  Support support@microimages.com  Web webmaster@microimages.com

---