MapWindow6
From MapWindow GIS
What is MapWindow 6.x ?
Up until now, all of the work in MapWindow has been developed around a portable C++ control wrapped in an Active X control. This model is changing for MapWindow6. We started with a topology suite that had been ported to C# from the open source Java Topology Suite. In and of itself, this set up a kind of idea that we are attempting to build around in MapWindow 6, by adhering to OGC standards where possible. This is actually fairly tricky when I (Ted Dunsford) am still just learning how to do 3D rendering with DirectX, so we are drifting towards compliance, but may not be exactly there for a while.
Map Window 6 will be entirely dot net, though we plan on designing a "Data Provider Plugin" concept that allows one to easily extend the basic file support structure of the original application. (i.e. one of the earlier plugins will be one that can use GDAL to extend the file formats that we support.) We plan on providing a wrapper to the very popular GDAL libraries through this interface, even though the GDAL libraries are ultimately not dot net. The native file formats in planning are ESRI Shapefiles for feature layers, bgd grid format, possibly an existing multi-band grid format, and some simpler image types like BMP, JPG, TIF etc. A control called the PluginManager will allow developers to easily decide whether to support existing plugins.
The basic display in MapWindow 6.x is a 3D control that will rely on DirectX for drawing. The development may take a little longer as I learn how to program in DirectX for the best results, but the viewable display is much faster than what can be achieved in GDI+. The down side is that the symbology options may be trickier to implement.
The architecture is still being discussed, but one of the traps that existed in MapWindow4.x was the inability to support vector layers that were not connected to a file. The new architecture should allow us both to support entirely in-ram entities and entirely file-based entities. The advantage of an In-Ram entity is that it is easier to change on the fly, faster to work with and more portable. The advantage of the file-based entities is that you can support a huge amount of data (more than what can be loaded into ram at one time) and run processes on enormous amalgamations of data. I am in the process of rewriting the Shapefile objects that came with NTS because they do not optimally handle the binary reader and won't support this dual purpose treatment.
Here are some links that might prove interesting for those following the development process:
