2005:71 Release of TNT products

Mac OS X: Geologic Mapping Station
Mac OS X: Mac Stereo Viewing with the Sharp 3D Monitor
TNTatlas: Nebraska Land Viewer Atlas
TNTserver: Open Geospatial Consortium (OGC) Specifications (2-sided)
TNTserver: Configuration (1/2 page)
TNTserver: Managing General Controls (1/2 page)
TNTserver: Managing Image Properties
TNTserver: Managing Logging (1/2 page)
TNTserver: Managing Site Logo (1/2 page)
TNTserver: Managing Web Access (1/2 page)
TNTserver: Managing Administrator Contact (1/2 page)
TNTserver: Managing ID Titling (1/2 page)
TNTserver: Managing Directories (1/2 page)
TNTserver: Managing System Parameters
TNTmap: Browsing and Selecting WMS Layers
TNTmap: Viewing WMS Layers
TNTmap: Using Google Earth as a Client
TNTserver: Using a Third-Party WMS Client
TNTsim3D: Manifolds
TNTsim3D: Stereo Viewing
TNTsim3D: Smoothing Flight Paths (2-sided)
TNTsim3D: Making Movies (2-sided)
TNTsim3D: Custom Views from any Angle/Position
System: Direct Use of CAD Files (DWG, DXF, DGN, TAB)
System: Resolving Auto-Link Issues
System: AutoOpen External Spatial Data Files (2-sided)
TNTexplorer: Introduction to Project File Folders
TNTexplorer: Left Button Operations in a Folder
TNTexplorer: Right Button Features in a Folder
Miscellaneous: Managing Raster Null Cells
Style Editor: Embedded vs Linked Style Objects (1/2 page)
Theme Mapping: Embedded vs Linked Style Objects (1/2 page)
System: Orthographic Projection for Global Views (2-sided)
Spatial Display: Raster Layer Caching
Spatial Display: Geometric Layer Caching
Spatial Display: Automatic Highlighting of Vector Elements
Spatial Display: Subtle Display Hints in LegendView
Spatial Display: Merging LegendView Entries
Spatial Display: Improving Line Intersections (1/2 page)
Spatial Display: Partially Transparent Symbols (1/2 page)
GeoToolbox: Show/Hide Areas of Interest
3D Display: Faster Display with Stored Terrain Properties
3D Display: Control Accuracy of Terrain Rendering
3D Display: Perspective Rendering of Geometric Layers
3D Display: Use LegendView to Toggle Layers
3D Display: Polygon Styling Options
3D Display: Drape Labels over Terrain
3D Display: Render 3D Elements as 3D Shapes
3D Display: Stereo Viewing on the Sharp 3D Monitor
Mosaic: JPEG Directly to JPEG2000
Mosaic: MrSID Directly to JPEG2000
Export: Creating MrSID Files
Import: Selecting File First
Import: Selecting Format First
Export: Creating External Files
Export: Rasters for Google Earth
Import: Duplicate Microsoft Access Relationships
Scripts by Jack™: Workflow: Calibrating/Analyzing Multispectral Images
Scripts by Jack™: Calibrating Multispectral Satellite Images
Scripts by Jack™: Calibrate Satellite Images to Surface Reflectance
Scripts by Jack™: Correct for Terrain Induced Radiance Effects
Scripts by Jack™: Mapping Dense Vegetation and Bare Soils
Scripts by Jack™: Mapping Vegetation/Soil Biophysical Properties
Scripts by Jack™: Generalized Mapping of Biophysical Properties
Scripts by Jack™: Color-Enhance Satellite Images of Coastal Areas
Sample Tool Script: Control Display by Area of Interest (2-sided)
Sample Tool Script: Draw into CAD Object in a Script (2-sided)
Sample Tool Script: Measure Strike/Dip of Geologic Features (2-sided)
Sample Geospatial Script: Patch Holes in SRTM DEMs (2-sided)
Urban Studies: Slope Analysis
Urban Studies: Site Selection Analysis
Urban Studies: Watershed Analysis

Introduction

MicroImages in its 19^th year in business is pleased to distribute 2005:71 of the TNT products. This is the 56th release of TNTmips and adds approximately 164 new features submitted by clients and MicroImages. The version numbering for the TNT products has been changed to reflect the year:version (for example, 2005:71) of the TNT product you are operating. This follows the trend in software industry (for example, AutoCAD 2005, SQL Server 2003, and so on.). Thus your V7.1 has become 2005:71 and the next release will be 2005:72 or 2006:72 depending upon the day of its release via microimages.com. Previous versions are similarly renamed 1986:09, … 2003:68, 2003:69, and 2004:70. The actual release date of and this revised designation for every previous version number of a TNT product can be found at www.microimages.com/relnotes/.

What follows is a brief summary of many of the significant new capabilities in 2005:71 of the TNT products.

Mac OS X: Installation now uses the frequently encountered commercial Installer VISE program.
TNTsim3D: Planar, folded, or curvilinear manifold surfaces designed and viewed in TNTmips can be used in a simulation with or without a terrain surface. Fly around or through raster or vector features projected onto these manifolds to better visualize their 3D structure and its relationship to the topography and other surface features. Any view in any simulation can be switched to stereo using almost any viewing device (choose line or column interleaved or anaglyph). Recorded flight paths can be smoothed and played back to create a movie. Custom views can be created for any viewpoint but are slaved to the changes in the Main view (for example, centered on the same terrain position). Custom help and other metadata can be displayed in a new window.
TNTatlas: A DVD entitled Land Viewer: Nebraska Statewide is provided to demonstrate how to distribute a 1-terabyte color, 1-meter orthoimage of a large area (the State of Nebraska) as a JPEG2000 200:1 lossy compressed atlas. A Tool Script is provided to illustrate how to zoom directly to a view of a farm or ranch, city, county, or Natural Resource District of interest in this TNTatlas.
TNTfreeview: TNTatlas can now be easily used as a free viewer while still providing all its interactive tools. No need to learn how to startup and load a layer in TNTatlas. Simply click on any directly supported spatial data file (MrSID, JP2, JPEG, DWG, DXF, DGN, shapefile, a TNT layout, …) of any size and it will open TNTatlas with a view of it.
TNTserver: Publish any composite atlas view or its individual layers over the Internet or intranet using this OGC complaint Web Map Service. Combine atlas content being hosted with images from other sites publishing their geodata via a Web Map Service. Use these results as custom layers in Google Earth. Installation and patching now use the Install Shield process as the other TNT products. A new TNT server Manager program is included for easier setup, management, and optimization of the operation of TNTserver.
TNTmap: This is a new, free, open source, HTML-based client application to locate and select layers from any Web Map Service, including TNTserver, and composite these images into a view of the area of interest. It can also start Google Earth and overlay these results or save them locally as a raster for use as a layer in NASA’s World Wind.
Linking to CAD Files: Direct links can now be made to AutoCAD DWG and DXF files and MicroStation DGN files by selecting them with the mouse or from within a process via the TNT Select Object dialog. ISO Coordinate Reference Systems can be identified and added to their links. After a few seconds to build the link, they behave as TNT CAD objects for any further processing.
Starting from Data: Use a mouse click on a DWG, DXF, DGN, TAB, MrSID, JPEG, JP2, PNG, TIFF, ECW, and so on including an object, group, or complete map layout in a Project File to start your TNT product and view the file as geodata. “Open With” or an equivalent on any of these files will open it for immediate use in 2D Display. These actions will automatically open the entire TNT product and process starting with the X server and then link to and use any format supported for direct use in seconds.
Linking as Geodata: Spatial data files (for example, DWG, JPEG, …) selected for direct viewing by the mouse, “Open With,” or internally via the Select Object dialog do not have a known earth Coordinate Reference System (CRS). A prompt permits you to choose and assign them an ISO CRS so the linked object can be used with other TNT geodata objects. The prompt also permits you to compute raster pyramids as part of the linking activity for old fashioned “flat” raster formats, such as JPEG. Indexes are automatically computed for geometric data types and their attributes to optimize their access as geodata objects.
TNT Explorer: Using the same code underlying Microsoft Explorer every Project File now automatically looks and functions like a Windows folder on the desktop (TNT folder = Project File). When the folder is open the primary objects, groups, layouts or links to other spatial data files (for example, to DWG, shapefiles, …) in the Project File are shown in that folder. A left click on a TNT folder opens it in any of the five standard windows modes: thumbnails, tiles, icons, list, or details. A right click on a TNT folder provides many of the familiar Windows operations. A left click on a TNT object in this window opens a TNT product and loads the file into its 2D Display. A right click on a TNT object provides some of the familiar Windows options such as delete, rename, browse, properties (properties = “Info” icon in Project File Maintenance), and a thumbnail in the common tasks bar. This right click menu also lets you open a TNT object in the Spatial Data Editor or add it as a layer in any already open 2D view.
General System: Shapefile themes are now detected and used in a link and can be edited in the link file. Elements in point symbols can be set to be partially transparent. Line intersections are improved by multi-pass rendering. Styling can be embedded with the object when a style object from another file is selected. Large uniform value areas in rasters (for example, nulls) and most of a binary null mask are now greatly compressed using single value tiles, which store only the value and location of each uniform tile. There is improved support for using objects that circle the globe and overlap and/or contain the poles.
2D Display: Each layer added to a view now has its own separate real memory buffer for the area it occupies in that view. As a result, toggling layers on/off, changing layer order, toggling View-in-View, deleting a layer, and other actions on a complex view that do not change its position are nearly instantaneous. Adding a new layer is faster. Selecting and unselecting elements are nearly instantaneous including the new DataTip controlled pop-in of the actual geometric elements often called a “mouseover” event.
LegendView: Layer names are now color coded to identify why they are not visible in the current view: Toggled Off, Off by Scale, Off by Extent, or Content Changed. Combining or not combining duplicate legend entries is now optional.
3D Display: Rewrite of the process has been completed, therefore only the new variable, or irregular, triangulation terrain rendering model is automatically used to provide fast, high quality views. LegendView is available and provides all the same functionality as in 2D display. If the optional terrain property subobjects are computed and stored during the import of the elevation raster object, then complex 3D displays take seconds. If not, these elevation property objects are computed for the first 3D view and all subsequent repositioning of that view or layer changes using that terrain will then take seconds. DataTips, 2D styling of all element types, and labels are as they are in 2D Display and have good depth perspective.
Raster Warping: A conformal model has been added to the choices (for example, affine, …) available in processes that perform this activity. This shape-preserving model allows rotation, scaling (same for both axes), and positioning while preventing distortion of features due to shear or differential scaling of each axis.
Predefined Raster Combinations: Rewritten process that now provides new operations and properties for each cell: rescaling, count, mean, median, mode, minimum, maximum, diversity, sum, standard deviation, regression slope and offset, exclusive OR, tasseled cap, multiple selections of same input raster, and compression of the output rasters.
Raster Mosaicking: Select compressed raster objects or linked rasters as input (for example, MrSID, JPEG, JP2, ECW, …) and output any compressed raster object (for example, JPEG2000, JPEG, …). Faster setup to mosaic many 1000s of linked or internal raster objects. Faster mosaicking of terabyte-sized objects.
Import Process: Rewritten as separate Import process to use automatic linking to external spatial data files wherever possible as the basis for importing them. Completely new interface presenting formats and extensions is in an easier to understand tabular form. A new uniform Import Parameters dialog is used to set choices for all imports. Import activities can start now by either choosing the file or the file format. Selecting multiple files for batch import is now easier to set-up.
Export Process: Rewritten as a separate process from Import process but uses a similar tabular interface and common Export Parameters dialog.
New Import Choices: DWG and DXF CAD files using the Open Design Alliance libraries. DGN CAD updated. ERDAS IMG files greater than 2 GB. Nikon, Ricoh, and Kodak proprietary digital image files. NETcdf. JPEG EXIF digital camera files. TIGER 2003 and 2004 as vectors.
Google Earth: Raster objects, or any geometric object converted to a raster object, can be exported to JPEG, TIFF, or PNG files with a co-named KLM file for use as local overlays in this viewer. Remember that PNG files can be transparent to permit the Google Earth background to show through overlays of polygons and other geometric elements. Before exporting, make sure to convert the object to the WGS84/Geographic CRS used by Google Earth.
MrSID: MrSID lossy and lossless (*.sid) files can be exported from raster objects for Mac OS X or Windows. (This is a proprietary compression and requires purchase of a data metering cartridge from LizardTech). Direct linking and import of MrSID files is now available for Linux.
Microsoft Access: The Access schema is now used in linking or importing relational databases.
Calibrating Multispectral Imagery: A script converts the data numbers from Aster, QuickBird, Ikonos, and Landsat sensors to surface reflectance of each ground cell in each band. If these images have a matching DEM, another script corrects this cell value for terrain effects to represent the horizontal surface reflectance.
New Vegetation and Bare Surface Properties: A script maps areas of dense vegetation and bare surfaces using the calibrated reflectance values from the calibration scripts noted above. Using these “end member” rasters as masks together with the band reflectance rasters as input, another script uses a new GRUVI algorithm to map the perpendicular vegetation index and the bare soil/surface brightness index with more accuracy than NDVI or other similar indices.
Generalized Biophysical Surface Properties: A script uses these calibrated band numbers in a tasseled cap approach to map vegetation greenness, brightness, wetness, and bare soil brightness. It can be used for experimenting with extracting other new properties from imagery providing 4 to 6 different wavelength ranges.
Enhancing Coastal Images: A script enhances the water penetration of these reflectance images and prepares a single, color image with good composite color representation of surface and shallow water features.
Documentation for Image Calibrations: Approximately 200 pages of documentation are available on the technical use of the scripts provided for the calibration of multispectral satellite imagery to reflectance and its application to mapping biophysical properties.
Measuring Strike/Dip: An interactive Tool Script is available to assist in measuring and recording strike and dip using images draped over a DEM.
Filling SRTM Holes: A script provides a variety of options for filling the holes or null areas in SRTM derived elevation rasters. It includes single hole patching, lake detection and filling, and plugging of larger holes with locally derived elevation rasters.
Geospatial Scripting Language: Use 16 new Import/Export classes (for example, DWG, GML, shapefile, …). Draw directly into a CAD object. Connect to an HTTP web server. Use SOAP to communicate with a SOAP web service. Use any input device to interrupt a script. Improved documentation for the Coordinate Reference Service classes. Save and use current display setup parameters. Compute contrast for a raster layer. Select multiple objects of different types in a single dialog.
Tutorials: Two new tutorials are provided on the topics of understanding and managing Project Files and using the new ISO-based Coordinate Reference Systems. The tutorials on mosaicking and understanding map projections have had significant revisions to bring them into alignment with recent changes. Printed copies of 21 new Quick Guides are enclosed. 66 new printed color plates also accompany this MEMO to illustrate the use of the new features in TNT 2005:71.
TNTtalk: A moderated discussion group is available to exchange ideas on the applications of TNT analysis products.

Editorial and Associated News [by Dr. Lee D. Miller, President]

Keeping Your Tools Sharp.

I am confused. Periodically someone buys a new, up-to-date computer running Windows XP for US$1000. Next they load all their software and say “run.” It is guaranteed that the TNTmips 1999:61(V6.1) we released 6 years ago for Windows NT and cost in excess of US$5000 is not going to run correctly without being upgraded. There is no way that Microimages can issue TNT products that anticipate 6 years in advance the future changes to your operating system, processor, and peripherals. The first thing you will find is that the computer does not have a parallel port for your software authorization key, whereas, USB keys and ports were not available in 1999 when version 1999:61 was released. Fortunately, you do still have your original computer and can continue to operate the 1999:61 model of your TNT product, right?

Keep in mind that this is the area where Microsoft makes most of its money. It comes from selling upgrades to Office and its 1000s of other products. Upgrades that do not necessarily provide new functionality but simply run, run better, or with better security in their latest version of Windows. Typically upgrading these products from the previous or any earlier version costs from 1/3 to 1/2 of the price of a new, current version. The cost of upgrading from TNTmips 1999:61 to 2005:71 is also about 1/3 to 1/2 the original purchase price and much less proportionally if the TNT product is a more recent version.

To keep pace with the rapidly expanding demands on the use of geodata and geospatial analysis, TNTmips has been upgraded 10 times since 1999:61 and has extensive new capabilities. What are some of these areas that more or less did not exist in 1999?

High quality, high resolution, multispectral satellite images are readily available everywhere.
Widely available, locally detailed DEMs or SRTM-derived DEMs of whole nations.
Accurate GPS devices to collect ground control points to use with these DEMs and new satellite image formats supplied with RPC coefficients to inexpensively process into orthoimages.
1000s of high resolution, high quality, color orthophoto maps to use together as virtual or real mosaics of large areas.
DVDs for the distribution of large geodata sets and soon even larger 25 to 50 GB HD DVDs.
New formats, such as GeoTIFF, JP2, shapefiles, Oracle Spatial, and new compression concepts, such as JPEG2000.
Graphics boards from the game world that permit real time simulations.
A rich suite of geodata layers in different projections to overlay in a composite view.
Typical single geodata layers have jumped from the megabyte range to the gigabyte and even the terabyte range. 6 years ago most of us did not even know what a terabyte was!
A constant demand for increasingly interactive systems but with more features that are easier to use.
Popular web application and distribution of geodata that result in new demands, such as a universally accepted means of identifying Coordinate Reference Systems.
And a general public that can now use geodata via Google Earth and soon other similar products.

I claim that TNTmips 2005:71 meets these challenges and thus has at least twice the functionality of 1999:61 all of which are available for a user of that earlier version at less than 1/2 of the original cost. The mips (Map and Image Processing) portion of TNTmips was originally chosen because of its association with “millions of instructions per second,” which seemed like a lot at the time. Would any of us be satisfied with that now—today we require a TNT-tera. Remember that TNT stands for “The New Thing.” Cumulatively, this TNT release brings you all of the above, even the first steps toward preparing geodata for use in products like Google Earth.

Everyone can now “Google the Earth”—the public is finally becoming geoaware!

At the moment, Google Earth’s content covers a few nations. Is there any question in your mind that its content will spread everywhere—to your nation or into your community? Governmental policy can not stop this kind of concept; it can only delay it by trying to control access (lost that one already) or content. Preparing its content or content for use with this and similar products is where your opportunities lie. It may be in preparing geodata for a Google Earth primary server (they license it), collecting and setting up pin map advertising content, or using TNTserver via a Vertical Private Network (VPN) to overlay confidential geodata into this user-familiar geobrowser. It’s going to take a lot of you to support this pending boom using a lot of geospatial analysis and geodata management products like the TNT products that are current and “sharpened to the finest cutting edge.”

Dispelling Popular Myths.

The 64-bit Processor Hype.

It’s easy to get caught up in the constant marketing hype that keeps this global data processing industry going. At the moment a major hyping effort is focused upon 64-bit processors and the release of operating systems to run them. Microsoft and Intel have 100s of millions of advertising dollars to hype us. It’s all about persuading us that we need to throw away our current computers and buy new ones.

I was enamored with the idea of “going faster and better” at 64 instead of 32 when the 64-bit G5 PowerMac was released. However, reality has set in here and elsewhere. Let me put it this way—have you seen a single article claiming that a commercial product built for both for 32- and 64-bit Macs, Windows/Intel, or Linux/AMD computer is any faster at 64 bits. Most of the articles I have read recently, some of which are quoted below, categorically point out that using a desktop based on a 64-bit processor is not going to be significantly faster than a 32-bit, all other things being equal. It appears that we are going to get our future improvements in raw performance from software written to take advantage of multi-core, multi-processor computers.

More Memory.

The current combination of 64-bit processors, compilers, and applications can provide one widely touted advantage. This is the potential of addressing more real memory, generally more than 2 GB of memory for a desktop machine. More memory means that you can run more concurrent applications at “full speed” as they each will have enough real memory available. There are also applications designed around operating on data that is in real memory. Photoshop is an example. It wants to keep the data in real memory and slows down for larger jobs requiring the use of virtual memory. Using Photoshop with more and more memory means larger jobs can be completed faster.

But, look carefully at that 64-bit desktop computer you are considering for Windows x64. If you can not eventually add a lot more memory to it, then the single most current advantage of a 64-bit processor and operating system will never be available. Alas few low cost 64-bit computers support more than 2 GB, which is the same upper limit for 32-bit motherboards. A quick look at the 64-bit based computers at a site like www.tigerdirect.com shows that a maximum of 2, 3, or 4 GB of memory is common. Even then it’s not even clear if the support chips on those motherboards will permit a single process to use more than 2 GB. Then there is the really high cost of memory since it is no longer treated as a commodity—every piece has its “notch” in a different place to make it special and expensive.

“I am not sure what rock I've been hiding under, but I didn't realize that the system RAM business was somewhat out of control. A few years ago when you wanted memory, you’d just get any old PC100 SIMM and away you’d go. This became PC133, then PC150, and now there are dozens and dozens of options. The notches are moving all over depending on the motherboard. There is no one memory that you can be sure will work everywhere.” John C. Dvorak, PC Magazine, Inside Track. v24n17, September 14, 2005.

Mac OS X currently takes advantage of 4 GB of real memory for each of its processors. As a result the dual processor G5-based PowerMacs are limited to 8 GB of expensive memory. This is just further evidence that even the best of the current 64-bit computers do not provide access to the large memory banks that are possible; things just get too hot and too expensive. And, after all, next year they are going to want to sell us a new and better model.

What is the impact on TNTmips?

The principal advantage of 64-bit processors at this time is that they can provide access to somewhat larger amounts of real memory for those who can afford it. However, the TNT products have been designed for desktop computer use starting 20 years ago. Almost all the TNT processes can operate efficiently in a small, real-memory footprint. Generally we get good comments about the speed of our analyses and displays compared to the competition when things are working properly. When they are not, we devote considerable attention to how to speed things up without simply using up real memory.

Compressing images into JPEG2000 is one area where real memory is currently required in proportion to the size of the raster being compressed. However, as discussed later in this MEMO, I have been able to compress a single raster object of 732 GB to a 200:1 JPEG2000 raster object and never used more than about 1.2 GB of real memory.

At the moment, the watershed process also uses too much memory. It was designed to handle an input DEM of say 10,000 by 10,000 cells. Now you are asking it to do 100,000 by 100,000 cells using things like an SRTM-derived DEM of a nation. This quickly runs it out of real and virtual memory. The process holds things in memory that it does not need to and this is will be rectified. However, even when this is altered, this kind of complex model will take considerable time to run since it is very computationally intense. Will it run faster with a 64-bit processor? Doubtful, but that remains to be seen and will be tested and reported to you as a good example of comparing a computationally intense process in a 32-bit and 64-bit version of TNTmips.

Should I buy a computer using a 64-bit processor?

Why not, it can not hurt to be prepared and you can always run its 32-bit operating system while you check things out. It is well established that the Intel, AMD, and PowerPC processors designed to run at both bit levels reliably run 32-bit applications under a 32-bit operating system at the moment and run them just as fast as if they were compiled for 64-bit operation.

Law-of-the-Minimum.

You have already become acquainted with this well know desktop computing law at some point in the past. You upgrade your operating system and find that some expensive peripheral of some years back will no longer work, “sorry no driver.” The computer software and hardware industry does not suddenly decide altogether, today is the day we all switch to 64-bit operations. So let’s start with my list of woes.

Microsoft Windows x64.

Microsoft released a Windows x64 but still has the 64-bit version of Visual Studio available only as beta. Why? Because they know, but are not saying, that the 32-bit version of Office works in Windows x64 and has no advantages if re-released at 64-bit. It is likely that working out the issues between their own Office and other products and the beta compiler is probably the source of the delay. Another possibility is the pending release of Windows Vista, which is also 64-bit and will require a complier. So Visual Studio 2005 may never be more than beta until replaced by whatever comes with Windows Vista and covers x64 as well. Anyway, does it make sense for MicroImages to release TNTmips for Windows x64 using this beta compiler? Perhaps, but don’t you have enough problems originating in TNTmips without adding those introduced by basing it on a beta compiler?

Running Windows x64 for Intel processors at this time is likely to be more risky as you will find from the articles abstracted below. Anyone ordering a Dell with Windows x64 today gets a caution: “Note: prior to purchasing a Dell Precision Workstation with a 64-bit operating system, verify compatibility with all current peripheral and application vendors.” There is a much greater variety of software and hardware available for Windows XP and 2003 than for the Mac. Furthermore Mac developers have been making the adjustment from 32-bit to 32- and 64-bit processors for the past two years. Windows vendors are looking 6 to 9 months in the future at a completely new Windows Vista operating system that is already being widely distributed in beta form. I’d put my money on many of them focusing on that much larger and more lucrative Vista upgrade agenda and new product market. Maybe they will do Windows x64 versions now, but many may simply wait and release for Windows x64 as a subset of their Vista product releases a year from now.

Apple Mac G5.

No 64-bit driver is available for the USB software authorization key for the Mac OS X. As a result we can’t release a true 64-bit version built only with 64-bit library for this platform. A 64-bit TNTlite could be released, as it has no key requirement, but to what purpose? Our serial key does not require a driver, but I have not seen a serial connector on a Mac in years. Macrovision is a major company whose FLEXlm product is used to manage most floating license products including ours. But they also do not provide a license manager for use in Mac OS X booted up at 64-bits. They look at the market and conclude, hmmm, the 32-bit version of Photoshop, Illustrator, Oracle, and all those other Mac applications, which have only a few percent of the market, run just as fast at 32 bits as they would at 64 bits so what’s the hurry? They also know that a single 32-bit based Mac OS X or a Windows computer on a network could serve up licenses to all the other Macs running the 64-bit version of Mac OS X.

Mac OS X 10.4.x can be booted up as 32-bit or 64-bit from the same drive, but it’s more convenient to use 2 drives. Install your 32-bit Mac OS X on 1 drive and the 64-bit version on another. Then reboot and install TNTmips under both versions. The new Installer VISE program for the Mac will automatically detect these different OS versions and install the correct version of TNTmips. The drive format is the same for both versions of your Mac OS, so however you boot up, you can access and use both drives for data. Using this approach all your 32-bit legacy equipment and applications can be reliably used by a reboot and the results shared via the common hard drive format. Gradually, however, to force the issue Apple’s own software is going to deliberately lack functionality when run under 32-bit until eventually it will not get any further upgrades, so you will need to continue to back-boot to use their applications. Ultimately, you have to give up. I have now discarded all MicroImages and personal devices that would only run under Classic Mac 9.x since they have little support from their original vendors.

Linux/AMD.

Linux users are oriented toward solving or finding someone to solve the problems that occur in an open approach. A switch to a 64-bit Linux is simply another incremental step in the gradual, constant evolution of a Linux based installation. As a result every Linux installation is unique, which makes every Linux installation of TNTmips unique. However, with patience they all eventually get going.

We have recently posted a 64-bit version of the TNT products for various flavors of Linux using 64-bit AMD chips. If anyone using it can show it’s faster than the 32-bit version. I’ll be happy to eat crow. Linux already tastes like crow to me anyway.

Sun Solaris/Sparc.

Sun users are running a few dedicated applications so if the key application, such as Oracle, a web server, or TNTmips, has already been checked out at 64-bit, then a switch to 64-bit Solaris is in order. Solaris 64-bit has been around for quite some time and can reliably run most 32-bit applications. Furthermore, a much smaller selection of dedicated, targeted hardware is available for use with Solaris/Sparc based workstations. As a result, any hardware deprecation that would result from a switch to Solaris 64-bit operation is well known.

The 64-bit current version of Solaris/Sparc is the only operating system installed on new Sparc workstations. A TNTmips purchased for use with Solaris/Sparc is supplied with a serial software authorization key and no software driver are required. Since you may be running a 32-bit version of Solaris on an older Solaris/Sparc workstation, both 32-bit and 64-bit versions of the TNT products are supplied. Either can be run with the 64-bit version of Solaris/Sparc with the serial key.

Should I move to Windows x64?

This is a different matter than simply buying a system with a 64-bit AMD or Intel processor and running your 32-bit operating system and software on it. It should be approached with caution. Personally I would wait to take this headache on just once next year with a switch to Windows Vista as soon as it is available. If you make the switch now, you will simply have to turn around and go through it all again next year.

Listen to what others are saying on this matter. The following are paragraphs excerpted from articles on this topic in the popular technical magazines in the past 6 months. Note carefully that the most recent, thorough, and critical article on Windows x64 appeared in PC Magazine just 3 months ago.

In InfoWorld.

64-Bit Traffic Jam. As vendors play down their own 64-bit technologies and wait for Microsoft, Linux and OS X roll along. Tom Yager. InfoWorld. February 14, 2005. Page 54. Read at infoworld.com (... link obsolete ...)

“Do we need 64 bits to run 32-bit operating systems and applications? Let’s put it this way: Many commercial developers are prioritizing 64-bit ports of their Windows and Mac OS X applications just below vacuuming out their power supplies.” …

“… But go to the page that Apple dedicates to the machine and look for the phrase “64-bit”. I found it exactly once: It’s ‘ready to run modern 64-bit applications.’ Ready? Modern? They’re both waffle words.” …

“Hope you like waffles. AMD, Apple, Intel, Red Hat, and Suse have all proclaimed 64 bits or bust. But when it comes to giving you bona fide reasons to buy the advanced technology they’re selling at PC prices, the person equipped to answer that question just stepped out of the office. What could possess vendors to bury the benefits of the biggest leap in technology in many years?”…

What possesses them is their knowledge of the law-of-the-minimum. They know that either their 64-bit bit software offerings are incomplete (for example, a Microsoft compiler, the Apple libraries at that time, Intel support chips to get at more memory, …). They also know of the incompatibilities with external devices that would prevent the assembly of a complete system.

“Vendors are relying purely on the allure of the number 64 not because Microsoft hasn’t yet legitimized 64-bit computing. Hewlett-Packard, IBM, and Sun RISC systems took care of that, while AMD and Apple added value and usability.”

Windows Done Right. Windows 2003 Server x64 Editions running on AMD Opteron will be the darlings of the datacenter. Tom Yager. InfoWorld. April 11, 2005. Page 58. Read at infoworld.com (...link obsolete...)

“Microsoft’s 64-bit pitch to date, adapted from Intel’s, has been utterly uninspiring: Big databases will go faster because they’ll have access to more memory. That draws a big shrug even from me. So let’s flesh out what they’re trying to tell us. Few IT shops are fretting over memory-bound database apps. Besides, it’s already possible to stuff 16GB of RAM into a 32-bit PC server, right? Wrong. You never actually have more than 4GB of directly usable RAM in a Xeon server.”

The article then continues on with some interesting information on the memory management tricks of Windows.

“Windows x64 is designed for Opteron. I’ll back that up with facts, but I won’t rush it. Nobody’s going to run out to buy 64-bit hardware the second they get their hands on Windows x64 CDs.”

The AMD Opteron and Athlon 64 are the same chip from the TNT products viewpoint and the same build of the TNT products works without any alteration for both under Windows x64. The Opteron is used for dual and greater processor setups.

In eWeek.

Microsoft focuses on x64, security. Tech Analysis: Windows Server 2003 SP1 creates a powerful first impression. by Francis Chu. eWeek. March 21, 2005. Page 50. Read at www.eweek.com/article2/0,1895,1777525,00.asp

“Although migrating to the x64 architecture will require both software and hardware platform upgrades, IT managers can expect significant performance gains when upgrading applications to run on x64 (see related story, next page). They also will likely see more pep in their existing 32-bit applications because of the 64-bit kernel’s much larger address space.”

64-bit Computing: What’s in it for you? Tech Analysis: eSeminar polls show gradual adoption for media, database tasks. by Peter Coffee. eWeek. Ziff-Davis Media. March 21, 2005. P. 51. Read at www.eweek.com/article2/0,1895,1777050,00.asp

“Windows users at the seminar learned of Microsoft Corp.’s March 3 promise of a 64-bit Windows as early as next month, exploiting the improved security of 64-bit PCs.” …

“Those expectations of benefits were almost evenly distributed among 32-bit performance improvements, 32-bit multisession capabilities, native 64-bit capacity for enterprise applications and native 64-bit capability for multimedia tasks. The lead application expected to demand 64-bit resources was image and video editing, closely followed by data mining and visualization.”

The text of this article can also be read under the title Customers Doubt Immediate Benefit of 64-bit at thechannelinsider.com (...link obsolete...)

Not sold on Cell, yet. Opinion: The next generation cell processor needs a realistic road map. eWeek. 7 March, 2005. Page 36. Read at www.eweek.com/article2/0,1895, 1771163,00.asp

“If IT managers have learned anything from the Merced/Itanium debacle, it is that they cannot plan for the next generation until promises turn into products. Too often, ‘the next big thing’ is superseded by improved old technology that is backward compatible. This is what happened with AMD’s Opteron processor, which proved that 64-bit technology can support the 32-bit world, something the 64 bit-Itanium could not do.”

“Just as the leap from 32-bit processing to 64 bits has been hard to digest, the Cell architecture will challenge developers. Cell processors will not rule the desktop market in the near future, but the architecture could be used in distributed computing environments.”

PC Magazine.

PC Magazine contains the most recent review of the status of 64-bit computing and it is a must read for anyone contemplating the use of Windows x64. This article has very thorough coverage of this topic and paints a pretty bleak current picture. This magazine has always been willing to try to present accurate information regardless of how its advertisers might react to it. Only a few highlights are reproduced here and anyone considering using Windows x64 should read the entire paper.

Reading this entire article is a important if you are thinking of using Windows x64 now.

Another Step Closer to 64-bit Computing. by Neil J. Rubenking and Rich Fisco. June 7, 2005. PC Magazine. pp. 34-36. This article was abstracted from a longer review entitled Windows XP Professional x64 Edition by these same authors, which you can read at www.pcmag.com/article2/0,1759,1788843,00.asp.

“Still, for forward-looking early adopters, we put x64 through its paces to see what you can expect. The good news: Most 32-bit applications work fine under x64 and may get a small performance boost. The bad news: Some programs, particularly low-level system utilities and drivers just aren’t compatible.” …

“When Windows XP was first released, Microsoft created an Upgrade Advisor that would scan a computer and generate a report of any hardware or software problems to be fixed before the upgrade. Microsoft has no plans to create a similar scanner for x64; the company will, however, catalog drivers and applications that have passed x64-specific logo testing.” …

“Lacking 64-bit programs to test, we exercised x64 by installing a variety of 32-bit utilities and applications. We tried three personal firewalls and got three strikes: …”

The 3 that each struck out and failed were Zone Alarm, Kerio Personal Firewall, and Sygate Personal Firewall.

“x64 ships with a 64-bit version of Internet Explorer, but the default desktop and Start menu shortcuts launch the standard 32-bit version. And with good reason: All your favorite add-ins install only in the 32-bit version. IE 64-bit can’t handle Flash or Java, won’t accept toolbars, and it manages PDFs only by launching them in an independent Acrobat Reader window. For now, there’s not much point in running 64-bit IE.” …

“You might think that raw performance distinguishes x64 from regular Win XP, but you’d be wrong, at least for now. The biggest deal related to performance is x64’s ability to handle more memory than the current XP. Initially x64 will support up to 128GB of RAM; XP supports up to 4GB of RAM. But even this won’t translate into a performance gain unless you have a large data set (such as a huge video file or a big database).” …

“We tested performance using a Dell XPS with 3.73-GHz Pentium 4 EE CPU. … the stalwart SYSmark 2004 could not run under x64. … When all was said and done, we saw mostly minor differences between the 32- and 64-bit operating systems. Most results were close, and in many instances it’s hard to tell if the differences were due to the OS or to not yet fully optimized 64-bit drivers.” …

“Without a doubt, 64-bit computing is the wave of the future, but the future isn’t here yet. While 64-bit hardware is becoming increasingly common, the 64-bit applications just haven’t arrived. You should expect x64 to be embraced by workstation and server users, where applications using large data sets can take advantage of the memory it can address. Eventually, all applications will move over to 64-bit, but this will take years. Even those applications that may gain nothing from a 64-bit environment will move to it simply so we can have just the 64-bit version of Windows.”

Luddites versus Early Adopters.

Luddite: One who is opposed to technological change—from a group of 19th century English workmen who destroyed laborsaving weaving machinery in a revolt.

This is not the first time around.

I was here for the switch from zip to 8-bit, 8- to 16-bit, 16- to 32-bit, and now here we are at the next plateau. I distinctly remember multiple Luddite articles just before the switch to 32-bit started with the introduction of the 32-bit Intel 386 processor. The general theme was “why do we need all that computing power and memory?” Once the switch to 32-bit got past the law-of-the-minimum, we quickly found a way to use it and justify it. To name just one activity would be the mutitasking now used all the time by everyone. Certainly that will eventually be how we look back on this transition to 64-bit, painful but eventually worth it. When can we forget the pain and look back with this attitude is really the question. I am guessing that a year from now with Microsoft Vista available, as a pioneer, I may be changing my position on this matter. As a long time Microsoft stockholder, I may find that a bit less painful.

What is your goal in this?

At this point this switch cycle is just starting and it is well to recall the long time computer user adage that “pioneers get arrows in their backs” and that is painful. The real question here is “do I want to get my geospatial analysis done or do I want to become a pioneer and fight with a situation that I do not have much control over?” If getting the analysis work done is the goal, then spend your current money to get 2 good monitors, more memory, and/or more storage. The monitors and the storage will be usable on your next computer. However, if you have an old computer and need to upgrade it, then why not get one with a 64-bit processor and run a 32-bit operating system on it for now.

Everything good in its own time.

MicroImages TNT software was designed many years ago for easy and quick porting across operating systems and processors. I suppose we have done this at least 50 times. 12 years ago we released a fully 64-bit version of the TNT products for the now defunct Dec Alpha 64-bit processor and its OSF/1 Unix. Then came a series of 64-bit Unix versions including the current 64-bit version for Solaris/Sparc. More recently we have supported the Apple’s pseudo 64-bit Mac OS X, Linux and Windows on the 64-bit AMD Opteron and Athlon 64 processors, and an unreleased prototype for Windows x64 for Intel processors. We know how to do these things when their time comes. However, we are not able to release them until all our other components are in place: software key support, floating license support, installation programs, licensed libraries, and so on. Furthermore, we are not clairvoyant. Thus we will not release versions until the marketplace clearly identifies that the operating system and the processor are going to be widely adopted. Otherwise we would be forced to tell you a year or 2 later that we can not maintain our product for that system as we had to do with the Dec Alpha. Lack to date of popular use is why we have not released TNTmips for the Itanium processor.

In the meantime you’re covered.

Those of you who have been using the TNT products for a few years know that when we support a new operating system and processor combination that if your license is current, it automatically becomes a free option for you. The USB key is your license and permits you to run any TNT product by downloading and installing a copy of the software on any computer/operating system/processor that we currently support. So as you choose to use your Apple Mac under a 32- and/or a 64-bit boot, use your Windows 32-bit 2000, XP, and 2003 and eventually, when we can compile it, a Windows x64 and a Vista as soon as your other software and equipment will allow. If you have a floating license, you can even float around to any of these installations. So for the moment, simply run the 32-bit version of your TNT products on Windows x64 if you choose and if you can get at your other equipment and network. If you have a problem, you can always reboot into 32-bit Windows from a second drive, move your key, or float your TNT license to another computer. Trust MicroImages, we are going to have you covered every way we can now and into the future.

TNT Explorer.

Introduction.

Making the TNT products look and feel like Windows and still continue to make it available and run efficiently on other platforms, such as the Mac, has been a 15 year challenge. This has had 3 major problem areas: the difference between X windows and Microsoft Windows, easy communication with other Windows software, and the unfamiliar concept of the Project File as a container. With the introduction of TNT Explorer in this version, only the ease of communication remains.

1) Windows as Windows.

Years ago we had complaints about the X window approach used to run the TNT products under Windows. Of course, without it there would be no TNT products for the Mac, Linux, and Solaris since these are small markets. As soon as we figured out that each X window could effectively become a Windows window, these objections pretty much went away. It finally turned out to be easy to do because Windows and our X server had matured to a point to permit it. Prior to that time I kept trying to justify the use of the X server on Windows and Macs based on other, then unique features it supported, such as remote operation over a LAN, using a virtual large window larger than your screen, and others. Today, not many of you are running your TNT product in the large X window mode due to your multitasking and dual screens. In fact, in TNT 2005:71 we have removed the startup window asking which way you want to run, which means, in X windows as pseudo-Windows or in one big X window. You have to go to the MicroImages X Server Preferences setup dialog to choose the option to run using the big X window approach.

2) Communicating with Other Windows Programs.

TNT products do not easily connect with other software running on the Windows platforms since TNT is still not a native Windows application. This is in the connections to other programs using Active this, OLE that, .net now, cut and paste, and so on. The solution to this is not obvious to us as it is not generic—that is, change one code area and have it. At the moment it seems better to improve our direct connections to needed major components such as our direct OO4O (Oracle Objects for OLE) connections to Oracle Spatial. Connections to other relational databases via ODBC are usable but slow. As these databases become “spatially enabled,” better communication with them is important. At this moment we are working on making direct connections to Excel, Access, and SQL Server using Microsoft’s own OLEDB (OLE for DataBases). We can then move on to direct connections to MySQL and PostGIS open source databases, which would not be likely to happen if we concentrated on only generic Windows OLE or .net concepts.

3) Project Files as Directories for Objects.

Now TNT Explorer hides away the Project File structure at least during the learning cycle and wipes away most of this objection to the TNT look and feel. Previously a new user of any TNT product would find it hard to get started because this aspect of the TNT products was not parallel to using Windows folders and files to get at data. Now, by the time they figure out the differences between TNT Explorer and Windows Explorer, they will already have a grasp of the Project File structure and its parallels to Windows directories. They will be more willing to move on into the more complex procedures for dealing with geodata objects. Move on with an understanding that not everything can be done with a click, click-click, drag and drop, and other simple actions since geodata is simply too varied and too complex. However, even if you are thoroughly conversant with the complex TNT object selection dialogs, there are times when you are also going to find it convenient to use TNT Explorer.

How did it come about?

Our original idea for TNT Explorer came from noticing how the contents of a ZIP file could be viewed as a directory. Since ZipMagic was doing it, further investigation led us to find that they were using the “shell name space” extension enabled by Windows Explorer. During the process of creating the 2005:71, we were eventually in contact with a Microsoft MVP (Most Valuable Professional) who had access to their source code in this area and has been of considerable help.

At this point it appears that not many strategies of this Explorer type have been implemented. First of all it requires starting with a hierarchical container-like structure such as a directory, a zipped file, or a TNT Project File. Products that assemble a variety of components into a single layout such as PDF, SVG, and GML use a container-like approach. However, they are designed to be cross platform, which Windows Explorer does not support, and do not necessarily treat their contents as discrete objects except perhaps for rasters and fonts.

I believe you will find that this is a very interesting development in the TNT products. Even though we can only provide this capability for Windows XP, 2003, and future versions of Windows, it is in and of itself a justification to upgrade now to XP. It is one of those things whose time has come. It did not take a great deal of software development, just someone here who knew what they were doing. Microsoft also made it easy for themselves and, thus, for us. The greatest residual problem is fighting with other installed software over who owns each extension. No problem at all with *.rvc and *.jp2, but lots of contention over *.jpg, *.dwg, and *.dxf with *.shp, *.sid, *.img, and others someplace in the middle. The Project File and its linked objects together with TNT Explorer allow you to put an umbrella or mini-catalog over all your spatial data files in other formats and use them as geodata, but keeping ahold of their extensions is a challenge.

Mac Is Orphaned.

We have had no success in locating anything equivalent to Windows Explorer in the Mac OS X. Searching to date has only turned up the reverse of Windows Explorer called a Bundle (combining files together for installation and other purposes). As Apple Developers we have sent email directly to Apple on this topic and to various Mac developer lists. No responses have been provided, we are simply ignored—it’s almost like they do not know anything about Windows Explorer. The best place to start would be to identify that someone has used a capability similar to this in some Mac software.

Please bring to our attention any Mac OS X software that presents a complex data file as a folder and permits manipulation of its contents as discrete files

Introducing Advanced Techniques.

Recent MEMOs have provided longer discussions of the advanced image, GIS, and database features being introduced into TNT products. The focus of these new geospatial analysis developments in the TNT products is on the nature and use of new concepts and not on faster procedures, interface features, formats, and so on (which means they focus on analysis not on the gimmicks). MicroImages’ web site is now also featuring these topics more prominently. Those visiting the site will realize that some activities in the TNT product development are “state-of-the-art.” They are connecting the research of other scientists in these areas into new, practical developments in geospatial analysis.

Examples of these more detailed discussions have already occurred in earlier TNT Release MEMOs on topics such as mipmapping for 3D image smoothing (2003:68 MEMO), using Oracle Spatial (2003:68 MEMO), using standard ISO Coordinate Reference Systems (2004:70 MEMO), and minimizing conflation issues (2004:70 MEMO).

This MEMO and its color plates go into detail in summarizing the Open Geospatial Consortium (OGC) standards and how they are and will be incorporated into this major update of TNTserver and associated client applications. From this you can get an idea of how OGC standard geospatial web services work and may evolve to support new public and proprietary geoaccess and visualization tools, such as Goggle Earth. The procedures to create and compress terabyte-sized mosaics are also outlined in detail. The most complex new topics introduced via this TNT release are the tools for converting multispectral imagery into maps of reflectance and analyzing these to extract more accurate maps of useful biophysical properties. This is movement toward a more quantitative analysis of imagery as contrasted to other already available qualitative methods such as NDVI or simply “classifying” surface features.

How do these ideas originate, grow into implementations, and get presented here? Few of them come from working with our competitors’ products, which we generally do not own and pay little attention to except in a general sense by looking at their list of features. Frankly, MicroImages prefers to be a leader in this business rather than a follower. From experience we know that you will soon point out to us where some new idea has surfaced in a competing product. Other ideas come from you when you bring a paper or some other research or development to our attention. You provide or point us to the reference materials involved, and we review them for their pertinence and the practicality of including them in a commercial product.

MicroImages also subscribes to literally 100s of technical and general industry publications that point out developments that can be used or researched via the Internet. From these we identify the pertinent technical papers of possible future interest and duplicate them for our library files. You can now peruse the titles and authors of the approximately 1900 papers in this file by searching it at www.microimages.com/advanced/ using your browser. Sorry, there is no subject index and we can not provide copies of these papers since most are copyrighted.

So how do these other technical materials and ideas get used? Often it starts with a key paper that clearly points to a better way, a more accurate result, or a new capability entirely. We then use our paper library and the web to gather related materials. Next the requirement gets in line for a priority with all the requests for new gimmicks, format, and feature tweaks.

For example, recent TNT releases have focused on improved 3D Display, TNTsim3D processes, computing watershed physiography, and other procedures that need a good DEM as input. This release adds the capability to use a DEM to correct multispectral Aster, Landsat, QuickBird, and Ikonos imagery for terrain induced radiance effects. These past efforts obviously raise the priority for improved TNTmips procedures to help you secure more accurate DEMs at various scales. The geospatial script provided with this release to fill holes in SRTM elevation rasters is one such step in this direction. It provides the basis for obtaining DEMs of national scale areas. However, just today I received the following paper that may provide the basis for further improvement in this script. On Merging High- and Low-Resolution DEMs From TOPSAR and SRTM Using a Prediction–Error Filter. 2005. Sang-Ho Yun, Jun Ji Zebker, and Paul Segall. IEEE Transactions on Geoscience and Remote Sensing, Vol. 43, No. 7, July 2005. Pages 1682–1690. On the other end of the elevation scale, you also need improved methods for obtaining accurate local DEMs for applications such as watershed analysis and the new multispectral image terrain correction. To this end, some time ago you requested a better conversion from digitized contours in a vector object to a DEM that produced a smoother result (less plateauing between contours). Your request was accompanied by a paper that you suggested as a possible method. A New Morphological Algorithm for Automated Interpolation of Height Grids from Contour Images. 1990. Sidney M. Peterson, William A. Barrett, Robert P. Burton. SPIE. Stereoscopic Displays and Applications. Vol. 1256. pp. 62–72. That paper led to other web references such as Semantically Correct 2.5D GIS Data – the Integration of a DTM and Topographic Vector Data. Andreas Koch and Christian Heipke. 13 pages and no date or source but available at ipi.uni-hannover.de (... link obsolete...) As a result of this need and these and other reference materials, improvement in this area is now a high priority.

Another area of recent requests is to use the Z values of a dense collection of ground control points to compute what would be equivalent to the rational polynomial coefficients (RPC) for an image. In this application you have a single image that does not have any RPC coefficients, but you have or can collect many accurate ground control points (GCPs) in the image and have a good DEM. The approach would be to compute the RPC coefficients for the image from the GCPs and then use them with the DEM to produce better orthoimages than simply using affine or conformal warping, which does not take terrain relief into consideration. The paper you provided on this topic is Incorporation of Relief in Polynomial-Based Geometric Corrections by Vicenc Pala and Xavier Pons. July 1995. Photogrammetric Engineering and Remote Sensing. Vol. 61, No. 7, July 1995, pp. 935-944.

Regarding this RPC topic, MicroImages has found from experience that collecting accurate GPS coordinates of distinct ground features can be accomplished with the right equipment and collections of these GCPs can be built up for reuse with each new image and the DEM of that area. However, even with 1-meter satellite imagery, I found it difficult in La Jolla (near San Diego) to locate these features in an individual 1-meter image cell or between cells. Thus, to date it has not been clear how to insure that the mathematics in this proposed RPC solution can be insured to converge since the location of the GCPs in the image can have multicell errors. However, as image resolution is increased to a foot or a few decimeters, identifying these distinct points in the image becomes easier and more in line with the accuracy of the GCPs. With these kinds of corresponding satellite or aerial image and accurate GCPs, deriving the RPC model from the image may now be a viable approach.

All this is a preamble to the advanced procedures available in 2005:71 for calibrating and analyzing multispectral satellite imagery. These have been implemented in the TNT geospatial scripting language (SML) as they are experimental at the moment, have complex input, and can be modified into even more advanced methods by you as appropriate. Using scripts is just one option for advanced features. DV2005:72 already has a new advanced image fusion method, which was provided via a client in the form of a process they have implemented in a competing product’s scripting language. Its approach does not appear to relate to any existing fusion method and produces excellent results. This advanced capability was recoded by MicroImages in a TNT procedure. It uses a new pipeline coding procedure implemented in 2005:72, which will be extended into SML to make scripts easier to create.

More 3D applications, such as 3D Display, lead to need for better DEMs via SRTM and digitized maps, which lead to a need for improvements in analysis methods, such as the watershed process and so on. So, keep sending descriptive technical papers, scripts, and/or source code along with your requests for advanced analysis features in TNT or via SML scripts. We do not ignore any input. Eventually your good ideas often get used in some manner. But, as you can see from the above, we are constantly trading off priorities, thus the timing in the use of our resources.

Changes to TNT Licenses

Immediate Access to DV2005:72.

Everyone who is using version 2005:71 of a TNT product can now download the Development Version 2005:72 for that TNT product. This will permit you to use new features as they are added and to participate in the development and perfecting of this next release. You can obtain access to DV2005:72 now by simply downloading it from www.microimages.com. Installing it will automatically create a completely separate TNT DV product set on your hard drive.

Your access to DV2005:72 will be temporary. When you download and install DV2005:72, it will be a timed license that will automatically expire in 30 days and this is controlled by your key. However, if you subsequently download a patch or new version of DV2005:72, this timeout will be automatically reset again to 30 days.

On the day of the official release of 2005:72, MicroImages will remove all access to DV2005:72, and its patches. Thus, all temporary use of DV2005:72 will expire for everyone in 30 days or less after its official release. Of course, if you have already purchased 2005:72, you can simply download it on the day of its official release or later to permanently replace DV2005:72.

New Multi-Core Licensing.

Intel is just announcing a new processor line that will have dual cores but will also be designed for future expansion to 4 or perhaps more cores. AMD already has dual cores and can be expected to have more. Sony’s PlayStation 2 has 9 cells, or cores. As you already know, dual cores means that the single chip has 2 processors on it and its operation is approximately the same as the desktop workstations currently used by some of you and MicroImages, such as the Apple PowerMacs.

This is your official notification of how the TNT product licenses have been modified to reflect these current and future developments on your desktop. These changes take nothing away from current users and licenses but are to clarify and set limits on how the TNT products will function with regard to future developments in hyperthread, multicore, and multiprocessor computers.

Definition of Terms.

These definitions are provided to help you understand MicroImages TNT product licenses.

Processor.
One or more computation engines, or cores, which occur on the same single piece of silicon base, packaged in the same shell, and/or occupy a single socket in the workstation.

Core.
A single computation engine, which can be physically identified and traced out on the logic circuits of the processor chip.

Hyperthreading.
The ability of a core running multithread-enabled application software to execute 2 or more threads in parallel.

Virtual Processors.
Counting each hyperthread on each core in a workstation yields a count of the virtual processors available on that workstation.

Fixed Licenses.

A fixed TNTmips license is authorized by the directly attached MicroImages software authorization key, and only by this key, to run one copy or instance of TNTmips on a workstation with 1 or 2 cores, each separately supporting hyperthreading. Within this single operating copy or instance of the TNT product, as many TNT internal application processes as it authorizes and you desire (for example, 2D views, 3D views, I/E, mosaics, edits, …) can be run to take advantage of the availability of 2 real cores and hyperthreading (for example, 4 virtual cores) on this one workstation.

Floating Licenses.

A TNTmips seat obtained for a single workstation from a floating license server via FLEXlm is authorized to run on a single workstation equipped with up to and including 2 cores, each supporting hyperthreading. Within this single operating copy or instance of TNTmips, as many TNT internal application processes as it authorizes and you desire (for example, views, mosaics, editing, …) can be run to take advantage of the availability of 2 cores and the hyperthreading on this one workstation.

Summary.

If you attempt to operate any TNT product on a computer with more than 2 cores, it will not start. MicroImages will indicate how you will be able to upgrade your licenses to use more than 2 cores when and if these computers are available to you.

Windows 98, ME, and NT

Please anticipate that the next release of the TNT products 2005:72 will no longer support W98, WME, or NT. Continued support of these old operating systems is counter productive because it restricts developments in the TNT products to the detriment of the large majority of our clients using a modern version of Windows.

Mac OS X

Versions Supported.

This release of the TNT products supports their use under Mac OS X 10.3.9 or the latest version of 10.4.x on G3, G4, and G5 single or dual processor systems. Future versions of the TNT products will be available for purchase for the Intel based Mac OS X and as part of your routine maintenance upgrade. The Intel versions will be available for purchase or in your upgrade after Apple officially ships a Mac OS X based hardware product using the Intel processor.

Complete 64-bit Support.

The TNT products have and continue to operate under Mac OS X running in 32-bits or 64-bits. However, while a completely 64-bit version of the TNT products has been experimentally built, it can not be distributed as of yet. The limiting condition is that a 64-bit driver has not yet been made available for the USB software authorization keys. As soon as this component is available, MicroImages can release versions of the TNT products using 64-bit libraries for Mac OS X.

MrSID Support.

Any raster object can now be exported to a MrSID (*.sid) file with various levels of compression and other options. Since MrSID is a proprietary compression scheme you must purchase a license (a compression metering cartridge) from LizardTech to use this feature in TNTmips. More details on this new feature are included in the major Import / Export section in this MEMO.

TNTmips and TNTedit are the only commercial software for Mac OS X that can compress a large variety of rasters into MrSID files.

Installation.

The TNT products and the patches you download are now installed by a commercial product called Installer VISE, which is licensed to MicroImages by MindVision Software. This Installer VISE operates like the Apple installer used for Apple software products but provides more flexibility in installing all the features needed for the operation of the TNT products, such as the separate X11 program. Installer VISE is used by many other commercial software products available for the Mac OS X, and so you are probably already familiar with its use, which is simple and intuitive. MindVision Software is another Mac OS X commercial software developer located in Lincoln, Nebraska.

Mac OS X Geology Workstation.

The previous MEMO accompanying the release of TNT 2004:70 described in detail the Mac OS X based workstations designed for geologic interpretation and mapping. Subsequently the attached color plate entitled Mac OS X: Geologic Mapping Station was created to illustrate this workstation and this application.

Stereo Without Glasses.

The Sharp stereo monitor is now supported for Mac OS X in addition to Windows and could be used on the geologic workstation noted above. This 15-inch Sharp monitor is illustrated and discussed in the attached color plate entitled Mac OS X: Mac Stereo Viewing with the Sharp 3D Monitor. Just recently Sharp offered this monitor to developers at a drastically reduced price. This implies that Sharp is clearing out this stock prior to releasing a new model. One could assume that this new monitor will be larger since the stereo effect is achieved at the expense of horizontal resolution when the monitor is used in stereo mode.

Just this week Sharp introduced a new 2nd generation power version of its portable computer using this stereo monitor called the Actius AL3DU model. This portable is detailed at sharpsystems.com (...link obsolete...) and can run the TNT products in stereo or 2D modes. At least 2 European manufacturers are offering larger format, no glasses stereo computer monitors that could be used with TNTmips and TNTsim3D at www.seereal.com and opticalitycorporation.com (...link obsolete...).

New TNT Version Numbering

A new TNT version numbering scheme is now being used with all TNT products. It adds the year of release to the version number to assist you in keeping track of the year and features in your TNT product. This system is more in line with current industry version numbering schemes, for example, AutoCAD 2005, Microsoft Windows 2003, and so on. This release of the TNT products is referred to as 2005:71 replacing V7.10. Thus the Development Version of the next TNT release, which can be downloaded now, is referred to as TNT DV2005:72 and may end up as TNT 2006:72 depending upon the date when it is officially released on microimages.com.

If you are using an older version of a TNT product, these new version numbers will directly indicate the age of the product. For example, TNTmips 6.3 becomes TNT 2000:63 indicating that the software uses the technology of 5 years ago. This will serve as a constant reminder that the last 5 years of developments in the rapidly evolving field of geospatial analysis (features, formats, data sizes, speed, ease of use, …) are not available in your TNT product even though it may be installed on a new computer.

The following is a partial translation table for recent version numbers of the releases of the TNT products. A complete translation table for all 55 older version numbers can be found at www.microimages.com/relnotes/.

V7.00 November 2004 2004:70 V6.90 December 2003 2003:69

V6.80 May 2003 2003:68 V6.70 August 2002 2002:67

V6.60 December 2001 2001:66 V6.50 May 2001 2001:65

V6.40 October 2000 2000:64 V6.30 April 2000 2000:63

V6.20 October 1999 1999:62 V6.10 May 1999 1999:61

V6.00 December 1998 1998:60 V5.90 July 1998 1998:59

… … … …

V1.20 June 1987 1987:12 V1.10 March 1987 1987:11

V1.00 December 1986 1986:10 V0.90 (first release) 1986:09

Hardware News

Dual Monitors.

Need help convincing your boss or accountant that you need dual or triple monitors for use with TNTmips? If so, show them the detailed technical study at the University of Utah: Productivity and Multi-Screen Displays. 2004. Janet Colvin, Nancy Tobler, and James A. Anderson. Rocky Mountain Communication Review, Vol 2, Issue 1, pp. 31–53 and located at utah.edu/rockymountain (...link obsolete...).

Their results have been summarized succinctly by IBM in clear economic terms at www.businessroundtable.org/pdf/ClimateRESOLVE/102804Christie_IBM.pdf as follows.

“Simultaneously viewing multiple applications on multiple monitors can save time and reduce errors. It increased task accuracy (33% fewer errors) and time savings of up to 16% in task completion for users who work with multiple data sources concurrently.”

Microsoft Magnifying Mouse.

Microsoft has just released the Wireless Optical Mouse 5000 (US$50) that provides a built-in pixel level magnifier and has many other useful control features. This mouse has a comfortable form for gripping and two additional small buttons on the left side for easy thumb access. Its wheel supports scrolling up/down and side to side and has a depression switch. Its 5 buttons can be programmed to any of many options, such as start a program, maximize view, minimize, copy, paste, and many more.

Of particular interest is that the scroll wheel button or either button on the left side of the mouse can be programmed to open a magnifier view around the cursor of a minimum of about 380 pixels horizontally by 280 pixels vertically. You can interactively increase the size of this view but, unfortunately it can not be made smaller. The amount of pixel magnification in this window can be set to be whatever you like in multiples of the screen pixels. Moving the mouse moves the magnifier with the cursor at its center. Depressing the same button closes the magnifier. The cursor at the center of the magnifier view can be used just as if the magnifier view is not open.

The use of this device in connection with your TNT products for Windows or Mac Os X has been checked out as follows. Program the small left button, which is harder to reach, to open TNTmips. Program the larger left button, which has easy thumb access, to open and close the magnifier. Then program the thumb wheel button to open your browser as that is also where you will also make the most use of the wheel’s up/down and lateral scrolling to review web pages. When the left thumb button is clicked, you will get a magnified view of any part of your screen, particularly the image in your TNT view window. Setting the zoom of this magnifier to 2, 3, or 4X works well. You will also find this mouse’s additional buttons and wireless functionality even more useful in controlling TNTsim3D features.

This mouse works almost identically in all features with Mac OS X 10.4.x except the magnifier window is equal to the entire screen and can not be made smaller. Moving the mouse moves this zoomed screen view across the original view and selection operations via the cursor at its center are still functional. The same button closes the magnifier to the original view.

Apple Mighty Mouse.

This mouse is completely functional with the TNT products as a 2-button mouse. Apple is clearly headed for more right mouse button functionality by releasing this device. TNTmips already uses right mouse button menus in various locations, for example, in the Spatial Editor. TNT 2005:71 adds more use of the right mouse button, such as opening a right button menu for all platforms including Mac OS X as described in the section below entitled Direct Use of External Geodata. You can expect more right mouse button functionality in future TNT features. Thus it is recommended that a 2-button mouse be used for operating the TNT analysis products. Alas, this new Apple Mighty Mouse has many shortcomings and is not recommended. For example, it is hard to grip while accessing its new, additional functionality.

Microsoft’s Wireless Optical Mouse 5000 is the recommended 2-button mouse for operating the TNT products under Mac OS X.

External Storage.

Write Test.

To facilitate testing of the read and write speeds of external storage devices for this mosaic operation, a new “Write” file option was added to 2005:71. You can use this to test any of your storage devices installed in your workstation, accessed via your network, or as attached external storage. This new operation is on the Support / Timings dialog box. When you choose this new option, you can specify that you wish to write a file of a given total size and buffer size. Once you have selected a destination storage device, it will write the file to that device filled with random values and then read that file back confirming that it actually has those same values.

Since nothing is read from any other storage device or memory, this is a simple test of the fastest rate at which the drive can write data at that buffer size on that workstation. Once the file has been written, it is then read back from the same device to make sure that it has correct values. Since the data is not stored, even in memory, this is a simple test of the fastest rate at which data can be read from that storage device on that workstation. Make sure that this test file has not been cached by the operating system in memory or this will greatly distort your results. Using files that are much larger than your real memory or rebooting will guarantee this. When the test is finished, it will report how long it took to write and read that file and at what rates.

Mac OS X Test Results.

The following Write tests were performed on a dual 2 GHz PowerMac using Mac OS X 10.4.2 with internal SATA drives and built in ports for USB 1 or 2, Firewire 400, and Firewire 800. All drives were first formatted as Mac OS X Extended (Journaled). Only one processor was used by this test procedure. The default settings were used for the TNT Write Test. The drive and test file size are in gigabytes and the transfer rates are in megabits per second.

Drive Capacity Test File Write Mb/s Read Mb/s

USB2 Thumb Flash 1 9 6.5 65

USB2 or Firewire 400* 160 50 111 125

Firewire 400 300 50 272 264

SATA (internal to PMac) 200 50 349 241

Firewire 800 300 50 415 432

Firewire 800 1000** 900 440 451

*same drive but testing each interface. **4 of 250 GB drives in a single housing.

As you have already found, thumb drives are extremely slow on a relative basis, but are only used for small files. Be careful not to be deceived in running this test on a small USB thumb drive by very high read rates. These small test files will be read in this test from the cache memory even though the file has been written to the storage device. In this case, since a large test file can not be used, use the Write then Read test, discard the read rate values, restart your computer to purge the memory, then immediately run the separate Read test available from this dialog to read the test file from the thumb drive.

Interpretation of Results.

You may be surprised that the fastest results are reported for the large external drive using the Firewire 800 interface. All these drive interfaces are controlled by more than just the communication standard, such as the read/write rates, rotation rate, buffer size, and other parameters of the actual IDE ATA, SATA, or drive interface. This is the interface built into the external or internal drive. There are no Firewire or USB drives but simply communication chips that make them appear so. For example, the USB 2 and Firewire 400 test above for the same drive produce the same rates since interface in the drive is obviously slower than the different and maximum transfer rates of USB 2 or Firewire 400. Thus this drive interface, which claimed on the box to have “transfer rates up to 480 megabits per second,” is the limiting factor in setting its maximum real rates. A further example is that Firewire 800 communication rates can be higher than those achieved in these tests, but current economical drive interfaces do not support this. Striping 4 of these drives together in the terabyte device test provides for somewhat faster results. 1, 1.6, and 2 terabyte lowest cost Firewire 800 drives are currently about US$100 per 100 gigabytes. Raid configured Firewire 800 drives of even large size are available and should be even faster.

External drives with either USB 2 or Firewire 400 connectors and a power supply now cost little more than a naked drive (SATA or IDE) that you have to install. External drives with connectors for USB 2, Firewire 400, and Firewire 800 interfaces are now appearing for only about 10% more than those with only 1 of these connectors. A card to add all 3 Firewire 400, 800, and USB 2 connectors to each of your PCs via a bus is about US$50 per unit.

Read Raster Object Tests.

You are also reminded that this same file test dialog also provides a means of determining how fast your workstation can read raster objects from internal, external, and network storage devices. This test reads the entire full resolution raster object and then simply discards the results after they are read into the RVC buffer. No TNT process can possibly operate faster on every cell in the raster than the rates yielded in this test of the efficiency of our raster read operation. This read rate will be somewhat slower than simply reading a file with no structure. Since this is the rate at which a TNT process can read your raster, it is an effective way to determine how the storage locations you are using for Project Files are performing for you. It is important in each test of this type that you make sure that the raster object is not already in the cache buffer of the workstation. If it is a raster much larger than your memory, this is not the case. However, the most reliable tests result if you restart your operating system immediately before each read test of the raster object located on each storage device.

TNTtalk Discussion Group

Enclosed is a color plate entitled TNTtalk: TNT products Discussion Group. It introduces TNTtalk and provides information on how you can sign up for it. TNTtalk is a moderated, broadcast discussion group where you can discuss your TNT projects, share ideas, and request/provide useful advice on your projects. Your specific support questions should still be addressed directly to MicroImages’ support staff and will be answered directly for you. Allowing these normal technical support questions and answers to occur on TNTtalk would make it cluttered and not serve its principal object as a means for you to discuss your ideas. If your question directed to support and its response are of wide-scale general interest to TNTtalk members, it will be repeated there. Please also join and use AtlasTalk to discuss your TNTatlas ideas. Atlas related communications sent to TNTtalk will automatically be resent to AtlasTalk for discussion in that more appropriate forum.

Land Viewer

The release of the TNT 2004:70 products provided you with the Property Viewer Atlas for Lincoln, NE on a sample DVD. It was focused on illustrating geoaccess to a high resolution color image of an urban area. It also provided a variety of geometric geodata layers all accessed from an urbanite’s viewpoint, by address or name. The Land Viewer: Nebraska Statewide TNTatlas DVD distributed with this 2005:71 MEMO looks at a different aspect of image distribution.

Nebraska is a very large state with low farm and ranch populations in over 90% of its area. There are also relatively few detailed information layers for these rural areas. Property ownership records are county level activities and their form and storage is almost exclusively a matter for the 93 county governments to decide as no land taxes are collected at the state level. There is no requirement for, or access to, a statewide property boundary layer. You either go directly to county records, in other word, visit the property ownership books and maps in a rural county courthouse, beg CAD files from some more progressive and prosperous counties, or download the vector layer and database tables for Lancaster County that is centered on Lincoln, which dominates its economy. Rural counties in Nebraska are losing population and thus their tax base, and it’s hard to be “progressive” with less tax income.

On the other hand, you may already have the coordinates of an area in our uniquely American Public Land System of state, county, township and range, section, quarter and quarterquarter section division of our land area. 80% of the USA area uses this messy, historical, but working system to break down the rural land into progressively smaller blocks. If you own farm or ranch land in these vast areas of the U.S., you absolutely know by memory your areas’ block coordinates and constantly use them on the paperwork referencing all aspects of your ownership. A ¼ ¼ section of land is nominally 40 acres (16.2 hectares), a section is usually 640 acres (640 acres = 1 square mile = 259 hectares), a township is usually 36 sections, and counties are made up of townships and have unique names within each state.

Children learn this system in school even if they are not in the 80% land area using the system otherwise they could not find “the old family farm” or use a topographic map. So, if someone called and said that they had 40 acres (16.2 hectares) of wheat growing in the NW¼ of the NE¼ of section 36 of T11R18W in Buffalo County in Nebraska, they could use a map(s) to go directly to that field. Alternatively they could now also use the Land Viewer: Nebraska Statewide atlas to zoom directly to it anywhere in the state. Gradually GPS coordinates are changing this somewhat but they can not change 100s of years of county records.

The sample Land Viewer: Nebraska Statewide TNTatlas is designed to provide direct access to a high quality 1-meter color image of any rural property in Nebraska using its Public Lands Description. For this it uses 5867 orthophoto JPEG images mosaicked into a single, uncompressed raster object of 724 terabyte. This was then compressed 200:1 using JPEG2000 for distribution on this DVD. This huge compression retains the 1-meter resolution by blurring the highest frequency variability within cultivated fields and natural areas (in other words, it degrades crop row structure and small shrubs). Using the latest features in TNTmips to build this image is described in detail later in this MEMO in the section entitled Raster Mosaic.

This TNTatlas is distributed to illustrate how a large area atlas can be designed to provide quality viewing and measurement tools for a 724 terabyte image. An image covering every soil patch, crop blemish, cattle feedlot, chicken barn, river, intermittent stream, farmstead, farm pond, rural road, shrub and tree in the 77,358 square miles, 49,509,120 acres, or 200,356 sq. km. of Nebraska. As usual, this atlas will autostart in Windows and will present a dialog permitting you to jump to several different kinds of views by entering their identity in a dialog created by a script. If you copy this TNTatlas and its contents to your hard drive, any view you choose will be on your screen in 5 seconds or less! The attached color plate entitled TNTatlas: Nebraska Land Viewer Atlas illustrates this special rural access panel where you enter your request. Entering your Township number, Range number and Section number will zoom in about 340X to an area of slightly more than 1 square mile (2.59 sq. km.) or a scale of approximately 1:15,000. On this view anyone can recognize their rural property and visually break it down further by area (e.g., to a ¼ = 160 acres and ¼ of ¼ = 40 areas) since most section line boundaries show in a view. The exceptions are the large ranches in the Western Nebraska Sand Hills, a pseudo-desert owned by people like Ted Turner who is the largest land owner in Nebraska and tears down these square mile fence barriers to allow his large herds of native buffalo to range. Alternatively you can enter the name of a rural city or community (for example, Halsey with a population less than 100) and zoom to it. You can also enter the name of a county or Natural Resource District and zoom to it. Natural Resource Districts are the 23 state government management areas based on watershed boundaries and not coincident with county boundaries.

Using the number “1” key with the cursor anywhere on any view will zoom in at the location of the cursor so that 1 image cell is 1 display screen pixel. This zooms your view to the full resolution of the Nebraska orthophoto mosaic and hides all the other layers except for the DataTip. This is a fixed scale in the range of 1:2000 to 1:4000. This scale is a ratio between the size of a feature on your monitor and its size on the ground. Thus, while this scale is a fixed value on your computer, its actual value depends on the pixel spacing on the monitor you are using and the resolution you have set for its use. For example, a setting of 1280 by 1024 will produce a different scale that 800 by 600. Note that you can calibrate the scale of your TNT products’ use of your monitor for Windows as described in an earlier color plate entitled MicroImages X Server Preferences located at www.microimages.com/documentation/TechGuides/65mixprefs.pdf.

A “1” will zoom your view to an area of 40 to 80 acres (16 to 32 hectares) at the cursor no matter what view you are looking at when you use this key. This is a very useful feature as it allows you to jump immediately to the maximum image detail in the area of interest and begin measuring. For example, use the Find Area off Interest dialog to zoom in to a township of 36 square miles (~100 square kilometers) by entering its township and range values or a small rural community by name. Position the cursor on the farm field or housing block of interest and then used the “1” key to zoom into it at full resolution. In other words, just use the dialog and the “1” key to view any property or housing block in the state in less than 30 seconds.

The number “2” key will zoom to scale of 2 times that of using “1” (20 to 40 acres / 8 to 16 hectares). The number “3” yields the scale of 3 times that of using “1” (15 to 30 acres / 6 to 12 hectares). The number “4” yields the scale of 4 times that of using “1” (10 to 20 acres / 4 to 8 hectares). At the “3” and “4” scales the image will show pixel blockiness since a 3 by 3 or 4 by 4 array of pixels is representing each original image cell of 1-meter.

The actual scale values applied with these keys depend upon the layer selected to determine the “1” zoom scale or if not specified, the scale of the first image selected which is the bottom image in your complex view. In this TNTatlas it is controlled by the 724 GB orthophoto mosaic with a ground cell size of 1 meter. You can change this default scale behavior for these numeric keys by designating differed preferred image on the Raster Layer Control dialog. In either case your composite will be rendered so that 1 ground cell image is 1 screen pixel and this will set the scale of the composite view and thus the scale of these zoomed views.

At any time if you want to jump your view to an exact scale or zoom, edit the current number in the Scale or Zoom readouts at the bottom of the view. If you want to center the view on any map coordinate (for example, latitude and Longitude, state plane, UTM, …), use the Zoom to Location selection on the View menu or Zoom to Location icon on the toolbar.

You can also enter the name of any 7.5' USGS map quadrangle and zoom to that area. If you would like to gain access to the somewhat higher quality of the original 5867JPEG compressed DOQQ files, the atlas will auto-link you to the source site for the specific DOQQ image of the area you are viewing. Please see the PDF file launched from the Help button on the Find Area of Interest/Download Orthoimages dialog for how this is done and other illustrated information on the operation of this atlas. If you would simply like to compare the quality of the 200:1 image with the original sample DOQQ, you will find 4 of these JPEG files on the DVD in the Documentation folder with the LandViewer data.

The farm and ranch population that owns most of the USA private land areas and state and federal agencies who manage the nation’s lands keep track of it in this national Public Land area system. However, other nations have their own unique cadastral systems. Making an equivalent national or provincial equivalent of this atlas must use the local land location scheme. This is where you need the ability to use the geospatial scripting language and its dialog building capabilities. Maybe a farmer can tell you the UTM or Latitude/Longitude coordinates of their field. However, it is much more likely that they use some equally bizarre, unique land ownership systems. Using this DVD as an example, you can construct some sort of algorithm in a script to at least approximately zoom to the area described in that local system. Your area subdivision procedure may not be as precise as you would like, but this merely determines how far you or they will zoom in using this approximate area or point coordinate value. If your approximation of the system is inaccurate, then zoom in less and leave it up to the farmer or rancher to recognize their property or point it out on the view to the TNTatlas operator to control further interactive zooming in on it. Property-oriented TNTatlases of your provinces or nation would be very popular even if the only images available at the moment are the NASA Zulu Landsat images supplemented by higher resolution images of urban or other high interest areas (for example, borders, mining concessions, tourist resorts, …).

Those without high speed Internet access in rural areas of your nation, in cars, and so on can use this DVD distribution media now. But how can anyone make money with a TNTatlas that is free or easily duplicated? Some of you have already discovered that you can prepare CD and DVD atlases for magazines and businesses to give away as promotional pieces that actually get used and, thus, keep promoting their sponsor. This could be very practical ideas like where are BP service stations with bathrooms for their customers, bike trails with hostels and other services, recreational or park features paid for by their local merchant and restaurant associations, and so.

Since the Lincoln Property Viewer DVD was shipped, Google Maps has provided name or address access free to exactly the same 1-meter color image of Lincoln. Outside of Lincoln and Omaha they are still using the more or less useless Landsat imagery. They will eventually get around to adding this same higher quality imagery as on this new DVD TNTatlas of the rest of Nebraska. In fact they too will get a copy of this DVD. Google charges nothing for this content but does charge for the advertising associated with it. Keep in mind that this same atlas can be used unchanged in a TNTserver. You will also see in the TNTmap section of this MEMO how this content can be added to Google Earth from the new Web Map Service compliant TNTserver 2005:71. These TNTatlases will soon be available from microimages.com to demonstrate this approach. This will help you understand how you can build and distribute these atlases as content for use in Google Earth, content that has its own advertising revenue if that is appropriate, or free content from government and other public agencies.

TNTserver™ 2005:71

TNTserver is a control and communication shell to permit web requests, rather than direct user input, to use TNTmips operations.

Background.

Past Situation.

MicroImages first introduced TNTserver in 1999 as a simple, inexpensive means of publishing geospatial data on the Internet or an intranet. At that time it was advanced in that it built upon the use of the unique TNTatlas structure, which has been available since 1994. This combination permitted viewing geographically related combinations of raster, vector, and tabular geodata in superposition. TNTserver was provided with a free, public code, Java-based TNTclient, which provided its remote interface via a web browser. Prior to 1999, atlases prepared in TNTmips could be published only on CD and used directly with the included FREE TNTatlas software. TNTserver provided low-cost network access to the same atlas content remotely over the network using TNTclient. Subsequent developments have focused upon small incremental improvements in TNTserver relative to these earlier objectives.

TNTclient provided geographic navigation features and a subset of the same simple analysis features as TNTatlas including the measurement tools, feature selection, metadata about features, and so on. Next an HTML-based TNTclient was developed since the download of the original Java-based TNTclient was slow by the then common phone modem access to the Internet. Finally a standalone TNTbrowser with the same features was provided as FREE, public Java code. This version functioned as a complete standalone special browser and could be downloaded once to the local drive and used repeatedly to access any TNTserver and its atlases.

Present Situation.

One of the impediments to wider use of geodata via the Internet has been the possessive nature of those who create the data layers. Local, State, and Federal organizations “live” by the data they create and control. This includes those who create and manage map, image, and other geographic datasets. Commercial vendors who create map or image data want to create a revenue stream from their investments in data collection and processing. They are reticent to provide their geodata in a form that would allow someone else to capture it in its entirety. These kinds of reservations about publishing geodata have given way over the past 2 to 3 years to the idea of preserving control and ownership of geodata by its creator and owner while serving it up in pieces that can be assembled together in a composite multilayer view by the end user. This permits those serving up public geodata to combine it with commercial geodata available for a fee or paid for by geopositionally-oriented advertising.

The retrieval and combined use of geodata layers from several remote sites require that they respond with metadata and geodata content meeting certain minimum standards. When a cooperating geodata source is located on a web site and interrogated by a client application, such as a browser, it must respond in a standard way with the required minimum of information about the geodata layers it is publishing for general use. It must also provide a variety of standard information about these layers, such as the format and Coordinate Reference System they can be provided in. You can then determine if you want to add that layer to your view and if it is available in a suitable form for your viewer to use. A more advanced client application acting as your agent can even make these assessments for you.

Fortunately, the Open Geospatial Consortium (OGC) of interested organizations is in the process of setting up these kinds of web standards. These OGC specifications are worked up, proposed, adopted, and revised in functional groupings called “services.” Supporting an OGC service means that a host web server will respond with the specified parameters and action to a client application interrogating the site via a URL in that OGC service’s standard protocol. These OGC services are a work in progress. Some are completed and approved or nearly approved as ISO standards while others are in very rough draft form and may or may not ever be adopted. The attached 2-sided color plate entitled Open Geospatial Consortium (OGC) Specifications summarizes the status of a subset of these proposed and adopted services. These are services that are already supported by TNTserver or those that are candidates for TNT support and several are discussed in detail below.

Difference in Terminology.

There is a potentially confusing difference in terminology between analysis products and web publishing products. The web and web applications refer to all spatial data being moved around and used generically as images. Geospatial and other content preparation and analysis products treat an image as a raster and make a clear distinction that not all rasters are images. From these technical products’ viewpoint, a raster represents an array of numbers regardless of how it is formatted, compressed, fragmented, pyamided, tiled, tiered, or otherwise stored on some media. It may contain categorical data, such as a soil map, a floodplain, a cellular representation of lines, a mathematical or topographic surface, or a wide variety of single band, composite, or multiband images, in other words, a wide variety of content. From the viewpoint of a client application on the web and a WMS in particular, what is requested, received, and used for all these different kinds of raster contents is called an image. Even when feature data is involved in forms like SVG or GML from the viewpoint of the end user these are images and discussions of web software may even refer to these data formats as images, in other words, an SVG is an image of a map. As a result it is necessary to switch terminology when discussing TNTserver and related topics in the following sections discussing web products. In these discussions, rasters are referred to as images unless the discussion concerns a specific raster geodata object’s characteristics before it is requested for use by a web product.

Open Geospatial Consortium Features.

Web Map Service (WMS). [in 2005:71]

TNTserver now supports V1.1.1 and V1.30 of the OGC’s Web Map Service (WMS) specifications that are nearing approval as ISO standard 19128 and that govern the network publishing of geodata as images. At this time the WMS is the most widely adopted of these various OGC services. It permits any WMS compliant client application to access TNTserver via the Internet or intranet. It is also the easiest OGC service to support since web servers using it are only required to deliver up a single image in any single image format. Typically they will offer more than one often selected from these standard image formats PNG (*.png), JPEG (*.jpg), GIF (*.gif), and/or TIFF (*.tif). It is even possible to use an HTML client as illustrated below or browser plug-in to locate a WMS site; locate, select, and retrieve its layer(s); and overlay them in other applications, such as Google Earth, which accepts these 4 standard image formats. At present as few as 100 web sites around the world publish geodata via a WMS and respond to a standard request for an image in at least one OGC identifiable Coordinate Reference System (CRS) with a structure described by an ISO 19111 standard description and identified by an EPSG identification number (for example, EPSG:4326, which is the WGS84/Geographic CRS) or an OGC identifier (for example, CRS:84, which is the same WGS84/Geographic CRS).

Web Feature Service (WFS). [planned for 2005:72]

OGC’s Web Feature Service (WFS) specifications cover the network publishing of geometric and attribute data from geodata sources. WFS was submitted this year for approval to ISO and has the ID number 19142. OGC’s Geography Markup Language (GML) v 3.1.1 was also submitted to ISO this year and has the ID 19136. It is the format in which a site supporting a WFS must respond to a request for graphical elements. GML is not yet widely supported in client application software because it is competing with many other geodata and other graphically oriented formats such as Flash, SVG, …, everyone wants their own markup language. Only a few geodata server engines can convert their vector, CAD, and shape contents to GML and few client applications can accept and use it. As a result WFS is not yet widely supported as a standard web service to provide for the exchange of geometric geodata content such as individual or groups of points, lines, polygons, attributes, and so on.

Now Microsoft, Google, and other search engine operators are directly entering the picture by introducing their own approaches for the delivery of geometric data to their map and image orientated client applications and for use in web 3D, animation, and others. For example, Google Earth uses the Keyhole Markup Language (KML 2.0) obtained as part of the purchase of Keyhole earlier this year. Version 2.0 of KML is similar to an earlier version of GML, and Google could make it a de facto standard by wide use.

TNTserver does not yet support the WFS operations for the elements in vector, CAD, and shape layers, but work is underway to support these specifications and is targeted for TNTserver 2005:72. TNTmips 2005:71 already provides support for the basic capability to export to GML from vector, CAD, and shape objects that the WFS will use. A current effort is underway for TNTmips to export to KML from these geometric objects. This will enable TNTserver to populate a Google Earth view with KML describing elements, styles, and so on derived directly from these TNT geometric objects.

Transforming Coordinate Reference Systems [in 2005:71].

Worldwide there are literally many 1000s of current and historic Coordinate Reference Systems (CRSs) using different datums and projections. Local geodata is often directly collected and used in a unique local, state, or national CRS. Various special systems are often defined and used because of the size or shape of the area covered. It is also common for accuracy and legal requirements that a special, local CRS be used. In these situations it is often mandatory that any locally used client application provide accurate coordinates in that CRS. At the other extreme, Google Earth at this time will only accept geodata from other sources expressed in WGS84 latitude, longitude, and altitude (which means EPSG:4326).

A web site serving up geodata may provide it in a single CRS or serve up geodata in a wide selection of CRSs. Its ability to respond to these varied requests for different CRSs will determine its flexibility to deliver geospatial data that ranges from satisfying specialized local needs for accuracy to worldwide requirements.

If a web site serving maps and images does not identify the CRS of its offerings in a widely adopted worldwide standard, then only client applications written specifically for that site can make use of that spatial data.

It is mandatory that a web site providing a WMS, WFS, or other OGC services must publish the CRS(s) available for each data source it will serve. These CRSs must be provided as a list of one or more EPSG numbers in response to a remote client application making a GetCapabilities request. The client can then determine if any CRS in the list is suitable for the current application and, if so, its GetMap request can specify by this EPSG number that the layers requested should be rendered in that CRS into an image.

If a host site only stores and supplies its geodata in a single CRS, such as WGS84 latitude and longitude, and its WMS and/or WFS will return that single EPSG number as part of its GetCapabilities response. The client application can then “take it in the CRS available or leave it.” If it takes it in the undesired form, then that client application will have to deal with any conversion required. The site may also have the geodata stored in several common CRSs and publish this list as available. Again this is a “take it in one of the CRSs available or leave it” situation. Or, if it is using a robust WMS and/or WFS, it will publish that most of the CRSs defined by ISO 19111 are available. That site then responds to a GetMap request for a specific CRS by transforming the requested layers into the CRS requested by the client application.

TNTserver publishes that all EPSG and OGC CRSs we support are available from its WMS and will transform to them from whatever CRS it uses for the TNTatlases or the individual atlas layers it is serving. TNTmips, the engine for TNTserver, provides this ISO 19111 based capability to transform layers along with a very few other geospatial analysis packages.

Web Coordinate Transformation Service (WCTS). [in 2005:72]

Only a very limited number of serious geospatial software packages that provide the engines for a WMS, WFS, or other OGC services currently support complex transformations between a wide variety of CRS datums and projections. An even smaller number of these are fully adhering to the ISO standard 19111:2003 (Spatial Referencing by Coordinates) and the widely associated use of the European Petroleum Survey Group’s (EPSG) parameters in these definitions. TNTmips 2004:70 provided support of ISO 19111 standard and EPSG with a new internal coordinate reference service and TNTserver 2005:71 makes internal use of this. TNTserver 2005:72 will make these CRS definitions and transforms available to client applications and other servers using the WCTS.

A WCTS extends the ability of a web site beyond simply serving up results in any defined CRS. It permits the site to also serve up the ISO descriptions and EPSG parameters of transforms it is using for this purpose so that its geodata can be requested in an available CRS and then transformed elsewhere to a new CRS. For example, a commericail web site might provide a client application to preview large images in its archive and then take orders for them in any CRS. To conserver storage these images are archived in only one CRS. This specific server is only offering them in that CRS. If some other projection is ordered then this could be handled off-line, by another site, or locally since reprojection of large areas takes time. The reference information needed to do this transformation would be supplied by the WCTS.

TNTserver will use this WCTS to publish the definitions of its CRSs. The client application determines that a site has geodata available in a defined CRS. It can then ask TNTserver for this definition and parameters so that it can transform this geodata to a different CRS. It can then even get the geodata from the source server and send it to the TNTserver to perform the transformation and then get the transformed result from the TNTserver. In this case the TNTserver is not providing the geodata but providing the service of reprojecting potentially large images for local use in a project, as a private local layer for Google Earth, and so on.

Sparse adoption of these defined CRS standards, or any standard, in geospatial software may be the cause or the effect of the WCTS specification currently being at a very initial “study version” of 0.3.0. OGC lists only 2 groups registered as supporting it at www.opengeospatial.org/resource. However, some means of publishing the CRS transformation definitions and capabilities of TNTserver are needed in TNTserver 2005:72. Therefore these proposed WCTS specifications have been selected for this objective since new TNTatlases use the EPSG or OGC identification of the CRS of each object and their conversion properties. As the WCTS specifications are refined by the OGC, it will be necessary to adjust their support in TNTserver. Note that earlier TNTatlases using the older custom TNT CRS service will still work since the new ISO-based system released in TNTmips 2004:70 will convert them automatically to the new EPSG and OGC definitions.

Web Terrain Service (WTS). [planned for 2005:72]

A server offering a WTS will return a 3D view using the available terrain and surface drape layers. This specification allows the client application to request a 3D view from a particular viewpoint and to specify a terrain layer and texture layer. It then builds that view and returns it. TNTserver 2005:72 will support the operations in this preliminary specification, but since the WTS is at version 0.5.0, it is also subject to change.

Web Processing Service (WPS). [planned for 2005:72]

A web server hosting geodata may be capable of performing complex geospatial analyses at the request of the remote client application, not just serving up raster and geometric geodata. If this is the case, the client application provides the user interface for its human user to choose and set up the analyses to be performed by the server. The server then performs these and returns the results to the client application. For example, using the interface supplied by the client application the user chooses an image and a DEM raster hosted by a WMS and then selects a ground point in this view. The application then requests that an application server, not the WMS, computes the viewshed and return it as polygon overlays via a WFS together with symbols for all the desired point features inside these polygons.

If this kind of analysis operation is offered by the web server, it must tell the client application that it has the required analysis available. It must also provide the parameters the client application must supply for it automatically or collect as input from the end user. In the viewshed example above perhaps the only parameter needed is the point indicated by the mouse on the current view of the image from the WMS.

The OGC has proposed a Web Processing Service (WPS) for this purpose. Its GetCapabilities operation will publish the analyses available from that WPS. The site supporting WPS, then respond to the request for a specific analysis with its needed input parameters and a request to execute it. These are returned as part of the request to execute the analysis. The WPS then computes the result and makes it available for retrieval by the client application. Alas, this proposed service is sitting at the moment at the earlier draft version of 0.3.0.

However, this early WPS will be added to TNTserver 2005:72 in combination with the support of the WFS. It can be used by the client application to ask TNTserver for its analysis capabilities, to describe the desired process or its parameters, execute the analysis, and return the results.

TNT geospatial scripting (SML) and the WPS will provide a way for custom web applications to be provided via a TNTserver. The client application will first set up a view using the WMS and WFS of TNTserver and/or other sites. Features in this view, for example a line, can be selected and transmitted to the WPS. To run a script, the client application needs to be able to select from the operations (which means the scripts) available at the TNTserver and get back the parameters needed for the user interface built into the client application. The client application can then send back the user’s input for use in the script. The results would then be returned to the client application in the format defined in the script. The WPS, even though it’s a very early proposal, can provide a means of controlling and using scripts in the TNTserver or using built-in TNTmips procedures.

Catalog Services for the Web (CSW).

This service provides the basis for a server to build a catalog of what geodata and services are available from other geospatial data servers. It is an approved specification at version 2.0.0. At this time it is not immediately planned for TNTserver because there seem to be only a few web sites publishing the availability of their geodata via a WMS, WFS, … using the CSW. It is hard to locate geodata servers in the first place to harvest their CSW published metadata.

Early Adopters.

In the WCTS and WPS outlined above, MicroImages is adopting preliminary specifications that have been published by the OGC but are not yet finalized at the level of 1.0. To move TNTserver forward at this time requires these kinds of operations. MicroImages could create its own new protocol or specifications for these purposes. However, it would eventually be necessary to adopt and adjust to these OGC specifications if they move on to approval. The developers of these specifications have already put a lot of thought into these proposals. It will be easier to adjust to changes in these open specifications later by adopting them now rather than proceeding independently. Initially the use of these WCTS and WPS preliminary specifications will be used to communicate between MicroImages application clients and TNTserver since few if any sites are officially supporting these services at this time. Since this is the case, MicroImages can extend them by adding any operations that appear to be missing or incomplete.

Locating OGC Compliant Sites.

At this time MicroImages has not found an Internet clearinghouse for web sites that have geospatial data available via one or more of the OGC services outlined above and on the attached plate entitled TNTserver: Open Geospatial Consortium (OGC) Specifications. Over the past few months an initial limited effort by MicroImages has located a collection of about 70 sites that claim to provide map and image rasters via a Web Map Service. The URLs for these sites are embedded in the TNTmap Builder introduced below when you obtain it. You can also update this list of known links from microimages.com since it will grow as MicroImages and you find more WMSs. As noted, if all OGC sites supported the Catalog Services for the Web (CSW), it would be possible to easily find them, harvest information about their WMS and other OGC and ISO services, and maintain such a clearinghouse. Frankly, it is hard to understand why the OGC does not provide such a service at their site to promote the wider adoption of its standards.

Installing a TNTserver.

TNTserver.

TNTserver now uses the same Windows InstallShield program as the other TNT products. Installation is familiar and simpler since this is the same program used to install your TNT analysis products. All the components of TNTserver are installed in a single TNTserver directory. The major components are RVCatlas.exe, which is the TNTserver program, TNTgateway.cgi, TNTgateway.ini, and TNTservermanager.exe.

The version numbering system and release and patching cycles for TNTserver now also match those of the other TNT products. Among other benefits, this means that any changes made in TNTmips and TNTatlas will be reflected in the matching version of TNTserver.

TNTgateway.

Remember as emphasized above that TNTserver is a control and communication shell to permit web requests, rather than direct user input, to use TNTmips operations. It is not your web server and thus it requires a means of communicating with the computer that is hosting your web site which in turn controls all communications with the Internet or intranet.

TNTserver comes with a small TNTgateway program that manages communications between the general web server publishing your site and TNTserver. TNTgateway acts as a remote proxy server routing requests to/from your web server (for example, OGC operations) and responses (for example, an image) from the Internet or an intranet back and forth to the TNTserver in the appropriate form. This new program runs on the computer that is hosting your web site and communicates with the computer running your TNTserver using port 4750. It sends a request to TNTserver and gets back its responses. Both these operations may be conducted on the same Windows computer in your office that is hosting your web site. Another approach could use a Windows computer(s) hosting only TNTserver(s) and communicating only over your local network to your web server, which is running any operating system. By using a Virtual Private Network (VPN) over the Internet, TNTserver could also communicate with your web server being hosted remotely at any location using any operating system. The communication could be over the Internet without using a VPN but this connection would be easily compromised.

TNTgateway is the executable program (tntgateway.cgi) that is installed along with the TNTserver components in a subdirectory. If you are using the same computer to host your web site and TNTserver, then TNTgateway.cgi from the Windows subdirectory should be used. However, it is recommended that you use a separate, network connected computer for your TNTserver to make its installation and management easier. Your TNTserver computer can still be located at your office if your connection to the Internet or intranet, even if by a VPN, is at least a cable modem or ADSL. This is an appropriate scheme if you are not able to set up and manage a secure web site at your location. Your TNTserver and TNTgateway can both be installed and maintained at the remote rental site if they provide this kind of service. They would set up your TNTserver and you simply copy atlases over the network into the designated directory at that site.

The computer you use or rent to host your web site on the Internet may not be running the Windows operating system. For this reason, compiled versions of the TNTgateway program for Mac OS X, Solaris, and other Unix/Linux systems are also installed in separate subdirectories of the TNTserver directory. If your web host uses one of these, locate, copy, install, and run the appropriate TNTgateway program for that operating system. This TNTgateway program is written to support the Common Gateway Interface (CGI) protocol that is the standard for interfacing external applications such as TNTserver with a web server. A copy of the TNTgateway source code (tntservercgi.c) is also installed in a wms_cgi subdirectory of the TNTserver directory. If your web host is using some other operating system, such as some special flavor of Linux, ask its system manager to compile this TNTgateway program from this C⁺⁺ source using the FREE TNTsdk and install it for you.

TNTgateway is a program that can be installed on a Solaris, Mac OS X, Windows, Linux, or other computer hosting your general web site and used for communication with the TNTserver installed on a Windows-based computer.

Since the TNTgateway program is open source, it can also be modified by someone familiar with C++ to expand its operations using the free TNTsdk. If there is more than one computer running a TNTserver on a network (which means you are using a TNTserver farm), then the TNTgateway can be modified to equalize the load between these separate TNTserver computers.

The TNTserver Manager introduced below will let you enter the web address to access TNTgateway.cgi. Thus, not only can TNTgateway be running under another operating system, it can be located anywhere that can be reached by a web address, even over the Internet using a VPN to secure its communications with a remote web host.

Tomcat and TNTservlet Now Optional.

It is no longer necessary to install the confusing Tomcat servlet manager or the TNTservlet. This servelet software served the same function as the new TNTgateway. Getting this open source Tomcat process up and running on a web hosting computer was the single greatest complication in setting up an earlier TNTserver. It was not a MicroImages product therefore outside our control, subject to considerable variation across various operating systems, and complicated to install.

Alas, if you wish to continue to use the HTML-based TNTclient you will need to continue to keep Tomcat running on your web server host for this purpose even if you are using the latest TNTserver. It would take considerable effort to modify this HTML program to use the new TNTgateway proxy server. This backward oriented effort is better spent improving the new TNTmap client introduced below. It is designed to locate and use the new WMS features, additional OGC services, and communicate with TNTserver via this new TNTgateway program.

The Java-based TNTclient and TNTbrowser talk directly to port 4750 and do not require the use of Tomcat with the current or previous versions of TNTserver.

TNTserver Manager.

TNTserver Manager is a program (tntservermanager.exe) that is part of the TNTserver package and is described in considerable detail below. It is installed in the same TNTserver directory as all the other components of this product. It is primarily a graphical interface used for entering parameters into the portion of the Windows Registry that TNTserver uses to control its operations. TNTserver Manager is used for many things starting with the simple controls to stop, pause, start, and display the status of your TNTserver.

TNTmap.

TNTmap is a new HTML-based client that is compliant with any mandatory operations of a web site publishing geodata using a Web Map Service (WMS) including those published by a TNTserver. It is automatically installed and patched with your TNTserver. It is introduced and discussed in the major section below entitled Introducing TNTmap 2005:71. Since TNTmap is an HTML client application, it is automatically used by any end user’s browser (Explorer, Safari, Firefox, Opera, Mozilla, …) that visits a TNTserver or can be set up to be accessed anywhere independently from a TNTserver. It is used to review the list of WMS compliant geodata any web site has published including your TNTserver. It can then be used to assemble a complex view with content selected from these WMSs including a TNTatlas composite view or selected individual atlas layers.

Let MicroImages Do It!

MicroImages will set up your TNTserver for you remotely from Lincoln or supply it preinstalled on a computer for standalone operation via a network connection with your separate web server. This is discussed in more detail in a following section on Prices.

Summary.

TNTserver is simple to install and update. The new TNTgateway proxy server eliminates the problem that plagued the use of the open source Tomcat program and the TNTservlet that are now optional. Using TNTgateway your TNTatlas content can be delivered to the Internet in a standard WMS format. TNTmap provides a new client to use this and other WMS content. If you are using a commercial web site for your content and have a VPN cable connection to it via the Internet, that web server can host your front end access pages for your TNTserver and the TNTgateway pointing over the Internet to your location that has the isolated TNTserver installed and supplies the disk space for the TNTatlases. You can then use the improved TNTserver Manager program to setup and manage your TNTserver and its TNTatlas content locally while relying on the remote site to provide your web access reliably and securely and a secure connection to your TNTservers via a VPN.

Managing a TNTserver.

A new process called “TNTserver Manager” has replaced the control panel applet in previous versions of TNTserver. This application has all of the earlier controls provided in the applet plus two additional panels for managing WMS operations.

At first thought it may not be apparent that a server oriented software product needs a user interface. After all, it is not an end-user product and its use is via some separate software, such as a browser. MicroImages’ 6 years of experience with creating and assisting you in managing the earlier TNTserver proved this to be misleading. The ease with which a web server can be set up and managed depends upon the flexibility it has built in and the user interface provided to its manager to set it up and subsequently alter its operation. As a result a considerable effort was invested in TNTserver 2005:71 in increasing its operational flexibility by creating an improved new management interface.

Most of the capabilities of TNTserver can be understood by reviewing setup and management options provided by the TNTserver manager user interface now made up of a dialog with 9 tabbed Panels. Each of these panels controls a different aspect of the operation of a specific TNTserver. A series of color plates introduced by the color plate entitled TNTserver: Configuration is attached to describe each of these management panels.

Control Panel.

The Control panel is illustrated on the bottom portion of an attached color plate entitled TNTserver: Managing General Controls. It provides feedback on the status of your license to the TNTserver followed by an area to enter an option enable code used for authorizing major upgrades provided under your annual maintenance contract. It also provides a Start button to start or restart the TNTserver if it has been paused or deliberately stopped. A Pause button and a Stop button are also provided. A Status button interrogates the TNTserver to determine its general operation status, which is then displayed in this panel.

Image Panel.

The Image panel is illustrated on an attached color plate entitled TNTserver: Managing Image Properties. It controls important features governing the rasters you are publishing. As manager of a TNTserver you use this panel to define the maximum output raster size, formats, and image detail (via lossy compression) that you are offering to any client application. Additional panels of this type will be provided when TNTserver supports the graphical activities of a Web Feature Service and others.

Size.
The maximum width and height of the image to be served is set in this panel. The larger the image in area and bytes that you permit TNTserver to prepare the more time it will take to satisfy a request. This also determines the communication bandwidth it will take up to send this image to the client application, and thus, its response time. This also controls how much of your raster and graphical geodata via SVG you are willing to let the end user capture or harvest and save at their site during each visit.

Format.
TNTserver 2005:71 is primarily a raster server that can respond to requests from client applications with images in JPEG (*.jpg), JPEG2000 (*.jp2) , and/or PNG (*.png) format. You can select any combination of these formats that TNTserver will then publish as available when queried by a client application. For example, using the settings in this panel you can advertise that your TNTserver will respond with large lossless compressed PNG images. Or, you may set up to offer only small, highly compressed versions of images by advertising that only JPEG and/or JPEG2000 images of a limited number of rows and columns are available. Using the settings in this panel can provide or prevent access to the original image detail and/or make it more or less difficult to download and reassemble the full geodata layer.

Compression.
The compression level of the JPEG and JPEG2000 images returned by your TNTserver can be set for each. The settings for JPEG are in percent. A maximum and minimum compression can be set so that a client application that overrides the default level can still only request a compression between these set limits. Similar settings are available for controlling the default, maximum, and minimum JPEG2000 compression that your TNTserver will supply. These setting are entered in compression ratios relative to the uncompressed size of the requested image.

If your TNTserver is going to respond to requests with PNG images, you can set it up to return 8-bit indexed color or 32-bit RGBalpha true color both of which preserver layer transparency.

SVG.
TNTserver will support a request to render an atlas view to an SVG containing rasters, features, and their attributes. This panel provides a means of allowing or preventing the client application to request an SVG response.

Layout Cache.
It takes time to open a TNTatlas layout. The layout list is used to set up those TNTatlas layouts that will be frequently used by caching them in real memory. The Layout Cache Size is the total number of TNT layouts that can be in real memory at one time.

Log Panel.

The Log panel is illustrated in the upper portion of an attached color plate entitled TNTserver: Managing Logging. It is used to set up system and statistics log files to permit you to track the health and use of your TNTserver. You can use this panel to set up the location for these files and name them. The system log will track the loading and unloading of each published TNTatlas and any errors encountered. You can set up the statistics log to record statistics on the use of your TNTserver resources at optional levels of granularity or detail. Specifying only the simplest level in this log will record the Connect Time and the IP adress of each visitor. The next level will record the Connect Time and the Thread Times which is the clock time a TNTserver processor devotes to servicing each operation needed to satisfy every visitor’s request: for example, how long is an input thread devoted to the request, how long to retrieve the requested image, to send it back, and so on. The third level records Connect Time, Thread Time, and Request Type.

You can also use this panel to determine the number of days to record to a specific log and how many earlier copies of log files should be kept. For example, you might specify that the log should record for 10 days before being closed and that 10 logs covering the previous 100 days should be keep. Left unattended some of these logs simply continue to grow, for example the third level has dense entries.

Logo Panel.

The Logo panel is illustrated in the lower portion of an attached color plate entitled TNTserver: Managing Site Logo. It provides a means of setting up the name and location of the logo raster object to be used by the TNTserver. The position where this logo, if any, will be inserted into the requested image is also set in this panel: top right, bottom right, center … Since this request may be for a small image to be used only for a reference or thumbnail in the view, the minimum width and height of the image, below which the logo raster will not be superimposed, can be set.

Web Panel.

The Web panel is illustrated in the upper portion of an attached color plate entitled TNTserver: Managing Web Access. This panel permits you to set up and manage the working directories used by TNTserver and the local or remote computer directories where the temporary results of a server operation, such as an SVG result, can be found by the client application.

Web Addresses.
You specify the path to the directory where TNTserver will place the image, SVG, hardcopy layouts, and other results requested by the client application. The address you publish on the Internet for TNTgateway for TNTserver is also entered on this panel. Client applications address this TNTgateway at this address and it in turn acts as a traffic light and routes these requests in the proper form to the proper TNTserver. As noted above in the section on Installation, TNTgateway need not be on the same computer as the TNTserver and these addresses will identify these locations and directories on your internal network and/or on the Internet.

Directory Management.
This section of the panel is used to control the storage resources used by the directory where TNTserver is placing its results until the client application retrieves them or goes away. These files are temporary and many are being generated if many client requests are being served. They can not be retained indefinitely for possible use or reuse by a specific client application. Furthermore a client application may make a request and for various reasons never retrieve the result from this directory.

How many and how long you want to preserve these temporary files for your end users is a function of the kind of resources you wish to devote to this work directory. To control this you can set the maximum amount of storage you wish it to use. No temporary files will be deleted until this limit is reached. To determine which files will be deleted when that limit is reached, you set a maximum file age in minutes. When files must be deleted because this directory is full, those files with a duration exceeding this age limit in this directory will be deleted first. If no files exceed this age setting then the oldest files in the directory will be deleted first.

It is inefficient and usually unnecessary to have the TNTserver constantly checking, managing, and purging these files since there can be a large number of small files. To control this you set a time in minutes that will control how frequently the cleanup operation is performed.

Obviously all these settings interact with each other. For example, devoting a very large amount of storage to this directory will mean that every cleanup operation will have to deal with a large number of files. Thus, you will need to understand the use of your TNTserver’s log files and use them to adjust these settings to optimize its performance. Setting the wrong limits can waste your TNTserver computational and bandwidth resources by using them for this file cleanup operation. For example, not setting appropriate upper limits might mean the number of files to be dealt with for access or cleanup can grow to be very large. On the other hand, setting these limits too low means that the cleanup operation will be forced to be conducted frequently, which leads to thrashing. Monitor your TNTserver logs and do not hesitate to experiment with these settings.

Sharing This Directory.
You can operate more than one concurrent TNTserver to spread the computation requirements across a number of low-cost desktop workstations. These servers can all share the same workspace directory. This is convenient since in a multiple TNTserver configuration you do not control, unless you wish to by modifying the TNTgateway, which server will respond to a client application’s sequence of requests. It is also convenient because the workspace directory must be accessible to the Internet or your intranet and publishing one directory for all your TNTservers is more practical.

On this panel you are setting up the parameters for just one selected TNTserver for its operation on that specific computer. If you have, or plan to set up more than one TNTserver to share a work directory, you can signify this by using the toggle button provided on this panel for that purpose. Then enter the range of the files to be used in the common work directory by this specific TNTserver. These numbers will be sequentially incremented and incorporated into these files’ names (for example, vid00000000235.png). They are then used by their range to determine which files belong to which specific TNTserver. This prevents other TNTservers from accessing or deleting any of this specific TNTserver’s temporary files since you will set each TNTserver up with its own exclusive range of files in this common directory.

Locating Special Files.
This area permits you to tell TNTserver where to find special files it may require. Only one is currently showing on this panel. It is the location of the HTML template you have set up for a client application to use as a layout. It is used if the HTML-based TNTclient application requests a print of the current view’s contents in the layout you have designed. You could have a number of special files of HTML code added and located in this fashion. Each could respond to a different request from the client application(s) to provide other print layouts required for different tasks or other special features for use in the browser.

Contact Panel.

The Contact panel is illustrated in the lower portion of an attached color plate entitled TNTserver: Managing Administrator Contact. This is where the contact information for administrator of the TNTserver is entered. Most of this data is mandatory if the TNTserver is publishing its TNTatlas content for use as a WMS according to the governing ISO 19115 standard. This mandatory contact information for a WMS is automatically available to the client application which may or may not make it accessible to the end user.

Title Panel.

The Title panel is illustrated in the upper portion of an attached color plate entitled TNTserver: Managing ID Titling. The Title entered into this panel is also required by the ISO 19115 standard and is the name published for this WMS of the TNTserver. The abstract and keywords to be published for your WMS can also be entered using this panel.

Directory Panel.

The Directory panel is illustrated in the lower portion of an attached color plate entitled TNTserver: Managing Directories. Using this panel a directory lock list can be created. This list permits you to change all or part of a TNTatlas without shutting down the TNTserver. Make sure to place a directory on this list if you are about to update an atlas object in that directory. This will pause any client application’s attempt to access that object while it is being replaced. This list is set up with toggles for each directory added to this list. Thus you can add all directories being used by your TNTserver(s) to this list and toggle them on and off if you frequently alter atlas layers. For example, you might be replacing a vector layer of road repairs in an atlas every day. The drive mount list is used to map drive letters to UNC (Universal Naming Convention) paths if links to data sources specify a full path. For example, a layer in an atlas is a link to a file at J:\data\... When TNTserver attempts to find this link it will attempt to find an entry on the Drive Mount List, map J: to the specified UNC path, and access the link.

System Panel.

The System panel is illustrated on an attached color plate entitled TNTserver: Managing System Parameters. The section above on the Web panel discusses the features available for managing the storage requirements for the files being cached by the TNTserver. The System panel is where you configure the use of your memory and processor resources, set the communication parameters, and save and load all these management parameters during a TNTserver update.

Thread Control.

Thread Queues.
TNTserver generates and uses multiple threads for processing requests. A thread is a section of code in a process that is designated to run concurrently with other sections of code in the process. TNTserver designates three thread types for which there are client request queues that wait until a processing thread is available. The three threads are Receive, Compute, and Send and limits placed on them in the System panel determine how many client requests can be queued up waiting to be processed. A client request is removed from the queue when a processing thread is available, and when a processing thread is done performing its task, the client request is placed on the next queue. There is a thread in TNTserver whose sole task is to accept incoming connections and place the client request onto the Receive Queue. If the Receive queue reaches its limit, TNTserver will refuse more connections until the queue can accept more clients.

Processing Threads.
In addition to the queue threads, there are three sets of thread pools that do some type of processing on the client request. The “Number of Threads” section in the System panel controls the number of threads in each pool. The threads in the “Receive Thread” pool do the task of parsing (interpreting) the client request, whether they are TNTserver cgi text Key-Value Pairs (KYP used in an OGC HTTP GET operation) or XML (used in OGC HTTP POST operations), and validates the parameters received. If information from another OGC service is called for in the client request, this thread will submit the sub-request and wait until the sub-request is complete. This is known in OGC parlance as “cascading,” and will be available for 2005:72. When it is done, the parsed client request is passed to the Compute Queue. If the request is for metadata operations, the client request bypasses the compute section and goes directly to the Send Queue.

The thread in the “Compute Thread” pool do the task of processing the client request from one or more Project Files into an image, or feature data, or transforming geometric data. The pool does most of the work and the TNTserver hardware key controls the maximum size of the pool. When the work of the Compute Thread is done, the client request is passed to the Send Queue. The thread in the “Send Thread” pool converts the result from a Compute Thread into a form ready to transmit to the client application. If an image is generated, this thread converts the image to JPEG, JPEG2000, or PNG and places the result in the “Work Directory” designated in the “Web” panel. If an SVG is requested, the Send Thread will compress it before saving it to the Work Directory. If a metadata request from a Receive Thread is to be processed, this thread will generate the appropriate response. Bypassing the Compute Thread pool for metadata requests allows TNTserver to be more responsive to some client requests. When this thread is complete, the client has the proper reply to their request and the instance of the client application’s request is removed.

Optimizing Performance.

A simple access to a complex view from a properly designed TNTatlas is not particularly computationally intense as its required response is mostly controlled by hard drive access times. As a result, when operating in this mode, a large number of simultaneous end users can be accommodated with good performance by a single TNTserver and CPU. To optimize your queue setting, you will need to consider the nature of the tasks your particular server is commonly doing as reflected in its log files. Perhaps you did not wish to put all the layers in your TNTatlas in the same CRS and are willing to spend the TNTserver’s CPU time reprojecting them over and over for every request. Why, because you are in a hurry, the layers are from some other site, or other good reasons. In this case your TNTserver will be using a lot more CPU cycles on the Compute Thread on the average for each client request.

When the number of nearly simultaneous requests is much larger than the receive queue that can be serviced by your CPUs and still get the computation done and out, it is time to add more memory, CPUs, and/or TNTservers. For a bit more information on this complex subject see the following page.

Software must take full advantage of multicore platforms. by Peter Leyssens. Electronic Engineering Times. May 9, 2005. Page 64. Read at www.us.design-reuse.com/articles/article10318.html

Microsoft Windows Limits.

Windows is the only operating system available for the operation of a TNTserver. If you are using the same computer as your web host, Microsoft via IIS controls the number of concurrent connections that a Windows-based machine can support. If you are using a Home Edition of XP, you can not use it to support multiple connections. When using Windows as a web server, you must pay for the number of connections that can be made to it. It is meaningless to set the receive queue or send queue to a number larger than the number of connections available under your Windows license.

Important. The desktop and server variants of Microsoft Windows all place an upper limit on the number of simultaneous remote connections to a web site.

Connections.

By default, port number 4750 is used to initiate communication between a TNTserver and the TNTgateway and Tomcat programs. You can change this port as long as you understand what you are doing. It is recommended that you do not change this port number unless you have a specific reason to do so. TNTmap and other client applications will use port 80 on your web site computer to initiate communications with the TNTgateway program, which will act as a gateway to port 4750 and the TNTserver.

We “let our fingers do the walking on the Internet.” We ask a web site for something and it prepares it, but we become impatient and move on before the answer is formulated and returned. Thus a web site must have a time period when it should no longer keep those results available or anticipate your request for them. The timeout settings for monitoring for communications from any outside client application are entered on this panel. There are separate settings for the timeout for automatic monitoring for a continued communication and for how long the TNTserver will continue to wait to respond to a request to send results request from a client application.

Updating.

The Apply button at the bottom of the window records the current setting on that panel in the TNTserver section of the Windows Registry. At some point you will want to install a new version or a patch to your TNTserver. The Save Parameters button on this panel will bring up the Windows Save dialog and permit you to save or backup this Windows Registry section in a file. You can then stop your TNTserver from the Control panel and update it. The Load button will then permit you to navigate to the saved file and reload it. You can then restart your TNTserver from the Control panel with the same Windows Registry section setup parameters. You can also load this file to set up other TNTservers with the same parameters. It is recommended that you keep this backup copy in some other directory in case you or an installation accidentally deletes or replace it with a new file with default settings. It is also a good idea to use this Save button every time you make a set of changes to this file via these panels.

MicroImages’ five years of selling and supporting TNTserver at various sites form the basis for the current efforts to advance the TNTserver. Setting up a simple promotional site on the web is easy. Setting up and managing a secure web site with complex content is not. A site with any significant content and little or no security in place will be severely compromised within 5 minutes. Thus, publishing geodata on the web via a TNTserver first requires that you have set up, or have the ability to set up, a secure web site or rent space for a TNTserver on someone else’s.

Summary: Selecting a Geodata Server.

Frankly, the use of a TNTserver has not been a pleasant experience for you or MicroImages for several reasons, often outside the control of either of us. Every web site is unique. Using and managing a TNTserver is not like installing a typical end-user software product into a well defined operating system isolated from attacks from the Internet. When your web site is not managed by you at your location, you are not familiar with its technicalities and are depending upon someone, often far removed and with different priorities, to do it for you. Tomcat has also been a big complication as its configuration is typical of open source products—complicated and sensitive to the local operating system and setup it is asked to run in. Now it has been eliminated.

TNTserver 2005:71 is a 2^nd generation incarnation of TNTserver that is backward compatible with previous versions but addresses ease of set up and management and provides new features compliant with the developing Open Geospatial Consortium and ISO specifications and operations.

A number of factors need to be considered in the use of anyone’s product designed for serving up geodata in its many forms and formats.

What is the real cost?

There are sophisticated, commercial server products available but at a substantial commitment in purchase and maintenance prices and a high level of indirect system staff costs. Although the price of a TNTserver will soon increase, it is still reasonable relative to competing products. Alternatively, you can use one of the FREE open source geodata servers if you want to go it alone with the features they offer.

What is complexity in the published results?

This can be expanded to: how easy is it to set up and maintain your geodata and its complex interaction in the setting you have available for hosting your web site and the geodata server? TNTserver has been superior to all others in this area since it directly uses the TNTatlas structure built in any TNTmips. There are free and other commercial geodata servers that can handle a few layers but do not have the features automatically available though the use of a TNTatlas. By accessing a TNTatlas, TNTserver can deliver a complex view of many layers or the access to every individual layer using an efficient geodata structure like the TNT Project File. It can also provide access to other commonly used spatial data formats, which are linked into Project Files and managed by TNTatlas. There are other commercial servers that manage structured geodata resident in databases. These latter are high total cost and high complexity approaches requiring a large enterprise commitment.

What are the computer resources and bandwidth requirements?

A TNTserver with one CPU can service 1000s of application clients in a few minutes using one or more atlases of 1000s of gigabytes and a single high speed cable or ADSL line. Using a more expensive dual processor desktop workstation has proven that it can service 1000s of simultaneous real-world requests.

Can you scale up your offerings?

Eventually your geodata site’s popularity can exceed the limits of a single TNTserver and its dedicated low-cost desktop computer. Probably this is what you want to eventually happen. This creates the justification for more capacity, which is handled by adding additional low-cost computers and TNTservers to access the same or bigger atlases.

Can you publish geodata in a standard form?

It is not clear who will be dictating what this standard form will be for images, geometric features, coordinate reference definitions and format, and so on. TNTserver is publishing the image views and CRS information of atlas views or individual layers following the Web Map Service specifications of the Open Geospatial Consortium. This and additional developments in the standardization of TNTserver results were discussed in detail above.

How easy is it to set up?

This is a major concern with any geodata server and considerable effort has been made to simplify this for setting up TNTserver. These improvements have already been discussed in a section above entitled Installing a TNTserver. TNTserver is now easy to install if you already have a working web site. Setting up that web site is not the responsibility of MicroImages and its operating system and configuration have little impact on adding a dedicated TNTserver to it.

How easy is it to manage/optimize performance?

This is another important area of improvement in TNTserver. By looking at the tools provided for managing any geodata server, you can judge how complex it is to set it up, optimize it, update it, and set up the geodata content it serves. This is another area where TNTserver has been improved as discussed above in the major section entitled Managing a TNTserver and illustrated in 6 attached color plates. When reviewing these, you will note that managing a TNTserver has to do with managing your geodata contents since this is so adroitly handled by the TNTatlas concept. Check out the other geodata servers you are contemplating using. You are going to find that setting up and managing the geodata content they are serving is an area where they have many complex rules, special mark up languages, and complications. TNTserver merely automatically acts on the TNTatlases placed in a specified directory, the same atlases that can be distributed on CD and DVD with the FREE TNTatlas program.

Where do the end-user client applications come from?

By expanding to support the WMS and the ISO Coordinate Reference Service (CRS), TNTserver permits other vendors’ WMS client applications to request atlas views and individual layers. Any client application or its components that use WMS and CRS content can be used with a TNTserver. Alas, almost no generic client applications seem to be available. Each vendor has extended his client application(s) to use the special proprietary, non-OGC compliant extended operations of its geodata server. The new TNTmap client application only uses the earlier proprietary TNTserver operations when addressing a TNTserver site. Thus your client applications and TNTmap can be used to locate and use (for example, make measurements, control layers, …) other site’s WMS content and/or combine them as appropriate with those of a TNTatlas. Furthermore, TNTserver and TNTmap are being designed to be used with other generic client applications, such as using layers and views in Google Earth.

Prices.

TNTserver 2005:71.

The price of this current version of the TNTserver is still US$5,000. All current or earlier users of a previous version of a TNTserver can also upgrade to this new version free of charge. However, no upgrade to TNTserver 2005:72 will be FREE.

Pending Price Increase.

Effective on the first date of the official release of TNTserver 2005:72 via microimages.com, the price of a TNTserver will increase from US$5,000 to US$10,000. This TNTserver 2005:72 will, as a minimum, add support for the OGC’s Web Feature Service (WFS). It will also be available only for Windows XP and 2003.

Effective with the release of TNTserver 2005:72, its price will increase to US$10,000.

2^nd, 3^rd, or additional TNTservers subsequently added using additional computers installed at the same physical site to handle an increasing demand can be purchased at a substantially lower price.

Remote Installation.

This new price will include the remote installation of the TNTserver by MicroImages via the Internet. To use this option you or your web site manager must be willing and able to provide MicroImages’ staff with remote desktop access to the computer hosting the TNTserver using XP Remote Desktop, VNC, logmein.com, or the equivalent.

Keep in mind that the license to use a TNTserver requires a USB software authorization key to be attached to that computer. If you plan to have a remote site host your TNTserver, then they must be willing to attach TNTserver’s software authorization key to that computer. This key is not attached to the local or remote computer that is hosting only the TNTgateway program.

Delivered Installed.

As an alternative to remote installation, MicroImages will preinstall and configure your TNTserver on a suitable new, brand name (for example, Dell, Gateway, HP, …) commercially built Windows XP computer. The price of this computer is included in the US$10,000 price for a TNTserver. This computer will have a current resale value of approximately US$1,000 and a processor of at least 3.0 GHz. It will be ready for you to add to your network using Ethernet 10/100. It will be ready for you to copy your TNTatlases to its hard drive of at least 160 GB. It will be set up with a sample global TNTatlas preinstalled and you can send your first TNTatlas to MicroImages on a hard drive or DVD to be preinstalled.

The price of shipping this computer to you by air express is also included in the new TNTserver price. However any VAT, duties, or other final delivery charges in your nation will be your responsibility at the time and point of delivery. Alternatively, you can ship or have shipped to MicroImages, a new computer you wish to use for your TNTserver. Installation, setup, and testing will be done by MicroImages and you can visit and test this TNTserver before shipment using a private access via microimages.com.

Annual Maintenance.

For 2005:72.
The 12 month maintenance of TNTserver 2005:72 will be 20% of the original purchase price of each of the TNTservers installed at that site. This includes any upgrades and new versions of TNTserver and access to TNTserver technical support for 12 months from the original date of the purchase or the expiration of the previous annual maintainance contract.

For 2005:71.
Anyone operating a 2005:71 or earlier version of TNTserver should upgrade it now to a TNTserver 2005:72 at 20% of its currently lower purchase price. This will include any upgrades and new versions of TNTserver 2005:72 and access to TNTserver technical support for 12 months from the date of the official release of 2005:72. The day that TNTsever 2005:72 is officially released for downloading from microimages.com and its new price goes into effect, this same 12 month annual maintainance will be 20% of its new US$10,000 price noted above.

Yes, it is possible to purchase TNTserver 2005:71 at the current lower price and secure TNTserver 2005:72 and 12 months of its maintenance and new releases at 20% of the current price if you act before TNTserver 2005:72 is released.

TNTclient/TNTbrowser 2005:71

TNTclient and TNTbrowser have not been altered and will continue to work as before with TNTserver 2005:71. As noted above, a Tomcat servlet manager is no longer required if a TNTserver is used as a WMS and other current and planned OGC compliant services with the TNTmap client application introduced below, some other WMS client application, Google Earth, or your own client application. However, if you plan to continue to deploy and support the HTML version of the TNTclient plug-in for browser access then you must continue to operate Tomcat for this purpose. If Tomcat is maintained, the TNTatlases you have published can be used with this earlier client application. These same atlases can be used with all the new TNT operations via MicroImages open code TNTgateway program which is automatically installed as part of TNTserver 2005:71.

Introducing TNTmap™ 2005:71

OGC Compliant Clients.

Background.

An OGC compliant client application would be able to assemble and use geodata content from one or more of the OGC services (WMS, WFS, WCTS, …) discussed above and published by various web servers. Each of these services has its mandatory and optional operations summarized on the attached color plate entitled TNTserver: Open Geospatial Consortium (OGC) Specifications. Each of the individual operations in a specification may or may not be properly supported by a specific site claiming to offer an OGC service. Furthermore these operations can be extended, and usually are, to provide additional custom operations by each server site. So, there are the OGC standards and many customizations and proprietary extensions to them to support additional features.

Proprietary Client Applications.

These proprietary extensions come into existence either because no adopted standard exists within these specifications for a task area, such as the Web Coordinate Transformation Service, or the client application is deliberately designed for commercial purposes to use proprietary features of the geodata server. The latter is the current situation with many Web Map Service (WMS) operations. To be compliant with a specific service, such as WMS, the client application must properly support at a minimum that standard service’s 2 mandatory operations. Alas, most geospatial clients are designed to use additional custom features added to their host servers to extend its WMS or other services. These client applications can get geodata layers from other WMS sites but then perform many additional non-standard things when communicating with their host server and its proprietary add on services. They are not generic and can not be readily used independently of their host site.

Versions 1.x and 2.x of TNTserver (in other words, those prior to 2005:71) were not compliant with OGC’s WMS mandatory operations. This permitted features not supported by a WMS/client combination, such as using geodata layers interrelated in TNTatlas form and retreving database information about a feature. The OGC Spatial Coordinate Service and ISO 19111 standard were also not used in the earlier versions of TNTmips and TNTatlases and thus, were not available for use in those TNTservers. TNTserver 2005:71 now adds all the operations needed to fully support access to a TNTatlas by any generic WMS. The original custom operations are all still supported so that TNTserver also still responds to the TNTclients and TNTbrowser. Installing this TNTserver 2005:71 does not alter the way your TNTserver operates with respect to the use of the earlier TNTclients.

Open Client Applications.

TNTmap is an ongoing effort to replace all these older client applications and features with a generic open approach that does not depend upon any of the older TNTserver’s proprietary operations or protocol. TNTserver 2005:71 responds to appropriate client application requests as a WMS and uses the OGC Spatial Coordinate Service, EPSG parameters, and ISO 19111 descriptions. In this fashion it makes your TNTatlas views or the individual layers in your TNTatlas available to any remote client application that properly requests that TNTserver perform the 2, and only 2, mandatory WMS operations. GetCapabilities: give me information about the geospatial layers you have available and their extent, CRS, available format, … or GetMap: I want you to send me this part of this layer you have in the form you indicate that you can.

Once a client application has received an image from a WMS, it can then perform additional local operations on it. For example, TNTmap Viewer will soon be able to make measurements on its view. The more different kinds of things a client application can do locally and separately from a server, the larger and more complex it gets. Gradually it becomes what is often called a “thick client” in contrast to a “thin client”, which may be only a simple viewer of a image retrieved from a WMS. At the moment Google Maps is a relatively thin client. Most of the operations it performs, such as locating the ground site, assembling and sending the map and/or image, and finding a route is performed by the 10s of thousands of Google servers, not by the Google Map local plug-in client application. Google Earth is a “thick client.” It performs most of the operations on your comptuer and the Google servers merely supply images as tiles and GML overlays.

Review of Available Sites.

There is an overview of the penetration of OGC specifications into web sites in the review paper entitled A Survey of OGC Deployment, Dec 1, 2004, by P. Ramsey, 7 pages that can be read at digitalearth.org (...link obsolete...). It summarizes results by the major OGC services, type of server operator, nation of location, number and type of layers, and so on. This is a particularly important review if you really want to grasp how small this OGC movement is at this time. This review will help you understand that almost all the potential lays ahead, thus providing many new opportunities over the next few years, especially in nations just moving from phone access to broad access to the Internet.

As of the beginning of 2005, this review reported that 230 sites proclaimed to support some OGC service with 166 offering a WMS. The author of the review has provided MicroImages with the locations of these sites. From these, MicroImages has compiled a shorter list of about 70 that actually respond to a GetCapabilites Request from TNTmap and have at least some layers that can be retrieved and viewed. You will also find by trying each that many of these sites provide some pretty simple, sparse, sample geodata of limited use. Many others provide basically the same geodata layers that are on the MicroImages’ Global Data DVD in various modified styles. Other sites offer various NASA, NOAA, and other public domain image and elevation data sets. Relatively little unique, high quality geodata content is available from this list. TNTmap automatically provides access to these sites via a drop down list which comes with it and that can be updated from microimages.com.

Introduction.

To expand the use of the TNTserver, MicroImages is adding standard Open Geospatial Consortium services to it as discussed above. As a result your geodata site is no longer restricted to using or modifying our special end user TNTclient and TNTbrowser client applications. These applications will still function as before with TNTserver 2005:71 as long as you have installed and maintained the Tomcat servlet manager for use with the HTML-based TNTclient.

The incorporation of a Web Map Service (WMS) and the other related specifications within TNTserver has generalized its ability to serve up its atlases’ contents. Anyone’s web client or application that can communicate with a generic WMS can now request and use images from a TNTserver as a composite view from a TNTatlas or as individual atlas layers.

It is transparent to a WMS what method, coding language, or use will be made of the images it serves by the client application. A request made to a WMS must be compliant with the standard or it will be refused. Similarly, the remote client application is isolated from the way in which the WMS compliant site fulfills its requests. The WMS can use any geodata engine, complex or simple, free or commercial, as long as it correctly performs the requested WMS operations and provides the image in a timely fashion in the published Coordinate Reference System (CRS).

One way to use a TNTserver is to acquire or create a generic WMS compliant client application from any source. As discussed above, finding one that is not proprietary in some aspect is not as easy as it should be. As a result, MicroImages has created, published, and is improving TNTmap, a generic HTML client application to access WMS images from sites offering a WMS including those using a TNTserver to publish TNTatlases.

Even with the OGC standards, there is still a murky area between the WMS site and the WMS compliant client application. This is when the end user of a client application served for use with a specific WMS has to wander around the Internet to locate other sites that have published that they have WMS content available. As a result to be useful this new TNTmap client application is currently structured in 2 major segments. It provides a TNTmap Builder window to help its end user locate any WMS compliant site, review its contents, and select them as layers. The other segment is the TNTmap Viewer, which performs a similar function as the earlier HTML-based TNTclient. It uses the layers selected in TNTmap Builder to make and present a composite view of the selected layers and provides tools to manage and work with it. TNTmap Viewer can get its content exclusively and directly from TNTserver from TNTatlases and/or can assemble it from various WMSs using the TNTmap Builder. In fact all the layers found and selected in the TNTmap Builder can come from other WMS sites.

Another approach to exploiting TNTmap Builder’s capabilities is to use it to find WMS content, select a layer, prepare a description of the layer in the Keyhole Markup Language (KML), and launch Google Earth, which will then use this KML file to retrieve and image and overlay it at the proper location. The Builder can also save the KML file locally for later online use to create an overlay in Google Earth, or as an XML file for use in NASA’s World Wind geodata browser. Amazon A9, Yahoo Maps, Google Maps, Microsoft’s pending Virtual Earth, and other popular geodata web viewer strategies that emerge can use an expanded Builder to add TNTserver and other WMS public, commercial, or proprietary content in this fashion.

TNTmap and other geodata browsers can only be as effective as the WMS site’s implementation permits. The usefulness of the image data published by a site with a WMS can vary widely. Any site claiming to be WMS compliant must support the two mandatory WMS operations (GetCapabilities and GetMap) and may support the only optional GetFeatureInfo operation. But, how it does this can vary greatly as to reliability, responsiveness, image formats available, CRS supported, hardware used, and even “being up” 365/24/7 can be highly variable. When you go to a WMS site to review its available geodata layers and select one, you can expect a considerable amount of variability in successfully completing that service request. The site may not respond at all because it is not completely WMS compliant, is currently down, or appears to be down because it is very slow due to its current implementation, demand, bandwidth, hardware, … It may not provide transparent PNG (*.png) images thus eliminating the any use of any variable transparency of its features. Gradually, as you try some of the sites listed in the TNTmap Builder, you will learn which sites and layers can be depended upon to be quickly, efficiently, and reliably used and which should be avoided and used only if absolutely necessary.

TNTmap Builder.

TNTmap Builder is designed to help you locate and use WMS layers and subsequently other OGC services published by TNTserver and non-TNTserver sites. TNTmap Builder is a subset of the TNTmap client and is automatically installed with and published for use with a TNTserver. It is also available for direct use and download from www.microimages.com/downloads/tntmips.htm. It is written in HTML and is, thus, open for your modification and use. You use it to browse to web sites offering a WMS, see what they are publishing as images, and select from these images for use as layers in the TNTmap Viewer portion of TNTmap. The Builder provides your browser (Internet Explorer 6, Safari 2, Opera, and Firefox) with the capability to link to any of the known WMSs in the list that MicroImages provides or to any others you may locate. For this reason it might have been named TNTmap Browser, but since the objective of its use is to build up a layer list for viewing in TNTmap Viewer or other applications, its name focuses on this application. Builder permits you to select any site(s) and see the image data they are publishing via their WMS that covers your current area of interest. TNTmap Builder is illustrated on the attached color plate entitled TNTmap: Browsing and Selecting WMS Layers.

TNTmap Builder uses the mandatory WMS GetCapabilities operation to interrogate the selected WMS site to determine what geospatial data it has published and is able to provide. It then presents the name of each layer published for that site in a scrolling layer legend. You can then select a layer and determine its CRS and its extent in that CRS. Its extent is also shown as an outline on an inset world reference image view that can be zoomed in and out. The various types of metadata provided for each layer including its abstract can also be viewed. If the site’s WMS provides images of the legend entries for each layer, they are shown below the layer’s name. For example, TNTmap Builder would show the zigzag road styles for the roads in a vector layer in a TNTatlas in this selection list. It also lets you choose the format the site will provide the image layer in (JPEG2000, JPEG, PNG, GIF, TIFF, …). Using these and other capabilities, you can decide if you are interested in opening the TNTmap Viewer window from the Builder to look at and use the currently selected layers. If you use the Builder to navigate to a TNTserver site, you will see either a TNTatlas view listed as a layer and/or all the layers in the TNTatlas and legends depending upon the choices the designer set up for the TNTatlas. Thus each atlas may appear to be a single layer in Builder’s layer list or a list of groups that can or cannot be opened to review individual layers.

You will immediately find that the FREE TNTmap Builder is useful independently of any TNTserver activity on your part as a means of looking at the content of any and all sites offering a WMS. At this time there are few tools that provide this kind of WMS and subsequently WFS browsing capability. TNTmap is also new and is a “work in progress” so that you can expect it to get new browsing capabilities and become easier to use. If it just had web access to a clearinghouse catalog for WMS compliant servers, it would be even more useful. For the moment this “where are the WMS sites?” service will have to be performed by the site list maintained in the Builder, via MicroImages’ web site, and others independently compiling these kinds of links.

TNTmap Viewer.

TNTmap Viewer is designed to permit you to view and use the images you have assembled in the Builder. TNTmap Viewer is a subset of the TNTmap client automatically installed with and published for use with a TNTserver. It is written in HTML and is open for modification and use. One of its objectives is similar to the earlier TNTclients’ objectives with regard to viewing the TNTatlases published by a TNTserver. However, as is the case with TNTmap Builder with which it is combined, it is not necessary to use any TNTserver content in this Viewer. If you do not select any site hosting a TNTserver in the Builder you will be viewing only geospatial content published by other web sites’ WMSs. TNTmap Viewer is functional in several browsers (Internet Explorer 6, Safari 2, Opera, and Firefox).

The current version of TNTmap Viewer is illustrated in the attached color plate entitled TNTmap: Viewing WMS Layers. It provides a legend panel with toggles to temporarily turn layers on and off. Coordinates are listed for the cursor position. A navigation gadget is provided to reposition the current view up, down, left, … Zoom, Print, Layer Reorder, and other icons are provided. To date development efforts have been focused upon the Builder component. If you can not locate and select layers from a non-TNTserver, then the TNTserver’s support of the WMS would be only to provide maps and images to other client applications. This, however, can be quite important as its first primitive uses with Google Earth will illustrate. However, gradually more features are being integrated into this Viewer from the HTML-based TNTclient and soon the measurement tools will be available.

Using Google Earth.

Controlled by TNTmap Builder.
Google Earth provides another client application that can be used to view and use geospatial layers from a public or private web site, such as a TNTserver 2005:71 or some other WMS. However, you can not request the use of layers from sites via their WMS unless you can find and select them. TNTmap Builder can be used as described above to do this for Google Earth. After the Builder has been used to locate one or more suitable geodata layers of interest, they can be used as overlays in a 3D view in Google Earth.

TNT Builder has a “Launch in Google Earth” icon. When this icon is clicked the layers you have selected for use in TNTmap Viewer automatically launch your local Google Earth client application which retrieves these layers, zooms to their location, and overlays them on its base imagery all in a few seconds. Every WMS must respond to a request for its layers in at least WGS84/latitude and longitude, which is the CRS that Google Earth uses. When you use this Launch icon, the metadata required by Google Earth is converted by TNTmap Builder to a KML file. This file, including the network locations of the layers, is then used to launch Google Earth. Google Earth uses this file’s content to contact and request the layers in latitude and longitude. It then zooms to the approximate extent of the largest of these layers and overlays them on its standard 3D view. If they are transparent, as can be the case with vector layers converted to PNG images, the Google Earth base image content shows through.

Once Google Earth has constructed its view, you can toggle these layers on and off and perform all the other operations with them as overlays. If you zoom in or change the view, Google Earth will recontact these WMSs and retrieve new layers of the appropriate new resolution. The actual content of these layers may change as you zoom in, for example if the layer is from a TNTatlas it may change completely or alter its features according to the links or scale range settings in the atlas. A few other WMS sites also offer some form of scale range control of the content of a layer.

Saving a Viewing Context.
Google Earth’s File menu provides a Save As option. Once you have used TNTmap Builder to design a set of overlay layers from TNTserver and other WMSs, you can use this option to save this design as a viewing context in a KML file on your hard drive. You can save as many different KML context files as you like for various special overlays of WMS layers for viewing in Google Earth. Later, when you select a KML file it will open Google Earth and zoom into the saved view including reconnecting and fetching the layers being used when the context was saved. You can then proceed as if you had just used TNTmap Builder to set up the Google Earth viewing context. This KML file can even be sent to someone else who can use it to open their Google Earth, fetch the WMS layers, and manipulate the same viewing context as you created. The context can even be provided for use as shared context or “bookmark” via the Internet.

Use Save As in Google Earth to save your multilayer WMS reviewing context set up in TNTmap Builder as a KML file. Use this file later to open Google Earth and reconstruct and continue using this viewing context.

Example of Use.

Using TNTserver’s WMS support to automatically add a vector geodata layer to Google Earth is illustrated in the attached color plate entitled TNTserver: Using Google Earth as a Client. In this plate TNTmap Builder has been used to select the floodplain vector object from a TNTserver hosting the Lincoln Property Viewer Atlas you received on DVD as part of your TNT 2004:70 hardcopy release kit. Google Earth is launched from its icon in the Builder with this layer selected. The Builder launches Google Earth by sending it the KML description that identifies that this image is availalble from the TNTserver. TNTserver responds by converting all or the requested portion of this vector layer to an image of the requested extent and sending it to Google Earth in the WGS84/latitude and longitude CRS. Since this is a vector object in the TNTatlas, it is scaleable and its geometric elements as viewed in Google Earth will be refined as you zoom in. As you know, the conversion from geometric objects to rasters, or images as they are called by a WMS, is built into a TNTatlas. Also, any conversions of layers from one CRS to another are automatic in a TNTatlas.

When Google Earth is launched by the Builder with this local floodplain layer it zooms to that layer’s extents, which is the Lincoln, Nebraska urban area. It then automatically overlays this floodplain boundary layer using its individual polygons’ partial transparency preserved in the PNG (*.png) image format that you specify. It happens that Google Earth’s base image of the Lincoln area is the same higher resolution 1-foot color image as provided in this TNTatlas via the TNTserver. Thus it is not necessary to select this image layer in the TNTmap Builder. You can then proceed as you choose in Google Earth to use this custom addition to its world. An additional Lincoln hotel locater layer available from Google is then added.

The final composite view in this color plate illustrates how the worldwide base images and collateral data provided by Google can be customized with a locally important floodplain layer that is not likely to ever be available from Google. It also illustrates how points of interest relative to these floodplains can be added from Google or a TNTserver. These kinds of local layers may even be proprietary and require access to a TNTserver via a Virtual Private Network (VPN). As described, this floodplain layer is supplied via the WMS feature of TNTserver 2005:71 to Google Earth as a transparent PNG image overlay. However, developments in TNTserver and TNTmap are now moving forward to support OGC’s Web Feature Service (WFS) and more of Google’s Keyhole Markup Language (KML). This will enable the TNTserver to provide and interact directly with contents and attributes of the TNT geometric objects requested by TNTmap, by Google Earth, and others.

The Land Viewer, Nebraska Statewide TNTatlas is also being published via the TNTserver. TNTmap Builder can be used to select its 200:1 JPEG2000 compressed image coverage of all of Nebraska. When this layer is selected and projected into Google Earth, its 1-meter opaque image overlays the much lower resolution Landsat base image provided by Google Earth for any zoomed in Google Earth view of rural Nebraska.

Google Earth is only available for use with Windows 2000 and XP. Those of you still using 98, ME, and NT are simply going to have to give up and upgrade as these older versions are restricting your access to important new geospatial software developments, such as Google Earth, TNT Explorer, and TNTsim3D. Alas, Google Earth is not yet available for Mac OS X. However, Google Earth’s download page notes that this version is currently being developed.

Generic WMS Clients.

One goal of moving TNTserver to support ISO and OGC standards is to permit sharing technology for building client applications. Client applications that are built using HTML are essentially in the public domain since it easily captured, read, and recycled. Alas, there are few generic client applications that can run exclusively with content from any Web Map Server. The strategy of those who sell geodata servers appears to be building a product that supports the OGC and ISO standards but adds additional proprietary options. The site will cooperate and serve up its WMS images to other visiting client applications. However that vendor’s client application uses their extended protocol to add features and to make it difficult to use the client application without it. Thus, in effect the client is slaved to that vendor’s geodata servers.

You may recall that MicroImages previous TNTserver products did not support the WMS operations. Thus client applications, the HTML- and Java- based TNTclient and TNTbrowser, could only work with a TNTserver. The new TNTmap implementation is being designed to run independently of TNTserver. It does not require access to any TNTserver in order to use images accessed from other Web Map Services and subsequently with Web Feature Services. MicroImages is focusing it commercial interests on a low cost, standards based TNTserver and the use of TNTmips to prepare and assemble the TNTatlases so easily installed in it.

There are generic versions of client applications that will run independently with geodata from other sites. Two of these are illustrated in an attached color plate entitled TNTserver: Using a Third Party WMS Client. Both of these client applications display the same TNTatlas content acquired exclusively from a TNTserver WMS site. The results appear just as they would in a TNTmap Viewer. One of these is a stand-alone client, which can be downloaded from Cadcorp at www.cadcorp.com/products_geographical_information_systems/map_browser.htm and provides several interesting features and tools. The other is from Intergraph at www.wmsviewer.com/main.asp and runs from their site but can use WMS results exclusively from TNTserver and/or other WMS compliant sites.

What is again peculiar is that the Open Geospatial Consortium has not made available benchmark client applications for their WMS, WFS, and other approved operations. These could be designed to provide basic functionality for each of these services and thereby serve as a sort of certification procedure. In other words, if you could access and use a WMS site’s content with this basic viewer, then the site is functional. Perhaps they felt this would be interfering with commercial interests. Clearly it’s the nature of this business that client applications are eventually going to be free or very low in cost even if they have extended functionality associated with a specific geodata server. MicroImages clients were and are free; Google Earth, Google Maps, Virtual Earth client applications are free, the clients noted above are free, even those using special protocols of a specific commercial geodata server are free. There would not be complaints from commercial vendors if OGC provided benchmark test clients. It would be a means of policing sites which claimed to be WMS, WFS, etc. compliant. It would further the idea of using their standards by making any standard server have immediate basic utility.

Some Technical Considerations.

Latitude/Longitude Only.
At the present time Google Earth does not deal with transforming Coordinate Reference Systems. Google’s KML requires images, points, lines, … expressed in WGS84 latitude and longitude in decimal degrees and an optional altitude in meters above sea level and projects these to a simple cylindrical or Plate Carrée projection. Thus Google Earth will only use image content from a WMS or other image server that provides it in the required latitude and longitude CRS. Converting content between CRSs, such as from UTM to latitude/longitude, is the responsibility of the web site providing the WMS and WFS. This is one of the strengths of TNTmips and, thus, TNTserver. However, providing this conversion is not the job of the TNTmap Builder at the client location. Thus if the TNTmap Builder is used to acquire an image(s) for Google Earth from some non-TNTserver, make sure that its WMS provides access to the image in the appropriate latitude/longitude coordinates.

There is another web concept that can be implemented in TNTserver where it would act as a proxy for the less capable WMS and WFS sites. In this context TNTmap Builder would locate WMS content published on any site in any of the 1000s of TNT supported CRSs. It would then request that this content pass through a TNTserver to convert its CRS to those required. This might be latitude, longitude, and meters or any other CRS that is required by the viewer using TNTmap Builder, such as Google Earth, TNTmap Viewer, … This cascading service for OGC compliant geodata sites will be implemented in TNTserver as needed.

Using Geometric Objects.
As described above, you can use TNTmap Builder to open Google Earth adding any appropriate image layers into the Google Earth view. If the WMS layer is available in PNG (*.png) format with transparency, it will be overlaid using this characteristic. When you access a TNTatlas layer(s) or a composite atlas view as a layer, TNTserver will provide the result as you specify for that layer in the Builder. At present image layers supplied via TNTserver in response to a WMS request can be PNG (*.png), JPEG (*.jpg), or JPEG2000 (*.jp2). Google Earth will accept images in PNG, JPEG, GIF, and TIFF (*.tif). A site’s WMS can only supply these image formats to Goggle Earth. All TNTatlas views served up by TNTserver 2005:71 are composite images or SVG. Thus a TNT geometric layer can be used in Google Earth when it is requested from a TNTatlas. TNTserver will do this automatically for all TNT geodata objects and combinations of objects (raster, vector, CAD, shape, or database) by converting them into a raster and sending them as a transparent image overlay in PNG format. This is illustrated by the floodplain layer in the attached color plate entitled TNTmap: Using Google Earth as a Client. These geometric objects can even be used in the TNTatlas in their original shapefile, DWG, DGN, or other native spatial graphics formats; from native raster formats such as MrSID (*.sid), ER Mapper’s ECW (*.ecw), JPEG2000 (*.jp2); or from databases such as Oracle Spatial and Access since TNTatlas handles converting all these for any extent to a composite image. Alas, Google Earth plus in is not available for all browsers especially for Apple’s Safari.

One of the key features of most of these WMS sites is that they host and deliver individual layers. Thus the idea of delivering a composite of many layers of differing types, such as a TNT layout or group is not available. Often this is because they are the primary creators of this geodata and use the WMS to make it available to the public for other uses. The result is most WMS sites publish only a few layers of a specific geodata type. Internally to their sites these layers may be made up of 100s or 1000s of tiles functioning as a virtual mosaic covering a large area but with a single content. TNTatlases can have many layers and a TNTserver can host many different TNTatlases. Someone else’s WMS client visiting a TNTserver may wish to select a specific layer from an atlas or simply select the composite atlas result for the area requested. Provision has been made in TNTserver for this.

TNTatlas 2005:71 for X

TNTfreeview.

TNTatlas is now a point and click viewer. A mouse click or “Open File” action can open TNTatlas to view and use any supported spatial data file, hence TNTfreeview.

The major section below on System Level Changes in TNTmips contains important developments that significantly improve the utility of TNTatlas as a FREE, stand alone viewer of geodata (TNTfreeview). TNTatlas can now be automatically opened on a Windows or Mac OS X computer that has no other TNT product installed by a mouse click or “Open With” action on any raster, CAD, vector, shape, or other spatial data that is supported by the TNT products. These familiar actions will start the X server, start TNTatlas, and add the selected object into the view as spatial data (in other words, an unknown earth Coordinate Reference System) or as geodata if the earth CRS can be detected or is supplied by the user. During startup, pyramiding can be optionally added for large files in older, flat raster formats such as JPEG files, to speed up their subsequent use. Once TNTatlas has opened a view of the file all its interactive geospatial analysis capabilities are available: measurements and sketching; feature and attribute selection; DataTips, GraphTips, and new feature mouseover events; feature links to a URL; region analysis; GPS input, your tools using fully interactive Tool Scripts, or other geospatial analysis (SML) script structures using dialogs.

TNTatlas is FREE software and has no size limitations on the single layer. It can directly open and use huge JP2 and MrSID rasters, pyramids large JPEGs for faster use, handles large shapefiles, and others when used as a TNTfreeview. It uses the spatial data file as geodata if its ISO standard Coordinate Reference System is known. Now auto-opening the layer directly from common spatial data file formats listed in the next paragraph or from a TNT Project File containing a single object, group, or map makes TNTatlas the most powerful FREE viewer and analysis tool available for use with geodata. Auto-opening from these files means that it no longer requires learning the TNT’s layer selection and layer control procedures after startup to access a single layer, hence its expanded use as TNTfreeview. Now the TNT Project File structure and use of an X server effectively disappears when TNTatlas is used as TNTfreeview with the distribution of your geodata. There are many other free viewers, but they do not satisfy important geospatial uses (in other words, large files, pyramided access, RDBMS access) and analysis (measurement, selection, …). However, as in the past, if TNTatlas is used as TNTfreeview, in other words, independently of an atlas file or Project File, it is limited to the use of a single layer at a time. For more complex visualization and analysis multilayers you will still need to use the low cost TNTview or use TNTmips to build and distribute the geodata as an atlas.

The auto-open of TNTatlas as TNTfreeview is available for Windows 2000, 2003, and XP and Mac OS X 10.3.x and 10.4.x. If you are using earlier versions of Windows (98, ME, or NT) the auto-open operation is not available. TNT Project Files with a single layer, group, or layout can be auto-opened. The common spatial data file formats that can auto-open in a view in TNTatlas are the same as those that can be used for a direct links in the other TNT products as follows:

as shape objects: ESRI shapefiles (*.shp) and Oracle Spatial Layers;

as raster objects: TIFF (*.tif), GeoTIFF (*.tif), JPEG2000 (*.jp2), JPEG (*.jpg), PNG (*.png), MrSID (*.sid), and ER Mapper ECW (*.ecw); and

as CAD objects: MicroStation DGN (*.dgn), MapInfo TAB (*.tab), AutoCAD DXF (*.dxf), and AutoCAD DWG (*.dwg).

Land Viewer.

Run Completely from DVD.

The sample TNTatlas described in the attached color plate entitled TNTatlas: Nebraska Land Viewer Atlas illustrates again how a common TNTatlas file structure can be used on a DVD in both Windows and Mac OS X. It will auto-start in Windows if it your preference settings permit this and run completely from the DVD. Mac OS X does not permit any auto-run from a CD/DVD so on a Mac, you need to double click on the TNTatlas icon. This will then run everything from the same DVD if X11 is installed as part of the Mac OS X. If the optional X11 X server was not installed from your original Mac OS X CDs, then you will be prompted to exit, install X11 from those CDs, and then restart your installation of TNTatlas.

Note that the current language conversion kits are also on this DVD so that the user interface can be switched to any supported language by choosing Options / General in the TNTatlas view window. This does not change the language used in the atlas content such as DataTips, labels, and so on, which will still be English. However, the content of an atlas can be built in any language supported by the TNT products.

Installed for Faster Performance.

This sample DVD also illustrates how you can set up a TNTatlas so that it can be installed on a hard drive for faster performance. Separate TNTatlas installation packages are also on the DVD for both the Windows and the Mac OS X versions. The Windows version uses InstallShield and automatically handles the installation of the necessary MicroImages X server. The Mac OS X version uses the common Installer VISE program now also used to install all the TNT analysis products. You may or may not have the Apple X11 server installed. If you already have some TNT products installed on the Mac, this X11 is already available. If you do not, you will be notified of this when you attempt to run the TNTatlas software and will be directed to exit, locate your original Mac OS X installation disk, and to install X11 from it. You can then run your TNTatlas software using Apple’s X11.

Both these commercial installation programs require that whatever they are installing be packaged into their format. This means that the TNTatlas software for Mac OS X and Windows is on the DVD twice—once for direct operation from the DVD and once within the installer package. To use these same installers to install the atlas data content and reference materials would mean that they would also have to be duplicated and of course they are too large and thus only occur once on the DVD. After you have installed TNTatlas, you will need to locate these materials and copy them onto your hard drive. See the Installation Help file on the DVD if you have any problem locating and completing this part of the installation.

More information on the content of this sample TNTatlas is presented in the attached color plate entitled TNTatlas: Nebraska Land Viewer Atlas and the major section above in this MEMO titled Land Viewer. The section below titled Raster Mosaic discusses in detail how the 724 GB image on this DVD was prepared.

Access Via a Web Map Service.

Keep in mind that the TNTserver 2005:71 can use an unaltered TNTatlas to present its composite views or individual layers over the Internet to any Web Map Service (WMS) compliant client application. As a result this new Land Viewer: Nebraska, Statewide atlas and the earlier Property Viewer: Lincoln, NE atlas can be accessed from TNTserver 2005:71 using any WMS compliant client application and combined with rasters requested from other sites offering a WMS. Soon all the many other TNTatlases currently accessible via the previous version of TNTserver will be moved to the drives used by TNTserver 2005:71.

TNTmap is a new MicroImages WMS-compliant client application being developed for FREE use with any WMS and is discussed in the previous major section titled Introducing TNTmap 2005:71. Two other FREE WMS client applications, which can use these TNTatlases, are those from Intergraph and Cadcorp and are also discussed in then same section under the subtitle Generic WMS Clients. MicroImages TNTmap goes even one step further than these other generic client applications. It permits you to acquire a view or layer from any WMS, including these atlases from the TNTserver, and then overlay these rasters into Google Earth and use all its functionality to manipulate them.

Inherited New Features.

TNTatlas 2005:71 inherits many additional powerful new features from changes to general TNT processes that it automatically uses. The most significant of these are highlighted here and all are explained in greater detail in the corresponding sections below for TNTmips 2005:71.

2D Display.

Separate 32-bit cache buffers are created in real memory for just the area of each layer in the view. By using these buffers, all layers in the view can now be instantly toggled on/off, moved up or down in order, deleted, toggled in View-in-View, automatically used in element select and unselect, and any other operation that does not reposition the view. New layers can also be added much faster to an existing composite view. This is very significant if the atlas is being run from a CD or DVD! It eliminates the many read actions used previously on these slow media to provide these features!

The color of the layer name in LegendView now indicates why that layer is not visible as follows: gray = toggled off, green = off by scale, blue = off by extent, and red = layer has changes. Black indicates it is on in the view but it may still be obscured in part or all by an opaque raster layer above it in the layer list. An option now controls whether or not legend styles are merged.

Shapefiles using theme ranges can now be directly viewed.

Components of symbols can now be partially transparent to let the underlying features show through.

The area tools in the GeoToolbox can be used to turn groups of layers on and off. For example, turn on just those objects in a hidden group of 100s of images making up a virtual mosaic that are contained in a rectangle or polygon. This is called “Area-of-Interest” selection in other products.

3D Display.

Extensive new features are provided in 3D displays.

Only the variable triangulation terrain model is now used, providing faster, high quality, accurate rendering.

LegendView is now available and works just as in 2D display providing many features including all the familiar layer controls. Geometric layers are now rendered into the view and using LegendView can be toggled on/off reordered, turned off, added, and so on.

DataTips are now shown just as they are defined and used in 2D views: in other words, computed fields, GraphTips, and so on.

Styling of geometric elements is the same as in 2D views and has good perspective depth effects. Labels defined in the layer or during the view can be draped on the surface.

Limited solid shapes of spheres, cubes, and pipes can be rendered anywhere in the view for a 3D geometric object.

TNTsim3D™ for Windows

There has been limited feedback from you with regard to the features or your specific applications of TNTsim3D. As a result the new features added to this process are those that occur to the staff at MicroImages. It is likely that some of the intensive past development efforts in this product will be shifted to other processes until it is clear how and if TNTsim3D is valuable and widely used.

Simulations with Manifolds.

The spatial relationships in a complex combination of topographical surface features and 3D manifold structures can be difficult to grasp when viewed only in static 3D views. As a result manifolds can now be viewed and manipulated in real time in TNTsim3D along with their interrelated topographic surfaces. Manifolds can be added to your simulations to depict cross-section, planar, or curving profiles in any orientation or to outline 3D volumes. You can then use your joystick or other control devices to move around, over, under, and into these simulated structures. The attached color plate entitled TNTsim3D: Manifolds provides a snapshot view of a variety of manifolds and topographic surfaces being manipulated in TNTsim3D.

Several additional capabilities have been added to TNTsim3D to further enhance your abilities to visualize complex manifold structures. Your simulations can be viewed in real time in stereo so you can use your control device to manipulate the complex structure and view it with depth. If you would like to replicate your interactive viewing of the manifolds, you can record your actions as a path using a geospatial script. The path can then be smoothed and used to generate a movie of that simulation that can be distributed to anyone for playback, and they can see the same results. A script has been used for this purpose so that you can modify it to compute a prescribed path around and through your simulation rather than simply record your manually-flown path. For example, you may simply want a path that appears to slowly rotate the structure or one that moves the position of the viewer vertically up and down on an arc while maintaining a fixed viewpoint in the structure. The format of the path and view direction record used in this script is also simple so that it can actually be prepared from some other geodata source by another TNT geospatial script or by other software.

The TNTsim3D Landscape Builder window now provides an Add Manifold button to add these layers to the Landscape File you construct for use in your simulation. It automatically uses the 3D georeference information stored with the original manifold object to create an optimized triangular mesh used for this surface in TNTsim3D. This mesh is used to access and intersect raster tiles in pyramided raster objects, providing for fast display of manifolds in your simulation. For more background information on the use of manifolds in the TNT products please see the detailed section on this topic in the TNT 2004:70 release MEMO at www.microimages.com/relnotes/v70/rel70.htm#_Toc93828714 and/or the 7 associated, illustrated color plates on using manifolds at www.microimages.com/documentation/html/version/2004_70.htm.

Simulations in Stereo.

TNTsim3D now supports the use of anaglyph, line-interlaced, and column-interlaced stereo viewing devices for all the views in your simulation. It creates a set of stereo pairs for each frame in each view window open in your simulation by computing views from each of 2 separate viewpoints. These pairs are then combined in each view window to display real time simulations of the scene for viewing in stereo. In the anaglyph mode, the red color channel is rendered from one of the pairs, and the blue and green (cyan) values are rendered from the other. The attached color plate entitled TNTsim3D: Stereo Viewing illustrates a Main view and Right view from an anaglyph simulation. Note that stereo occurs only in the viewing area of each view window and not in the control portions, other dialogs, or other areas of the monitor.

Selecting the line- or column-interlaced mode uses your video card’s stencil buffer to mask out every other line or column in this view. It draws every even numbered frame line or column from the first of the two images, and renders every odd numbered line or column from the second. Frame buffers and the hardware acceleration of your graphic card are also used in displaying all simulated views so that stereo has only a minor impact on the frame rate of a simulation. The same color plate illustrates a portion of a stereo view in both of these modes.

Smoothing Recorded Flight Paths.

The ability to record flight paths via a geospatial script was available in TNTsim3D 2004:70. That initial Flight Recorder script included recording, playback, and looping capabilities, as well as the ability to save the recorded flight path for use in a later session. On-screen controls for these actions were presented in a dialog created and opened by the script. The new Advanced Flight Recorder script expands upon those basic capabilities and controls by adding options to smooth the recorded path and to record a movie from a path during playback.

A path you record while flying using joystick or keyboard controls might include unwanted or too-abrupt changes in direction. You can use the path-smoothing options in the Advanced Flight Recorder to smooth out these abrupt changes in the recorded path for later playback or movie-recording. The path-smoothing procedure thins and then splines the recorded 3D path of the observer position to round off sharp corners but leave straight portions of the path unchanged. The view direction associated with each observer position (the view axis of the Main view) is also recreated during this procedure, using a specified number of previous and upcoming path positions to provide a smooth change in view direction through turns. An additional optional procedure can be applied to these view directions to provide more smoothing if desired. These smoothing procedures can be applied one or more times to the path until you achieve the desired degree of smoothing. The attached color plate entitled TNTsim3D: Smoothing Flight Paths provides more information on the smoothing procedure along with 3D views of a flight path before and after a single smoothing pass. The reverse side of this plate excerpts the portion of the script that smooths the flight path.

Recording a Movie.

The new Advanced Flight Recorder script also provides the option to record a movie from your simulation in TNTsim3D. New functions added to TNTsim3D now allow a script to capture a simulation frame for use with the existing movie classes in the TNT geospatial scripting language (SML). After you record a flight path (and optionally smooth it), you can play back the path in the Create Movie mode, which transfers each frame rendered by TNTsim3D to an MPEG or AVI movie file that can be played back on any computer. You can select the frame rate to embed in the file to control playback and also choose from among a number of standard codecs (short for Compressor/Decompressor) to reduce the size of the movie while maintaining quality.

Recording a movie from a flight path takes significantly longer than simply flying the same path because of the processing and compression required for each frame. Thus it is not possible to simply record a movie in real time while flying in TNTsim3D. However, after this one-time recording step, the resulting movie will play back at your selected constant frame rate. During movie recording you should set the TNTsim3D Terrain options to maximize terrain quality (rather than maintain constant frame rate) to reduce "breathing" of the terrain (changes in level of detail) from frame to frame. Although this option will increase rendering time during recording, it will not affect the playback speed but will produce a higher-quality movie. Further details and excerpts of the movie-making portion of the Advanced Flight Recorder script can be found on the attached color plate entitled TNTsim3D: Making Movies.

Custom Views.

TNTsim3D lets you open one or more Custom View windows that give you control over the position and direction of each individual view. In TNTsim3D 2004:70 the viewer position in a Custom View was constrained to lie along the current direction of flight (the axis of the Main view). You could offset the Custom View’s viewer position forward or backward along this direction of flight and set the yaw, pitch, and roll angles to determine the direction of the Custom View. In the TNT 2005:71 release of TNTsim3D, Custom Views provide you with much greater control and ease of use, as detailed on the attached color plate entitled TNTsim3D: Custom Views from any Angle/Position.

Custom Views now provide two separate viewing modes: Orbit and Offset. The new Orbit mode always looks at the same point on the terrain surface as the main view, but an Angle setting lets you look at it from different positions on a horizontal orbit. Using multiple Custom Views with the main view can thus give you several simultaneous views of the same terrain position from different angles, all of which are continuously updated as you fly through the simulation.

Use the Offset mode to direct a Custom View to look at a different terrain position than the main view. The controls in this mode set the Custom View’s viewer position and view direction relative to those of the main view. The familiar view-direction angle and forward-backward offset settings are now supplemented by vertical and lateral offset settings. Using these settings, a Custom View can be positioned and oriented anywhere relative to the main view position and flight direction, and these relative settings are maintained throughout the simulation.

Custom Help Dialogs.

When you use the TNT products to prepare a Landscape File for distribution as a FREE TNTsim3D, you can now take proper credit for your creative efforts. You can add text objects to your simulation that include information about their authorship and general information about the landscape, credit sources of spatial data, provide instructions for using accompanying scripts, and so on. Simply use the TNTmips Text File Editor to create or open the desired text and save it as a text object in the appropriate Landscape File. The name of each text object in the file is automatically shown as an entry on the Help menu when the simulation is opened in TNTsim3D, and the associated text is shown in a separate window when its menu entry is selected. Any additional information you provide in this manner is automatically accessible to anyone during the operation of the simulation in TNTsim3D. A splash screen crediting MicroImages as the source of the TNTsim3D software is shown when the software is loading. A provision for you to add to this screen or add your startup promotional splash screen can be added if you need it.

Special Geospatial Scripting Features.

Several additions have been made to the geospatial scripting language (SML) specifically to extend the usefulness of scripts in TNTsim3D. These modifications are discussed here to acquaint you with their special use in customizing your simulations.

SetStatusText.

This class method allows the script to display text directly on the status bar of the main view, reducing the need for popup messages or external windows to display information from the geospatial script. This permits information to be communicated to the user of the simulation without impacting its frame rate.

OnControlActivate.

This is a function you can include in a script to define the special action to be taken whenever any flight control (keyboard key, joystick movement or button press) is activated. This function is most useful with scripts that are designed to fly a prerecorded or computed flight path, such as an orbit. For example, a startup script could open the simulation by automatically flying an orbit around a predefined location. You could have the script turn over flight control automatically to the user by having this function stop the programmed flight and exit the script the first time the user activates any flight control.

TNTview® 2005:71

Inherited New Features.

TNTview 2005:71 provides the following new features described in greater detail in the corresponding sections below for TNTmips.

System Changes.

AutoCAD DWG and DXF files and MicroStation DGN files can now be directly viewed. During linking or importing they can be optionally converted to geodata by entering their Coordinate Reference System (CRS). You are prompted to enter this optional CRS information during linking. After linking or importing these CAD objects can be georeferenced to convert them to geodata.

Currently TNTview can link to external spatial data files with the following extensions:

as shape objects: ESRI shapefiles (*.shp) and Oracle Spatial Layers;

as raster objects: TIFF (*.tif), GeoTIFF (*.tif), JPEG2000 (*.jp2), JPEG (*.jpg), PNG (*.png), MrSID (*.sid), and ER Mapper ECW (*.ecw); and

as CAD objects: MicroStation DGN (*.dgn), MapInfo TAB (*.tab), AutoCAD DXF (*.dxf), and AutoCAD DWG (*.dwg).

Left clicking on any of these files will automatically open TNTview to view that file if its extension is registered to TNTview in Windows or Mac OS X. If some other product has control of that extension and you do not want to assign it to TNTview (for example, *.jpg), then use “Open With” from the menu or right mouse button menu to choose or browse to and choose TNTview as the application to use with that file. Project Files (*.rvc) are automatically registered to TNTview during installation and selecting one will also open TNTview showing the first group, or map layout in the file.

You are using more and more irregularly bounded compressed raster objects surrounded by null areas. Now these and any other uniform tiles in the raster object are greatly compressed by recording only the tile position and the single value in it. This compresses null masks to a very small size.

Geodata objects that span the globe and contain the poles are now reliably displayed.

TNT Explorer for Windows XP and 2003.

Windows Explorer is introduced at Wikipedia.org as follows.

“Windows Explorer is an application that is part of modern versions of the Microsoft Windows operating system that provides a graphical user interface for accessing the file systems. In brief, this is the component of the operating system that is displayed on the monitor and enables the user to control the computer. It is sometimes referred to as the Windows shell because it is the component that is visible to the user and allows the manipulation of functions that are ultimately executed by the kernel of the operating system.”

“In Windows XP, Windows Explorer is significantly different than in previous Windows versions; by default, the Luna interface is used but can be turned off if desired” [Luna is the new Windows interface introduced in XP.]

TNT Explorer uses the same functions as Windows Explorer to automatically make all Project Files look and behave much like native Windows folders. All the features explained in detail below and provided by TNT Explorer for Windows are available in TNTview. Project Files automatically become TNT folders on the Windows desktop. They can be opened with the left mouse button and modified with the right mouse button: rename, delete, … An open TNT folder shows all the primary and linked objects in it as if they were documents in a Windows folder in the optional window formats: icons, list, details, thumbnails, or tiles. A right-click on any of these TNT objects provides a pop-in menu of operations that can be applied to the TNT object, such as open in 2D Display or in the Spatial Editor with this file in the view, add it to an already open view, rename, delete, show properties (as in Project File Maintenance) and so on.

2D Display.

Separate 32-bit cache buffers are created in real memory for just the area of each layer in the view. For example, a view of a virtual mosaic with 256 DOQQ orthoimages would have 256 buffers each totaling up to the size of the view. A vector overlay would occupy another buffer the size of the view and so on. By using these buffers, all layers in the view can now be instantly toggled on/off, moved up or down in order, deleted, toggle View-in-View, element select and unselect, and any other operation that does not reposition the view. New layers can be added much faster.

The color of the layer name in LegendView now indicates why that layer is not visible as follows: gray = toggled off, green = off by scale, blue = off by extent, and red = layer has changes. Black indicates it is on in the view but it can still be obscured in part or all by an opaque raster layer above it in the legend list. An option now controls whether or not legend styles are merged.

Shapefiles using themes ranges can now be directly viewed and the theme ranges can be edited.

Symbol components can now be partially transparent to let the underlying features show through.

Line intersections are improved by optional multipass rendering, for example, intersecting double-line roads now join instead of overlap.

The area tools in the GeoToolbox can be used to turn groups of layers on and off, for example, turn on just those objects in a hidden group of 100s of images making up a virtual mosaic that are contained in a rectangle or polygon, the so called Area-of-Interest” selection.

3D Display.

Extensive new features are provided in 3D displays. Only the variable triangulation terrain model is now used providing faster, high quality, accurate rendering. It will display multilayered views from any viewpoint in 5 to 10 seconds if the Triangulation Property Raster subobjects are computed during the import of the elevation raster. If not, then they will be automatically computed for the first view making it slower and then automatically used for any other viewpoint setting.

LegendView is now available and works just as in 2D display providing many features including all the familiar layer controls. Geometric layers are now rendered into the view and can be toggled on/off reordered, turned off, added, and so on.

DataTips are now shown just as they are defined and used in 2D views: in other words, computed fields, GraphTips, and so on.

Styling is the same as in 2D views and now with good perspective depth effects. Lines are styled. Symbols are rendered and can have transparent effects. Polygons can be partially transparent, hatched, bit map filled, or use a new partial interior buffer fill that can also be transparent.

Labels defined in the layer or during the view can be draped on the surface.

Limited solid shapes of spheres, cubes, and pipes can be rendered anywhere in the view for a 3D geometric object.

High quality movies can now be made using this new rendering method. The path can be defined by a vector and the other means previously available in the older rendering methods that have been removed.

Importing Geodata.

DWG, DXF, and DGN CAD files can be imported. The new raster formats that can be imported are: ERDAS files greater than 2 GB; Nikon, Ricoh, and Kodak digital camera proprietary files; JPEG files from digital cameras using the EXIF standard; and NetCDF. Tiger 2003 and 2004 files can be imported to vector objects. Access files can be imported as relational structures using their schema.

Reference Materials.

Both of the new tutorials provided with this release concern operations that can be conducted in TNTview. These are Understanding and Maintaining Project Files and Coordinate Reference Systems. The additions and changes to the booklet Introduction to Map Projections also are applicable.

Upgrading TNTview.

If you did not purchase version 2005:71 of TNTview in advance, and wish to do so now, please contact MicroImages by FAX, phone, or email to arrange to purchase this version. When you have completed your purchase, you will be provided an authorization code by FAX. Entering this authorization code while running the installation process allows you to complete the installation of TNTview 2005:71.

Fixed License.

The worldwide prepaid price for a minimum of 2 or more future upgrades for TNTview will be $50 per each version plus shipping. For example, purchasing your upgrades now from 2005:71 to 2005:72 and to 2005:73 will be US$100 plus the estimated cost of shipping each of these 2 upgrades by air express.

Upgrades from any current version from any earlier version (2005:70 or earlier version) is US$200 which includes shipping by air express.

Floating License.

The worldwide prepaid price for a minimum of 2 or more future upgrades for TNTview for each seat will be $60 per each version plus shipping. For example, purchasing your upgrades now from 2005:71 to 2005:72 and to 2005:73 will be US$120 per each seat (each seat is 1 concurrent user), plus the estimated cost of shipping each of these 2 upgrades by air express.

Electronic Delivery Only.

Depending upon where you are located, shipping physical materials to your site by air express can be an expensive part of this low cost upgrade. If you wish to upgrade your TNTview by only downloading it to avoid this shipping cost, simply request this and only the upgrade authorization code will be sent to you.

TNTedit™ 2005:71

Inherited New Features.

TNTedit 2005:71 provides all the new features summarized just above in the section Inherited New Features for TNTview. The following additional new features not available in TNTview are summarized here for TNTedit. All these new features in TNTedit are discussed in detail in the corresponding sections below for TNTmips.

Georeferencing.

A conformal warping model has been added to the existing list of other optional models. This shape-preserving model allows rotation, scaling (same for both axes), and positioning while preventing distortion of features due to shear or differential scaling of each axis.

Editing.

For Windows XP and 2003 on a TNT object in the new TNT folder with the right mouse button and choose that it open TNTedit ready to be edited.

Using the new separate layer buffer only the layer being edited is refreshed. Now, when you draw into the special layer buffer created for your editing activity, it can be altered to erase the trace of an element almost instantly. This layer is simply adjusted and recomposited with the composite layer buffer for the view to refresh the display. It is no longer necessary to use a redraw to erase all traces of a deleted element(s) in a current view.

Moving a label outside or away from its element may create a leader line that is long and unsightly. A toggle is now available to suppress these leader lines in the Text Label Edit Controls (Add Leader Line When Label Is Moved From Element).

Validation of the topology of a vector object is faster.

Style object can now be set up to be shared or embedded into the object.

Export.

Raster objects can be exported to MrSID files using a LizardTech data metering cartridge.

Scripts.

TNTedit does not provide the TNTmips image analysis processes. However, the new multispectral image calibration analysis processes are SML scripts, which can be used in TNTedit. These include calibrating Aster, Landsat, QuickBird, and Ikonos multispectral images to ground reflectance adjusted for terrain effects. A new algorithm can be used on these multiband reflectance values to more accurately map the surface’s biophysical properties of green vegetation biomass and soil or rock surface brightness. Generalized mapping of the biomass brightness, soil brightness, wetness, and yellowness properties can be mapped from these calibrated reflectance values using the tasseled-cap model. Additional experimentation to extract and map different biophysical surface properties can be tried if more bands are available such as Aster imagery.

Strike and dip of geologic bedding can be measured and recorded using a Tool Script.

Hole filling can be performed on SRTM elevation data using a Macro Script.

Upgrading TNTedit.

If you did not purchase version 2005:71 of TNTedit in advance, and wish to do so now, please contact MicroImages by FAX, phone, or email to arrange to purchase this version. When you have completed your purchase, you will be provided an authorization code by FAX. Entering this authorization code while running the installation process allows you to complete the installation of TNTedit 2005:71.

The prices for upgrading from earlier versions of TNTedit are outlined below. Please remember that new features have been added to TNTedit with each new release. Thus, the older your version of TNTedit relative to 2005:71, the higher your upgrade cost will be.

Within the NAFTA point-of-use area (Canada, U.S., and Mexico) and with shipping by ground delivery. (+$50/each means US$50 for each additional upgrade increment.)

TNTedit Product	Price to upgrade from TNTedit:					2001:65
	2004:70	2003:69	2003:68	2002:67	2001:66	and earlier
Windows/Mac/Linux	US$350	550	700	800	875	+50/each
for 1-user floating	US$420	660	840	960	1050	+60/each
UNIX for 1-fixed license	US$650	1000	1350	1600	1750	+50/each
for 1-user floating	US$780	1200	1620	1920	2100	+60/each

For a point-of-use in all other nations with shipping by air express. (+$50/each means US$50 for each additional upgrade increment.)

TNTedit Product	Price to upgrade from TNTedit					2001:65
	2004:70	2003:69	2003:68	2002:67	2001:66	and earlier
Windows/Mac/LINUX	US$400	750	950	1100	1200	+50/each
for 1-user floating	US$480	900	1140	1320	1440	+60/each
UNIX for 1-fixed license	US$750	1200	1550	1850	2000	+50/each
for 1-user floating	US$900	1440	1860	2220	2400	+60/each

Tutorial and Reference Materials

There are now 79 TNT Tutorial and Reference booklets. These booklets provide more than 2000 pages and over 4000 color illustrations. The most important of these booklets are up-to-date with the features in version 2005:71 of the TNT products.

Tutorials.

Each new professional TNTmips ships with 3 thick notebooks containing a color printed copy of these 79 booklets. Those of you receiving your 2005:71 upgrade on CD can view and refer to all of these booklets using Adobe Acrobat or Reader. If you install all these booklets as part of any TNTmips product, you can directly access these booklets from the Display process, by choosing Help / Tutorial Overview and selecting the booklet, or via Help / Search and using the index this provides.

New Booklets Available.

Understanding and Maintaining Project Files. (printed copy provided)

Inspecting and managing the contents of a Project File is an important aspect of operating your TNT products. The TNT Project File structure has been designed and refined over a period of 20 years to efficiently manage your geospatial materials in a directory-like structure. This tutorial provides a quick reference to the tools that are provided for inspecting and managing it in the Project File Maintenance process. Reviewing these tools will help you understand how a Project File is structured, the parameters of geospatial components, and how to manipulate them. It describes how to view the descriptive information or metadata about each object and subobject. Some limited, object-level editing tools are discussed as well as how to view the metadata, which might have been automatically imported along with some external spatial data. Copying objects between Project Files is explained as well as how to break a lock, refresh, and delete an object and recover the space of a deleted object. The autodetection and color-coded presentation of illogical, missing, and other problem objects are reviewed as well as what to do about it. Recovering part or all of damaged Project Files is also discussed.

Coordinate Reference Systems. (printed copy provided)

Increasing image resolution and coordinate accuracy in geometric objects requires more rigorous attention to how their Coordinate Reference Systems are described and transformed. Geodata is now sold, shared, and moved about the globe via various media and via web services so this information must also be standardized so that layers from various sources accurately fit together. All TNT products, now including TNTserver, use industry accepted standards to meet these objectives. These include the standard CRS descriptions in ISO standard 19111 and the commonly accepted parameters for these systems and the transformation between them provided by the Open Geospatial Consortium (OGC) and the European Petroleum Survey Group (EPSG). Spatial data accompanied by this standard information can be accurately and directly used by your TNT product, imported into a geodata object, and converted to some other standard CRS.

As a result of these demands there are now many 1000s of CRS in use that must be managed by the TNT interface introduced in 2004:70 for this purpose. This tutorial provides quick reference to the use of this universal system. It provides background on CRSs and the ISO Spatial Referencing Standards that have been adopted by MicroImages and others. It introduces the Predefined panel as a shortcut, which avoids making you sort through these 1000s of systems every time to find the few you commonly use. Using this panel you can toggle open lists to select from a large number of standard CRSs, which will then appear on your short list. If the CRS you require uses a datum not covered on the short list, you will need to review how to select a datum or define a datum that it is not standard. MicroImages’ earlier CRSs and conversions are still available in this new system to automatically support the use of older objects. However, if a CRS defined in this new system is used that is not in the earlier system, then your geodata object can not be used in a version of your TNT product before 2004:70 and these limitations are also explained. Additional reference materials on this complex topic are also discussed.

Revised Tutorials with Major Changes.

The following tutorial booklets have been revised since the release of 2004:70. They were selected for update since they represent areas of significant recent changes in the TNT products. The added functionality of newly released features is introduced by the addition of new pages and examples as noted. As part of this update, their user interface illustrations, terminology, default parameters, and sample data have also been adjusted to be current with 2005:71 of the TNT products.

Mosaicking Raster Geodata has been updated and expanded to discuss new JPEG2000 compression options and the use of null masks to indicate no-data areas in the mosaic. The coverage of raster overlap options and feathering has also been expanded. The following new pages have been added:

• Feathering Overlaps and Deviation Filter—introduces the Feathering Option to provide smooth blending across the seams between input images in the mosaic;

• Mosaic Digital Elevation Models—how to set Mosaic parameters to ensure that input cell values are not altered, smoothed, or resampled during transfer to the mosaic;

• Compression for Large Mosaics—discusses the JPEG2000 compression options that can greatly reduce the stored size of large mosaics; and

• No-Data Areas and Null Masks—discusses how blank (no-data) areas are handled automatically by creating and storing a null mask to differentiate image and non-image cells in the mosaic.

Introduction to Map Projections has been revised, rearranged, and refocused to provide a more streamlined conceptual introduction to the elements of coordinate reference systems: geodetic datums, coordinate systems, and map projections. Step-by-step instructions on how to set up these parameters are no longer included in this tutorial as they are now covered in much greater detail in the separate new Coordinate Reference System tutorial provided in printed form with 2005:71. In their place you will find expanded discussions of planar coordinate systems, map scale, and map projections.

FAQs by Jack™.

A major section later in this MEMO entitled Calibrating Multispectral Images introduces a series of new specialized geospatial analysis scripts for advanced multispectral image analysis. The proper application of these scripts is complicated. As a result their operation is supported by approximately 200 pages of new color illustrated reference materials organized in part as Frequently Asked Questions (FAQs). Since these FAQs by Jack are supporting an advanced, research-oriented, application they may be expanded, clarified, or modified at any time. Thus, they are not installed with TNTmips and their latest version matching the latest version of the corresponding script can be viewed or downloaded from www.microimages.com/downloads/FAQsByJack.htm. These FAQs by Jack are listed below and more detailed descriptions of the contents of these new written reference materials are included in the Calibrating Multispectral Images section.

FAQ A: Remote Sensing Tutorial (42 pages).

FAQ B: Surface Reflectance Images – SRFI.SML (40 pages).

FAQ C: Diagnostic Products for Surface Reflectance Images – DIAG.sml (13 pages).

FAQ D: Terrain Correction for Surface Reflectance Images – TERCOR.sml (11 pages).

FAQ E: Grand Unified Vegetation Index Images – GRUVI.sml (31 pages).

FAQ F: Tasseled Cap Transformation Images – TASCAP.sml (38 pages).

FAQ G: Improved Coastal Images – WATER.sml (19 pages).

Quick Guides.

The following new Quick Guides are provided in printed form as part of your TNTmips 2005:71 upgrade kit. Some synopsize new features added to 2005:71 and some cover previous features of which you may be unaware. These and all the other upgraded Quick Guides are installed in PDF from the CD as part of 2005:71 or can be downloaded from www.microimages.com/documentation/QuickGuides/.

Suggestion: Add these Quick Guides to the notebook you keep for easy reference.

Page Layout Placement Tool.
The Placement tool produces three layout viewing modes and interactive features.

Save Scripts with Groups/Layouts.
Save custom tools and operations with groups and layouts.

Inserting Styles.
Insert styles for points, lines, and polygons from a previously created style object.

Use Polygon Attributes to Style Lines.
Use polygon attributes to determine line drawing styles.

Text Style Formatting Codes.
Format text (including DataTip and GraphTip text) using style formatting codes.

Pan by Query.
Select elements by query when zoomed in and move (auto-pan) from one element to the next with a button click.

Formatting Label Elements.
Edit and change the appearance of your labels in any language.

Copy, Cut, and Paste Geometric Elements.
Copy, cut, and paste geometric elements of any type within an editable vector or CAD layer.

Labeling Raster Objects for Display.
Label raster objects in a view using an overlay raster created by a geospatial script.

Searching Reference Materials.
Search all TNT products’ reference materials using the Help menu.

Validating Project Files.
Use Project File Maintenance to check your RVC files for validity and conflicts.

Adjusting Project File Validation Errors.
Use Project File Maintenance to adjust errors flagged by a color code in a Project File.

Creating DEMs from Text Files.
Create digital elevation models and contour lines from text files.

Scaling and Orienting Raster Objects.
Change cell size and orientation of raster objects.

Geometric Object Types.
A brief overview of the 5 Types: vector, region, shape, CAD, and TIN.

Direct Use of Popular Geodata Formats.
Directly view and use geodata in other raster, shape, and CAD formats.

Direct Use of ESRI Shapefiles (*.shp).
Directly view and use ESRI shapefiles in the TNT products.

Direct Use of MrSID Files.
Directly display and use MrSID files in the TNT products.

Antialiasing and Hinting for Thin Lines.
Choose antialiasing and/or hinting for display of thin lines in your view.

Change DataTip Background Color.
Specify the background color of DataTips and change it for each layer.

New TNTmips 2005:71 Features

Main or subsections preceded by the asterisk “*” symbol introduce significant new processes or features in existing processes released for the first time in TNTmips 2005:71. Major improvements added in this release focus on the operations of TNTmips at the system level in the use and management of the Project File and in various aspects of 2D and 3D visualization.

System Level Changes.

Direct Use of External Geodata.

AutoCAD’s DWG and DXF and MicroStation’s DGN Files.
Autodesk’s AutoCAD 2005 internal *.dwg and exchange *.dxf and Bentley’s MicroStation V8 *.dgn CAD files can now be directly selected and used as a layer in TNT display, georeference, import, and other appropriate processes. For example, simply navigate in the Select Objects dialog to a file with any of these extensions and select it and identify its Coordinate Reference System to add it as a layer to a 2D or 3D view. This direct method of using these files in TNT does not import them. When the file is selected, a TNT link file (*.rlk) is created in the same directory to make the native CAD file format appear as an internal TNT CAD object to the TNT processes. This TNT link file will be created with the same name and in the same directory as the original CAD file. The data in the original CAD file is not altered in any way by the creation of this separate link file or its subsequent use as a CAD object via this link in other TNT processes.

These new TNT capabilities to directly use DWG, DXF, and DGN formats and their corresponding import discussed below use libraries produced by the Open Design Alliance. The MicroStation DGN format specifications have been made available to this Alliance by Bentley Systems, Inc., whereas the Autodesk DWG format has been reverse engineered by the Alliance. MicroImages pays a license fee to this Alliance to use these libraries. More information about the Open Design Alliance can be found at http://opendesign.com/. The attached color plate entitled System: Direct Use of CAD Files (DWG, DXF, DGN, TAB) summarizes and illustrates the direct use of a DWG file.

Identifying a Coordinate Reference System (CRS).
The DWG, DXF, and DGN CAD files use double precision coordinates that can be in a wide variety of earth oriented CRSs such as UTM, latitude and longitude, and so on or simply use some arbitrary engineering coordinate system not related to the earth’s surface. Alas, there is no provision within these popular files to identify if an engineering or specific earth CRS is used for the coordinates in the file. This design circumstance is inherited from the initial development of these popular CAD file formats for use for isolated engineering drawings and not for whole earth and mapping applications. Without access to additional information not contained in the CAD file, the coordinates in the file merely establish the internal spatial relationship of the elements making up that file. The information needed to identify the earth CRS of a CAD file may be as simple as the knowledge that the coordinates are in decimal degrees of latitude and longitude. Any TNT selection process encountering one of these CAD files for the very first time, such as for their selection for direct display as a layer, will immediately recognize that no CRS is present. In this case you will be prompted as discussed below to identify the earth CRS used for the file from among the 1000s of TNT CRSs. This CRS information is then added to the TNT link file, which is automatically created for the CAD file and is used for all future uses of this CAD object.

There are 3 general conditions for the coordinates used in these CAD files.

1) The coordinates are only internally related with a common origin, axes, and scale restricted to that single CAD file. These CAD files are commonly referred to as using an engineering, local, or arbitrary coordinate system such as used for a machine part, a floor plan, or some other isolated drawing. This kind of drawing can be viewed and used in TNT processes including those which form and use its topology. However, without manually adding georeference information, they can not be geographically related to any other geodata in an earth CRS.

2) A group of files may share a common engineering Coordinate Reference System. For example, all the CAD files making up a project share an arbitrary, but common origin, axes, and scale. This would be typical of a CRS used for all the parts of a machine stored in separate CAD files or all the houses in a subdivision. Since each of these CAD files shares a common CRS, they can be displayed together to show the whole machine or the relative position of each house in a subdivision drawing. These drawings can be viewed, used, combined, and intersected together in TNT processes including those that build and use their internal topology. However, without manually adding georeference information, they can not be used individually or collectively with any geodata in an earth CRS.

3) The coordinates in the CAD file are referenced to some earth system such as latitude and longitude, UTM and a zone, or some other map projection and datum.   This case is typical of contour maps, which were prepared in or made available in CAD format.    However, as noted above, the CAD file does not identify this earth CRS. This leaves 2 alternatives for the use of these files in the TNT products. 1) They can be viewed, used directly, imported, and processed as interrelated objects making up a project that does not use other objects with an earth CRS or some other unrelated engineering CRS. 2) The inherent CRS of these CAD objects can be automatically read from a companion file accompanying the CAD file.   Since there are no standards set for such files, this is unlikely. 3) It is more likely that you will need to know the CRS of the file, often from its accompanying metadata, and manually enter it as the file is linked or imported. This earth CRS becomes part of the TNT link file for each CAD file and permits it to be used with other geodata in an earth CRS.

It is now common to refer to geometric data with coordinates in a known earth Coordinate Reference System as “geodata.” However, a CAD file is not geodata unless it has an accessible, known earth CRS. CAD and other files without a known earth CRS are simply referred to as “spatial data” (a building plan) or as “drawings” (such as a machine part).

Using CAD Files with Known Earth CRS.
Only CAD files with a known earth CRS can be combined in the TNT products with other linked or internal vector, raster, or shape geodata objects. Their earth CRS information may be provided for you to use in an accompanying metadata file or other information source for each CAD file or a related group of CAD files. If the complete designation is available in this fashion, it can be added to the link file for each CAD file and these CAD objects then become geodata files whose position in an earth system is known. These geodata files can then be automatically positioned in an earth framework relative to other geodata files of all types (raster, vector, …). If no earth oriented CRS information is available, the file can also be imported as a CAD object with an engineering CRS and then georeferenced, warped as appropriate, and converted into other geometric object types and other CRSs.

Using CAD Files With an Unknown Earth CRS.
A group of CAD files that have a common internal coordinate system can be used directly in the TNT products. These files may be parts of a machine or subdivision each in a separate CAD drawing with a common engineering CRS. They may also be a large collection of contour maps in a uniform but unknown earth CRS, such as a UTM zone. In both cases these CAD files can be linked to and used in TNTmips as a related collection of CAD objects as long as they are not also used together with geodata objects with a known earth CRS. If they are displayed as a group they will all occur in their proper relative positions in their common CRS. They can also be imported and merged into a single TNT geometric object (vector, shape, or CAD) using the TNT Merge process. The TNT object that results will still be in an engineering CRS and can then be georeferenced if desired.

Converting Engineering CRS to an Earth CRS.
A drawing in an arbitrary, local CRS can be converted from engineering coordinates to an earth CRS if adequate information is known. It requires that the coordinates in the linked or imported CAD file be related to an earth CRS. Using this information, any TNT product can convert this linked CAD file on the fly to any TNT earth CRS or the object can be imported into a TNT CAD geodata object in a known earth CRS. The TNT georeference process is used for this calibration and positions in the CAD file are visually co-located in some earth CRS using a georeferenced map or image or using ground coordinate positions recorded with a GPS device. Ground control points from one of these sources provide the georeference for the CAD file and are stored with the CAD object if it has been imported or in the TNT link file (*.rlk) of the same name if it is directly linked. Using a few such points distributed over a linked CAD drawing converts it from an engineering CRS to an earth CRS for every TNT process that subsequently directly uses the CAD file via this link.

Auto-Link Issues for Direct Link to Spatial Files.

To link or import, that is the question.
The TNT products are well known for displaying and processing geodata as fast as, if not faster than, any other commercial geospatial analysis product running on the same workstation. This results from on-the-fly conversion of object CRSs, pyramided rasters, object scale range control, optimized topological vector structures, indexed database fields, and other performance enhancing characteristics of the internal TNT geodata objects. Twenty years of development of the Project File concept has made this possible and as geodata object size increases these performance enhancing efforts must continue. An internal TNT object has an extensive substructure for containing the structured, controlled metadata needed to define and control their efficient use. The Project File internal structure is constantly changing with every new release to provide for new improvements and features. This is one of the important reasons it is not an open, public format.

By popular demand the TNT products also permit direct selection and use of popular raster, CAD, vector, shape, and database files. There is often a good reason why you may wish to directly use these external data formats even though they may yield slower results. These include sharing the data with other software or simply taking a quick look at their contents as is now possible using, new double-click and TNT Explorer features introduced in this release and discussed in detail below. However, when a TNT object is selected that is actually linked in from some other spatial data format, this format may not be optimal for use in the TNT products. The most common condition encountered is using a link to a large JPEG (*.jpg) file that is not pyramided. Its use in a TNT view would be slow unless pyramid layers are added to it in the associated TNT link file when it is first selected. Similarly, a CAD file selected for linking will not have a CRS automatically defined as in the case of all three of the new CAD file formats whose direct link is now supported.

The TNT products assist you in making external raster, geometric, and RDBMS spatial data into geodata layers so that they can be used together. Wherever possible during the linking activity, additional data is built up in the Project File link to make access to the structure of these simple spatial data formats more efficient.

Which external formats can be directly linked?
For version 2005:71 of the TNT products you can link to external spatial data files with the following extensions:

as shape objects: ESRI shapefiles (*.shp) and Oracle Spatial Layers;

as raster objects: TIFF (*.tif), GeoTIFF (*.tif), JPEG2000 (*.jp2), JPEG (*.jpg), PNG (*.png), MrSID (*.sid), and ER Mapper ECW (*.ecw); and

as CAD objects: MicroStation DGN (*.dgn), MapInfo TAB (*.tab), AutoCAD DXF (*.dxf), and AutoCAD DWG (*.dwg)

Why do issues arise during linking?
The TNT Project File is a closed format that as a result can be gradually modified as needed to keep it efficiently handling the ever increasing complexity and size of your geodata sets and their subsequent analysis on your desktop or via the web. On the other hand, direct links are made to popular formats designed and frozen years ago and thus are inflexible, contain only spatial data, and do not support their automatic use as geodata layers. It is also common that some auxiliary files, such as those needed to define the shapefile as a coverage or convey its styles, may or may not accompany the spatial file. You are not stopped from linking to an external file with geometric spatial content only, but you are warned that it will not be a complete TNT geodata object and prompted to supply the additional data needed. Similarly, you can skip the automatic building of the pyramid layers in the link to a large JPEG file but will find its subsequent use as a display layer to be slower than necessary.

How do you resolve missing mandatory components?
In the sections below you will find that it is now even easier to use external spatial data files as layers in the TNT products. However, if you want to use these files and activities to their best advantage as geodata layers in the TNT products, you will need to be prepared to resolve any missing reference data issues. You will also need to apply TNT optimizing operations to these files when they are linked to correct deficiencies in their structure or their use will be slow. If some required information is missing or an optimization is available for a spatial file selected for direct link, you will be prompted about this. This prompting appears as an Auto-Link Issues to Resolve window where you are requested to provide the missing data, such as the unknown CRS of the CAD file and to make decisions about what optimizations, such as pyramiding, should be created in the link file. The content of these Auto-Link Issues to Resolve windows varies depending upon the external spatial data file type being linked. Several of these are illustrated and discussed in the attached color plate entitled System: Resolving Auto-Link Issues. As support for additional external spatial data formats is added, you can expect even more of these windows depending upon what is missing for the minimum or effective use of that format as a geodata object in TNTmips.

Rasters that are not georeferenced. The Auto-Link Issues to Resolve window automatically appears if you attempt to link to a raster format that contains only spatial data but has no identifiable Coordinate Reference System (CRS) or georeference information. This window will not appear if you are linking to a file that has everything needed, such as a modern raster geodata file that has a CRS and pyramid layers that TNT can use directly (for example, a GeoTIFF file may have a defined CRS, pyramiding, and compression) or has no accompanying world file. However, JPEG, JP2, TIFF, PNG, and MrSID raster files may or may not contain geographically-oriented data and even when they do, they have no internal georeference data or identified CRS. If you wish to use these spatial data types as geodata raster objects in a TNT product, you will have to supply or create this information when linking to or importing these rasters. In the best case scenario, you have another co-named file (*.jgw or *.sdw) containing the georeference information that TNT can directly read and use or from metadata you know and can enter the earth CRS of the image. You also have the opportunity to form the pyramid layers for the JPEG, TIFF, GeoTIFF, and PNG formats that do not implicitly contain this kind of structure. If you are linking to one of these rasters in the georeference process and can identify its CRS, you can proceed on to add control points to create its georeference in the TNT link file. In the worst case, the earth-oriented image will need to be warped using many control points in TNT to approximately fit an earth CRS.

CAD files without a CRS. The following subsections illustrate the use of the Auto-Link Issues to Resolve window to obtain the CRS for use when linking to the 3 new CAD file formats.

Engineering/Local CRS. If the CAD file is a drawing, such as a house floor plan, machine part, or similar engineering drawing, you can choose the toggle Leave as Engineering/Local on the Auto-Link Issues to Resolve window. This will make a TNT link file with a local, uncontrolled CRS without any georeference. You can view and process this layer as long as you do not attempt to use it with any layer that is has an earth CRS (in other words, world coordinate system) since these two different coordinate systems can not be automatically related. You can choose to view several of these external CAD files and TNT internal CAD objects together as long as they are all designated as using an engineering CRS. This would be meaningful if all these layers added to the view, merge, or other process had a common origin for their engineering coordinates system, such as a collection of parts or floor plans of several buildings all with a common coordinate origin.

Geographic CRS. If you plan to use one of these CAD file types in TNTmips with other geographic data, you will need to know and identify which CRS its coordinates are expressed in the first time you directly use it (for example, UTM and zone or latitude and longitude). Choosing the “Ask for and set for this file only” in the Auto-Link Issues to Resolve dialog will allow you to identify the CRS of the CAD file. This toggle opens the new Coordinate Reference System dialog introduced in version 2004:70 of the TNT products. It permits you to choose from the 1000s of CRSs supported in TNTmips for your CAD file. You will need to have this specific data available for the CAD file from its provider, from a metadata file, or other source to use this dialog. When you have identified the CRS for the file it is automatically stored in the TNT link file (*.rlk) being created for this and any future use of this CAD file in any TNT product.

Handling Large Collections. You may encounter a large collection of CAD files that are geographically related in that they all use a common origin and coordinates. An example would be a directory of 100s of CAD files all of which contain adjacent contour maps all using the same UTM coordinates in the same zone. The TNT link file and CRS for all these related CAD files can be set up at one time. One additional toggle is provided in the Auto-Link Issues to Resolve dialog for this purpose. Choose this “Ask for and set for all files of the same type in folder” toggle button for the first file you select. Once you have designated the files as in UTM and the specific zone using the Coordinate Reference System dialog, all other files of the same extension in that folder will automatically get TNT link files using this same CRS information. The next and any additional CAD files selected from that folder will automatically open with the same properties.

How do you resolve warning issues?
Missing Style File. If the file being linked lacks or seems to lack some commonly available but optional reference data such as its styling, an Auto-Link Warning window indicating this may appear so that you will understand why some subsequently expected result is not obtained, such as styled lines. For example, when a direct link is made to a shapefile (*.shp), a co-named style file (*.avl) will be sought in the same directory as part of this linking process. If it is not found, you will see this Auto-Link Warning window to alert you that proceeding without this file will result in default styles being used whenever this shape object is viewed.

Rasters Missing a Pyramid Structure. JPEG, TIFF, and PNG files have no internal pyramid or equivalent nested access structure as they were designed before large rasters were common, such as those from satellite image sources, and when storage was at a premium. You do not have to wait for your TNT product to pyramid these files when you link to them. For example, perhaps you know that the directory contains 100s of small JPEG images to be linked. In this case you can skip the option to build the pyramid layers for each raster in its link file. In fact, if the raster is small enough, you will not be asked. However, if you choose to skip this step for a large raster file in these formats, you can expect its use as a layer in a TNT view to be slow, even excessively slow if it is very large. It is better to accept some delay while pyramid tiers are built when linking to these rasters rather than experience slow access every time you subsequently use these rasters. Many TNT analysis processes only use the full resolution raster object, but many include a view that will use these pyramid layers.

Some external raster file formats such as JP2 and MrSID are internally pyramided. TNT uses these and does not rebuild the internal pyramid structures that are available in these formats. However, large files in both of these formats are not required to have a complete internal pyramid structure and may be missing some of the smaller pyramid tiers.

Auto-Open from External Spatial Data Files.

The auto-open of a 2D display described in this section is available for TNT products operated in Windows 2000, 2003, and XP and Mac OS X 10.3.x and 10.4.x. If you are using earlier versions of Windows (98, ME, or NT), these auto-open operations are not available. The external spatial data files that can autoopen in a view in your TNT products are the same as those that can be used for a direct link as follows:

as shape objects: ESRI shapefiles (*.shp) and Oracle Spatial Layers;

as raster objects: TIFF (*.tif), GeoTIFF (*.tif), JPEG2000 (*.jp2), JPEG (*.jpg), PNG (*.png), MrSID (*.sid), and ER Mapper ECW (*.ecw); and

as CAD objects: MicroStation DGN (*.dgn), MapInfo TAB (*.tab), AutoCAD DXF (*.dxf), and AutoCAD DWG (*.dwg).

This direct viewing access is illustrated on the enclosed color plated entitled System: AutoOpen External Spatial Data Files. Only one spatial data file can be used to open your TNT product and its view in this fashion. But, as soon as this first view is available using this file, you can use the TNT internal layer controls to add other TNT objects or to select and add additional layers representing any directly supported external spatial data format.

This auto-open of a view by a double-click on the external spatial data file can be quite useful when you want to quickly link to, build its geodata link (including add CRS and pyramids), and view a file. For example, it is a direct means of reading coordinates of features from a CAD or shapefile file known to be in latitude/longitude or UTM coordinates. It is also an effective way of starting up to view multiple layers using this first spatial data file as the reference layer. For example, you might constantly reuse files containing a world, country, province, city, and local area layers as a means of starting your TNT product. Each auto-opens your TNT view with a base or reference layer ready for the addition of other geodata layers. In this fashion you can automatically preset the desired local extents for rapid viewing of a vector or raster object with much larger extents. If you have previously viewed any of these files in a TNT product, its co-named link file will already exist in the same directory and it will open your TNT product and this reference view in a few seconds.

Double-Click to Open.

Your TNT product can now be automatically started, including the X server, by double-clicking on the icon or any other Windows or Mac representation of an external spatial data file that is supported for direct use in the TNT products. This action will automatically open your TNT product, make a TNT link file (*.rlk) as it opens if it is not available, and then display this geodata file in a 2D view. If the external file type needs special help to be used as a geodata layer, you will be prompted for it using the Auto-Link Issues to Resolve dialog explained in earlier sections. An example of this would be the need to define a CRS for the new CAD file link.

Clicking the right mouse button (a control-click action on the Mac) on a spatial data file presents a pop-in menu. As expected, the Open option on this menu also opens a TNT product with a view of that external geodata file.

If your 2D Display is already open but without a view window open, this file selection procedure will recognize this and open a view of this spatial data file. If you already have a view open with layers in it, this selection procedure will open a new view for this file, it will not add it to the existing view.

Gaining Ownership.

As you know from previous experience in this area, the application that opens when a data file is double-clicked or otherwise selected is the application that “owns” all files with that specific extension. In order to auto-open spatial data files in a TNT view by selecting them, their extension must already be owned by a TNT product or can be shared with some other software product. In the case of an unassigned extension, you will be prompted by the operating system to browse to the application you wish to use to open the selected file. If an extension (for example, *.jpg or *.shp) is owned by or shared with some other application, you can select between these products using the Open With option, and you can transfer ownership to a TNT product.

For Mac OS X.
For the Mac gaining ownership of a spatial data file(s) for a TNT product using its file type extension can be temporary for one time or fixed until changed. Select the file with a single left mouse click and use the Finder’s File menu’s Get Info option to open the Get Info panel. Use the Open With option on this panel to designate that your TNT product is to have ownership of this file. The Change All… button will then make this ownership of the extension the default and apply it until changed to every file with that extension. Note that you must have Read & Write privileges to change the application ownership of a file(s), and this can be set on this same Get Info panel.

A more direct approach for a single file would be to use the right mouse button equivalent on the file’s icon to open the file management menu, which also provides access to the Open, Open With, and Get Info options. Remember that the right mouse button equivalent on the Mac OS X desktop is a control-click whereas within the TNT processes (in other words, within an X server), it is a command-click. For a temporary direct use of a particular spatial file you can also use the Open With option on the Finder’s File menu and browse to your TNT product.

TNT products are using right button menus and actions for convenience in more and more situations. Mac OS X users should consider the use of a low-cost 2- or 3-button mouse or Apple’s new multibutton mouse.

For Windows.
Gaining ownership of a spatial data file(s) for a TNT product using a supported file extension in Windows can be temporary for one time or fixed until changed. Use a left mouse click on the spatial data file’s icon to select it and then use the right mouse button or choose Open With from the File menu to show the list of the available programs to open the file. If your TNT product appears on the list select it, and it will open up a 2D view with that spatial data file in it. If it does not appear on the list, then use the Choose Program option at the bottom of this list to open the Windows Open With dialog. You can then find your TNT product on its list or use the Browse button to locate it to use to open the file.

On the same Open With dialog there is a toggle button to “Always use the selected program to open this kind of file.” If you want the TNT product you are selecting in this dialog to automatically open this kind of spatial file until changed, then set this toggle which will assign that file’s extension to your TNT product. Now any double-click on a file with that same extension will automatically open it in a view in your TNT product. The option to use that same TNT product to open a file you have selected with the left mouse button will also appear at the top of the Windows File and right mouse button menus.

TNTatlas/X is automatically installed as part of TNTlite and does not have any file size limits. You can use the procedure described above to assign the extension of any supported spatial data file to your TNTlite version of the TNT products. Once this has been done, any size of spatial data file will open in a view in TNTatlas/X and use the tools it provides. This automatic use of TNTatlas as TNTfreeview to view large spatial data files on any computer is described in more detail in this MEMO in the major section titled TNTatlas 2005:71 for X.

Keeping Ownership.

As you have already encountered, Microsoft and Apple both use disruptive and preemptive strategies to subtly regain and usurp control of popular extensions for their own commercial software products. This is in part the basis for the monopoly suits against Microsoft. Apple automatically opens Power Point files (*.ppt) with their Keynote software. Adobe Reader and Preview constantly contend for the *.pdf format on the Mac, especially via the Safari browser. It is hard to control or at least keep track of which of your installed applications owns the *.jpg extension for your slides among the varying contending viewers. The conflict to own popular extensions on your desktop computer is determined by the variety of different programs you have installed. For example, you may have various viewers for *.dlg and *.tif files. You will need to become familiar with how to assign and keep default and temporary control of the extensions that represent spatial data files among your applications including TNT Explorer.

AutoOpen Project Files Without TNT Explorer.

TNT Explorer is optional for Windows operation of the TNT products but unavailable for Mac OS X. The absence of TNT Explorer is obvious since each Project File still looks like a file icon and not like a folder icon. The following is the behavior of Project File icons if TNT Explorer is not being used.

In Windows using the right mouse button menu on a Project File icon will expose a file action menu. On the Mac OS X platform, use the control key and a mouse click to emulate a right mouse button click to show this same menu. Selecting Open or Open With from this menu will auto-open the selected TNT product and add all the objects in that file into its 2D view. For example, if you select a Project File with 256 orthoimages, the view will be the virtual mosaic of all these images.

The Project File’s *.rvc extension is relatively unique and its ownership on your computer is not very likely to be assigned to some other software. Thus ownership of Project File’s *.rvc extension is assigned to the TNT products during their installation and will probably remain uncontested. As a result double-clicking the left mouse button on the icon of a project file will open your TNT product with a view of an object(s) in that file. Use the Open option to locate your TNT product if by some chance it is the alternate choice for the *.rvc extension.

Auto-opening a TNT product with a left mouse button click(s) on any supported spatial data file format is unambiguous as that external file is only a single geodata layer. Similarly using the left mouse button to auto-open a TNT product with a Project File containing a single (1) primary geodata object (raster, vector, shape, or CAD object) or a single group/layout is also unambiguous and supported. For example, a single complex map layout in a Project File made up of several groups and many layers will auto-open a TNT product including the FREE TNTatlas and build the map by simply left-clicking on its Project File icon. Conceptually this is similar to using a map in a PDF file with a free Reader. It differs in that in a TNT layout all the individual layers can remain available in the Project File, as linked layers somewhere else on a local area network and perhaps eventually at a web site.

However, a Project File is actually a container that can hold a collection of primary objects and their modifying subobjects, groups, and folders. Thus using this new autoopen feature on a multiobject Project File can be ambiguous and undefined and will automatically default to use all the objects it finds if no group or layout is present or to the first group or layout it encounters. The order for opening all the objects will be related to the order they were put into the Project File, which is not currently changeable. Thus if the display order is critical (foe example, a combination of raster and geometric objects are involved) and this auto-open is involved, then the objects’ order and/or placement need to be set up as a display layout.

Windows TNT Explorer.

Introduction.

TNT Project Files now automatically appear and behave as TNT desktop folders in Windows 2003 and XP using a TNT Explorer integration with Microsoft Windows. The powerful integrating structure of the Project File has not been changed in any way to accommodate this new Windows-orientated access to its contents. However, a new, optional shell procedure makes the Project File structure behave as if it is an extension of the Windows directory structure. Now in Windows the Project File has the icon and look and behavior of a Windows folder. Opening this pseudo-folder exposes its primary objects and groups as if they are individual geodata files in a folder. Interaction with the icons or other Windows representations of these geodata objects parallels those of other singular data files used in other Windows software: Open, Open With, Copy, Delete, Properties, and so on.

From the viewpoint of someone using version 2005:71 for the first time, this approach hides another major variance in the initial way they expect a Windows product to operate. The X server was effectively hidden from you some years ago by the introduction of 1 TNT window = 1 Microsoft window. Now the complex but powerful, important, unifying structure of the Project File is also hidden from new users.   Previously a new user of a TNTmips or other TNT product encountered the precipitous learning curve required to understand the Project File structure and how to move around and control it using the TNT object selection tools. Now their start up learning curve will be a gradual slope using point and click Windows file management procedures familiar from their other products and their general knowledge of Windows.

Advanced geospatial analysis and problem solving is not made any simpler or easier by this introduction of a new, easier to learn startup desktop interface. But now the new user can get underway and gradually build up an understanding of the Project File concept (for example, keeping all your geodata organized so as to avoid losing pieces of it).   The creation, modification, and detailed control of complex geodata still requires use of TNT’s many control windows and geodata object management tools. All the TNT processes internally access and use the Project File just as in previous versions. It is only their appearance and supported activities on the Windows desktop that have been altered.

This important enhancement uses Microsoft’s Windows Explorer (the technical name is the Windows shell namespace extension). This is an integral part of the Microsoft Windows operating system but should not be confused with Microsoft’s Internet Explorer. If you are not using Microsoft Windows 2003 or XP, you will only be able to use the new auto-open behavior described in the sections just above and your Project File will still appear on your desktop as a single file, not a folder. Alas, as yet MicroImages has not found any equivalent to this Windows Explorer for use with the Mac OS X. As a result TNT Explorer supported pseudo-folder behavior for Project Files is not available in Mac OS X. In our capacity as Apple Developers we have addressed several questions to Apple on how to accomplish this same objective in Mac OS X. As yet neither they nor anyone else has given us a hint or even had the courtesy to answer. At the moment, progress in providing a parallel capability for Mac users is not yet feasible.

TNT Folders (The Windows Desktop Representation of a Project File).

Appearance.
When you install your version 2005:71 of your TNT product under Microsoft Windows 2003 or XP, every Project File you have (in other words, every file with the extension *.rvc) will appear as a closed pseudo-Windows folder (hereafter called simply a TNT folder). Your Project Files will no longer appear as icons representing them as files. This change does not effect how a Project File appears or is selected or behaves from within the TNT products.

While appearing and behaving as a Windows folder, a TNT folder can be distinguished from other Windows folders on your desktop by the MicroImages logo embossed on it. The name of the Project File and the *.rvc extension will appear with the TNT folder. Descriptive pop-in information about the TNT folder will appear if the cursor is placed over it: date modified and size. The TNT folder will also automatically be expressed in whatever additional forms you select to represent a folder in Windows: Thumbnails, Tiles, Icons, List, or Details. A Windows window with several TNT folders in it (in other words, Project Files) is illustrated in the attached color plate entitled TNT Explorer: Introduction to Project File Folders.

General Behavior.
Right and left mouse button operations on any TNT folder parallel those for other Windows folders. Opening a TNT folder uses a single- or double-click on it with your left mouse button depending upon your preference setting for this in the Windows’ Folder Options. A TNT folder can be dragged around in the directory window, dragged to another directory window, duplicated, deleted, and so on just as with any Windows folder. These activities are managed by MicroImages’ extensions to Windows Explorer and do not start the X server or any of your TNT products.

There are some current limitations such as copying a geodata object from a TNT folder to the desktop. This is an action that would require the use of a TNT product to create a new TNT folder (i.e., automatically create a new Project File to hold the geodata object). TNT manages these limitations and simply will not complete an illogical or as yet unsupported operation. For example, if you attempt to drag an external spatial data file into a TNT folder thinking that it will be copied into and auto-linked to that Project File, it simply will not be done. Why, because again this requires the use of a TNT product and none as yet is being used by the TNT Explorer. The only TNT product operations supported for the contents of this folder are to open a 2D display in the Spatial Display process or the Spatial Editor process or to add a new internal object as a layer to either of these processes.

Let it be emphasized again here that these new TNT folder, TNT file, and their interactive Window-like manipulation on the Windows desktop is simply another means of manipulating and using Project Files. The integrity of the Project File and its valuable properties are still being maintained by the TNT Explorer throughout these familiar click, drag and drop, rename, copy, delete, and other Windows desktop activities on or between TNT Folders. Working with the complex aspects and capabilities of a Project File from within your TNT products is unchanged.

Properties.
Using the right mouse button to select a TNT folder will open a Properties window showing the standard General attributes for a Windows folder.

Opening.
As noted above and expected, a single or double left button click on a TNT folder will open a new window showing every geodata object or group/layout object it contains or has links to as a pseudo-object (hereafter all these are called TNT objects—internal or linked). These primary objects will be expressed as a file icon or whatever other representation you have currently chosen in Windows’ View menu for representing the file contents of windows: Thumbnails, Tiles, Icons, Details, or List mode. All these objects are still in the Project File but appear and act similarly to other files in a native Windows folder.

Open in Icon Mode. Each primary geodata component in a Project File will appear as a separate Windows-like TNT object icon in the open TNT folder. Each Windows-like TNT object icon will be embossed with the standard TNT object type icon to identify it as a raster, vector, shape, CAD, TIN, or database (for example, a pinmap) object; a group/layout; or an SML query or layer script. Each TNT object icon will have the name of the object showing below it. Descriptive pop-in information about the TNT object will appear if the cursor is placed over it: TNT object type, description, date modified, and size. If you have used folders within your TNT folder (in other words, with a Project File), they will appear and behave as additional TNT folders within this open TNT folder. If you have any links to external spatial data files linked in a TNT folder (in other words, linked to a Project File), they will also appear as icons representing TNT objects. These icons will be embossed with a “shortcut” arrow to indicate that they are links to the contents of external spatial files in their original formats. A TNT folder open in Icon mode is illustrated in the attached color plate entitled TNT Explorer: Introduction to Project File Folders.

Open in Details Mode. In this mode each TNT object (primary geodata component) is represented in tabular form by a line containing its TNT object icon, Name, Size, Type, Date Modified, and Description. This is the same information about the file that would pop-in in the other modes when the cursor is on the TNT object’s icon. A TNT folder open in Details mode is illustrated in the attached color plate entitled TNT Explorer: Introduction to Project File Folders.

Open in Thumbnails Mode. In this mode each TNT object (primary geodata component) is represented by a thumbnail view of its contents. These are the same thumbnails you have already been viewing in the TNT Object Selection window. Below each thumbnail will be the name of the object. If no thumbnail is available, such as for an SML layer script, the TNT file icon will represent this object. A TNT folder open in Thumbnail mode is illustrated in the attached color plate entitled TNT Explorer: Introduction to Project File Folders.

Open in List Mode. In this mode each TNT object (primary geodata component) is represented in a multicolumn list with an icon embossed with a TNT object type icon and its name. A TNT folder open in List mode is illustrated in the attached color plate entitled TNT Explorer: Introduction to Project File Folders.

Open in Tiles Mode. In this mode each TNT object (primary geodata component) is represented similarly to the Icon mode but shows much larger icons with more space around them.

Left Mouse Button Desktop Operations on a TNT File.

On a Primary Object.
A left-click or double-click (depending upon your settings) on any file’s representation on a Windows desktop will perform a single operation on that file determined by the application that currently owns its extension. A left click on any TNT object in a TNT folder functions the same. It automatically starts MicroImages’ X server unless it detects that a copy is already running. It then starts your TNT product, the Spatial Display process, and a new 2D group with that TNT file displayed in it. All this is automatic and will typically take 10 to 15 seconds, which is a time approximately equal to left clicking on a typical Power Point presentation and opening it in Windows assuming that the Microsoft Power Point application must be opened from the hard drive (in other words, it is not already open). If you have clicked on a huge TNT file representing a geometric object without appropriate scale control, you will get the Dense Layer Verification window to set the view scales and avoid a delay just to see a meaningless view.

Typically you have installed several TNT products: TNTmips, TNTedit, TNTview, TNTatlas, and TNTsim3D. When you left click on a TNT object it will find and open the geodata layer it represents in the highest level TNT product you have licensed and installed. This will be TNTmips if you are operating in TNTlite mode or have a professional license to TNTmips. It will be TNTedit if your license is for TNTedit. It will be TNTview for a TNTview license. The same sequence is used if you are using TNTlite and the TNT file is within the size limits for that object type. Since TNTatlas is FREE you can always install it and open a TNT file and the geodata it represents of any size and use its features.

On a Group/Layout Object.
Left-clicking on a TNT object representing a group/layout object functions just the same as noted above. In this fashion an entire map can be automatically displayed by a mouse click if the TNT object represents its layout. Completing this map view takes a bit longer as it starts and uses the Spatial Display process and all the components defined in that layout must be read and positioned in the new view. For example, the Property Viewer Atlas for Lincoln, NE provided to you on DVD with 2004:70 has 15 geometric layers and 2 raster layers, more than 4 gigabytes of geodata. If this geodata is copied to a hard drive it can be used to open TNTmips and its composite first view in 17 seconds when nothing is cached and this layout is double-clicked. Any subsequent zoom in or out with any layer combination can then be made in less than 7 seconds. Similarly double-clicking the TNT file representing the startup layout for a TNTatlas starts up the FREE TNTatlas product if no other TNT product is installed.

Common Tasks Sidebar.
The Windows’ Folder Options Settings (Tools/Folder/Options) can be used to add a sidebar to the left side of a Window’s window. This task bar is available and presents similar options in a TNT folder. The common tasks sidebar for a TNT folder is illustrated in the attached color plate entitled TNT Explorer: Left Button Operations in a Folder.

Rename. The option to “Rename this item” can be used to edit the name of the TNT object. It can not yet edit the description embedded within this object. This must be done from within a TNT product using the Project File Maintenance process.

Copy. The option to “Copy this item” can be used to copy a TNT geodata from one TNT folder (Project File) to another already existing TNT folder (Project File). Attempting to copying a TNT object to any other Windows folder will perform no action. It will not automatically create a TNT folder (Project File) with this TNT object in it or export the TNT object to some external spatial data file in a Windows folder.

Delete. The option to “Delete this item” can be used, with a follow-up confirmation, to delete the TNT object from the TNT folder (Project File). It is has the same result as selecting the object’s icon and then using the delete key. A deleted TNT object is not backed up temporarily in the Windows Recycle Bin in a similar manner as deleting a file in a Windows folder. It is gone! Furthermore, the Project File is not packed in this operation and the space formerly used by the deleted TNT object is still held by the TNT folder. You can only pack this space out of the TNT folder by using the TNT Project File Maintenance process provided for this purpose.

Move. The option to “Move this item” copies a TNT object from one TNT folder to another and deletes it from the source file. This move operation has the same limitations as noted above for a separate copy and delete operation in that it does not reduce the size of the source file.

Details and a Thumbnail. It the TNT file is selected with a single left mouse click the details section at the bottom of this common tasks sidebar will show the name of the TNT object, the object type (raster, vector, …), and the date it was modified. You can also view the thumbnail of that TNT object’s contents in this same area of the common tasks bar. By checking this thumbnail view you can often instantly determine if this is the TNT file of interest without opening it in any TNT product!

Right Mouse Button Desktop Operations.
Using the right mouse button to select a TNT object will open a right button menu presenting several different actions you can then select to apply to that TNT file. These include selecting to open and use the TNT file in a new 2D group in the Spatial Display or as the editable layer in the Spatial Edit process. Various TNT file management options are also available on this menu. These features and a right mouse button menu are illustrated and discussed on the attached color plate entitled TNT Explorer: Right Button Features in a Folder.

Open in a New 2D Group.
The first choice on the right button menu is “Open In New 2D Group.” Selecting it with either the left or right mouse button automatically starts MicroImages’ X server unless it detects that it is already running and available for use. It then starts the TNT product you have associated with the Project File (*.rvc) extension and opens up the View window and the Group Controls dialog. All this is automatic and will typically take 10 to 15 seconds. For comparison, this is approximately equal to left-clicking on a Power Point presentation on this same computer and opening it in Windows assuming that the Microsoft Power Point application must be opened from the hard drive (in other words, it is not already open).

Since this is a new view, it has no other object in it to set the scale so this TNT file will become the reference object and the complete extent of this object will be loaded into the view. If you have elected to open this new view with a huge TNT file representing a geometric object without appropriate scale control, this operation is interrupted by the Dense Layer Verification window to advise you about potentially lengthy display times at full view. It may be faster to first select some other simpler-content TNT file with this option (for example, a USA state and county outline vector object), zoom in the view to the area of interest, and then use the “add to group …” option on the right mouse button menu to add the more complex TNT file. It will then autozoom and position itself to match the reference object.

Add to an Already Open 2D Group.
If you already have one or more views open in a TNT process, you can use TNT Explorer to directly add a TNT object to it with just two mouse clicks. The TNT objects can be either internal TNT geodata objects in a Project File or other supported spatial data formats using their Project File links. Use a right mouse button click on the icon, thumbnail, or name representing the TNT object you wish to add as a new layer. This will open the right button menu for that TNT object and list the names of any open 2D views (groups). Selecting the name of any open view from this menu with either mouse button will add that layer to that specific view (group). It will be added to the view just as if you had used the Quick-Add object selection procedures in the Group Controls dialog associated with that view. It will be positioned at the scale, zoom, projection, and other display control features of that open view.

Add any TNT geodata object (linked or internal) to an existing view with 2 mouse clicks!

Open in the TNT Edit Process.
If your objective is to immediately edit a TNT object then choose the Edit option from the right button menu for that icon, thumbnail, or name representing that object in your TNT folder provided by TNT Explorer. This will open the TNT Spatial Editor and display this layer as an editable layer in its view window.

Add to an Already Open Edit View.
If you already have a view open in the Spatial Editor process, you can now directly add a TNT object to it with just two mouse clicks. The TNT object can be either an internal TNT geodata object in a Project File or other supported spatial data formats using their Project File links. Use a right mouse button click on the icon, thumbnail, or name representing the TNT object you wish to add as a reference layer. This will open the right button menu for that TNT object and list the names of any open Editor groups. Selecting the name of any open edit view from this menu with either mouse button will add that layer to the view. It will be positioned in the view at the scale, zoom, projection, and other display control features of that open editable view.

Rename.
Rename is provided on the right mouse button menu and on the Common Tasks sidebar at the left side of TNT Explorer’s open folder. You can also left click the mouse button twice directly on the name of the TNT object to edit it just as used to rename any other Windows file. You can not as yet edit the description embedded within this TNT object. This must be done from within a TNT product using the Project File Maintenance process.

Delete.
Selecting Delete from the right mouse button menu for the TNT object, with a follow-up in the Yes/No confirmation dialog, will delete the TNT object from the TNT folder. “Delete this item” is also available from the Common Tasks list at the left side of the TNT Explorer’s open folder. You can delete the object from the TNT folder by dragging its icon into the Recycle Bin.

These and any other means of deleting a TNT object from a TNT folder does not temporarily place it in the Recycle Bin similar to a delete action on a file in a Windows folder – remember, a TNT object is only a pseudo-file as far as Windows in concerned. If you drag a TNT object to the Windows Recycle Bin and confirm its deletion, it is gone!

A TNT object is not packed in this delete operation and the space formerly used by this TNT object is still held by the TNT folder (in other words, in the Project File). You can only compress this TNT folder and regain this storage space by using the “pack” feature provided in TNT Project File Maintenance for this purpose.

Properties.
Selecting Properties from the right button menu for the TNT file will open a new Properties window, which presents the same detailed information (in other words, metadata) about the TNT folder as you would get using the Info button in the TNT Project File Maintenance process. Now you can simply right click on any TNT object or any of its subobjects at any time for immediate and direct access to this geodata object information without the need to open any TNT product or X server. This window has scroll bars and is named “object name” Properties. A Properties window for a TNT raster object named LincolnNE is illustrated in the attached color plate entitled TNT Explorer: Right Button Features in a Folder.

View properties of any TNT object at any time via your the right mouse button.

Browse to Subobjects.
Selecting Browse from the right mouse button menu for the TNT object will open a new TNT folder containing icons representing the modifying subobjects and attributes of that TNT file. These icons represent properties of that TNT object such as its colormaps, styles, histograms, database tables, and so on. Each Windows icon is embossed with the TNT icon used in the TNT products to identify the contents of these subobjects. You can right click on these icons to open a right button menu to manage them.

Subobject Delete. Using the various delete options for any of these icons representing subobjects of a TNT file functions as described above for the entire object. Deleting subobjects should be done with care! Some activities of this type are useful, such as deleting a histogram so that a new one is automatically built. Many other delete actions on subobjects, such as deleting a database structure, can have serious negative consequences.

Subobject Copy, Rename, and Move. These are available but should be used with care since these subobjects are properties of a primary TNT geodata object (rasters, vector, …) and are unlikely to be applicable and useful with any other TNT object.

Subobject Properties. This is a very useful option on the right mouse button menu and Common Task sidebar and functions the same as described above for TNT objects, but the detailed metadata presented is for the selected subobject of the selected TNT object.

View properties of any subobject of a TNT file at any time via your right mouse button.

Summary.

A TNT Project File is still a real single file to your Microsoft Windows operating system and to every TNT product and process. A TNT Project File is a container that organizes and keeps together geodata objects and subobjects, groups, SML scripts, and other components of your project materials. Internally a Project File can even organize these constituents into folders within that single file. If you are using a TNT process, you still have to think about and work with Project Files that have various objects, folders, and other components in them that are selected and manipulated throughout the internal TNT graphical user interface. You can still have 100s or 1000s of object and subobject components and options available to handle all sorts of conditions and applications.

However, now every TNT product installed under Windows 2003 and XP adds an extension to Windows associated only with the *.rvc file extension called TNT Explorer. This uses facilities provided by Windows Explorer, which are also applied in a similar context in Internet Explorer and other Windows products. For example, if you use Internet Explorer to access an FTP site, you will see its local directories as folder icons with file icons in them and you can drag and drop these onto your desktop, which will copy them to your local drive.

Using Windows Explorer, TNT Explorer creates the familiar desktop paradigm for the easy and simple management of all your geospatial data independently of starting up any TNT process or X server. A TNT folder is an artificial construct of TNT Explorer, which makes a TNT Project File look and function as a pseudo-Windows folder on your desktop. In this TNT folder the primary contents of a Project File, the geodata objects it contains, appear as pseudo-Windows files. If you are not in a TNT process and are merely working on your desktop, you can manipulate and use these TNT folders and TNT objects in much the same fashion as any other Windows folder and its contents.

Project Files.

Faster Vector Validation.

Improvements in the Project File structure have resulted in faster access to vector objects in selected processes. The processes most likely to be affected are vector-based operations that perform topology validation at some point in their operation, for example, “Merge to Vector,” “Validate Vector Topology,” “Geometric to Vector,” and others.

Compression of Uniform Raster Tiles.

Each pyramid layer in a raster object is written, stored, and read in tiles. The actual area covered by the raster object can be highly irregular in shape and have large areas that contain no data, or null cells. Rasters that represent categorical or theme data such as large polygons also have large uniform areas and tiles in these areas can be uniform in value. TNT 2004:70 stored all tiles in the rectangular extent of the raster the same. A tile covered by a uniform, single value occupied the same storage area as a tile whose cell values were varied unless raster compression was used.

Tiles made up of uniform values in TNT 2005:71 are now compressed into a few bytes by storing only the uniform value of the entire tile. This uniform tile compression is automatically applied to all raster object data types when they are compressed via any of TNT’s standard compressions. Under the current approach each homogeneous, or uniform, tile is stored in the raster object as 10 bytes versus ~200 bytes for an 16-bit signed integer raster object in TNT 2004:70 or 12 bytes versus ~250 bytes for a 32-bit integer. Non-uniform tiles are compressed just as previously.

The tiles in the binary null mask raster subobjects introduced in TNT 2004:70 are almost all uniform. Saving only a single binary value for each uniform tile can reduce these masks by as much as 100 times if the primary raster is large. Mask raster objects are automatically compressed in this fashion and you can not change this. A primary raster object representing a large, irregularly bounded area can also have a large number of homogeneous cells to fill out its null area into a rectangular shape. An example of this would be an image of the State of Florida with the water areas set to null. Since homogeneous tiles in all primary raster objects are also automatically compressed, this results in larger lossless compression ratios for situations like Florida. It is also important to remember that the smaller the stored raster size is relative to its uncompressed size, the faster it is written to and read from the source drive/network. Furthermore this kind of compression requires negligible compute time to build and is almost instantaneous to read and decompress since its occurrence is detected by a simple test of the tile whose single value can then be read and used to populate the tile.

Optional Creation of Pyramids.

Spatial Display, Spatial Edit, Mosaic, Georeference, and the other TNT processes provide direct and convenient access to external spatial data files in other formats. If these are raster formats which do not have pyramid layers available, you are automatically presented with the recommended option of computing and storing these layers in the TNT link file. Doing this makes all TNT access to these rasters at all scales nearly as fast in any TNT process as if they were internal geodata objects inside the Project File. When you select one of these external raster files that lacks pyramid layers, this will automatically be detected and the Auto-Link Issues to Resolve window is presented to you. This window will not be shown if you are linking to an external spatial data raster file format (*.sid, *.ecw, and *.jp2) that already contains built in pyramid layers.

This Auto-Link Issues to Resolve window provides an explanation as to why the link has not yet been completed and toggle buttons for you to control the building of the highly recommended pyramid layers. These toggles are mutually exclusive and one is always selected. Using the “Do not pyramid” toggle will simply close this window and proceed without computing or storing any pyramid layers in the link file. Using the “Create for this file only” toggle results in computing pyramid layers for the single file to which you are linking.

Using the “Create for all files of same type in folder” will cycle through every file with the same extension in the folder and build its link and pyramid layers. For example, in the Spatial Display process you select to display a single JPEG (*.jpg) raster file from a folder with many JPEG files. This toggle button will cause a link with pyramid layers to be computed for every JPEG file in that same folder. For example, in the Mosaic process you can select a folder with 256 orthoimages in it in JPEG format. You can then auto-select all these files for mosaicking with a single mouse click. This Auto-Link Issues to Resolve window then appears and the result of using this toggle would be 256 links with pyramid layers loaded into the list for immediate mosaicking. This is very convenient when you have organized folders with 1000s of images, slides, orthoimages, and so on.

Designation of Coordinate Reference System.

When links are made to use external files not created in the TNT products, they may contain spatial data that is in some unidentified and even unknown Coordinate Reference System (CRS). This situation and its rectification is discussed above in detail since it is often the case with data in CAD formats. Suffice it to say again here that CAD and other external file formats supported for direct use in the TNT products may contain spatial data but it is not geodata unless it is linked or imported into a Project File with all the necessary data such as its earth CRS, georeference points, and so on.

When you choose any supported, external, spatial data file anywhere in a TNT process for direct use, the link is built and the earth CRS identified if it is available in that format or an accompanying auxiliary file, such as a world file. If no or an incomplete earth CRS is available in the selected format, the Auto-Link Issues to Resolve window will appear providing you with an explanation as to why the link has not been completed and toggle buttons to use to resolve this issue. These toggles are mutually exclusive and one is always selected. Using the “Leave as Engineering/Local” toggle will complete the link with the CRS identified to be in arbitrary units.

Using “Ask for and set for this file only” will open the TNT earth Coordinate Reference System window so that you can select from the 1000s available. This CRS will then be included in and used as part of the link to that single file. Using the “Ask for and set for all files in a folder” toggle will ask you to select an earth CRS and then will cycle through every file with the same extension in that folder and build its link and identify each as having this same earth CRS.

Null Masks.

The introduction of the use of binary null masks began with the release of version TNT 2004:70 and is expanded in TNT 2005:71. The earlier designation of a specific null value within the raster’s cell content is no longer a viable approach to identifying areas and cells of no data within a raster’s bounding rectangle. This older approach often causes difficulties when the raster is fully populated (stretched) over its whole possible data range. This happens with 8-bit and 16-bit integer rasters stretched to their entire data range or when unique values were not easily defined and retained, such as in floating point rasters and which might later be rounded up to less precision. This approach had to be changed with the introduction of lossy compression schemes for raster objects. These forms of compression can alter any value in the raster, thus changing a null value of a cell to some other slightly different not-null value.

The switch to using a binary null mask raster subobject kept with the primary raster object alleviates these and other problems and permits null cell areas to be recorded and used with lossy compression of the main raster. These null masks now add very little to the size of the primary raster object since they are highly compressed. Most of the tiles in this binary raster are all 1 or all 0 and use the new homogenous tile compression explained above. Those tiles containing both 0 and 1 values, in other words, edges of areas, are also compressed using lossless run length encoding.

After the null mask was introduced to all processes, it was found that the concept of a null value had to be retained. Several external raster formats still use this null cell value approach (for example, MrSID). For this purpose their TNT export procedure permits you to convert the null cells defined by the TNT null mask to a stored or designated null value for the cell in the output raster file. More information on the adjustments necessary to accommodate both methods of defining null cells can be read in the attached color plate entitled Miscellaneous: Managing Raster Null Cells.

Autolinking.

MrSID Files on Linux.

Direct links can now be made to MrSID files (*.SID) created in any operating system in TNT processes operating under Linux.

PNG.

Direct linking to 8-bit PNG files and their color maps is now possible and will preserve their transparency. These files are commonly available from various web sites since they are small and can be compressed. Direct links to 24-bit PNG files was already available in TNT 2004:70.

Styles.

Embedding.

Styles were stored in separate objects in TNT 2004:70 and earlier. This permitted selecting styles for geometric elements from a common set of styles shared between objects. This design was also commonly used in other commercial systems and collections of styles were provided with the products and additional styles were sold separately as add-on products. This also minimized storage when drive space was scarce. It had the disadvantage that when an object was copied to a new Project File the style object might be left behind and longer could be located in a future operation. It was hard to keep the geometric object referenced to the proper style object especially when working over a network or building a layout or a TNTatlas.

Style objects can now be optionally embedded as a subobject of the geometric object that uses them. This means that they will automatically be available regardless of how the primary object is moved around. This is discussed in more detail in the top portion of the attached color plate entitled Style Editor: Embedded vs Linked Style Objects. A logical approach would be to create Project Files each with a master style object. For example, one each for your lines, symbols, bit map fills, hatch patterns, and so on. The various TNT style editors can be used for this purpose and styles can be imported from other sources. During the creation of geometric objects, styles can be assigned from these sources and subsequently embedded under them for portability.

Copying.

It takes time to check off all the individual styles to copy from a source style object to insert into a new stand alone style object or embedded style subobject. Check All and Clear All buttons have been added to the Select Styles dialog used in the Style Editor. These buttons will check on or off every style in the object regardless of current settings. You can then deselect or add styles from these states to most easily create the desired sublist to be copied and inserted. A new Quick Guide entitled Inserting Styles is included to illustrate this activity.

Session Logs.

The session logs introduced in version TNT 2004:70 and explained there in detail now also record your product version, update status, and serial number and various details of your workstation. This additional information can be helpful to MicroImages software support in diagnosing problems.

Whole Earth Objects.

These are TNT geodata objects that span the whole earth or large areas crossing 180 degrees of longitude and extending to the poles. They can be a single large object or a group of objects. Handling these objects has now been improved in all TNT processes. Examples of the use of whole earth objects are illustrated in the attached 2-sided color plate entitled System: Orthographic Projection for Global Views. It illustrates the use of several kinds of TNT geodata types from a variety of center points.

Miscellaneous.

The quick action selection lists for the CRS for each nation have been grouped to combine similar sets, for example, grouped by common datums. Access to the less frequently used CRSs is provided through the more complex selection interface.

The special ellipsoid and datum used for MODIS imagery has been added.

The datum transformation from Indian 1954 to WGS84 for Thailand has been added.

Macedonia CRS and datum support has been added.

Stomlo CRS for Australian Capital Territory (ACT) has been added.

The Mollweide projection is now available.

2D Display.

Separate Layer Caching.

Background.

For almost 20 years the development of the TNT products has focused on visualization of complex multiple layers of raster and geometric spatial data. This has paralleled the evolution of the Project File, which is used to organize and manage these different types of spatial data for viewing and analysis. A highly interactive approach to the analysis and presentation of geospatial projects requires as fast and flexible a visualization procedure as is possible. Each improvement in the speed of TNT’s composite viewing has permitted the design of new interactive tools. This means that you can complete the interactive aspects of your geospatial analysis quicker and with more efficiency.

Workstations with faster CPUs, dual processors, more and faster real main memory, and other related performance improvements allow periodic redesign of portions of the TNT Geospatial Rendering Engine (GRE) to improve the 2D Spatial Display process used in most TNT activities. The continual increase in the size of the geodata objects available in the Project File necessitates changes.

The buffering scheme used for the View window in TNT 2004:70 and earlier was designed and implemented when less than 256 MB of real memory was common for computers, especially when portable computers are used for the TNT products. Now everyone doing professional geospatial analysis uses a computer that has a minimum of 256 MB of memory and perhaps a lot more. This memory can also be faster and use at least Double Data Rate (DDR) access and simultaneous read and write cycles. This means that the TNT 2D Spatial Display process can rely on access to a larger amount of faster real memory than a couple of years ago. Furthermore, you are also setting up views, layouts, TNTatlases, and other materials that have many more layers in them. For example, you view a virtual mosaic or set up a mosaic process with 100s or 1000s of layers. Or, as in the sample Nebraska Land Viewer Atlas accompanying this release, there are many layers of different types used in superposition. It is now quite common to use a View window that superimposes 10 to 20 different layers of different types. An improved memory buffering scheme is used in version 2005:71, which takes advantage of the larger, faster real memory now available to the TNT products.

What Problem Has Been Solved?

Viewing in a TNT product is fast, ranging from fractions of a second for huge internal or linked rasters to seconds for large, scale-controlled geometric objects. Assembling a complex composite view will take more time if the view is made up of many diverse layers requiring reprojecting several rasters, computing shading from a DEM, querying and subsetting large vector objects, and so on. The ability to be able to quickly build this composite view is one feature that distinguishes your 2D and 3D visualization activities in TNT from any other geospatial product, either they can not do it or it takes too long to be practical. This TNT achievement still requires a lot of computing power and drive access and has not changed in this 2005:71 and is a target for future TNT improvements. It is also an area in which dual processors offer some advantages where one processor deals with the X server and the other with the rendering.

This release of your TNT products does greatly improve the speed with which you can add, hide, and modify the component layers of the current view as long as you do not change its scale or location. Previous versions of the TNT products used a single, real memory buffer to accumulate the contribution of each layer in the view area from each geodata object you selected. Each layer added its selected spatial features to this single buffer. When this superposition was complete, this memory buffer was swapped into the screen refresh buffer of your display board to update the contents of the View window. Any activity that required a redraw of the contents of this view required all layers to be reread and this composite buffer to be reconstructed. Your redraws can be grouped into 2 different kinds: those that occur automatically or only on demand depending upon how you have set this preference for your TNT Display process.

Redraws at New Position.

Redraws occur when you move the ground area of your view or zoom it out. Any redraw action that results in repositioning your view relative to the ground requires all the layers used by that view to be reread from their Project File, subjected to all required computations, and used to replace the current view. This is not changed in this release of your TNT products as it is an inherent feature of the GRE wherein the TNT products permit a great deal of flexibility in what and how you view your geodata. This is also why smooth panning and scrolling are not available in the TNT products—any movement of the view relative to the ground requires rereading all the objects and supporting all these flexible viewing computations. This would require computing power and storage access rates not currently available to the TNT GRE.

Repositioning a view is no faster in TNT 2005:71 than 2004:70!

Redraws “In Place.”
Many of your activities in using composite views, display and map layouts, groups, mosaicking, and other TNT procedures require many redraws that do not change the ground area (in other words the extent) of your current view. These activities include adding or deleting a layer, altering the way a layer is viewed, hiding or exposing a hidden layer, and many more. These and other manipulations of the view are becoming more and more common.

Prior to this TNT version, redraw in place activities directly used the single composite view buffer and required the same reread and recompilation of every layer even if it was unchanged in position. Often your operating system automatically caches smaller layers in real memory during their first read making subsequent reads much faster. TNT 2005:71 now creates and retains its own separate pixel cache or buffer in real memory for each layer in your view. The view is then redrawn by recombining the contents of these individual buffers for each layer into the composite buffer read by the display board’s refresh memory. Now any action affecting one layer means only that layer’s buffer would be affected. For example, a vector layer’s buffer is replaced because you changed the query controlling how that vector is displayed. In this activity no other layer buffers are affected and the redraw is faster. If the action you take is something like hiding a layer or moving its position in the display order, no layer needs to be changed. In this case the composite memory buffer is simply recreated from the individual layer buffers. This kind of redraw can be nearly instantaneous.

Redrawing a composite view without changing its extent is much faster in TNT 2005:71!

Impact on Raster Layers.
The attached color plate entitled Spatial Display: Raster Layer Caching presents an example where 256 linked orthoimages are being viewed as a virtual mosaic. Each 7 megabyte JPEG image selected had been lossy compressed 20:1 from its approximately 140 megabyte uncompressed size. The pyramid layers for these images were created in about 20 seconds each as part of building their Project File links by automatically adding all of them to this virtual mosaic. The viewed portion for each for their layer in the composite view was automatically cached in 256 separate layer buffers in real memory. Toggling any orthoimage layer off in the LegendView to hide it will remove it from the view of the virtual mosaic. Since no new data is required by this activity, and that single layer buffer is still available in memory, the automatic redraw of the remaining 255 layers or subsequent redraw of all 256 layers required 0.246 seconds. Hiding and then exposing any or all the layers in this virtual mosaic occurs if you use the new TNT 2005:71 geographically oriented layer hide/expose tools that interact with the view. For information on these new “in-view” selection tools, please see the subsection below entitled GeoTool Box and the new Tool Script for the control of tiled layers discussed in the section on the Geospatial Scripting Language.

Impact on Geometric Layer.
The attached color plate entitled Spatial Display: Geometric Layer Caching provides examples of the impact of the new layer caching on a vector layer in a composite view using 16 objects totaling 4.3 gigabytes. The first view of this complex mixture of raster, vector, and other layer types required 5.406 seconds. During this time all the layers currently visible were read, processed, and cached. But, toggling off the layer in the view which is part of a vector object with 100,000 property ownership polygons required .222 seconds, and it could be toggled back on in the same time. The second example illustrates that deselecting a polygon that has been highlighted by filling it in color is now almost instantaneous.

Technical Implementation.

Separate Layer Buffers.
All the TNT processes that provide 2D Spatial Displays now use a separate area of real memory to cache each selected layer’s separate contribution to the current view. After each of these layer cache buffers has been created from the corresponding selected object or linked object, they are composited together into a single real memory buffer’ that is then used as the composite buffer for the contents of the View window. This composite buffer is then mapped almost instantly into the refresh memory buffer on your display board in a single vertical frame refresh cycle. This is duplicated for each 2D view if you have several View windows open with similar or different contents.

This new caching scheme does not change the time required to add each layer to a view for the first time. Creating a single layer’s current, real memory buffer will take a fraction of a second or longer when the required portion of the geodata object being linked to, pyramided, resampled, reprojected, or any of the other automatic TNT transformations are applied. In other words, the time required for the first viewing of a layer alone or as part of a composite stack is more or less the same as in previous TNT versions. But, any subsequent activity that merely reuses the content of the layers in a composite redraw but does not change the area used from their source objects is now much faster.

Since each layer buffer is now cached separately, the composite buffer and the corresponding refresh buffer can be reassembled almost instantly from these layer buffers to change the view. The GRE is merely reading values for the matching screen pixels from each layer’s buffer, applying any pixel oriented filters, and then combining them with matching pixel values from the other layers into the composite buffer. All these reads and writes are done at real memory read and write cycles, and the display operations on the matching pixels from the layers (for example, creating transparency) are simple and fast. This often requires a fraction of a second for all layers for the entire view. In fact, it is so fast that the time showing for recreating a TNT View window’s contents in the lower left window status line has been changed from showing S (whole seconds) to S.sss (1/1000s of seconds) as many redisplay in-place operations now take less than the previous 1 second timer increment.

Alpha Channel.
The memory cache for each layer in your view uses 32 bits per pixel. The cache is made up of 8-bit RGB color values for a pixel in the current view window and 8 bits for what is commonly called the alpha channel. This alpha channel is to be used for transparency.

Memory Conservation.
Often each layer in a view comes from an object that covers only a part, often a small part, of the area covered by the current view window. A good example of this would be when you are viewing a virtual mosaic made up of 256 adjacent orthoimages. If you are viewing all of these objects in a single view, each represents a layer that covers only 1/256 of the area of the view window or much less if your current View window has a blank frame area around an irregularly shaped mosaic. The TNT layer buffer scheme buffers each of these layers for only those pixels that it contributes to the current view. In this example if the view frame fits the virtual mosaic, the sum of all the memory used for the buffers would be slightly larger due to their overlap than the size of the composite buffer or the refresh buffer. Their sum will be even less for a typical view of the virtual mosaic that contains a large frame or background area, which is in the composite buffer but requires no data from any of the 256 layers.

At the other extreme assume you have 2 of 2D Spatial Display windows open on your dual monitors each of which has 1024 by 768 pixels in its composite view. Each also has 20 objects selected for the composite view each of which covers the entire area of the view. Each layer would require 1024 by 768 by 4 bytes or approximately 3 megabytes. For 2 View windows and extent coverage for 20 full layers, this would total up to about 120 megabytes of real memory. It is very likely that this amount of real memory would be available to this TNT feature on a computer with 256 MB of real memory.

Applications.

Adding / Deleting A Layer.
Adding new layers one at a time into a composite view using the Group Controls dialog is a common practice. In this fashion you can observe the effect of the content of the new layer on the current view. Now when a layer is added to a view in this fashion, it simply creates a new separate cache buffer in real memory. All the other cached buffers for the other existing layers are already available for use. A redraw simply creates a new composite buffer adding in this new layer. However, if you delete the object used as the layer to establish the group projection, this might cause these layer buffers to be purged and rebuilt if the extent, reprojection, or other factors are different for the new auto-match layer.

Toggle Layers Off/On.
You can toggle layers off and back on in a composite view of many layers via the check box in LegendView or the glasses icon in the controls windows. This is frequently done if you wish to check the area of coverage or content contributed by a specific layer to the current view. For example, as discussed above, for a virtual on-screen mosaic of many orthoimages, you can toggle each layer to locate and identify a specific raster object illustrating some problem.

Using LegendView to toggle any layer back on in an existing group/layout view is now almost instantaneous. When a layer is toggled off, the composite memory buffer is simply rebuilt without it. The separate buffer for any layer that is toggled off is retained so that toggling it back on is simply the action of adding it back into the composite buffer. This is particularly useful if you are viewing a complex layout and want to quickly toggle an object off and on in that layout.

Changing Layer Order.
Probably the most common practice affected by this new buffering is that of changing the order of the layers in a view. An example would be to move a raster layer lower in the layer order in LegendView so that the graphics it obscures can be viewed over it. Another practice is to display several raster objects that have overlapping extents and then change their layer order to move them up or down in the layer order to expose one then another.

Interactively dragging a layer’s graphical entry up and down in the order in LegendView will change the order it is used in the composite view. Moving layers up and down in the composite view can also be done with the Raise, Lower, To Top, and To Bottom menu choices in the Group Controls dialog. In either approach this simply changes the order in which all the layer buffers are recomposited into the refresh buffer and this is effectively instantaneous.

Element Selection.
Highlighting a selected element(s) in the view has been fast as these elements were drawn directly into the refresh buffer. However, as discussed below, removing the highlight was slow as the area of the highlight was rebuilt from all layers. Elements that are highlighted are now simply drawn into a separate cache buffer with the desired new style. This refresh buffer is then recreated almost instantly from the contribution layer buffers and the highlighted element(s) takes precedence and replaces the actual element in the view.

Element Deselection.
Selecting a new element in a layer in a view may remove the highlighting of the previously selected element. Previously there was a lag in an element’s deselection from the view while all the layers making up the rectangle containing the element were redrawn to remove the features highlight from the view. Now the highlight of the layer in which the selected element exists is used to overdraw the element when it is first highlighted. When it is unhighlighted this representation of the element in the highlight buffer is deleted and the composite buffer is rebuilt making this unhighlight action almost instantaneous.

Interactive Element Highlighting (mouseover events).
Fast layer buffer control of highlighting and unhighlighting of features now provides a new interactive feature technically called a mouseover event. This is the automatic highlighting of a feature merely because the cursor is near to it. Automatically presenting extensive metadata for features via complex DataTips and GraphTips has been a unique, advanced capability of visualizing your geodata in the TNT products. Now due to the redraw speed of this new layer caching, any combination of the elements to which the DataTips apply can also be instantly highlighted when the DataTip is presented. This new feature is illustrated by the attached color plate entitled Spatial Display: Automatic Highlighting of Vector Elements.

It is also possible to automatically highlight features without showing any DataTip text. In this case the element for that DataTip will be highlighted for the cursor position but no pop-in text will appear. This is also illustrated in the same color plate. These automatic highlight events are set up as DataTips whether or not you show any DataTip text. You can set the highlight color to whatever you choose and to be different from the color used for the direct selection of elements. Transparency fills for mouseover highlighting of polygons is not yet available.

View-in-View.
The interactive View-in-View tool toggles on/off the layers you designate for the area of the elastic box you pull out in the View window. An inset view is created in this box by designating which layers are drawn into the composite buffer for the area outside and inside this box. Adding/deleting layers from it required a redraw in TNT 2004:70. Using the new separate layer caching scheme, this is almost instantaneous. Toggling layers off or on for the inside and outside of the box is also just designating which are drawn into the inside or outside of the box from these same separate caches. This increase in performance means you can now use View-in-View without waiting for redraw when you turn the tool on/off.

LegendView.

Faster addition, selection, management, and viewing of layers introduced above means that your legend entries in the View window may be more and more complex. This has required additional features to help you keep track of the visibility status of the layers in the legend.

Layer Visibility.

Often you have wondered why you do not see any features in the view for a layer that is listed in the LegendView. There are a variety of reasons why a layer’s content is currently hidden. It may be set to be hidden or at least hidden for the current scale, have no coverage of the extent, a redraw is necessary, and other circumstances. It can take time to figure out the reason they are off and not currently visible. To help you in keeping track of this, LegendView now uses color to identify the visibility status of each layer in the current view. These new alert colors are illustrated in the attached color plate entitled Spatial Display: Subtle Display Hints in LegendView. The DataTip automatically provided for every layer name in the Legend View also has a new last line that explains the reason if a layer is not visible.

Blue: Off By Extent.
A layer name in blue in the LegendView is indicating that the extent of this layer has no common coverage of the extent of your current view. You commonly get this result when you have small layers covering only a portion of the view. You zoom in and a layer’s name turns blue because it has no coverage of the area viewed. The DataTip for the layer’s name in the LegendView also shows that the layer is “Outside visible extent.” When you zoom back out or pan your view into the extent of this layer, this will change color to indicate that the layer now has some coverage of the view. Note that it may still not be visible if it is obscured by being under an opaque raster layer.

Green: Off By Scale.
A layer name in green in the LegendView is indicating that the current view has a scale that is outside the scale range set for this layer. Scale ranges for raster or geometric layers that properly reflect their content will commonly produce this result as you zoom in and zoom out. The DataTip for the layer’s name in the LegendView also shows that the layer is “Not visible at current scale.” If your complex views seem slow and do not produce any of these green entries, then you are probably not setting any viewing scale ranges for your objects.

Red: Layer Has Changed.
A layer name in red in the LegendView is indicating that the current view has a layer that has been changed and that the changes will not appear until you do a redraw. In setting up and working with a large number of objects for a view, it is common to shut off the automatic redraw and redraw only on demand via the icon, menu entry, or a hot key. Under this circumstance those layers that have not yet been drawn or have been changed by a style or other change will be red. The DataTip for the layer’s name in the LegendView also shows that the layer is “Not yet rendered – Press Redraw.”

Gray: Toggled Off.
You toggle off a layer to temporarily hide it. Now in addition to changing the check box to empty that layer name will also change to gray. If you toggle off an entire group, the name of all its layers will show as gray.

Black but Not Visible.
This condition can not yet be automatically detected and can occur if you have a raster object covering the entire view with no transparency effects assigned and placed higher in the display order than any other layers. Another common condition is that the layer names are black and you see nothing or at best dots or tiny-sized features in your view. This will occur when you have errors in the CRS of these objects that are creating views with very large, often global scale views, in which your layers are mere dots at their incorrect scales and locations.

Duplicate Legend Styles.

Duplicate styles in a layer’s element legend are automatically merged by default. An earlier TNT release added this feature to compact style lists and by listing in one text line all the attributes sharing that style next to the single legend entry. If many attribute types are assigned the same style, their text entries are concatenated into that legend entry, which is shortened to fit in the LegendView by inserting an ellipsis. Thus some attribute names can be omitted entirely. This can also carry through to shorten the legend entries in a map layout. Under these circumstances many attributes are assigned the same style and it is not possible to find a particular attribute’s style. Now, merging entries or not merging entries in LegendView is optional. As outlined, merging the list is the default setting to provide a manageable LegendView list. To prevent them from merging, toggle off the “Merge duplicate styles in legend” button in the Vector Layer Controls dialog. This optional setting and its behavior in multi-object legends in a layout is illustrated in the attached color plate entitled Spatial Display: Merging LegendView Entries.

Shapefile Themes.

Linking to a shapefile will use its original styles only if a style file (*.avl) is found in the same directory with the same name as the shapefile (*.shp). Otherwise, default styles will be used or you must style these shapefile elements in the Project File link. This is not new, but now this version handles shapefile styling that is by theme range and not by styling each element type. If the TNT linking procedure encounters a shapefile with theme styles, it creates an equivalent set of theme ranges and styles in the link file. This linked shapefile object will then show the same theme ranges in TNT as it exhibits in ArcView. Since these theme ranges are in the Project File link, they can be edited to add or change ranges just as if they were created for an internal geodata object. This is illustrated in the bottom portion of the attached color plate entitled Theme Mapping: Editing Shapefile Theme Ranges. These altered themes will not be altered in the linked shapefile. To accomplish this you would need to import the shapefile into a geometric object, alter its theme ranges, and export the results to a new shapefile.

Improved Line Intersections.

You style lines so that some specific feature they represent can be identified. You may strive for realism by using dual parallel line styles for a divided highway or common symbolic representation, such as using a red-white dashed line for an unpaved road. The result is many different styles of multiple components can be assigned to the lines in a single geometric object. Another alternative is to cover the actual intersections with a node symbol that identifies the type of intersection. This is commonly used on state road maps to denote a complex interchange on an Interstate highway.

When symbolic intersections are not used, the attractive intersection of complex line styles at various scales can present complex situations. Depending upon the purpose of the map, these complex intersections may have to be manually prepared at the desired reproduction scale in a pixel editor.

Single pass rendering in the TNT products may produce suitable results in many situations and application areas. Lines are rendered in an order you do not control if they are all in the same geometric layer. Thus at intersections, a line in one style that crosses a line that has different styling will simply obliterate the earlier line in the area of the intersection. This effect of rendering lines in a geometric object in a single pass is acceptable for many applications such as forestry, geology, and so on.

Multiple pass rendering can now be used as an option to improve typical types of line intersections as illustrated in the color plate entitled Spatial Display: Improving Line Intersections. This special effect slows down the rendering somewhat. It can be used as needed, such as in rendering a map with a road net to a raster for printing. Turn on the “Use multi-pass for improved style joining” toggle on the Lines tabbed panel of the Vector Layer Controls dialog to use this multiple pass reconciliation of line intersections.

Partially Transparent Point Symbols.

Open symbols, symbols whose polygon elements are not filled, permit the underlying features to be seen inside the symbol in a 2D or 3D view. A simple, solid-filled square can be used to represent every road intersection or other node whereas a larger, unfilled square might be used over a road intersection or node to denote some special condition. The unfilled square would permit the actual nature of the road intersection and surrounding features to show as well.

A third option now permits setting partial symbol transparency in both 2D and 3D views to permit subtle and visually appealing effects in screen views and printed maps. This is especially effective in 3D views, simulations, and movies where you may permit relative scale symbols to grow large in the foreground. With judicious use of partially transparent fills, these symbols will appear small and solid in the distance since only their solid boundary elements are apparent. In the foreground they can be large and transparent allowing the surface features to show through if they have a high level of transparency set for their color fill elements.

Any component in any symbol you create can now have a transparency level set for it in percent. These partially transparent symbols or symbol components, such as a polygon fill, permit anything under them to show through the symbol’s components. The transparency of each symbol’s component is set in the Color Editor window at the same place you set its custom color. Some examples of the results of setting a partial transparency level are illustrated in the lower portion of the attached color plate entitled Spatial Display: Partially Transparent Symbols.

Miscellaneous.

Clipping.
When geographically attaching a group to another group in a layout, it is now optional to clip to the attached group. An example of the use of this would be to add another geospatial group that extends beyond the edge of the clipping area for the group geographically attached to.

Raster Correlation Histogram.
Use default palette with wider spectrum and gray as minimum value to improve ability to distinguish differences in values.

Map Grid Ticks.
UTM map grids can now optionally contain a global quadrant identifier in their tick mark labels. UTM labels can be xXX or xXXN (where N = North or E = East). Adding this direction to the label avoids ambiguity near corners as to which coordinate is which.

GeoToolbox.
In complex views of many layers it may be difficult to determine which layers to turn on and off for an area of interest. The attached color plate entitled GeoToolbox: Show/Hide Areas of Interest illustrates this. In this example a layout was used to build a view of a regional map with many small orthophotos covering this region. Finding those images that cover only an area of interest in the larger region using only the show/hide toggle for each photo can be difficult. You are faced with a long list of 100s of images or detailed scale maps with no clear idea of their geographic location in the region.

If all the smaller component image or map rasters are geographically related your area of interest can now be shown or hidden using the area tools in the GeoToolbox. The Select tabbed panel in the GeoToolbox for any area tool (rectangle, circle, polygon, …) provides new Show Layers and Hide Layers buttons. These will Show/Hide the layers in the group for the current area of that tool. These Show and Hide buttons each have a drop down menu to let you choose which selection of layers should be used in that action: Partially Inside, Completely Inside, Partially Outside, or Completely Outside.

DataTips
The “All Layers” option for DataTips has been renamed “Maximum” because it is limited to a maximum of 20 lines (or a few more if the 20^th line begins a multi-line DataTip). A new “Automatic by Scale” option has been added. When you use this option, layers that turn on and/or off by scale are not shown in a DataTip if you are zoomed in 100X more than the map scale at which the layer display turns off or zoomed out 10X more than the map scale at which the layer display turns on. Thus, a layer that is set to display between 1:1,000,000 and 1:240,000 will be represented in the DataTip at viewing scales between 1:10,000,000 and 1:2,400.

* 3D Display.

Several previous releases of the TNT products have provided incremental modifications to the original 3D Display process to improve old features and add new features. Over this same period this process was being completely rewritten to include many of the interesting and advanced features you use in your 2D Display activities in the TNT products. Some components of this new process were made available as additions to the original 3D process as they became available, for example, mipmapping and new terrain rendering models were provided for higher quality views.

After 3 years of effort the new 3D Display process is available with many features previously available only in 2D views. All the older, previously missing features are available in the new 3D Display process. As a result the original 3D process has been removed from the TNT products. Gone are its hybrid features such as selecting an older rendering model in order to make a movie or choosing one model for speed or another for quality. The new 3D Display process is fast, provides high quality views with all the earlier features, now has the same LegendView features as 2D display with all its powerful layer controls, provides DataTips for features, and has other new features tailored specifically toward current and planned 3D geospatial analysis activities.

3D Rendering Engine.

The 3D Display in TNT 2004:70 provided use of an optional Variable Triangulation model. It integrated all the improvements in speed and quality of earlier terrain rendering models tested in the older 3D process. The older Dense Ray Casting and Sparse Triangulation rendering models were also options in TNT 2004:70 since they provided you access to older, legacy 3D features that had not yet been implemented for this newest model. Since all these legacy features are now available for the new variable triangulation rendering engine, it is now used automatically, and you no longer need to choose the surface rendering method to be used.

Trading Storage Space for Speed.

Variable triangulation means that for every viewpoint, the foreground elevation triangles represent small ground areas to provide surface detail, whereas the distant triangles represent large ground areas while still preserving points of terrain inflection as vertices. Think of it this way, your view on the screen has a fixed number of pixels. The size of a triangle in the foreground must be small to map to a single pixel. A triangle in the distant part of the view can be quite large and still map to a single pixel. An error tolerance can then control how many pixels (1 or more) can be covered by each triangle in this net. This setting will determine how many and which variable triangles need to be computed by a subdivision strategy and, thus, the speed of rendering and the quality of the view.

This variable triangle network must be computed from the elevation raster for the first and every new viewpoint. The computation of this triangulation net can take several minutes for large terrain rasters. However, this computation can be accelerated by a factor of 10 to 30 times (from minutes to seconds) if certain viewpoint-independent properties of the terrain triangulation have been precomputed and stored with the terrain raster. These properties relate to the complexity of the terrain and can be used over and over for each new viewpoint. They are also independent of any surface drape layer you might eventually use with this terrain.

Since these triangulation properties are inherent in the terrain and do not vary with the viewpoint, they can be stored permanently with the terrain raster object. A special subobject of the terrain raster now stores 3 triangulation properties in an inverted tree-like structure (i.e., like a root system) of raster subobjects for efficient access. (For ease of discussion, the following section refers to each of these properties as single raster subobjects.) These triangulation properties are then automatically detected, read, and used to reconstruct the triangulation whenever the viewpoint changes within a 3D view. Some examples of the relative times for creating 3D views using large terrains with and without these 3 auxiliary raster can be compared in the table included in the attached color plate entitled 3D Display: Faster Display with Stored Terrain Properties.

Triangulation Properties Rasters.

Their Significance.
The first time rendering using small terrain objects, for example up to 1000 by 1000 elevation cells, is now a few seconds. However, as in all aspects of geospatial analysis and visualization, much larger terrain and texture layers are now available to you. Their first rendering using a large terrain, such as 5000 by 5000 cells, and a much finer detail texture drape can be slow if the 3D process cannot simply find and read the 3 triangulation property rasters. In this case the 3D Display process has to first compute the special structure raster from the original elevation raster you select. By precomputing and storing subobject raster with the elevation raster, your first 3D view can be much faster (seconds instead of minutes). Whether these rasters are first computed in the 3D process or read from the raster object, all subsequent repositioning or redraws of the view of this terrain layer will automatically use them.

The values of the cells in these property rasters are organized in a tree-like structure for easy access when they are used to construct the finer and finer triangles needed in the variable triangulation. While this structure is unique to this level-of-detail oriented application, it still contains one computed value for each original elevation cell. The technical concept of variable triangulation and its use of these 3 special Optimized Elevation, Error, and Radius property rasters are described in the report:

Terrain Simplification Simplified: A General Framework for View-Dependent Out-of-Core Visualization. P. Lindstrom and V. Pascucci. 2002. USDOE, Lawrence Livermore National Laboratory. Preprint UCRL-JC-147847. 25 pages. Available at www.llnl.gov/icc/sdd/img/images/pdf/tvcg02_lindstrom.pdf.

The method is designed specifically for applications where rendering quality and the large size of the terrain are the main considerations, not real time animation. It provides the basis for applications that stress flexibility over speed—where DirectX and OpenGL are less useful—and where the terrain model must operate in real memory to support layer management, feature selection, and other special features.

Optimized Elevation Raster.
This special form of the elevation raster contains the same elevation cell values in the same data type as the primary raster object but in this special optimized tree structure. The stored size of this subobject set is approximately equal to the uncompressed size of the primary elevation raster without pyramid layers.

Error Raster.
This raster contains the maximum discrepancy between each cell’s elevation value in the original primary raster and the value the variable triangulation model is allowed to produce for this same cell. This raster matches the data type and stored size of the primary elevation raster.

Radius Raster.
This raster contains a floating-point property of the model for each cell. Since it has one floating-point value for each original elevation cell, it is 1 to 2 times the uncompressed size of the primary raster object (for 32-bit floating-point and 16-bit integer elevation rasters, respectively).

Net Result.
From the above you find that computing these 3 rasters and storing them as subobjects with the primary elevation raster object used in other TNT processes increases its size from 3 to 6 times (or more if the elevation raster is compressed). However, remember that elevation rasters are not common and hard to come by, usually singular and unique, and have a large cell size relative to your many images. Storage is cheap, and this increased size greatly improves the speed of the first view in 3D.

Computed During Import.
The recommended means of preparing these special raster structures is to compute them when you import an elevation grid into a raster object you intend to use for a 3D display. The new Import process provides an option for this purpose that is available for any raster format. Choosing this option will still import the elevation as a primary raster object with pyramids for use in other TNT processes. It will also compute and save these 3 triangulation property rasters and add them to this raster object in the subobject structure described above. This increases the raster object’s size as noted above but performs this additional computation once as part of the import where the added delay is of minor importance.

Computed For First View.
If these 3 terrain properties are stored with the elevation raster object you select for use in a 3D display, they are automatically read and used for the first and each additional 3D viewpoint. If they are not precomputed and already part of the elevation raster object, the 3D process will automatically compute them during the initial rendering of the 3D view of the terrain and its draped layers. This will delay the first 3D view, but each subsequent repositioning of the view will be fast since they are available in memory. By default these 3 properties are automatically saved in the previously-described subobject structure under the elevation raster so they will be available the next time you use this raster object as a terrain in a 3D view. If for some reason you do not want to save these properties for future use, turn off the “Save optimization structure for fast startup” toggle on the Surface Layer Controls dialog after you select the terrain raster but before you add other layers and render the perspective view.

Possible Additions.
A utility procedure to build and add these property raster subobjects, separate from the 3D display, may be useful. Like pyramid layers, any TNT activity that alters the primary elevation raster object, such as extracting a piece, sampling, or reprojecting, will require that these subobjects be rebuilt for the new object generated. It is possible that the size of these rasters might be reduced by lossless compression, but decompressing them for every new view might then reduce performance. Also since one of these rasters is floating point, MicroImages would need to implement a lossless floating point compression algorithm.

Trading Quality for Speed.

Why Not Always Maximum Quality.?
Your 3D visualization activities in the TNT products can vary widely between projects. Now that a 3D view has the same LegendView controls as a 2D view, it might be the primary way in which you view your geodata when very accurate terrain rendering is not important. In the next project you may use a 3D reference view with moderate accuracy while you edit in a 2D view. You may be setting up to make a movie where you want to minimize the effects of terrain popping or jumping and the movie will be rendered in slow time while you are doing something else. Or, you may be preparing a poster from high resolution geodata sources where high accuracy is important and time to render is not.

Setting a Morphing Error Tolerance.
As detailed above, the variable triangulation model drapes all the texture layers over a triangular terrain net with small triangles representing foreground and high-relief features and large triangles for areas in the distance. The new “Error Tolerance” parameter in the Surface Layer Controls dialog lets you set how much the elevation modeled by the variable triangulation can deviate from the actual elevation surface for each raster cell. Set this value for your specific terrain layer and its complexity to accommodate your current 3D viewing objective. The smaller you set this tolerance, the smaller each triangle will be, thus improving vertical accuracy in the view. Correspondingly, many more triangles will be needed taking more time to recompute for each new viewpoint.

The attached color plate entitled 3D Display: Control Accuracy of Terrain Rendering illustrates the results of setting this tolerance and discusses its use in detail. To summarize this discussion, this morphing error tolerance setting controls how far vertically (in screen pixels) any location on this surface might be displaced up or down from its correct position when the triangulation model is constructed for the current view. The lowest setting of .5 pixels means that nowhere in the view at any distance to the surface will any location be displaced more than .5 pixels from its correct vertical position. The highest setting of 10 means that you will tolerate a morphing error or vertical displacement up or down of up to 10 screen pixels in order to achieve a maximum preview redraw rate.

Results for Settings.
The color plate illustrates the visual results of using the extremes in the morphing error tolerance settings. At a casual glance you would not notice the distortions for a setting of 10 until they are pointed out to you. In the earlier 3D view application you might have used only the wireframe to rapidly position a view. Using a tolerance of 10 permits you to view the terrain and its image texture layer for such rapid initial positioning and most other simple 3D viewing actions. At any time you can lower this tolerance setting for a slower, more accurate rendering. This color plate also provides a table to evaluate the time differences between small and large error tolerance settings when viewing reasonably large terrain and texture layers.

Since the variable triangulation rendering engine is fast at the triangle splitting operation when the triangulation property rasters are available, and since other aspects of rendering take time, there is not a huge variation in display time between the extreme settings of this tolerance for most viewpoints. In one test run reported on this color plate, the time to render varied 3 to 1 and in the second case the difference was only 1.3 to 1. For this reason the default setting for this tolerance is set at 3 pixels, which may be suitable for most of your 3D viewing activities. Also note from this table that changing to a new viewpoint is much faster since the 3 property rasters are automatically cached in memory, which makes access to them much faster in a new variable triangular computation for a new view.

Turn Off Mipmapping.
Anisotropic mipmapping is the most complex method available for smoothing a 3D view especially to smooth pixelation in the foreground. It requires a sort of random access to cells scattered throughout the texture layer(s) for computing each screen pixel and these cannot be effectively buffered. It is also computationally intense when implemented in software. It will slow down a 3D display by a factor of 5. It is on by default for each layer to insure that you get the final best quality 3D view possible. You can temporarily switch from the MipMap Anisotropic sampling option to Nearest Neighbor using the Texture Filter menu on the Raster Layer Controls / Options panel as you add each texture layer. You can also directly access this dialog to make this change using the Controls entry at the top of the right mouse menu presented when you click on the texture layer's name in the LegendView.

Redraw a 3D view for a new viewpoint in 1 second by switching the view’s texture filtering temporarily from mipmapping to nearest neighbor.

Summary.
Progressively larger triangles are used as the screen pixels map to larger and larger ground areas in the more distant areas of the view. For speed only larger triangles are initially formed for the terrain using the triangulation property rasters. For every view or new viewpoint these triangles are broken down into smaller and smaller sizes as they are needed for the foreground and high-relief portions of the view. All the proportional sizes of the triangles used in each view are controlled by a morphing error tolerance setting. Thus for a tolerance setting of .5 pixels you are requiring that your textures and overlays are rendered with an elevation accuracy of more or less 1 screen pixel everywhere within the view. A tolerance setting of 10 means that much larger triangles can be used requiring less triangle splitting and other computations providing faster rendering.

So where does all this end up? If you follow through the tables, you will find that an elevation raster of about 5000 by 5000 cells can be draped with about 10,000 by 10,000 image cells in 20 seconds for the first view and 3 seconds for any redraw operation. These times assume that you have already computed and stored the triangulation property rasters during import or by viewing this terrain once in 3D and also use an Error Tolerance setting of 3 pixels. If you will temporarily switch off mipmapping as the texture filter, you will achieve about 1 second redraw with a good quality view with a slight pixelation in the foreground cells depending upon your current vertical view angle and altitude (low view angles at low altitude give more pixelation in this mode). This is the base time for then adding or deleting geometric layers and features for this high quality 3D view of a moderately large geodata set.

Draping Geometric Layers.

Benefits.
Previous versions of the 3D Display process rendered each geometric layer (vector, CAD, shape, and pinmaps) into the image selected for the drape layer. It then draped this composite raster over the terrain to produce the 3D view. This older design prevented the addition to 3D views of any sort of realistic layer-oriented features such as layer controls, DataTips, transparency, and many, many more of the visualization features popular in 2D Display. Now 3D Display is fast enough to support direct rendering of geometric layers to the 3D view, achieving useful redraw rates when you pick a new viewpoint or add or hide a layer. This innovation allows many other new additions to bring the features and operation of 3D views into alignment with 2D Display.

Buffering.
Layers you add to a 3D view are now rendered individually into that view directly from their original object types. This is technically important as it permits individual elements in the 3D view to detect the nearby mouse cursor position and retrieve attributes for display as DataTips, allows elements to be highlighted in the 3D view when they are selected (by left-click in the 2D view or by a query), and many other important geospatial features. It also significantly improves the quality of the rendering of styling, transparency, perspective, and other visual properties of geometric elements. For example, line patterns are attractively rendered even as they vanish into the distance. These effects are illustrated in the attached color plate entitled 3D Display: Perspective Rendering of Geometric Layers.

Each layer is still rendered into a composite TNT display buffer, which is transferred as needed into your display board’s refresh buffer. Separate layer buffers as described above in the section on 2D Display are not used as yet in 3D Display. In 2D views, 2D or 3D geometric and raster objects can be added to the plane of your view in the order you select or subsequently arrange them. In a 3D view, 3D geometric objects may be rendered in front of or behind the terrain and in front of or behind each other. Thus it is not a simple matter of rendering each object to a separate layer buffer as in 2D. Furthermore, geometric elements have 2D styles and eventually 3D shapes and styles whose interaction in their order of rendering must be considered. For example, consider just the complexity of the interaction of 2 line styles in 3D, then consider the complexity of blending transparent features as they cross in front of and behind other line styles in a 3D view. At the moment MicroImages is discussing what priority to give the implementation of a combined individual layer content and depth buffering approach to provide similar fast layer manipulations of the redraw of a 3D view such as those introduced and described above for 2D views in this release.

LegendView.

Many of the features in the 2D version of LegendView are unique to the TNT products and more are being added with each release. Now this same LegendView can be used to control the layers, order, view styles, and set other properties of your 3D Display. Since this 3D LegendView uses the same code as in a 2D view, its operation and features closely parallel those you are already familiar with from your previous 2D viewing activities. Therefore, it is not necessary to expand further on the operation of the use of LegendView even though it is a major new addition to a 3D view. The attached color plate entitled 3D Display: Use LegendView to Toggle Layers illustrates this powerful new addition to your 3D viewing.

DataTips.

DataTips, GraphTips, computed fields, and other element-specific features are now available in 3D views. The occurrence of a DataTip in a 3D view is illustrated in the attached color plate entitled 3D Display: Use LegendView to Toggle Layers. Previously, 3D views were quite static when compared to the interactive capabilities of TNT 2D views. Now with DataTips and these other features, your 3D views can have the same level of interaction with the elements in the view. It is even more intuitive to have complex DataTip information appear for a position in a 3D view than in a 2D view. However, it is important to understand that if your cursor is over a very distant area in the view, its DataTip attributes and coordinate readouts may be ambiguous since many elements may occupy that area in the view.

Styling.

All the various styling you assign to 2D geometric element types will now be rendered for these elements when then are draped on a surface in a 3D view. These styled elements will conform to the surface shape with the appropriate perspective in the view.

Lines.

Lines can be rendered as solid lines or with any available line pattern.

Polygons.

Polygons can be rendered with any fill type including solid, transparent, hatch patterns, and bit-mapped patterns. Samples of how these various fills appear are illustrated in the attached color plate entitled 3D Display: Polygon Styling Options. This plate also illustrates a useful new polygon style feature available in 3D only. Filling polygons in 3D views often can obscure the surface images. As an alternative, try leaving the polygons unfilled and use a wide polygon border instead. Polygon borders in 3D views are now drawn on the inside edge of each polygon boundary rather than centered on the boundary. Boundaries that are shared between adjacent polygons get separate borders rendered inside their respective polygons. Wide borders (solid or with a pattern) can thus help identify the polygons without obscuring their interiors. This is an approach taken in printed maps where the interior of the polygons contain other information such as city names, roads, and so on. Unfortunately, you can not yet use this inside border feature for map styling in 2D views.

Symbols.

Point symbols can be draped on the surface from a vector object or via pin mapping with the same styling as in 2D. Symbols draped on the terrain are illustrated in the attached color plate entitled 3D Display: Perspective Rendering of Geometric Layers. Vector point symbols can also be rendered in an upright, billboard orientation. Billboarded symbols are illustrated in the lower right corner of the attached color plate entitled Spatial Display: Partially Transparent Symbols. This plate also illustrates a new feature added to both 2D and 3D symbol styles: you can assign partial transparency for any element used in a symbol. This new transparency feature is described above in more detail in the section on 2D Display entitled Partially Transparent Point Symbols.

Labels.

Draped Labels.
Label elements in a vector layer and labels assigned on-the-fly for a layer can now be rendered in 3D draped on the terrain. They are viewed in perspective (larger in foreground and vanishing in the rear) with the orientation originally assigned to them in the object. For example, if all labels are oriented East to West then that is the orientation they will have in a 3D view—as you rotate the view the labels will be pasted on the surface and rotate with it. The outline boxes (frames) of the labels are also rendered together with their straight line or triangular leaders. Text styling is preserved, along with color, box color and transparency, and so on. Several different uses of labels draped on the surface are illustrated in the attached color plate entitled 3D Display: Drape Labels over Terrain.

Current Plans.
Having good, flexible labeling in a 3D view is another of those special requirements of geospatial systems that would not have a high priority in a game or flight simulator. To render labels in 3D in perspective draped on a triangular model, this text also has to be rendered as triangles just as other geometric object elements such as point symbols and polygons filled with hatch patterns are. TNT’s font rendering engine will now serve up a glyph, or character, in any language in this microtriangular structure for rendering in 3D. Now that this has been implemented, support for other optional rendering methods for labels is underway. For example, labels could remain draped on the terrain but reorient themselves in 3D to be parallel to the bottom of the view in billboard fashion. Other options could raise the labels up off the terrain as billboards into the plane of the view to avoid distorting them (for example, the symbols and text showing in Google Earth). Labels could be extruded up from the surface and so on. Draping the labels on the terrain was the hardest implementation. Implementing these other variants primarily involves adding the interface dialog needed to select and define their properties.

Solid Shapes.

Shapes.
Elements in a TNT vector object can have XYZ coordinates even though the topology of such a vector object is only maintained in the X-Y plane. This is commonly called a vector object with 2.5D topology. Adding this vector object to a 3D view adds elements that in the 3D space can lie on, below, or intersect the terrain surface. These elements can be rendered in a limited initial number of solid shapes. 3D points that have been styled for 2D display with square symbols of a specified size and color will render in 3D as cubes with that size and color; those that have been styled with circles render in 3D as spheres. Solid lines are rendered as continuous, colored, cylindrical pipes whose diameters are the widths set for each line. Dashed lines are a sequence of cylinders and spheres. All these simple 3D shapes are shaded according to the sun elevation and azimuth set for their group with the Viewpoint Controls window. These solid elements are illustrated in the attached color plate entitled 3D Display: Render 3D Elements as 3D Shapes.

Features.
These solid elements are rendered with perspective and their sizes will vary according to their distance into the 3D space of the current 3D view. The elements in a 2D vector object can be converted to 3D by transferring Z values from a corresponding elevation raster. If the resulting 3D vector is displayed in a 3D view with the source elevation raster as the terrain surface, all of the 3D vector elements will lie on this terrain, and their 3D solid shapes will intersect the surface in the 3D view. Thus, they can also be viewed from below using a viewpoint setting below the terrain.

Plans.
Solid objects in a 3D space, like all other features in a TNT 3D view, are rendered using triangles with textures mapped onto them. TNT can now render solids whose shapes can be defined by a 2D style (squares or circles). Rendering more complex solid shapes will require the selection or design of a format for defining 3D styles. You will then need a dialog to enable you to design, store, select, and assign these styles to the elements. Before this becomes important, it will be necessary to find sources of XYZ spatial data to import that are useful in geospatial analysis or create more operations in the TNT products to create elements that do not lie on the terrain surface.

Sharp Stereo.

The 3D Display in 2004:70 provided multiple approaches for viewing 2D and 3D surfaces in stereo using some sort of additional viewing device. The 3D Display in all the TNT products now supports direct, unaided stereo using the Sharp monitor described in detail in the color plate entitled 3D Display: Stereo Viewing on the Sharp 3D Monitor. This monitor produces excellent stereo for direct viewing without the use of any viewing device. The color plate notes that this monitor has a price of US$1500. Just a few days ago Sharp sent a notice to its software developers that this monitor could be ordered for US$450. It is assumed that this means that this particular product is being discontinued and the inventory cleaned out. It seems that anyone could try to purchase this monitor. Perhaps Sharp is about to release a 17-inch or larger version of this monitor with more pixels, irrespective of price the current model is too small to be used in its non-stereo mode for routine work.

Movies.

MPEG and AVI movies can now be made with this new 3D high quality rendering method. Previous releases used only the older, now deprecated, rendering methods for this purpose. These movies can contain all the styled elements outlined above. TNTsim3D now provides a geospatial script to record your flight path and its view direction, smooth it, and make a movie of it. However, 3D Display permits much more flexibility in the kinds of geospatial features you can include but works in slow time as contrasted to a simulation. While such a movie is time consuming to compute, this approach provides the opportunity to create movie frames of higher quality and with more cartographic features than in TNTsim3D.

Possible Future Efforts.

More options for displaying labels would be the most immediate need in this process. Other options such as solid symbol design and compressing the triangulation raster subobjects have also been mentioned. It may even be possible to significantly speed up the rendering of a 3D view by using the DirectX or OpenGL supported by your graphics board. This will not turn 3D Display into a simulation since it must still build views from multiple, complex layers. However, rendering a 3D view in a time near that of the 2D view would make using these 2 views together more interactive. For example, an element selected in a 2D view could also be highlighted immediately in the 3D view of the same area and vice versa.

Georeferencing.

Conformal has been added to the list of models at Edit / Georeference / Model. This shape-preserving model allows rotation, scaling (same for both axes), and positioning while preventing distortion of features due to shear or differential scaling of each axis.

Raster Extract.

This process permitted you to extract irregular area(s) from an input raster object into the new raster object with the remainder of the raster filled with null values. The irregular area(s) to be extracted could be defined by a manual sketch, a mask, a region(s), or the selected polygon(s). The most common use is to use a polygon(s) to define the cells to be transferred to the output raster. However, in TNT 2004:70 only polygons in a vector object could be used. It is more likely that the area(s) you wish to extract are defined by a polygon(s) in a shapefile or a CAD object. TNT 2005:71 adds this new capability for using polygons selected from any geometric object type.

Raster Resample and Reproject.

Default Conversion of Cell Size.

When a projection system is being changed, the cell size will now automatically be matched to the cell size of the projection of the input raster. You can then change it if you require a different exact cell size. For example, if you are reprojecting a raster from UTM coordinates to a raster in Geographic coordinates, a default cell size in degrees will be computed and filled in as the default cell size of the reprojected raster. A typical application would be to convert a UTM raster to WGS84 latitude and longitude cells for use in the mandatory coordinates automatically used by Google Earth. This requirement was discussed in detail in the major section above entitled Introducing TNTmap 2005:71 describing its use as a gateway to add layers to Google Earth. Similarly this reprojection is required before you export a raster for use in Google Earth with its KML description. Without this new default to a comparable cell size in degrees in these situations, you would need to manually compute and fill in this cell size in degrees to reproject into these geographic coordinates.

New Conformal Model.

Conformal has been added to the list of reprojection models. This shape preserving model allows rotation and scaling (same for both axes) and positioning while preventing distortion of features due to their shear or differential scaling.

Matching Extents to Input.

In TNT 2004:70 you were able to set resampling to exactly match the extents of a reference layer. Now, when you are not using a reference raster, your output raster grid will automatically align with the input grid. The new raster will also be a multiple of the input cell size. For example, if the output cell size is 10 meters, the resulting raster extents will be a multiple of 10 meters and expanded as needed by 1 cell to accommodate this.

Predefined Raster Combinations.

The process for computing combinations of raster objects has been recoded (Process / Raster / Combine / Predefined). Using this new code base it has been easy to add a number of new features from the list and that you have requested at one time or another. Only these new capabilities are listed here.

Input.

The same raster can be selected for use more than one time, for example, for use in an algebraic expression.

Algebraic.

Now you can rescale results of a combination to a data value range you specify.

Statistics.

Statistics can now be computed for corresponding cells in a set of rasters and saved in a new raster object(s). These include the Count, Mean, Median, Mode, Minimum, Maximum, Diversity, Sum, Standard Deviation, Variance, Regression Slope, Regression Offset, or all of these at once.

Logical.

Combining rasters with an exclusive OR (Exclusive Union (XOR)) has been added.

Vegetation Indices.

The tasseled cap operation can be performed on Landsat 7 ETM+ images.

Output.

Choose from any of the TNT compression methods for your output raster objects. These include Standard Lossless, Huffman, JPEG2000 Lossless, JPEG2000 Best Quality, JPEG2000 User-Defined, JPEG Best Quality, or JPEG User-Defined.

An existing raster object can be selected as the output raster object, which is convenient if you are experimenting and wish to continue to reuse the same destination raster object without continually re-allocating new space.

Raster Mosaic.

Introduction.

Modifications have been made to increase the robustness of TNTmips for mosaicking large numbers of rasters and then compressing the large raster that results. The large mosaic may be the objective of this operation as described in detail in this section. However, it is even more likely that your objective would be to start with orthorectified images, maps, or DEMs covering a large area in some logical pieces. But these are not the pieces, Coordinate Reference System, compression, or format that you need. Creating geodata layers for use in Google Earth, a Web Map Server, or a large tiled printing task are just some examples of these applications. The easiest means of meeting these objectives to mosaic the available spatial data into a large geodata raster object in the needed CRS. It can then be cut up into smaller objects of the correct size, compression, and format.

As a test of these improvements, a single 1-meter color image of all of Nebraska has been mosaicked and lossy compressed 200:1 to fit on a DVD for free distribution and use as a sample TNTatlas. This TNTatlas is provided to you as part of the hardcopy release of TNT 2005:71 to illustrate the results of this more efficient capability. The specific contents of this DVD are discussed in the attached color plate entitled TNTatlas: Nebraska Land Viewer Atlas. These new mosaic features and the most efficient step by step approach to this kind of task are discussed here.

Mac OS X Setup.

All the activities reported here were completed using TNTmips on a PowerMac with dual 2 GHz processors using Mac OS X 10.4.2, dual internal SATA drives, and an external hard drive of 1 terabyte connected by Firewire 800. All drives were first formatted as Mac OS X Extended (Journaled). No step in this activity used more than 2 GB of real memory. The read/write performance of various hard drives for this application is discussed in the major section above entitled Hardware News. From it you find that this large external Firewire 800 drive provided read/write operations that are faster than the internal SATA drives.

Acquiring the Input Orthoimages.

Description.
This test of the mosaic process started with downloading 5867 public domain rasters from the Nebraska Department of Natural Resources Internet site (www.dnr.state.ne.us/databank/fsa03.html). Each raster represents a color digital orthophoto quarter quadrangle (DOQQ) covering a 3.75′ by 3.75′ ground area. All were acquired in the early summer of 2003 using a Leica ADS40 Digital Camera and orthorectification system. Each of these DOQQs is made up of 1 meter, 24-bit color image cells in the Nebraska State Plane Coordinate Reference System (CRS) in feet. For your information, standard topographic and geologic maps of the United States are published in units covering 7.5′ by 7.5′ in area and this is called a map quadrangle, as a result these orthophoto units are referred to as Digital Orthophoto Quarter Quads (DOQQs).

Each of these 5867 DOQQs available from this web site has been compressed from the original source imagery about 20 to 1 using JPEG compression. No access to the original uncompressed DOQQ is available if it still exists or ever existed. The size of each DOQQ JPEG file ranges from 5 to 8 megabytes. Every JPEG DOQQ file (*.jpg) is accompanied by a world file (*.jgw) containing its georeference information. The Nebraska web site has these pairs of files organized in 44 directories each containing the 256 DOQQ files and 256 world files for the 44 areas of Nebraska of 1 degree of latitude by 1 degree of longitude. The 1-degree directories around the boundaries of Nebraska contain fewer pairs of files as areas outside the irregular boundaries of the State are not available (in other words, DOQQs of neighboring states were not available from this site).

Downloading.
Using Apple’s Safari to view the Nebraska FTP site noted above shows the 44 DOQQ FTP directories as 44 Mac folders that contain the 512 files for a 1-degree area, just as if they were all in a folder on the local drive. Safari then permits each folder to be dragged from that FTP site to a local Mac hard drive, which automatically downloads all these files to that hard drive into an identical folder. The standard download managers in Explorer, Firefox, Mozilla, and Opera were all tested for this purpose in both Windows XP and Mac OS X. Safari proved to be the most automated by permitting all files to be set up for downloading by simply dragging and dropping the entire folder onto the local drive. Downloading each 512 file folder containing about 1 GB of files takes about 12 to 15 hours at a very slow average transfer rate of about 160 kilobits per seconds. This limit appears to be deliberately set by the source web site to control connections to it since the Mac computer had a 5 megabit connection to the Internet. Thus it took 500 to 600 computer hours to FTP these JPEG files totaling about 30 GB of data from this site. The result is 44 folders containing 512 or fewer files that are the source or start up spatial data for the following mosaic operations.

Converting Orthoimages to Geodata.

Linking to Spatial Data Files.
The 44 directories downloaded from the source site are a logical organizational structure for these files and were used just as they were downloaded. The TNT Spatial Display / Single Raster select process was used to automatically select all the 256 DOQQ files (*.jpg) using the Add All icon. As soon as this Add All icon was clicked, this process automatically begins to create a link Project File for each of the 256 files. However, since these files are only spatial data in JPEG files, the linking process first brings up the new Auto-Link to Resolve dialog discussed above in the section of that name. This dialog is then used to identify the Coordinate Reference System (CRS) of these pairs of JPEG and world files in this directory.

The toggle in this dialog’s CRS panel “Ask for and set for all files of same type in folder” was used to indicate that the missing CRS will be the same for all the 256 world files (*.jgw) in the original directory and can automatically be used for each corresponding JPEG file. The toggle in the Raster Pyramids panel “Create for all files of same type in folder” was used to specify that all the DOQQ images should have pyramid tiers automatically built for them in their corresponding and co-named link Project Files. After these toggles are set, the CRS dialog is presented so that the identity of the CRSs of all these DOQQs can be selected. The CRS of these DOQQs is identified in the metadata at the Nebraska DNR site as Nebraska State Plane in feet. After this CRS was input, all 256 link Project Files were automatically built in the same directory as the 512 source files. After this step each complete 1-degree directory has 768 files and there is a total of 17,601 files in all the directories whereas the final mosaicked image will be a single Project File.

Each of the 256 JPEG image files was decompressed during this link operation so that its pyramid tiers could be built and added to the link file. Pyramid tiers built in a link Project File for an unpyramided spatial data file format automatically use the same compression parameters as the spatial data file they are linked to. If the JPEG file is 75% quality, then the TNT pyramid tiers will be 75% quality. If the file is a lossless JPEG2000 (*.jp2) file, then the pyramid tiers will be compressed with lossless JPEG2000 and so on. For your information, this is the same as if the raster object is internal to the Project File; its pyramid layers will use the same compression method and level. During this automatic link operation, the CRS was also added to the link file and the georeference transferred into it as well.

After these simple link control parameters were entered for all the files in the directory, it required about 5 seconds to build the Project File link described above for each DOQQ. Thus this totally automated step to convert these 256 JPEG spatial data files to geodata required about 20 minutes of unattended computer time for each 1-degree directory. When this link process is completed for the 256 DOQQs, a virtual mosaic is displayed so that the result can be visually inspected for the 1 by 1 degree area to insure that none were omitted.

This all is now a straight forward process once you are familiar with it. To reiterate, you select all 256 files in the directory at once, designate with a toggle that all should be pyramided, use another toggle to designate that all are in the same selected CRS, and then wait 20 minutes while they are all processed into TNT objects. In this fashion you set up all the 5867 DOQQs as TNT raster objects in 44 directories ready to be mosaicked or used in some other TNT process. At this point the total size of these 44 directories now making up usable geodata including their Project File links with pyramid layers is about 41 GB.

Alternatively Import the Spatial Data.
As an alternative test all the 256 DOQQ files (*.jpg) in a directory were imported into a single Project File of 256 internal raster objects, which also use JPEG compression. This operation took more time than the linking procedure outlined above as it had to decompress, pyramid, and then recompress each primary object and tier. The storage requirements can also balloon up in this approach if preserving maximum final image quality is important.

The 44 Project Files total about a terabyte if stored as uncompressed, pyramided raster objects, about 500 GB as lossless JPEG2000 raster objects, 200 GB if imported to raster objects and best quality (100% quality) JPEG compressed, or 200 GB as JPEG2000 Best Quality Lossy. During import these objects could not be compressed back to the same JPEG lossy level as the 20 to 1 lossy compression used on the source DOQQ JPEG files. Uncompressing 20 to 1 lossy JPEG images does not restore their original detail or eliminate artifacts. Thus, recompressing them back to this level simply introduced new additional loss of detail and artifacts into these images before they were mosaicked. From these tests you can see that using links to the original unaltered DOQQ files in JPEG format is the fastest approach with the smallest intermediate storage requirement and does not further degrade the source image quality.

Setup.

Loading Objects.
Loading the 5867 linked objects into the mosaic process required navigating to each of the 41 directories and then using the Add All icon to automatically select all the 256 Project Files in that directory. This took a few moments to interactively set up each directory and then 20 to 30 seconds while all the files in the directory are opened and set up for mosaicking. After all 5867 objects were selected and loaded, they were displayed as a virtual mosaic in about 20 minutes. This permits inspection of these preliminary results to make sure that all input components have been selected and properly prepared. Each DOQQ in this large project still occupies several pixels vertically and horizontally in the virtual mosaic. If any are missing, they are easily detected, especially if the background of the view is set to be a bright color, such as red.

Displaying all these objects in mosaic in TNT 2004:70 would have required several hours as it was necessary to build each layer’s complex legend view entries. In 2005:71 the LengendView is off by default in the Mosaic process avoiding this time consuming activity for 5867 layers. If you want a LegendView in the mosaic View window use a LegendView / Show menu option to turn it on.

More and more applications of the TNT products are using views of 100s of layers with complex LegendViews. Since this can significantly slow using a LegendView, work is underway at this time to more rapidly build these graphical entries for each layer to support these kinds of applications. In the meantime Mosaic is a process that uses large numbers of rasters and suppressing the LegendView greatly improves the setup time for mosaicking a large number of input raster objects.

Setup parameters.

All mosaic control parameters were left at their default settings except the following.

Sampling.
For this mosaic test nearest neighbor sampling of the source DOQQs is used since nothing in this process is going to change the cell size, orientation, CRS, or projection of the input DOQQ images as they are mosaicked into the single, large raster object.

Overlap.
The source DOQQs for this mosaic do overlap. However the overlap contains the same matching color cells as these DOQQ units are cut up from orthoimages covering larger areas. Overlap was included in each DOQQ so that its edge is not abruptly clipped to 3.75′ by 3.75′ areas potentially creating missing cells at the edges of adjacent DOQQs. Since the cells match exactly no feathering was requires. However, some images had a null frame of RGB = 0,0,0, or black and some had a null background of 255, 255, 255 or white. The image frame is the area of cells at the edges needed to accommodate a northerly converging image content, in this case 3.75′ by 3.75′ of latitude and longitude in a rectangular raster. To accommodate this, a new “Least extreme” overlap option was added to mosaic and used. Least Extreme means that in areas of overlap the least extreme value will be selected for the output cell. Using this setting means if a null cell of a frame of 0,0,0 or 255, 255, 255 is matched with a cell with an image value, the image value will be used.

No Compression.
The uncompressed, mosaicked raster object without pyramid layers is 351,947 rows by 736,450 columns or about 724 GB. The objective of this exercise was to create a single raster object of Nebraska that would fit on a DVD with room for other smaller reference layers to make up a statewide image, which could be viewed rapidly at any scale. This required a 200:1 JPEG2000 compressed raster of 3.79 GB including pyramids. A mosaic process has to permit a wide variety of edge, contrast, reprojection, and other options and some combinations of these must be completed with uncompressed images. For example, to lossy compress this raster without introducing artifacts at the edges of the input DOQQs requires that the entire mosaic raster be used as input to the compression process. To lossy compress this raster for its final use required temporary storage of 1 terabyte (TB) for the entire uncompressed raster object.

No Pyramid Tiers.
The option was selected to omit building pyramid layers for the temporary raster. Pyramid layers for the uncompressed intermediate raster were not needed to compute the final lossy compressed raster object. Creating all pyramid layers including the 2 by 2 tier for this intermediate file would increase the size of this raster object to exceed the capacity of the one terabyte drive. It would have considerably increased the time to complete the initial mosaic. If the temporary uncompressed raster is saved, pyramid layers with or without the 2 by 2 tier can be added later as a separate operation.

Adding Pyramid Tiers.
For testing purposes all pyramid tiers were computed for this 724 GB raster. As noted above, insufficient space was available on this one terabyte drive for all these tiers. This was accomplished by specifying that three pyramid tiers be created on a different hard drive in a separate Project File linked to the 724 GB raster object. This yields a pair of Project Files that function as a single, large, uncompressed raster object of greater than one terabyte and whose content can be accessed at any scale without requiring any decompression.

Executing.

Best Performance.

The 5867 linked DOQQs were read by the Mosaic process from an internal SATA hard drive. The output Project File and its single uncompressed raster object of 724 GB was created on the external hard drive connected by Firewire 800. The Mosaic process first created this Project File and the large, empty, uncompressed raster object in about 4 hours. It then decompresses each DOQQ file (*.jpg) into a temporary raster object and writes that single input raster into the large output mosaic using the mosaic settings. This single, temporary, uncompressed DOQQ raster was then automatically purged. In this fashion each linked DOQQ was decompressed and added to the mosaic in about 20 seconds. This step in the mosaic operation to build the single uncompressed temporary raster object took about 30 hours. For this mosaic the JPEG DOQQ spatial data files were in the same Nebraska State Plane CRS as selected for the mosaic. The mosaic process did not have to convert this input spatial data to a different CRS. If a CRS conversion was required, then reprojecting and mosaicking each of these linked JPEG DOQQs into a different CRS would take about 4 times longer.

Another set of about 6000 DOQQ JPEG compressed files is available from the Nebraska DNR web site but in the UTM CRS and in the 3 zones covering Nebraska. The majority of these DOQQs cover the center of the state in UTM zone 14. Nebraska is long east/west so a narrow north-south strip at the west edge is in UTM zone 13 and a narrow north-south strip at the east edge is in zone 15. To test the robustness and performance of the reprojection feature in mosaic, the same procedures outlined above were used to acquire, link to, and mosaic these DOQQ files. The Mosaic run was then set up to produce a single statewide mosaic entirely in UTM zone 14. Thus, as mosaic encountered a zone 13 or 15 linked DOQQ, it would resample that temporary raster to zone 14 and then add it to the mosaic. The only difference in this from the above best approach was that it required 4 times as long to process each zone 13 or 15 DOQQ into the zone 14 mosaic. This increased the total time to build the same uncompressed mosaic in UTM zone 14 to about 70 hours with all other mosaic setup parameters set the same.

Compressing.

Using Extract.

Available Methods.
The entire 724 GB raster object created by mosaic can be compressed to a reduced size raster object in the TNT Extract process. Compression method choices include Run Length Encoded, Standard Lossless, Huffman, JPEG lossy, JPEG2000 Lossless, JPEG2000 Best Quality, and JPEG2000 User-Defined. MrSID compression can even be applied if the uncompressed raster is exported to that format.

Testing Lossy Ratios.
Extraction of the uncompressed raster object to various levels of lossy JPEG2000 compression was tested. Each test created a statewide output raster object with lossy compression relative to the uncompressed size of 20 to 1, 40 to 1, 100 to 1, and 200 to 1. Samples of the results of these tests can be viewed and compared in the attached color plate entitled Mosaic: JPEG Directly to JPEG2000. The time to compress each of these test JPEG2000 images was approximately the same at 25 hours since most of the time is spent in building the compression model, not in reading or applying the model to the entire raster. Compressing a raster is where the price of using JPEG2000 lossy compression is paid—it takes time. On the other hand, viewing any of these statewide, lossy compressed images from a hard drive takes 1 or 2 seconds or less and 6 to 8 seconds from the DVD on the same computer, about the same as for the 1 TB uncompressed raster object with pyramid layers.

Evaluating Results.
Careful comparisons were made for various ground areas between the original 20 to 1 JPEG compressed DOQQs and these various levels of JPEG2000 compression at a 1X zoom (1 screen pixel = 1 raster cell). These showed that 20 to 1, 40 to 1, and even the 100 to 1 lossy JPEG2000 compressed statewide raster showed almost no loss in detail compared to the original DOQQs. You can confirm this in the attached color plate noted above. At 100 to 1 the JPEG2000 image compared quite closely to the original JPEG DOQQ images. This is because these JPEG DOQQs were already lossy compressed 20 to 1 with loss of detail and the introduction of artifacts. Thus the 100 to 1 JPEG2000 compression was compressed only 5 to 1 relative to the original JPEG images. Since the losses in JPEG compression are not oriented toward removing noise, this additional 5 to 1 compression could be easily achieved by noise removal with no apparent effect.

This statewide image was targeted for distribution on a DVD and this required a JPEG2000 compression ratio of 200 to 1. At 200 to 1 some loss of detail was detected principally in agricultural fields with row crops and other parallel structured features where the row structure is no longer as obvious. This is also evident in separate tests compressing 1-meter, color orthoimages from Germany. These images were never lossy compressed and thus show these same loss of detail in areas of row crops at about 40 to 1 JPEG2000 compression. In the attached color plate entitled Mosaic: JPEG Directly to JPEG2000 you can compare an area in an original JPEG DOQQ to the same area in the single statewide 200 to 1 lossy compressed image. The most obvious difference in this comparison is in the partial loss of the detail in the agricultural field at the left containing raked rows of straw in a harvested wheat field.

Time to Process.

Several test mosaic runs were made that required the Mosaic process to finish compressing the 724 GB temporary raster object directly to the specified JPEG2000 lossy raster object. This works just the same as above but adds the 25 hours to the already long 30 hours needed to mosaic the uncompressed raster object. It is better to break up and modularize the task into mosaicking and saving the temporary raster object and then extracting it to the compressed form since it takes only a couple of minutes of your time to set up the intermediate extraction step.

JPEG2000 and MrSID compression can be optimized for various purposes: video, still images, faster compression and decompression, streaming, and other objectives. Their use in geospatial software is focused upon single images for large reductions in file size and fast display time at any scale. Tradeoffs to achieve this objective are needed and use a pyramid concept that optimizes the compressed structure and its distribution on the storage media for this special kind of access, which means to fetch a few cells fast. This is a very inefficient structure if every cell value must be decompressed in a row and column order. As a result, processes like TNT Raster Extract and Mosaic and other commercial products that must serially decompress every cell from MrSID or JPEG2000 to obtain and use its value in a raster structure are going to do so slowly.

Slow compression using software is why JPEG2000 is not yet used in digital cameras and web image servers; it is and will continue to remain too slow compared to JPEG until implemented in custom hardware processors. Another reason JPEG remains popular for cameras is that it compresses 8 by 8 groups of cells requiring very little high speed memory or can even be done in a pipeline approach from the detectors. JPEG2000 must process large image areas from memory to achieve its considerably superior results—high speed memory that is not yet available in small cameras and phones.

Interpretation of Results.

Reducing the 5867 DOQQs to a single raster object that will fit on a DVD or a portable’s hard drive greatly increases its utility. It could have been just as easily extracted or mosaicked into a single JPEG2000 file with a world file (*.jp2 and .j2w) or extracted to a MrSID (*.sid) file of the same size and quality for distribution in these formats. However, this single image is even more useful when used as a raster object in a TNTatlas on a DVD or hard drive. As demonstrated with your DVD after startup, you can quickly and directly zoom to any area in the entire state using familiar rural property descriptions. Then you can interactively apply any of the TNTatlas tools such as measuring, sketching, GPS input, and so on. Almost all the potential applications of the original 5867 DOQQs are possible and greatly facilitated by this new convenient size and the use of TNTatlas. From the color plate entitled Mosaic: JPEG directly to JPEG2000 it is obvious that even at this high lossy compression you can still identify, measure, and sketch natural or real land features such as:

• building locations, type, access, …;

• roads, trails, and other access features;

• agricultural fields and their use and general interior patchiness due to soil variation, drought, …;

• shelter belts, tree and shrub coppices;

• plantations and orchards including tree counts, size, canopy closure, surface care;

• forest features such as tree stands and patchiness and crown density, closure, diameter, …;

• natural land features such as clearings and shrubs and their density.

About the only rural area application that is seriously impacted by using this high compression ratio on 1-meter color imagery is the ability to identify and count cattle in feed lots or open pastures.

MrSID to JPEG2000.

Approach.
The Mosaic process in TNT 2005:71 can now accept lossy or lossless MrSID (*.sid) files as input. Just as described in detail above for using JPEG files as input, each MrSID file is first linked to make it available as a raster object. It is decompressed and processed into the temporary uncompressed mosaic raster using your settings for overlap, feathering, and so on. That single input raster is then purged and the next MrSID raster object is processed. When the temporary uncompressed raster is complete, mosaic will save it or apply lossy or lossless compression to reduce its size using any of the available TNT compression methods.

Test Case.
The attached color plate entitled Mosaic: MrSID Directly to JPEG2000 illustrates this new capability using the results of another large test mosaic. Similarly to the Nebraska mosaicking test detailed above, this test required the use of another one terabyte hard drive connected by Firewire 800. 54 MrSID files of Landsat imagery were downloaded from the NASA site noted on the plate and can be downloaded for the entire world. These color Landsat orthoimages were compressed 30:1 by NASA using MrSID and each covers a 6 by 5 degree area of the United States. The final mosaic of the United States was 230,619 lines by 404,822 columns and 261 GB. It was lossy compressed 90 to 1 in mosaic using JPEG2000 to 4.4 GB to fit on a DVD.

Interpretation of Results.
The section above entitled Using Extract discussed how recompressing 20 to 1 JPEG images relative to their uncompressed size to 100 to 1 using JPEG2000 had little impact on the detail in their content. The illustrations in this color plate show this is not the case when going from lossy 30 to 1 MrSID to more lossy 90 to 1 JPEG2000. Both of these lossy compression methods produce very similar results when compressing from the same source material to the same lossy compression level as illustrated in the attached color plate entitled Export: Creating MrSID Files. They are both very efficient at preserving image content and not adding artifacts. This mosaic was compressed 90 to 1 or 3 times as much as the MrSID input images. This 90 to 1 JPEG2000 result does show additional loss of detail compared to the 30 to 1 MrSID input images. However this loss of detail would have been the same for these MrSID images if they had been distributed using 90 to 1 compression.

Miscellaneous.

Contrast matching can be applied to 16-bit raster objects.

An additional option to use the “First Raster” read for the overlap area was added. Use “Last Raster” was already available.

When multiband rasters are being mosaicked, the new single output set of multiband rasters is automatically assigned the names of the first set of multiband rasters selected as input. For example, if the first input multiband set is named red, green, blue the mosaicked output raster objects will be named red, green, blue.

An option is available to set the value of null cells when the output is composite color or any other data type. In this case the null output cells may be written as the maximum value to represent white or minimum value for black. This means the background in the output mosaic may be white instead of black.

Import/Export.

Introduction.

The Import/Export process has been rewritten as separate Import and Export processes. Periodically software must be rewritten to conform to current coding practices, to eliminate the many subsequent add-on grafts for unanticipated features, and to provide the appropriate base for adding new and future features. Recreating a major TNT process can proceed by incrementally changing and releasing subsections, as was done for 3D Display, or writing separate, parallel, new processes, such as with Import and Export. The choice depends on the complexity of the process, the length of time needed for the effort, and our perception of your need for the new features the new code can provide. As discussed above, the incremental recoding cycle has been completed for 3D Display and now provides many new features.

New, separated Import and Export processes are provided on the Process menu. These were completed during this single release cycle providing new important formats and linking options for these and other popular formats. The Import/Export process available in 2004:70 and new, separate Import and Export processes consist of a main shell managing 100s of format-specific interfaces and the associated import or export code. As yet the modules providing the actual import and the specific dialog for many less popular formats have not been recoded, and are simply used as before by the shells of these two new processes. As more of these are recoded additional formats will be able to be auto-linked and directly used and your suggestions for improving import or export of a specific format will be easier to accommodate. A few formats are currently missing entirely from the new Import and Export processes and require using the older single Import/Export process, which has been left on the same TNT Process menu for this purpose.

Technical Considerations.

Auto-Linking.

Linking Is Used for Importing.
Linking is now the key to importing. A principal goal in recoding the TNT import process was a design that provides the basis for expanded direct use of non-TNT spatial formats. A link through a Project File means that the spatial data can be used in the appropriate TNT process just as if it were already an internal geodata object in the Project File. It follows therefore that the link to a spatial data file can also be used as the basis for importing it.   If a direct link can be made to an external spatial format such as *.dwg, *.shp, *.jp2, and so on, all imports can be handled in a single standardized module for each TNT geodata object type. For example, a raster object import module for all linked raster types, a CAD import module for all linked CAD formats, and so on.

Linking is Important.
A direct link must be properly “hooked” to the external spatial data structure to support its efficient, fast use in all the TNT processes. All its elements, styles, and missing features must be dealt with to link it in such a way that it appears to be a complete geodata object in a Project File. The new TNT Import process is now structured so that it builds up a link file whenever possible and then uses the link to import the contents of that file. You then have the option to use that spatial file via its link or complete its import into an internal geodata object. As a result the same “front end” code used for linking during an import can now also be used as the basis for making direct links in the TNT Select Object dialog in any TNT process using the new direct selection option on the Mac OS X or Windows desktop.

To Link or Not to Link.
The external spatial data format you choose may or may not provide sufficient data to be treated as geodata that can be automatically related correctly and accurately to the earth via a known Coordinate Reference System. Many spatial data formats such as *.jpg or *.dwg were not originally defined with this objective in mind. Depending on the format, the linking and/or import of a spatial data format may be fully automatic or may require a large amount of input from you. Providing automatic or nearly automatic linking may be a clumsy approach for some formats that require you to input a large number of parameters. It is also impractical to use a link to some spatial data formats in their original format since using them over and over directly from that format would always be slow. An example of this would be a direct link to a comma separated text file containing sets of points defining polygons whereas this same data in a humanly readable XML file might provide the basis for a direct link.

The new import approach of building a link as the basis for an import will permit more and more spatial formats to be directly linked to. The files that could be directly linked to previously (for example, *.shp, *.tif, *.jpg, *.jp2, …) are now handled this way and new ones have been added (.dwg, *.dxf, *.dgn, and *.sid). As more of the specific formats’ import code modules are rewritten, more links for direct use of those spatial data formats will be created using these new link-oriented techniques. However, some spatial data formats will still require that you supply the same information about the files internal spatial structure, a missing CRS, location of georeference information, location of styling information, and so on that you would just as if you imported the file.

Import Filters.
Format specific filters and related techniques are used in the new Import process to minimize your interaction with the linking to that file. A format filter identifies the kinds of structures, data types, and supporting data that can be present in that specific format. A filter approach is more easily adjusted to accommodate new conditions encountered in a format than modifying each import module. For example, the linking module for a specific format might be gradually adjusted to look for, identify, and use the filter to ask you to resolve only the conditions it can not and warning you about missing optional characteristics of a complete geodata object. These auto-link issues and warnings are discussed above in more detail in the section entitled Auto-Link Issues for Direct Link to Spatial Files.

For some formats a direct auto-link operation may not be realistic, so the filter can indicate this condition and control only the options available in the import dialog for that format. For example, it may identify the choices of raster data type conversions during import for the data type detected in the file or which object types (vector, CAD, shape, …) can be selected as targets for the import of that format. Filters also provide the default values for an import’s dialog.

Export Filters.
The filter and related new techniques controlling the export of an internal geodata object serves a similar function. It identifies the optional conditions that are allowed in the non-TNT format. For example, if the target raster’s spatial data format supports only 8-bit and 16-bit data, these will be your choices in the dialog. If you choose a 32-bit raster object to export, you may be asked how you want to rescale it or simply sent back to TNT to use another process for this purpose. The filter will also identify to the export process how to handle information in the TNT object that has no place in the target format. For example, for a shapefile it will create a project (*.prj) file of the same name for the georeference materials. The filter can also server as a basis to warn you of what important information is not being exported, such as styling information or a database schema, either because its export is not supported by the module or because there is no known place to put this information internal to the format or as a separate file.

Tabular Interface.

The TNT products provide for the import or export of 100s of spatial data formats some of which have identical extensions. These existing options and more that you need and are requesting required a new, scrolling, tabular oriented interface. The color plate entitled Import: Selecting File First illustrates this tabular list area, which is common to both the Import and Export user interface.

It had become progressively more difficult for you to quickly locate the format and import/export options of interest and to accommodate your request for more formats. For example, you may want the option to import a spatial data type into more than one TNT geometric geodata object (in other words, CAD, vector, …). Your choice of object type created during import can then be determined by its proposed use in TNT. You can always convert object types later in TNT if your objectives change. For example, a shapefile can be imported as a CAD or vector object or linked as a CAD or shape object. If the shapefile contains property boundaries or other inherently polygonal materials, you might want to use it in TNT as a vector object and have its topology built during import. However, if the shapefile contains a complex collection of engineering-oriented data such as a highway interchange design, you may never want to create its complex topology and, thus, import it as a CAD object for editing over an image or using in a TNTatlas. Similar to the Import process, the new Export process has built-in options controlling which type of geometric object (which means CAD, vector, …) can be exported to the target format.

Table Columns.

Name.
The Name column contains the short name from which you may quickly recognize that format.

Extension.
The Extension column will present the 3- or 4-character extension for each format that can be imported. This is the extension of your file if you are using Windows or if you have your Mac OS X preferences set to show extensions. There may be more than one extension shown as in the case of *.tif and *.tiff or in the case of ERDAS’s *.lan or its newer *.gis, both of which can contain raster materials. There also may be no extension widely identified with that format so none is shown, such as for as a simple array, ARC-GENERATE, USER-DEFINED, and others.

Description.
This column contains a longer text description of the file format for use if you are not familiar with a particular extension. It is also needed to help you identify the source of a file from its extension or to select from among redundant extensions if you do not recognize the shorter name.

Icon.
A column of TNT object type icons is presented to quickly tell you which TNT geodata object can be used with each format.

Reordering Columns.
The default order of these is as introduced above. Just as in other TNT tabular views you can use your mouse to rearrange the left to right order of these columns. Simply select the column heading with the left mouse button down and drag it left or right to drop it in a new position. For example, you may want the left most column to be the list of extensions.

Sorting.
When first opened by default this list is sorted by the leftmost or Name column. Just as in other TNT tabular views, you can click on the column heading for any field and it will sort the table’s contents.

Restricting Choices.

The TNT object type icons at the top of the table act as toggles to permit you to see all supported formats or restrict the list to those that can be used with a specific TNT geodata object (which means a raster, vector, or …).

Entering a Specific Extension.

You can directly enter the desired extension to select that format as long as it is unique. However, there are several sets of extensions that are not unique, such as the 8 different formats with the extension *.img. Entering this extension will produce a new but similar Import or Export format table containing just those specific matching extensions representing these formats for you to choose from.

Importing by Selecting a File.

You can start an import by selecting 1 or more spatial data files with the same extension. The process will then use the appropriate procedure if the extension is supported by the TNT products and is unique. If the extension is not unique to a single format, then you will be prompted to select from the subset of those formats associated with that extension such as the 8 for a file with an *.img extension. Illustrations and more information on this approach are provided in the attached color plate entitled Import: Selecting File First.

Batch Import Equals Selecting Many Files.

You can automatically select all the files that have the desired extension in the same directory or assemble files together from various local and networked locations. If all the files are in the same directory, they will have unique names and will be imported with those names. If the names are too long for the TNT 2005:71 object name space (15 characters), they will be truncated. If you select files from several different directories, they may have the same name and create corresponding objects of the same name appended by a number to distinguish them in the same Project File. If you select all the files in a directory and any of them have another extension, you will get a message window advising you to correct this. If you select several files in different formats, this same message will appear because the input parameters for each format can be different making their setup confusing in a single import.

Setting Parameters.

After you have navigated to and selected the various files of the format you wish to import, the Next button opens the new, more generic Import Parameters dialog for the type of TNT object that will be created from these non-TNT files. The settings you make in this panel will apply to the import of each and every file you have selected as they are sequentially linked or imported.

For a JPEG Raster.
For example, the import of JPEG (*.jpg) raster files provides toggle buttons to Link Only (form the link but do not import), Create Pyramid Tiers, and Compute 3D Surface Properties. If you do not check the Link Only button, you can choose from all the available compression methods for the imported raster object and set a Null Value. During import to this object, the lossy compressed *.jpg file will always be decompressed as part of the import and then recompressed using the method you choose for the imported raster object. If the import process automatically finds a .jgw world file of the same name in the same directory, it activates the Reference System button in the dialog so that you can use the Coordinate Reference System (CRS) dialogs to select the CRS of these files.

For Other Rasters.
The selection of other formats proceeds just the same with the import filter for that format controlling which of the options in the Import Parameters dialog you need to give attention to. For example, if you choose PNG (.png) files that have co-named world files (*.pgw) available, then the Reference System button will permit you to set up to link to or import these as geodata rather than simple images.

For a Shapefile.
Similar filters for other object types (such as vector, CAD, …) control the options you are provided in their generic Import Parameters dialog for these kinds of imports. For example, if you have selected a shapefile (*.shp), its import filter provides a drop down options list at the top to permit you to import it to a vector or CAD object or link it as a shape, vector, or CAD object. You can select the CRS if the *.prj file is not present. You can set the area of the file to extract during the import and choose the edge management method to be Completely Inside, Partially Inside, or Clip Inside. Now you can even select the text encoding (for example, ASCII, Chinese, Japanese, Arabic, …) used in the files and it will then be set up in the link or in the imported objects.

Setting up Objects.

When you have completed the Import Parameters dialog for the selected files’ format, you click on the Import button. This provides the standard TNT Select Object dialog to define the Project File(s) into which these imported raster objects will be placed.

Importing by Selecting a Format.

You can also start an import by first selecting the format of the spatial data type you wish to import from the scrolling tabular list or typing its extension into the Extension box. Now if you use the Select Files button and navigate to any directory, the Import process will only show those files whose extension matches the one you have chosen. If there are files with any other extensions in the directory, they will be not be shown and if you choose the Add All icon, they will be ignored. If your directories have mixed file types, this is a fastest way to set up to import many files of the selected format. For example, each shapefile in a directory is accompanied by a number of other descriptive files that will be ignored in this selection process but used as needed during the actual import. Once you have selected all your files in this fashion, the Next button continues the link or import sequence for these files just as outlined above. Illustrations and more information on this approach are provided in the attached color plate entitled Import: Selecting Format First.

Exporting by Format.

Export is now a separate process but shares many design, appearance, and operational characteristics with the Import process. The Export tabular dialog looks almost the same as the Import tabular dialog except that the Select Object panel has been moved to the bottom from the top. This is to alert you to the fact that it is a different process and activity and that you must always choose the export target format for the geodata you are about to export. Other than this deliberate difference, the Export window has the same features as outlined in more detail above in the Importing by Selecting a File section. Selecting the TNT object type by icon restricts the list entries to those spatial data formats appropriate and available for exporting that object type. You can choose a target format by selecting its entry in the list. You can type in an extension to select it but will have to resolve duplicated extensions by selecting the specific format. Columns can be rearranged horizontally in the table and the table can be sorted on a column by clicking its name. Once you have selected the target format you can use the standard TNT Select Objects dialog to select one or many objects for export. These and other user interface components of this new Export Process are illustrated and discussed in more detail in the attached color plate entitled Export: Creating External Files.

Setting Parameters.

After you have navigated to and selected the various objects you wish to export to the target format, the Next button opens the new generic Export Parameters dialog for the type of spatial data format. The settings you make in this dialog will apply to the export of each and every object you have selected as they are exported sequentially. The choices available in this panel to control your exported files can vary considerably depending upon the complexity and optional characteristics of the target spatial data format, which can vary from a simple image (*.jpg or *.png) to a more complex spatial data format such as a shapefile. The user interface inputs for the Export Parameters dialog are controlled by a filter for each export format.

For a MrSID Raster.
If you use this new export option and have purchased and installed a compression cartridge from LizardTech you have many more options in the Export Parameters dialog than for a simple PNG file. These are illustrated in an attached color plate entitled Creating MrSID Files. Thus you have the option to create a companion world (*.sdw) or MapInfo (*.tab) file, a descriptive text file, Text and Arc-World files, or leave set at None to leave this information behind. Depending upon where you intend to use these MrSID files, you can make the appropriate selection.

If you are exporting to a lossless file, you can export the TNT null mask into a value to be subsequently used as null in the MrSID file. Your options for this null value are From Source, Zero, Minimum (black), Maximum (white), or User Defined.

By default you will be exporting to a lossy 10 to 1 MrSID file. You can change this compression ratio in the entry box provided. Next to it is a Lossless toggle button that negates the ratio entry and will export to a lossless MrSID file.

You can specify the number of resolution levels, in other words pyramid tiers, you want to have in your MrSID file. You can let this be determined by the Automatic choice, which will create every level needed, or you can select the levels to be from 1 to 12.

MrSID compression uses the libraries and compression engine licensed from LizardTech. It provides an option to compress in a single pass, which is faster and might go virtual for large files if not enough real memory is available. The option for a 2-pass method is also available and is somewhat slower but will not go virtual and tie up your system for a long time. Either of these options can be selected in this dialog.

For a Shapefile.
Exporting a vector object to a shapefile presents a generic Export Parameters window to Export to 2D or 3D coordinates. You can set an X and Y shift and choose the element type to export from Polygon, Line, Point, or Label since these must be in separate shapefiles. A toggle button will convert the coordinates in the vector object to latitude and longitude from whatever CRS is being used in the vector object. You can select which relational attribute table to export since only a single flat database table is permitted with a shapefile. You can pick the style table to export to a companion *.avl file of the same name. And finally, you can specify the string encoding method to convert the labels and other text exported to the encoding of the target language in which the shapefile will be used (in other words, ASCII, ANSI (Windows Code Page), Chinese, Japanese, Arabic …).

Export Rasters for Google Earth.

Google Earth permits you to select and use local raster files as overlays. These raster files must be in JPG, PNG (including transparency), GIF, or TIFF format. To overlay the Google Earth reference images in the proper position, these rasters must use WGS84/latitude longitude coordinates as Google Earth does not have any capability to recognize or convert from other CRSs. The raster file must also be accompanied by a Keyhole Markup Language (KML 2.0) co-named file using XML grammar to describe it to Google Earth.

Any TNT geodata object can be converted to a raster object. (Remember to use the various TNT transparency options in building your original vector or CAD objects for this purpose.) Resample and Reproject can then convert it into the required CRS.   Now when you export that raster object to any TNT supported raster format an option is available to create the co-named KML file for its immediate use as a local overlay in Google Earth or some other product. Exporting to 8-bit or 32-bit PNG is a good choice for this purpose since these formats preserve transparency, even if the source is a raster such as shaded relief or a satellite image. These steps are illustrated in the attached color plate entitled Export: Rasters for Google Earth.

You can also use files in your Google Earth requested over the Internet using a Web Map Service, and this is discussed above in the major section on TNTserver. This approach also permits you to save a local reference to this raster in a KML file. Thus you can set up many different kinds of WMS overlay combinations by creating them using TNTmap Builder and saving each as KML file. Clicking on any of these KML files will autostart Google Earth and fetch and overlay these same layers without using TNTmap.

If you export a TNT object for use with Google Earth, make sure that it already is in the required WGS84 latitude and longitude CRS! If it is not, it will not overlay in Google Earth with the correct position or geometry.

KML 2.0 is much like a subset of the Open Geospatial Consortium’s GML (Geographic Markup Language). The specifications for KML 2.0 can be reviewed at http://code.google.com/apis/kml/documentation/. A KML file can contain many other kinds of geographic data for local use in Google Earth beside the raster metadata created during this export. MicroImages is currently working to support more export to KML capabilities. MicroImages is also well aware of World Wind and the pending release of Microsoft’s Virtual Earth and will address these export objectives as the need for them arises and appropriate documentation becomes available.

Version 2005:72 Modifications.

The development version of TNT 2005:72 now automatically supports using long object names to avoid truncating or mangling object names for files that are imported with names longer than the 2005:71 limit of 15 characters in an object name. It permits object names of any length. They are not limited by the operating system since they are internal to the Project File structure.

DV2005:72 also supports the use of long names for database fields to support long names used in imported or linked databases. This is important to support future developments where the TNT products will be making more direct links to more commericial and open source relational/spatial database systems.

This next TNT version also detects the specific operating system in which you are naming a Project File and prevents your use of the several characters not permitted in each operating system. For example, you can use a “/” (forward slash) in a Mac OS X file name but you can not use it in a Windows File name. Since Project Files can be used between operating systems, it is still possible that their names will be mangled in some manner if this is not anticipated, in other words, a character in a name that is valid in one operating system is not valid in another. A “/” used in the name of a Mac OS X file that is transferred to Windows will simply be skipped (in other words, 10/06/05 is altered and becomes 100605).

CAD Linking and Import Formats.

DWG files and DXF files from AutoCAD version 2005 and earlier can now be imported into a TNT CAD object or directly linked to.

DGN MicroStation V8 file import has been improved and can now be linked for direct use.

These CAD link and import operations now use libraries MicroImages has licensed from the Open Design Alliance and are discussed in detail in the major section above entitled AutoCAD’s DWG and DXF and MicroStation’s DGN Files.

Raster Export Formats.

MrSID.

TNTmips and TNTedit are the only commercial software for Mac OS X that can compress a large variety of rasters to MrSID files.

Any raster object can be exported to MrSID, and this is described in more detail in the section above entitled Exporting by Format and illustrated in the attached color plate entitled Export: Creating MrSID Files. This export capability is built directly into every TNTmips and TNTedit and uses libraries that MicroImages has obtained from LizardTech under a license agreement. As part of the export you have the option to create a companion world (*.sdw) or MapInfo (*.tab) file, a descriptive text file, Text and Arc-World files, or leave set at None to leave this information behind. Depending upon where you intend to use these MrSID files, you can make the appropriate selection.

Your access to use this to export to a *.sid file is authorized by a compression metering cartridge from a LizardTech distributor. They call this simply a cartridge. They have cartridges available for various versions of Windows, Mac OS X, Sun, and various flavors of Linux. The price of this cartridge is based upon the uncompressed bytes that it permits you to compress. They have cartridges of various sizes available including unlimited and a cartridge can be refilled as you need and pay for it. Cartridges are available from their sales representatives who are listed at www.lizardtech.com/purchase/other.php.

Important! You do not need to buy GeoExpress or any other software from LizardTech to order, install, and use their compression metering cartridge with TNTmips or TNTedit.

Please take careful note that you do not have to purchase any other LizardTech software product, such as GeoExpress, in order to install and use a compression metering cartridge with TNTmips. If the LizardTech sales representative you contact is unaware of this, please ask them to contact Jim Dielschneider (West Coast Sales Representative) at LizardTech’s main office or you can contact him directly on this matter by email at jim@lizardtech.com.

JPEG2000.

Some plug-ins and built-in capabilities for viewing JP2 files are not able to make use of the GeoJP2 metadata built into it to provide its georeference information. ArcView 3.2, which uses older Kakadu JPEG2000 libraries, is an example of a program that will crash on a GeoJP2 file built using current Kakadu libraries. As a result the export to a JP2 file no longer automatically includes this metadata to define it as a GeoJP2 file. It is now an option to add this metadata into the JP2 file. This option can be used if you are exporting to JP2 and know by previous experience that the target application software can use this means of georeferencing. Alternatively, check to see if the software can use a world file, tab file, KML, or other file for this purpose since they are also options in the TNT Export process for JP2 files.

PNG.

Transparency is now preserved when raster objects are exported to an 8-bit PNG file.

When exporting to the 8-bit or 32-bit format you now have the option to create a companion world (*.pgw) or MapInfo (*.tab) file, a descriptive text file, Text and Arc-World files, or leave set at None to leave this information behind. Depending upon where you intend to use these PNG files, you can make the appropriate selection.

Raster Import Formats.

MrSID files (*.sid) import and auto-linking is available for 32-bit Linux platforms using an Intel processor.

ERDAS files (*.img) greater than 2 GB can now be imported.

Nikon camera files (*.nef) can be imported. This is the format used by the Nikon DX2 12.4-megapixel SLR camera. It’s their proprietary, encrypted form of the public EXIF (Exchangeable Image File) raster format and can only be decrypted using their licensed libraries. This TNT import uses the Windows libraries licensed from Nikon. Their Mac OS X libraries are not suitable for use in the TNT products.

Ricoh digital camera image files can be imported using the EXIF V2.2 headers they add to the JPEG (*.jpg) files they create.

NetCDF files (*.cdf) Network Common Data Form arrays can be imported.

Kodak Digital Camera Raw files (*.dcr) can be imported.

Database Linking and Import.

TNT 2004:70 imported and linked to Microsoft Access tables but did not preserve the relational links (the schema) of these tables. The tables either had to be a single flat table representing elements or linked directly to the graphical elements being imported. If the Access table structure was relational, these relations had to be reestablished (relinked) in TNTmips or TNTedit. TNT 2005:71 now duplicates these relationships and maintains the schema in the TNT relational database or in the link in to the Access database. This is discussed in more detail and illustrated in the attached color plate entitled Import: Duplicate Microsoft Access Relationships.

Vector Import Formats.

TIGER 2003 and 2004 Line files (*.rt*) of the U.S. Census Bureau can now be imported. The federal government’s standard metadata for the file will be stored in a metadata subobject under the imported vector object.

Map Calculator.

The Map Calculator can now convert coordinates in any supported Coordinate Reference System (CRS) to and from the X, Y, and Z coordinates in the Earth Centered, Earth Fixed (ECEF) geocentric CRS. This is the system in which both the GPS and Glonass systems report the raw coordinates from a GPS device or satellite. Your handheld GPS readout device converts these to a specific CRS and datum, usually WGS84 latitude and longitude.

Spatial Data Editor.

Instant Element Erasing.

The section above on 2D Display / Separate Layer Caching describes the new buffer scheme now used by the TNT Graphics Rendering Engine (GRE). As described in detail, layers in any 2D view, including the one being edited, are no longer refreshed by reading every object and compositing it into a new view. Now, when you draw into the special layer buffer created for your edit activity, it can be altered to erase the trace of an element almost instantly. This layer is simply adjusted and recomposited with the composite layer buffer for the view to refresh the display. It is no longer necessary to use a redraw to erase all traces of a deleted element(s) in a current view.

Active Layer Remains Visible.

Now the active layer is not changed to another layer if its visibility is toggled on or off in the LegendView. This permits it to be hidden temporarily during editing so that you can see other layers that it might otherwise obscure. This is a simple feature but can be very useful now that you have nearly instant redrawing via the separate layer buffers. For example, you may want to make a check of how a feature you are tracing appears in another image layer loaded below the main reference image layer.

Suppress Long Leader Lines.

Moving a label outside or away from its element may create a leader line that is long and unsightly. A toggle is now available to suppress these leader lines in the Text Label Edit Controls (Add Leader When Label Is Moved From Element).

Render to SVG.

Set Coordinate Accuracy.

When you render a layout to SVG, you need to control the accuracy of the coordinates in the SVG format. Version 2004:70 provided a hard to understand resolution parameter on the Options tabbed panel to control coordinate accuracy relative to the potential scale at which the SVG file would ultimately be viewed or printed. This has been replaced by permitting you to set the coordinate accuracy and units to be used in the SVG file. Setting an accuracy that is too high, such as using the TNT internal working coordinates, unnecessarily creates too large an SVG file for network applications. Use these settings on the Options panel to specify the SVG coordinate accuracy to reflect the accuracy of the spatial data used in the layout.

Browser Compensation.

Firefox and Opera have both introduced native, standard support for the use of SVG files. Internet Explorer and Safari still require someone else’s plug-in. Unfortunately, the support of JavaScripts also varies between browsers. SVG output and the attached JavaScripts now have improved structures to compensate for these variations. A toggle button to “Optimize for Firefox/Mozilla” is also provided to further improve the use of the SVG file in these specific browsers.

Calibration and Quantitative Use of Multispectral Satellite Images.

Introduction.

The utopia of optical remote sensing is to work only with images that have been converted to rasters that represent accurately-located reflectance values of the ground surface cells. Under these circumstances your rasters would be a surrogate for a spectrometer scan of each cell. This spectroreflectance of each cell, especially as the number of uncorrelated bands increased and the bandwidth decreased, would be much closer to identifying the biophysical characteristics of the cell than the raw data values in the original image. With other information, such as shape, we could begin to think seriously about using look-up tables of spectral reflectance by image band to identify materials such as paint, roof coating, crop conditions, soil surface color, and so on. A myriad of fully automated applications would immediately open up. For example, images taken under different lighting conditions on successive days would be similar (within the limits of shadow content and bidirectional reflectance, in other words, sun angle and observation angle).

Currently, the demand for commercial satellite imagery is coming from direct visual interpretation and promotional applications. The vast majority of the purchasers of color and panchromatic satellite images simply want good color with high resolution. This is the market and it sets the requirements and pays the bills. Fortunately, the engineers building the best systems have still done their best to make these into quantitative sensors. Using the ancillary engineering and ephemeris data they have provided, it is possible to make some headway into quantifying the spectral values in an image and relate these to the biophysical properties of the surface being imaged; “bio” because it could be grass and “physical” because it could be soil or rock, thus biophysical since these components are often mixed. Need more examples? Physical because it is a water surface but biophysical if it contains an organic pollutant such as red algae; physical because it's paint, plastic, and concrete and so on. Until we have very high resolution images (cell sizes measured in centimeters), we are going to have to contend with mixed cells and the idea that the surface observed can be physical and static (excluding rain and snow) and/or biological and change in the short term by senescence, green up, routine growth, or even the wind blowing from a different direction.

30 to 40 years ago, in the earliest days of multispectral and thermal remote sensing, Dr. Jack Paris, Dr. Jim Tucker, Dr. William Malila, this author, and a few other scientists addressed image analysis from the viewpoint of measuring biophysical properties and not from the popular viewpoint of qualitative classification of surface materials. Over the intervening years there has been gradual progress in the direction of this utopia by an ever increasing cadre of new remote sensing scientists and engineers. Sufficient progress has been made in the design of satellites, desktop computing power, processing tool kits, and related developments to apply those early ideas and subsequent developments. Fortunately, Dr. Jack Paris has continued his research efforts in this area and has used TNTmips for almost 20 years to test and apply them. He has kept current on the ability to use optical imagery in a calibrated fashion to map the biophysical surface. As a result MicroImages has been able to employ Dr. Jack Paris as a consultant to implement these ideas for your quantitative analysis and application of optical multispectral imagery. What results is a system of interrelated geospatial analysis scripts for your possible application to the images of several different satellite systems including ASTER, QuickBird, Ikonos, and Landsat. Dr. Randy Smith of MicroImages, working directly with Jack, has provided their critique, testing, editing, and color illustration. Since these are open-code, well-commented SML scripts, you can modify them to improve them or apply them to other imagery on any TNT supported operating system.

Why Use SML?

Let’s Each Do What We Do Best!

The primary reason these are scripts will become obvious to you when you use them and the associated reference materials provided in the FAQs by Jack associated with each script. Each of these satellite systems and their engineering and ephemeris characteristics are constantly changing: new, improved, or simply adjusted calibrations as the sensor ages; new orbit and orientations; constant changes in delivery formats, and so on. It would be almost impossible to create and keep current a meaningful dialog-oriented interface for even one satellite sensor to cover all these variables and then instruct you in how to use them. Using scripts enables an easily changed serial approach to applying these calibrations where the interface instructs and advises you, as well as accumulates the information needed.

This is applied science and engineering or at least a direct development that is only one step removed from those creating it. SML is an excellent way to undertake this because it empowers those who use it for scripting and also know the physical and biological science to work independently of the MicroImages computer scientists who created this specialized geospatial scripting language. If a new script operation is needed, Jack or you request a solution, and a new function, class, or method is added to SML and released as part of the next weekly patch.

The MicroImages software engineer is able to provide solutions to SML much faster than via a formal TNT process as the new feature does not have to be integrated into a complex TNT process and added somehow to an already complex TNT interface component. Often the capability you request is already present in the TNTsdk libraries and merely needs a software wrapper to become available and usable in SML. The software engineer simply implements the needed component making sure its compatible in its interface to other SML components, such as those used in the Graphics Rendering Engine (GRE), MicroImages Graphical User Interface (MGUI), and MicroImages Project File (RVC) classes. They then simply put it into the SML library and everyone can go forward independently.

Many of you are now coding more complex, unique geospatial scripting solutions with SML and asking for new features. If they are easy, these are added right away to enrich this geospatial scripting language for everyone’s use. At this moment there are no SML classes, methods, or functions that you have requested that are waiting for implementation.

Let’s Be Practical.

Jack and Randy are both quite familiar with using the SML geospatial scripting language. Jack managed the design of all the SML production line scripts used by DigitalGlobe to produce its AgroWatch product. Randy has 10 years of experience at MicroImages, in part in writing scripts and in general in figuring out how to get what is needed from within the MicroImages culture. As a result, by using SML they have made it possible for those of you who have advanced remote sensing backgrounds and ideas to modify these completely open, public scripts to improve them for your special imagery sources and needs. Finally, whether or not you use these scripts for their designed objectives, they provide more complex analysis scripts from which you can abstract sections and ideas for your own private SML applications.

Doing It Even Better.

Some of you are active, current remote sensing scientists and engineers. These scripts are a work in progress. Since these are scripts, they can easily evolve as justified by new information and technology. Jack is very interested in your ideas and input to these scripts and FAQs and can be contacted using the information at the bottom of every color plate in this series. Correspondingly, MicroImages is very interested in your applications of these scripts. If MicroImages does not learn about your successes and failures with them, then there will be no motivation for investing further effort in this or similar new activities.

Please also note that Jack is available to do contract geospatial analysis scripting using SML.

Scripts by Jack.

At this time there are 7 related scripts in the quantitative satellite image analysis Scripts by Jack™ series. The latest versions of these scripts can be downloaded from www.microimages.com/downloads/ScriptsByJack.htm. Also with these scripts are sample datasets that have been used in the illustrated plates, and which can be used to test the scripts. These scripts use new features added to SML 2005:71 and will not run in previous versions of the TNT products.

Scripts by Jack will only run in 2005:71 or later of the TNT products!

The flow through these scripts and the following discussion is best understood by referring periodically to the attached color plate entitled Scripts by Jack: Workflow: Calibrating/Analyzing Multispectral Images that provides an overview of the step by step approach to using these scripts. Accompanying this is a color plate entitled Scripts by Jack: Calibrating Multispectral Satellite Images. It provides an example of the results that can be expected when these calibration procedures are successfully applied to high quality ASTER images collected at about the same time but 1 year apart. This plate presents only a single example of the use of the calibrated surface reflectance produced by these scripts. But even the qualitative images in this plate should make it clear that if you want to compare 2 images a year apart to detect changes visually, by classification, or by other means, these calibrations are going to give better results. They remove as much variability in the atmospheric, terrain, mixed pixel, ephemeris and other system factors as is possible at this time, using readily available parameters of the sensor, the atmosphere, the geometry of collection, and the surface material properties.

The application of these Scripts by Jack does require the understanding of the applied physics underlying remote sensing and its manifestation in the many acquisition system parameters required as input in these scripts. To assist you in this, Jack has written approximately 200 pages presented as individual sections related to each script, in a series called FAQs by Jack. FAQ A: Remote Sensing Tutorial is not about the operation of a particular script, but instead provides general background materials on the remote sensing concepts that you may need to review to assist you in understanding what these scripts are designed to do. In particular, to use these scripts you will need to understand how your ground features occur in what are called spectral space plots. These are used throughout these FAQs together with illustrations of the results of each procedure to provide a conceptual framework for what is happening.

Calibrate Satellite Images to Surface Reflectance (SRFI.sml).

The SRFI script is designed to convert the digital data value stored in each cell of an image band to a Standardized Reflectance Factor Index (SRFI) value for the cell. The reflectance of a surface material in a particular band is the ratio between the radiance of the solar energy diffusely reflected by the surface and the irradiance of the incoming solar energy incident on that surface. Reflectance can thus vary between 0 and 1. SRFI is a scaled integer representation of this band reflectance. For a physical surface, reflectance in a spectral band or spectroreflectance in many bands is a physical property of the surface. To emphasize this, realize that the reflectance of a physical surface is the same in bright light, dim light, or in the dark, barring subtle changes such as dust, dew, frost, and so on, which actually create new and different surfaces. The same holds true for biological surfaces, but these surfaces seldom remain the same even for short periods. Thus their changes in reflectance, transmission, and absorption can vary widely, from nearly instantaneous leaf wilt or orientation toward or perpendicular to the sun, to broader seasonal changes.

The data values recorded by a satellite sensor for an image cell over a set of bands are related to the radiance in each spectral band reaching the satellite at that angle from that ground cell. This is often referred to as spectroradiance, and it is modified before recording in the sensor system by numerous factors including the health of the sensor, the spectral nature of the filtering mechanism used, the detector’s spectral sensitivity, the current ephemeris position and orientation, and others. These factors are reviewed in the introductory FAQ A: Remote Sensing Tutorial in the FAQs by Jack reference materials. They are recorded and supplied with your image with more or less accuracy depending upon the design of the image sensor used.

The impact of these sensor factors on the data value can be compensated for by using various reverse transformations to convert the recorded data value back to the spectroradiance input to the outside of the optics of the sensor. This same spectroradiance value can be converted back to the value at the top of the atmosphere, since the only thing that happens in the vacuum of space is to reduce the gain, or overall amount of the radiance, not its spectral distribution. This diminishment can be computed easily by using the sensor-earth geometry to determine the spectroradiance value for each image cell at the surface of the atmosphere.

The incoming solar irradiance values at the top of the atmosphere for each image cell across the range of bands, called the spectroirradiance, can be computed from the angle and distance of the sun at the date and time the image was acquired. The computed incoming spectroirradiance and outgoing spectroradiance at the top of the atmosphere can then be used to compute the top-of-atmosphere spectroreflectance for each image cell.

The incoming solar irradiance at the ground and reflected radiance at the ground differ from their corresponding top-of-atmosphere values for each image cell because of the effects of the atmosphere. A model atmosphere can be used to remove these atmospheric effects and compute the spectroreflectance at the ground for each image cell.

SRFI implements its calibration of the imagery of all the supported satellite sensors in 3 optional steps. Proper application of these steps is described in FAQ B: Surface Reflectance Images in the FAQs by Jack reference material. The results of applying these options are also described and illustrated in the attached color plate entitled Scripts by Jack: Calibrate Satellite Images to Surface Reflectance.

Option 1 in SRFI computes the spectroradiance equivalent to the cell’s recorded data value by removing the sensor gain and offset factors. It then uses the estimated incoming solar spectroirradiance and the solar elevation angle to convert this value to the effective spectroreflectance at the top of the atmosphere for that cell. A portion of this spectroreflectance originates from the spectroradiance scattered into the optical path by haze particles in the atmosphere in the area being imaged. It may also be diminished somewhat by attenuation in the atmosphere due to absorption.

Option 2 in SRFI incorporates the top-of-atmosphere reflectance computation of Option 1, but in addition computes the amount of that spectroreflectance that is due to atmospheric haze rather than the ground. This haze component is subtracted for each cell to produce a SRFI value that represents the ground-surface reflectance for that cell adjusted for the major atmospheric effect (haze). There are many models available for this kind of correction, and the most accurate depend upon having access to local measurements of the atmosphere at the time of image acquisition. The SRFI script uses the band histograms and a simple power-law function based on the Rayleigh scattering model to approximate the haze reflectance in each band. This is an area of the script that you can improve upon by refining the scattering model or by using real ground or other satellite measurements of haze and other atmospheric path measurements for the area and time of the optical image’s acquisition. This is one of the reasons why this script is built in optional steps that permit you to modify and improve any one of these options.

Option 3 replicates the adjustments made in the other two options, but makes a further adjustment for the attenuating effects of spectroabsorbtion by water and other components of the atmosphere. These effects are removed by using a simple model atmosphere derived from the haze adjustment. The resulting SRFI value represents the estimated ground surface reflectance adjusted for all atmospheric effects. The rasters that result from applying each of these 3 steps are illustrated in the attached color plate entitled Scripts by Jack: Calibrate Satellite Images to Surface Reflectance.

The SRFI computations assume that the ground surface in each image cell is flat, horizontal, and lambertian, meaning that it diffusely reflects solar energy equally in all directions. Thus the SRFI value is assumed to be the same for any direction of view. This assumption does not account for any bidirectional reflectance of the surface material, which is an area in which you could improve the model. For example, given the row direction of a crop relative to the observation angle, a non-lambertian, bi-directional surface reflectance could be modeled that also took into account the shadowing of the incoming irradiance.

As a final step, the SRFI script uses these effective surface reflectance values in red and the near infrared to compute two rasters that are the first estimates of the nature of the biophysical content of each cell. These are the Perpendicular Vegetation Index (PVI) and the Perpendicular Brightness Index (PBI) of each cell. These indices can be used as input to other scripts in the Scripts by Jack series as described below.

Replace 0-Value Cells in Images (REPAIR_IMAGE.sml)

The value 0 is typically used as a “no-data” fill value in each band for blank areas around the edges of satellite images. In TNTmips you would typically set 0 as the null value for such images so these blank areas are ignored during display (treated as transparent) and during any processing. However, the 0 value may also occur within the image area in some bands of such images. In this case 0 is the minimal brightness in that band for that cell rather than “no data.” If 0 has been set as null for the band, SRFI and other scripts will incorrectly ignore these isolated 0-value or minimum brightness cells.

The REPAIR_IMAGE script in the Scripts by Jack series can be used to solve this problem. Interior 0-value cells are likely to occur only in longer-wavelength image bands, but true no-data cells will have the null value in all of the image bands. This utility script searches for null cells that are limited to one or a few bands and replaces them with the next-highest legitimate value (1 for integer raster types). The repaired bands can then be used in the SRFI script to provide a complete set of SRFI values for all legitimate image cells.

Correct for Terrain-Induced Radiance Effects (TERCOR.sml).

The SRFI script assumes that the ground cell is horizontal. If you look carefully at an image with the same surface material on the front and rear of a hill, even if both were in the sun, you will see a difference in brightness unless the sun is at the zenith for the these terrain-induced radiance effects, and these can be large if the multispectral image is collected for an area of rough terrain. The TERCOR script in this Scripts by Jack series adjusts the output of SRFI Option 3 to compensate for the terrain-induced radiance effects for cells that are not horizontal.

Mitigating these terrain-induced radiance effects requires an estimate of the orientation (slope and aspect) of each image cell from a DEM. This orientation and the solar azimuth and elevation angles can be used to compute the incidence angle of sunlight on the cell; the solar irradiance received by a cell varies with the cosine of the incidence angle. The relative irradiance variations for a particular image can be derived quickly by applying the TNTmips Slope, Aspect, Shading process to the DEM to compute a Shading raster using the solar elevation and azimuth angles at the time and date the image was acquired. The TERCOR script uses a Shading raster to adjust the original SRFI values for these terrain effects.

These adjustments require that you have an image with good geometry and a good estimate of the elevation of each of its cells. This can be accomplished with an orthorectified multispectral image and a DEM with a resolution that can be larger, but not greatly different than the image cell (for example, a 10-meter DEM used with 1-meter imagery). Since you may not have this matching DEM, TERCOR is provided as a separate procedure so that you can skip it and only use SRFI to compute reflectance values when the terrain is relatively flat, which is the case in most agricultural applications. Also if you have an image that is not orthorectified but has a matching similarly distorted DEM, then TERCOR can be applied. Additional details and an illustration of results produced by TERCOR are provided in the attached color plate entitled Scripts by Jack: Correct for Terrain Induced Radiance Effects. The use of the TERCOR script is detailed in FAQ D: Terrain Correction for Surface Reflectance Images in the FAQs by Jack reference materials.

Mapping Dense Vegetation and Bare Soils (DIAG.sml).

The DIAG script is used to prepare intermediate results as input for the GRUVI script in the Scripts by Jack series (described below), which can be used to map variations in vegetative cover and soil brightness. DIAG uses the SRFI results in just 2 bands, the red and near-infrared, to identify ground areas in the SRFI images of relatively “pure,” actively growing vegetation cover and areas of soil or geologic materials relatively clear of any vegetation. Using DIAG, you identify those ground cells whose effective red and near infrared reflectance values identify them as being one or the other of these relatively pure surface covers. This information, in the form of new auxiliary mask rasters, is then used in the GRUVI script to map out the amounts of these and other components in all other mixed cells.

DIAG can be applied to raw surface SRFI images if the area is relatively flat, otherwise the TERCOR script should be applied first. The DIAG script provides tools to identify the relatively pure surface materials from their known positions in a plot of the red reflectance (SRFI red) versus the near-infrared reflectance (SRFI near-infrared). Using the script, the ranges of values for dense green vegetation and bare soil are identified from their known positions in this 2-space spectral plot. A new set of multiband rasters is produced that contains the unmodified SRFI cell values for those cells representing dense vegetation and bare soil. All other cells are set to null. 2-space spectral plots of the DIAG-processed red and near-infrared bands are uncluttered by mixed cells, making it easier to define representative values for dense green vegetation and bare soil that are needed when you use the GRUVI script.

Information on the operation of the DIAG script is provided in the FAQ C: Diagnostic Products for Surface Reflectance Images of the FAQs by Jack reference materials. The attached color plate entitled Scripts by Jack: Mapping Dense Vegetation and Bare Soils illustrates an input SRFI and output DIAG image and 2-band spectral space plots before and after DIAG processing. This is an area where you can undertake further development of this script for more interactive input or other approaches to defining these areas. You may know where the fields of dense growing vegetation and bare areas are from ground observation at the time of the acquisition of the multispectral imagery. For example, for agricultural mapping in spring images you may have noted the locations of fields of heavy green wheat and fields of bare soil recently tilled for the summer crops; in mid-summer you could record the fields of heavy corn growth and newly tilled wheat fields, and so on. To use such “training sets,” interactive tools could be added to the script to identify these known areas in the SRFI images. Alternatively, these areas could be identified by polygons drawn around the fields in the SRFI images using the sketch tool in TNTatlas or extracted from a vector object.

Mapping Vegetation and Soil Biophysical Properties (GRUVI.sml).

GRUVI stands for GRand Unified Vegetation Index; grand because it is, unified because it builds upon and integrates concepts from a number of other previous vegetation indices proposed by Jack and others. The objective of this script is to use the red and near-infrared reflectance images computed in SRFI (or SRFI plus TERCOR) to compute a “vegetation index” raster that maps variations in vegetation cover more accurately than any other previously documented method.

By adjusting GRUVI processing parameters, you can use the script to compute a range of standard vegetation indices, including NDVI. But for many applications you will obtain better results by using the novel aspects of the GRUVI algorithm that take into account the variation in soil surface spectroreflectance below and among the green vegetation canopy. With appropriate processing parameters, GRUVI can remove these soil effects to produce a more accurate mapping of green vegetation biomass than traditional vegetation indices. This approach is illustrated in the attached color plate entitled Scripts by Jack: Mapping Vegetation/Soil Biophysical Properties, where wet soil and dry soil in a field being actively irrigated look just the same in the GRUVI green biomass map but are distinctly different in the NDVI map. GRUVI also computes a bare surface brightness index, a physical property, for areas that are partially vegetated.

The logic applied in the GRUVI model is explained in detail in FAQ E: Grand Unified Vegetation Index Images of the FAQs by Jack reference materials. The implementation of GRUVI is also open for your examination and modification in the actual script.

Generalized Mapping of Biophysical Properties. (TASCAP.sml)

The analysis method used in the GRUVI script for deriving 2 biophysical properties from the red and near-infrared reflectance values for each cell can be generalized to map additional biophysical properties. The TASCAP script applies the same general logic to 3 or more SRFI or SRFI- and TERCOR-derived reflectance bands. It is already well known that the tasseled cap transformation applied to the Landsat multispectral images can be used to derive 4 biophysical indices: vegetation green biomass, yellowness, and wetness and bare soil brightness. TASCAP goes further by applying this transformation to spectroreflectance rasters derived from ASTER, QuickBird, Ikonos, and Landsat multispectral imagery. It improves the accuracy of these 4 indices by using surface reflectance rather than the original data values or radiance values. You can also use it for your own exploration to isolate additional indices in other areas such as geology, soil mapping, and so on, using imagery with more and narrower spectral bands.

The TASCAP script allows you to choose from 3 tasseled cap implementations when run. Method 1 uses the coefficients derived for this transformation for Landsat TM bands to SRFI spectroradiance values calibrated only to the top of the atmosphere to compute the green vegetation biomass, brightness, and wetness and bare soil brightness. Method 2 applies predetermined, estimated coefficients to transform the spectroreflectance of 4, 5, or 6 input spectral bands into a standard set of indices as raster objects. Method 3 can be used to adapt the tasseled cap transformation approach to any SRFI values computed from any sensing device that has 3 or more spectral bands. You train this method using materials you identify in the SRFI calibrated imagery. These are then used to derive the coefficients for the transformation that will map the particular surface materials that you are interested in, assuming they have reasonably predictable and consistent surface reflectance in each of the spectral bands used as input. Further discussion of the TASCAP approach can be found in the attached color plate entitled Scripts by Jack: Generalized Mapping of Biophysical Properties and in FAQ F: Tasseled Cap Transformation Images in the FAQs by Jack series.

Color-Enhance Satellite Images of Coastal Areas (WATER.sml).

Images that have large areas of both clear shallow water and vegetated land are difficult to enhance to properly show both land and water-bottom details. If the imagery is panchromatic, both areas may be enhanced simultaneously by applying the Local Area Contrast Enhancement (LACE) transform in TNTmips. The WATER script is used to separately enhance both the land and water areas in a color, color-infrared, or other color rendition of multispectral imagery by using the SRFI rasters as input. It first makes a simple classification of the SRFI rasters to separate land from water and prepares a water mask raster. Various separate processes can then be applied in the WATER script to enhance how the land and water images are recombined to better portray each in various kinds of color images. The dramatic improvements in a coastal image are illustrated in the color plate entitled Scripts by Jack: Color-Enhance Satellite Images of Coastal Areas, and the details on using this approach and the operation of the script can be found in FAQ G: Improved Coastal Images in the FAQs by Jack reference materials.

The following article has also been recently published based on applying the ideas in this script.

DANGER. Deep Water Ahead! Mapping submerged water features with satellite imagery requires an approach that differs from land mapping. Jack F. Paris. May/June 2005. Earth Imaging Journal. 2005. Vol. 2, No. 3, pp. 30-32.

More Scripts by Jack?

Dr. Jack Paris is completing an advanced script to automatically extract object polygon boundaries, particularly agricultural field boundaries. His approach will use these calibrated biophysical image properties, edge filters, watershed basin finding, and other unusual concepts. Watch MicroImages news for a color plate and more information on this new topic. Additional scripts on other advanced topics may also appear as ideas occur and if you respond favorably to these scripts.

FAQs by Jack™.

Introductory and background material to assist you in understanding, locating, and setting the parameters required for each of these scripts is provided in an associated PDF file.   Since these are dynamic and changing applications, these FAQs by Jack may be periodically adjusted and thus are not installed as part of TNTmips. The most recent versions of each of these references can be viewed or downloaded from www.microimages.com/downloads/FAQsByJack.htm. The following are the titles and abstracts of these FAQs and an abstract of the script each of them covers.

FAQ A: Remote Sensing Tutorial (42 pages).

This tutorial-oriented FAQ reviews the background ideas and concepts used in these scripts and in the additional FAQs: remote sensing, atmospheric windows, spectral bands, spectral radiant energy terms, Standardized Reflectance Factors (SRFs), SRF Indices (SRFIs), c-factors, n-Space, and transformations from one n-Space to another n-Space.

FAQ B: Surface Reflectance Images - SRFI.sml (40 pages).

The SRFI.SML script converts multispectral (MS) digital numbers (DNs) to Standardized Reflectance Factor Index (SRFI). Three Correction Level Options are available:

1. Make no corrections for atmospheric effects, i.e., produce top of atmosphere SRFI: SRFItoa.

2. Correct only for atmospheric reflectance effects, i.e., produce atmospheric-path-corrected SRFI: SRFIapc.

3. Correct for all atmospheric effects, i.e., estimate surface SRFI: SRFIsfc.

When appropriate, SRFI.sml also produces a pair of calibrated index rasters called the Perpendicular Vegetation Index (PVI) and Perpendicular Brightness Index (PBI). PVI and PBI rasters are required by DIAG.sml, a script designed for diagnostic analyses.

FAQ C: Diagnostic Products for Surface Reflectance Images - DIAG.sml (13 pages).

Diagnostic products help you determine the SRFI spectral signature for two specific kinds of land cover: bare soil and dense vegetation. These are key inputs to subsequent analysis tools. With a well-selected set of parameters, DIAG.SML may produce other “pure-pixel” signatures of interest.

FAQ D: Terrain Correction for Surface Reflectance Images – TERCOR.sml (11 pages).

TERCOR.SML corrects SRFI values for the predictable effects of shading caused by terrain slope and aspect. Terrain shading values are obtained from a digital elevation model (DEM). Based on the corrected SRFI values, TERCOR.SML then produces a new pair of PVI (Perpendicular Vegetation Index) and PBI (Perpendicular Brightness Index) rasters.

FAQ E: Grand Unified Vegetation Index Images – GRUVI.sml (31 pages).

GRUVI.SML produces a user-controlled pair of calibrated indicator rasters for vegetation biomass and soil-brightness assessments. GRUVI.SML can provide a solution to the non-linear mixing problem that faces the MS imagery analyst when dealing with mixed vegetation and soil spectra. Non-linear mixing occurs when foreground materials, e.g., vegetation, are partially transparent in one or more of the spectral bands that are involved as inputs to the GRUVI algorithm. In the usual application of GRUVI.SML, the near infrared (NR) band (either NA or NB) is selected as the input SRFIY band (Y-Axis) and another band, e.g., RL, is selected as the input SRFIX band (X-Axis). Partial surface transparency creates a complex non-linear spectral mixing between foreground vegetation and background materials that have a range of brightness. The GRUVI algorithm is much like the SAVI algorithm (Huete, 1988); however, GRUVI is more flexible than the SAVI algorithm in that GRUVI can be optimized to minimize the disparate effects of variations in background brightness.

FAQ F: Tasseled Cap Transformation Images – TASCAP.sml (38 pages).

The most common use for TASCAP.SML is to produce two or more measures (TC raster values) of specific biophysical properties from multispectral imagery that has more than two spectral bands. Often, the main measure of interest is TC Greenness (a kind of Vegetation Index, VI). But measures of other properties of vegetation such as (leaf) wetness and (leaf) yellowness are also possible. TC Brightness, usually the 1st TC raster, has less utility.

FAQ G: Improved Coastal Images – WATER.sml (19 pages).

WATER.sml produces an IMAGE raster that is a merged combination of an enhanced water picture and a reference land picture. IMAGE is a single 24-bit color RGB raster that can be exported to an external file, e.g., a single GeoTIFF file, as a value-added image product. This script is based on recently published ideas by the author (Paris, 2005).

Geospatial Scripting Language (SML).

Introduction.

Editor.

Responding to your requests the following features have been added to the SML editor. Added syntax highlighting makes scripts easier to read by showing comments in red, keywords in blue, and text strings in cyan. Text can be selected with the shift-arrow and shift mouse click. The current line number is shown at the bottom of the window.

New Classes and Functions.

An important new class permits your script to draw directly into a CAD object in a Project File. One application is to capture graphs your script draws on the screen so that they can be used in a TNT layout or exported for use in some other software.

A script can now use a new class to connect to an HTTP (web) server as a client and to accept a message from an HTTP server. Connections can also be made from a script to a web server using Simple Object Access Protocol (SOAP) and to accept parameters returned from a SOAP web service.

A function is available to use any flight control device to interrupt a script running in TNTsim3D. This function can be used to change the operation of a running script that is executing an automated or preprogrammed flight. For example, it was implemented so the user of a recorded or orbiting simulation can interrupt it and regain user control of the flight automatically simply by activating any flight control.

Expanded Classes.

Coordinate Reference System classes have expanded documentation to make them easier to use.

All of the parameters defining the current use of an object in a display are saved. This provides the opportunity for a script to redisplay the object as it was last viewed in any TNT process.

Parameters are available to permit you to compute the contrast for a raster layer. The transparency of a raster layer can be set. You can now also access the current contrast setting for a raster object.

Multiple objects of different types can now be selected in a single file selection dialog. When a text field is being imported, its encoding can be specified so that it is imported in the proper character set for that language. This is needed to localize the import of text into the target language by a script.

Localizing Script Text.

It is now possible to localize the dialogs you create in your geospatial analysis scripts (SML). This is illustrated in the printed instructions entitled Nebraska Land Viewer Atlas Installation included in this 2005:71 release for use with the Land Viewer: Nebraska Statewide DVD. The Find Area of Interest dialog in this TNTatlas can be used in Spanish and Turkish since this script includes the resources for these 2 languages. With this addition your TNTmips, TNTatlases, Applidats, Tool Scripts, and other uses of scripts can be localized to match the language they are operating in.

When you use this new approach, your script’s dialogs will automatically appear in the language that is currently selected for use in the TNT product running the script. Since the text elements you use in a dialog can be anything you choose, they are not automatically available from the MicroImages translation resource file for that language. You must include the translations of each dialog’s text elements in the script for each language you choose to support in that script. Consult the Find Area of Interest script to see an example of how each language is set up in the script.

Sample Scripts.

The 4 sample scripts included with this release were prepared by MicroImages as usual to provide you with sample script code segments that you can cut, modify, paste, and reuse in your scripts. The reverse sides of the color plates illustrating these scripts provide the annotated script or that portion that is new and unique to that script.

3 of these sample scripts also provide useful applications that are of current general interest but are either subject to future modifications as new ideas occur (Patch Holes in SRTM DEMs) or are Tool Scripts, which operate more or less just the same as if they were coded into the TNT processes but are easily modified because they are not.

Interactive Hide/Show of Tiled Layers.

This is a simple, sample script that was written in an evening while a client was visiting MicroImages. It is a straightforward interactive Tool Script that illustrates how to access the layers open for use in the active group in a view, test their extents against an interactively created region, and then show or hide them in the view. It mimics the purpose of an ESRI “Areas of Interest” Avenue script, which the client demonstrated and claimed was needed. Concurrent with this Tool Script implementation, this functionality was incorporated directly into the TNT processes. It was added in a couple of hours as an option to the GeoToolbox where any region you draw can now be used to turn the layers in the group/layout on and off. This is explained in more detail in the section entitled GeoToolbox. View changes triggered by this script or the GeoToolbox approach are nearly instantaneous using the new TNT 2005:71 separate layer caching scheme.

If you select its icon, the application of this script is simple. Simply pull open a rectangular region and click the right mouse button to show only the layers partially or entirely covering the rectangle. At any time the toggle button for the group can be used to rehide all the layers in the group. The example in the attached color plate entitled Sample Tool Script: Control Display by Area of Interest uses an area map reference with a hidden overlay of a virtual mosaic of 256 linked Digital Orthophoto Quarter Quad images. The Tool Script is used to pull open a rectangle covering some area of this reference map. A right mouse click (z key and click on the Mac with a single button mouse) will show only those DOQQ images in that area or intersected by this rectangle. A control key and right mouse click will turn off only those completely inscribed by the rectangle. The shift key and right click turns on new layers that are in or overlap the rectangle leaving all others on or off as determined by previous actions. A control and shift key depressed and a right mouse click will ignore the rectangle and turn on all layers in the group.

Creating a CAD Object.

TNT 2004:70 provided and illustrated a sample Tool Script entitled Infrastructure Graphical Profile. It created an on-screen profile using sewer, water, or other line features interactively selected in a TNT view. At some point in the use of such a profile, it will be necessary for the selection view, the profile, and the associated tabular view to be used in a TNT layout template, which would combine them to produce an engineering report. The selection view can be used directly in the layout. The tabular results can be saved as a CAD object. Now the profile script has been modified to enable the profile to be saved as a CAD object as well. The script operates just as described in the 2004:70 plate and discussion. There is simply a new Create Graph as CAD button in the profile management pane below the profile. This new capability is discussed and illustrated in the attached color plate entitled Sample Tool Script: Draw into CAD Object in a Script.

Although the use of this Tool Script is specialized, the new CAD drawing class in SML has much wider uses. Now any script that uses the generic drawing to a screen can duplicate and save this result in a CAD object. If a view of the results is not required, then the script can use this new class to draw only into the CAD object. The annotated portions of this script on the reverse side of the color plate cover the sections that create the on-screen profile and then duplicate it and save it into a CAD object.

Measure Strike/Dip of Geologic Features.

The objective of this sample Tool Script is to encourage you to consider creating the specialized, interactive tools needed in your specific discipline or personal activities. It illustrates how a view of an area can be the basis for selecting visual cues that are combined with other information not being viewed to model some result. The visual feedback of these results can then be used to refine the interactive visual selection and iteratively yield the desired analysis.

The specific objective of this Tool Script is to place and move three points on the outcrop trace of a geological bed (viewed in an image) to define its strike and dip using elevations of the points read from a DEM raster of the same area. The script provides a triangle drawing tool for this purpose, with the triangle vertices defining the locations of the three points. The plane defined by these three 3D points is computed and its local intersection with the ground surface is drawn in color for every placement and movement of any of these points. If the surface intersection trace does not locally match its representation in the image, you can return the triangle graphic to the screen to adjust any or all of the point positions. When the result is satisfactory, you can accept it and a vector point is added to the view with the appropriate strike/dip symbol at the center of the triangle.

There are a variety of other interactive features provided in this tool for possible use to refine and adjust these results. These include saving the strike/dip information and also the points of the triangle and the trace. At any time an earlier strike/dip symbol can be selected to display the trace and multiple traces can viewed at once. Any symbol’s position and result can be revised by bringing back and adjusting the triangle used to create it. This script and its interactive features are discussed and illustrated in the attached color plate entitled Sample Tool Script: Measure Strike/Dip of Geological Features.

The annotated script excerpt on the reverse side of the color plate highlights the portion of the script that gets the Z value of the 3 points from a DEM raster object, the computation of the orientation of the plane described by the 3 point’s Z values read from the DEM, and the procedure used to compute the strike and dip of this plane.

Patching the Holes in the SRTM DEMs.

This is a standalone script written to satisfy requests from several of you. Its objective is to fill the voids, or holes, in the Shuttle Radar Topography Mission (SRTM) elevation raster objects, which are important data sources in many geographic areas that do not have other suitable DEMs available. The script provides an approach to fixing the voids in these DEM rasters so they can be used in 3D Display, TNTsim3D, in the Scripts by Jack (if absolutely no other more accurate DEM is available or can be created), in the watershed process, and many other TNT procedures, such as the strike/dip script discussed just above.

This void filling is an excellent application for the use of a geospatial script. The script would be used just once for the SRTM elevation raster for an area and then is not particularly useful for any other purpose. However, new ideas may occur for handling these image artifacts and then the script can be modified or extended and run again to produce an improved DEM.

In preparing this script various other activities toward this objective have been examined including those of JPL, IBM, and others. Some of these efforts are reviewed and compared in Void Fill of SRTM Elevation Data: Performance Evaluations. by Trina Kuuskivi, Jennifer Lock, Xiaopeng Li, Steve Dowding, Bryan Mercer. ASPRS Annual Conference, March 2005, 12 pp. and available at intermap.com (...link obsolete...)

Frankly these expensive efforts are singularly unimpressive. It is difficult to grasp why a program costing a billion dollars from start to almost finished is best patched up with a single SML script written by a junior MicroImages software engineer!

This script is structured so you can choose from and combine a number of hole filling operations depending upon the nature of the holes you find in the geographic area you are dealing with. The script does not use surface fitting to predict the missing data in large holes as this does not work. Single isolated void cells are filled by the interpolation of the surrounding cells. Small collections of voids surrounded by cells with a specific value are assumed to be water and are filled with that edge value. Large void areas are filled from any available local DEM. This patch DEM could be derived in TNTmips by digitizing map contours from 1:50,000 scale maps and deriving a local DEM for just that void area. In the worst case scenario the GTOPO30 DEM provided on your TNT Global Data DVD can be used for patching, a solution that is better than nothing. When these larger hole areas are patched with a locally-derived DEM, various options are available to match and feather it into the SRTM hole.

The attached color plate entitled Sample Geospatial Script: Patch Holes in SRTM DEMs illustrates the dialog for this script and the effect of several of these hole filling procedures. MicroImages would be more than happy to receive your suggestions for improving this script. Effort is about to be expended to increase the size of the DEM that can be processed in the TNT Watershed Process. The objective is to permit you to apply the process to larger basins using these corrected SRTM DEMs. It is possible that the results of the application of this process will identify the need for even more accurate preprocessing operations on this SRTM elevation data. For example, the largest SRTM holes appear behind peaks and ridges and in deep ravines and canyons. These are also the areas that define the edges of major watersheds and the direction of flow of drainages. Filling these holes correctly is thus critical and is why filling them by surface fitting is not going to produce useful results in this process.

If your objective is simply to fix up these holes for qualitative use in 3D views and simulations, then filling them from the GTOPO30 DEM would be adequate and nearly automatic instead of using some surface fitting method. Surface interpolation is used by simple geospatial analysis systems where getting the DEM data ready for patching into the holes, even from GTOPO30, would be complicated: reprojecting, resampling, fitting, combining, feathering, and so on. This script uses the familiar TNT capabilities to do all this for you automatically.

Smoothing Recorded Flight Paths.

The subsection above with this same name in the major section entitled TNTsim3D™ for Windows discusses a new script that can provide new sample script segments for reuse in your scripts. As usual there is an annotated portion of the script on the reverse side of the attached color plate entitled TNTsim3D: Smoothing Flight Paths. It highlights the key portion of the script that splines the 3D coordinates of the irregular path recorded during your operation of TNTsim3D.

Recording a Movie.

The subsection above with this same name in the major section entitled TNTsim3D™ for Windows discusses a new script that can provide new sample script segments for reuse in your scripts. As usual there is an annotated portion of the script on the reverse side of the attached color plate entitled TNTsim3D: Making Movies. It highlights the script segments that set up the parameters needed and how to start and stop recording a movie in TNTsim3D.

You are reminded that there are several other sample scripts available as examples of how to generate movies using content defined in a 2D or 3D view and paths you define with a vector, by equations, via sensors, or some other method. These sample scripts are PAN1.sml, ORBITSP.sml, VSHEDMOV.sml, PATHcALT.sml, and movie.sml. The topic of making movies using scripts is also discussed in the tutorial booklet entitled Writing Scripts with SML.

New Functions.

Raster Functions. (3)

HasNullMask( ) note: also added to SML version 2004:70
Does a raster object have a NULL mask?

HasNullValue( ) note: also added to SML version 2004:70
Does a raster object have an assigned NULL value?

HistogramGetSampleInterval( )
Returns the sample interval used when the histogram is created.

TNTsim3D Special Functions. (3)

SetStatusText( )
Display text directly to the status bar of Main view.

OnControlActivate
Control device interrupts simulation and runs your custom custom script.

GetInputObject
Modified so that any object type can be selected.

New Classes.

Import/Export Classes (16).

MieARCGRID
Import and export the Arc Grid file without compression into/out of a raster object.

MieCSV
Import comma separated values (CVS) into a table.

MieDB_TEXT
Import a simple text file into a table.

MieDBASE
Import and export a dBASE file into/out of a table.

MieDCR
Import Kodak digital camera DCR file into a raster object.

MieDWGCAD
Import AutoDesk DWG drawing file into a CAD object.

MieDWGVECTOR
Import AutoDesk DWG drawing file into a vector object.

MieGMLCAD
Export a CAD object to an Open Geopatial Consortium’s GML V3.1 file. (GML 3.1 is proposed ISO standard 19136)

MieGMLVECTOR
Export a vector object to an Open Geopatial Consortium’s GML V3.1 file. (GML 3.1 is proposed ISO standard 19136)

MieMAPINFO_ATTRIB
Import MapInfo Attribute Tables.

MieNetCDF
Import NetCDF to a raster object.

MieNIKON
Import the NEF format from a NIKON camera.

MieORACLE_SPATIAL
Export vector object to an Oracle Spatial layer.

MieSDTSCAD
Import SDTS files to a CAD object.

MieARCSHAPEFILESHAPE
Import a shapefile to a vector object.

Other New Classes (11).

GLGOBJECT
Gives access to the setting for Generic Logic’s GLG widget/gadget set.

GRDEVICE_CAD
Allows for “drawing” into an RVC CAD object.

GUI_CTRL_GLG
Allows insertion of Generic Logic’s GLG widgets/gadgets into dialog boxes.

HTTP_CLIENT
Allows a client connection to a HTTP (web) server.

HTTP_MESSAGE
A class to hold a message from HTTP (web) server or the headers of a request to a server.

SOAP_OBJECT
Allows connection to a SOAP (Simple Object Access Protocol) web server.

SOAP_VALUES
Allows connection to a SOAP (Simple Object Access Protocol) web server.

New Methods.

SML now has many of the important classes available among the more than 300 already available. More and more of your requests for new features in SML involve the addition of new methods to these exising classes. Until this time their has been no means to easily identify the new methods added since the prior release for reporting here. This is being changed and future Release MEMOs will be able to itemize here the new methods added since the last release.

MIE
Specify language encoding of the text fields when importing databases.

GRE_LAYER_RASTER
To allow control of contrast settings for raster layer.

GRE_LAYER
To allow saving of display parameter subobject.

Upgrading TNTmips.

If you did not purchase version 2005:71 of TNTmips in advance and wish to do so now, please contact MicroImages by FAX, phone, or email to arrange to purchase this version. When you have completed your purchase, you will be provided with an authorization code by FAX. Entering this authorization code while running the installation process lets you complete the installation of TNTmips 2005:71.

The prices for upgrading from earlier versions of TNTmips are outlined below. Please remember that new features have been added to TNTmips with each new release. Thus, the older your version of TNTmips relative to 2005:71, the higher your upgrade cost will be.

Within the NAFTA point-of-use area (Canada, U.S., and Mexico) and with shipping by UPS ground. (+150/each means US$150 for each additional upgrade increment.)

TNTmips Product	Price to upgrade from TNTmips:					2001:65
	2004:70	2004:69	2003:68	2002:67	2002:66	and earlier
Windows/Mac/LINUX	US$500	750	950	1100	1250	+150/each
for 1-user floating	US$600	900	1140	1320	1500	+180/each
UNIX for 1-fixed license	US$800	1250	1650	2000	2250	+200/each
for 1-user floating	US$960	1500	1980	2400	2700	+240/each

For a point-of-use in all other nations with shipping by air express. (+150/each means US$150 for each additional upgrade increment.)

TNTmips Product	Price to upgrade from TNTmips:					2001:65
	2004:70	2004:69	2003:68	2002:67	2002:66	and earlier
Windows/Mac/LINUX	US$600	900	1150	1400	1600	+150/each
for 1-user floating	US$720	1080	1380	1680	1920	+180/each
UNIX for 1-fixed license	US$900	1400	1850	2200	2500	+200/each
for 1-user floating	US$1080	1680	2220	2640	3000	+240/each

Promotional

Urban Studies.

The following color plates have been created using TNTmips by a MicroImages staff member with a Ph.D. and experience in Urban and Regional Planning. They are provided as an introduction of how geospatial analysis can be applied in this professional area. They illustrate the importance of using a system that is capable of closely integrating the use of raster, vector, CAD, RDBMS, and other geodata types in these kinds of applications.

Color plate entitled Urban Studies: Site Selection Analysis.

Color plate entitled Urban Studies: Slope Analysis.

Color plate entitled Urban Studies: Watershed Analysis.

Internationalization and Localization

It is now possible to localize the dialogs you create in your geospatial analysis scripts (SML). This is illustrated in the printed instructions entitled Nebraska Land Viewer Atlas Installation included in this 2005:71 release for use with the Land Viewer: Nebraska Statewide DVD. The Find Area of Interest dialog in this TNTatlas can be used in Spanish and Turkish since this script includes the resources for these 2 languages. With this addition your TNTmips, TNTatlases, Applidats, Tool Scripts, and other uses of scripts can be localized to match the language they are operating in.

When you use this new approach, your script’s dialogs will automatically appear in the language that is currently selected for use in the TNT product running the script. Since the text elements you use in a dialog can be anything you choose, they are not automatically available from the MicroImages translation resource file for that language. You must include the translations of each dialog’s text elements in the script for each language you choose to support in that script. Consult the Find Area of Interest script to see an example of how each language is set up in the script.

New MicroImages Authorized Resellers

The following new companies are authorized to resell the TNT products. Please contact them for assistance in your own language if you are interested in learning more about our products.

EGYPT.

Cairo
	GeoTiba
	Mohamed Eleiche	voice:	(816)817-3470
	P.O. Box 17, Zamalek	FAX:	(202)757-8060
	Cairo 11211	email:	mohamed_eleiche@hotmail.com
	Egypt

GREECE.

Piraeus (Athens)
	European Air Support Ltd
	George Mertinos	voice:	(3021)0411-3388
	107 Alkiviadoy Street	FAX:	(3021)0411-3357
	Piraeus 18532	email:	easltd@otenet.gr
	Greece

MEXICO.

Leon
	Click Redins de Mexico S.A. de C.V.
	Jorge Malo	voice:	(5247)7719-0262
	Paris #604, Colonia Andrade	FAX:	(5247)7636-4830
	Leon, Guanajuato CP 37370	email:	info@grupoclick.com.mx
	Mexico	web:	www.grupoclick.com.mx

Discontinued Resellers

The following resellers are no longer authorized to sell MicroImages’ products. Please do not contact these former resellers regarding support, service, or information. Please contact MicroImages directly or one of the other MicroImages Authorized Resellers.

MicroImages is pleased to provide new resellers the opportunity to use, learn, and resell the TNT products. However, professional geospatial analysis is a complex undertaking. MicroImages discontinues resellers for various reasons. Foremost among these is that it is not in our interest, your interest, or the interest of prospective new clients to be put in contact with a reseller who makes little or no effort to use and understand the TNT products. As a result, they can not help design or participate in projects, contribute input to MicroImages product improvement and development, or effectively promote the TNT products.

Bolivia.

Industrial Consulting Services Ltd. (ICS) [Rafael Arias] located in Santa Cruz de la Sierra is discontinued and reorganized as DICORP Digital Corporation (see above).

Chile.

GeoVectra [Danko Ambrus] located in Santiago is discontinued.

Bosnia and Herzegovina.

Geo-centar. [Vladimir Petrovic] located in Banja Luka is discontinued.

France.

Geosciences Consultants S.A.R.L. [Richard Guillande] in Paris is discontinued.

Appendix: Abbreviations

For simplicity, the following abbreviations were used in this MEMO.

2005:71 = the official release or subsequently patched version 7.1 of the TNT products.

DV2005:72 = the Development Version of the next release of version 7.2 of the TNT products.

W95 = Microsoft Windows 95.

W98 = Microsoft Windows 98.

WME = Windows Millennium Edition.

NT or NT4 = Microsoft NT 4.0 (the TNT products require the use of NT4.0 and its subsequent Service Packs). NT4 now has a Service Pack 6a available.

OGC = Open Geospatial Consortium.

ISO = International Organization for Standardization.

CRS = Coordinate Reference System.

W2000 = Microsoft Windows 2000. Windows 2000 now has Service Pack 4, which is recommended if you are working with large files.

W2003 = Microsoft Windows 2003.

XP = Microsoft Windows XP. Requires Service Pack 2 for TNT Explorer.

Mac 10.4.2 = Apple Macintosh using Mac OS X version 10.4.2

MI/X = MicroImages’ X Server for Mac and PC microcomputer platforms and operating systems.

GRE = MicroImages’ Geospatial Rendering Engine, which is at the heart of most MicroImages products. The current GRE will respond and render requests from either X/LessTif or Windows.

VB = Microsoft Visual Basic

MB = megabyte (1,000,000 bytes)

GB = gigabyte (1000 megabytes) or 10⁹ bytes

TB = terabyte (1000 gigabytes) or 10¹² bytes

©MicroImages, Inc. 2013 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

TNT Products 2005:71

Table of Contents

Editorial and Associated News [by Dr. Lee D. Miller, President]

Hardware News

TNTserver™ 2005:71

TNTatlas 2005:71 for X

TNTsim3D™ for Windows

TNTview® 2005:71

TNTedit™ 2005:71

New TNTmips 2005:71 Features