Very old news (2003)

29 December 2003 Version 0.2.2 of DSpatial was just released on SourceForge. This is a pretty exciting release for those of you interested in satellite imagery. The main feature of this release is the 3-channel renderer, which lets you assign bands of a multi-spectral satellite image to the individual colour channels of the renderer. On top of that, support for pan-sharpening has been added, so you can make optimal use of the high-resolution pan band available on many satellites (for instance Landsat 7 ETM+, band 8; Ikonos; SPOT), or use high-resolution aerial photography with lower resolution imagery. This is a feature you will not find in many commercial packages.

The pictures to the left speak for themselves. Shown is a detail from an Ikonos image at 4 meter resolution. Channel assignments are RGB::red,nir,blue (using the near-infrared brings out the vegetation), with contrast enhancement applied manually based on the histograms of the individual bands. The picture on top shows the native Ikonos resolution, the picture below uses the 1 meter resolution pan band for pan sharpening. The purple blotches on top reveal themselves as a house and a shed on the bottom. Individual tree crowns can be distinguished on the bottom image. The pan channel adds structure to the spectral channels, thus providing more detail. This is particularly useful when working with imagery of urban areas, with its straight lines and sharp edges between features, but it has application in land management as well.

You can now save data in a different format. If your favourite GIS does not support some complex format (like HDF or SDTS) you can use DSpatial to "downgrade" the format to something more easily understood. For instance, getting SDTS DEM data into ArcView 3 has always been a troublesome task (ArcView's USGS DEM import is faulty). With DSpatial you can load the SDTS DEM and convert it to an FLT file, which ArcView easily reads (File | Import Data Source | Binary raster). Currently rasters can be saved as BIL, BSQ, FLT, and Idrisi raster.

Then there is the usual assortment of bug fixes, optimizations, and minor enhancements. Work on the 0.3 release is already underway and you may find blocks of code in the kernel that appear to be useless. Don't worry, you are looking at the future. Version 0.3 of the kernel will provide the infrastructure on which the extension modules depend. With this upcoming 0.3 release there will also be two of those extension modules: gridmath (basic arithmetic on raster bands) and terra (for terrain analysis). Version 0.3 is expected to be released sometime in February.

27 November 2003 Today DSpatial was released in version 0.2.1. Compared to version 0.2.0 there are some improvements to the rendering engine, making it less memory intensive and faster too, panning support in the viewer (press F7 in the demo), added raster data formats (ESRI FLT binary rasters, Idrisi rasters, and HDF files), and, as you can see above, a flexible histogram component. Under the hood there have been some changes to the PFA, mainly related to thread separation, and certain additions in preparation for analytical modules. The TDSpViewer component is now offered in a package together with the TDSpHistogram component, so you can install them in the IDE by using the DSpComponents package.

The analytical modules will be offered separately from the kernel module. Currently there are two modules being constructed: "gridmath" for arithmetical operations on raster bands, and "terra" for terrain-based operations (such as slope, aspect, visibility, etc.). A third module called "orbit", for the analysis of satellite imagery, is on the drawing boards. While gridmath and terra are not far away from being useful, the kernel needs to support saving data sets before any analysis results can be saved persistently outside of DSpatial. This will be the main development objective for the coming release (0.2.2).

The HDF format driver for Win32 is offered as a separate download from the Drivers module on the download page. There are two reasons to do so. Firstly, HDF is not for everybody. Chances are you will never use HDF files, unless you use satellite imagery produced by NASA. Secondly, the driver depends on two DLLs (548 kB), making it bulky to distribute. HDF is produced by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. DSpatial uses HDF version 4.1r5. HDF-EOS, the HDF descendant used by NASA, is not explicitly supported, but any HDF-EOS version 2 file will be read successfully by the current driver.

7 November 2003 DSpatial has undergone a major overhaul, at least on the inside. The kernel and the PFA have seen some far-reaching changes, made to facilitate multi-threaded access to data sources and to reduce the dependency of DSpatial on the Windows API. Version 0.2.0 has just been made available through our download page. The biggest changes relate to the way that data is managed in the kernel, but this has had an influence over all other code. Beware that some units have disappeared and that the folder structure is somewhat different (less folders, for instance). The kernel is now thread-safe. For every data source that you access a separate thread is created, which can be accessed by multiple processing or display threads. But even if you write a simple application for displaying some data your application will exploit the multi-threaded architecture through the asynchronous rendering pipeline.

From the user perspective this release is equivalent to version 0.1.3. With the improved multi-threading in place we can now focus on expanding functionality: (1) Writing data sets in the raw binary format; (2) Additional data formats (HDF); (3) Improved support for projections; and (4) Analysis functions for rasters.

25 September 2003 The next release of DSpatial, version 0.1.3, has just been made available through our download page. This minor release has some unspectacular, but nevertheless handy improvements over the previous release.

It is now possible to delete data sets from the data manager. While this may seem like a rather mundane capability, changes in the code cascaded right down to the PFA and into the rendering engine.

You can now save raster data as a graphic, using the current rendering settings. There are two options to pull this trick: 1 - You can save the contents of the viewer to a graphic, which will include any renderer data that is visible at that time; and 2 - You can generate a graphic from a single renderer. When there are multiple bands in a renderer, all bands will be rendered in one graphic at the coarsest resolution of any of the bands. When there is only one band, the graphic will have the same resolution (pixel dimension) as the source data. Try this with a bunch of contiguous DEMs, or maybe some GTOPO30 data? The current demo uses the PNGImage package developed by Gustavo Daud.

A driver for raw binary data has been added. The raw binary format is used for many raster data sets available on the web. One of the better known freely available data sets that this unit will read is the so-called GTOPO30, a digital elevation model of the world at 30 arc-second resolution. The current version supports reading of 8-bit (dspUInt8), 16-bit (dspInt16), and 32-bit (dspInt32) data. Reading coordinate system information in an ancillary file is not yet supported as this requires some quite extensive changes to the current coordinate system code. Support for writing data sets with this driver are planned for the near future.

And finally, some family pride. DSpatial is listed on the SDTS home page as a "private company implementing SDTS". Yes, right there on the very top of the page!

31 August 2003 A unit with support for raw binary data has been placed in the CVS, right around here. The raw binary format is used for many raster data sets available on the web. One of the better known freely available data sets that this unit will read is the so-called GTOPO30, a digital elevation model of the world at 30 arc-second resolution. The current version supports reading of 8-bit (dspUInt8), 16-bit (dspInt16), and 32-bit (dspInt32) data. Reading coordinate system information in an ancillary file is not yet supported as this requires some quite extensive changes to the current coordinate system code. Support for writing data sets with this driver are planned for the near future.

As with other drivers of data formats, all you need to do to use this unit is to include it in your project and add the folder with the unit to the search path of the project.

14 August 2003 Version 0.1.2 has just been released through SourceForge. This minor release has some major enhancements to the rendering engine. On the surface, the most interesting addition is the so-called smooth ramp as a rendering option. This smooth ramp can have an unlimited number of breaks with their associated colours. The rendering of intermediate values interpolates between the colours at the breaks, yielding some very dramatic displays. (Shown here is a 200-meter resolution DEM of Costa Rica's south-eastern Talamanca mountain range; data in E00 format.)

Under the hood, the changes are more substantial. DSpatial now supports multiple bit-lengths for raster data (8, 16, 32 bit signed/unsigned integer, 64 bit signed integer, 32 & 64 bit floating point). Raster data is now held in memory in an instance derived from a hierarchy of storage classes, opening up possibilities for compression and more efficient access.

DSpatial is now aware of coordinate systems. It can parse so-called OpenGIS Consortium Well-Known Text (WKT) strings that contain a full description of coordinate system parameters. While DSpatial does not yet support projections between coordinate systems, the ability to distinguish between coordinate systems brings that goal a whole lot closer. For now all data sets are assumed to be in meters, so the viewer will display an inaccurate scale if you use a data set in feet or some other unit.

The ArcInfo export format is now supported for raster files. The E00 export file must contain a GRID coverage (the second line should start with "GRD"), which will be converted to a single band raster image in integer (dspInt32) or floating point (dspFloat32) format. For now the reader assumes that the raster represents a surface (the only band type that the renderers will work with right now).

20 July 2003 The ArcInfo export format is now supported for raster files. The E00 export file must contain a GRID coverage (the second line should start with "GRD"), which will be converted to a single band raster image in integer (dspInt32) or floating point (dspFloat32) format. For now the reader assumes that the raster represents a surface (the only band type that the renderers will work with right now).

The unit DSpE00 is available through the CVS in /dev/v0.1/formats/E00. For those of you without a CVS client, a web interface to the CVS is available from the home page. Or you can simply click here. Just add the unit to your project and you are set (just make sure the DSpPFA unit loads before the DSpE00 unit).

18 July 2003 The next batch of code has been placed on the CVS and the complete code base has been released as DSpatial version 0.1.1. This current code includes a demo viewer which is the first application that uses the DSpatial kernel architecture. You can check out the main features of the kernel and the visualization sub-system on the library specification page.

There has been some development on the PFA, but the structure is still generally the same. Since all development effort over the last two months has been focussed on getting the kernel to work, the list of supported data formats is still dreadfully short: SDTS RPE data sets.

This release is unfortunately specific to Delphi; it will not compile on Kylix. This is due to the use of Windows-specific OS calls to support multi-threading in the DSpDataMgr unit. The call in question is WaitForMultipleObjects. (Similarly, in DSpRaster there is the OS call WaitForSingleObject, which will be removed in the next release.) DSpatial will become cross-platform as soon as somebody can support it by using Kylix on a Linux box.

This first release also marks the public announcement of DSpatial. Over 5 months have passed since 2 February, when a discussion on the JEDI-Maths newsgroup on Yahoo! spawned this effort. That may seem like a long time to some, but the kernel that has been developed since - the part that most users will never see - does provide a solid basis for building applications. We are not that far yet, there is so far no analysis in DSpatial, but extending upon the kernel should prove to be easier than designing the kernel itself. If you're interested, get involved!

22 April 2003 The first code is now available on the CVS! Patrick has implemented an SDTS reader, which can now read the so-called "Raster Profile and Extensions" (RPE) data sets. While it is still a work in progress, it does currently read the Digital Elevation Models that the USGS has published for the USA. A simple demo app is also available through the CVS.

As an offspring to the SDTS reader development, Ivan Lee Herring, author of the DTM application and an active GLScene contributor, has agreed to donate the source code of the formats supported by DTM. These include GLOBE, GTOPO, ETOPO, SRTM, ASCII and binary DEM, Surfer GRD and Arc GRD, among others.

Alex has in the meantime been working on the projection DLL, which is based on the venerable PROJ library, currently maintained by Frank Warmerdam and his team. The DSpatial code for accessing the DLL will be posted soon.

The DSpatial team has been joined by Zohrab Mawani. Zohrab, better known as zInc in the digital world, will be focussing his attention on raster and TIN modeling. Welcome zInc!

We're also still working on the general specification of what this project will be, what it will look like, and how it will be implemented. We need your input!

1 March 2003 DSpatial was established on 25 February 2003, so you can imagine that we are still dealing with the painful issue of being born. There is currently no code available for download, but the development team is working on a few code projects at this moment: spatial data formats, projection library, and visualization.

Of much greater concern at the moment is the general specification of what this project will be, what it will look like, and how it will be implemented. We need your input!