I finally managed to integrate my new digital elevation model (DEM) processing code into Kosmos. It was a lot more work than I anticipated, mostly because the existing Kosmos’ source code is getting large, difficult to maintain and even more difficult to introduce new functionality. For me it is the best example of why SOLID principles are not just a developers’ buzzword, but that they do have an impact on maintainability of the code as the code base gets larger and larger. Although Kosmos’ code is highly modular, uses all the paradigms of object-oriented programming, even uses inversion of control (IoC) containers quite a lot, this is not enough: certain portions of the code are pretty bloated with multiple responsibilities, which is a first no-no when we talk about SOLID principles: keeping the design clean by separating responsibilities into separate services/components.
When changing the code which serves more than one responsibility, it is difficult to separate these responsibilities and difficult to test the impacts. Unit tests in fact become mini-integration tests and you typically need more setup code in order for a test to be able to run. Which produces unit tests that are fragile and, like the “main” code, difficult to maintain.
I mentioned the usage of IoC containers (Castle Windsor actually). The problem is that you need some mileage to get things right: a common mistake is to drag the container around in your code and use it explicitly to create objects. This defeats the purpose of the IoC container: to wire things together without your intervention. I agree with Joshua Flanagan when he says that the “container” word was unfortunate choice: it should be called a “composer”. Kosmos was one of the first projects where I used an IoC container and it shows: there are a lot of things which I would have done differently now.
All the more reason for me to continue on my effort of rewriting the critical parts from scratch. But that’s a story for some other blog post.
Anyway, I hope the new IBF thing works. The bad news is that I needed to change/hack some code, so I cannot exclude a possibility of a bug or two. The other bad news is that the old “.dat” contours format is no longer supported, so you’ll need to recreate contours for your projects.
The good news, on the other hand, is that we switched to the NASA’s new SRTM server, since the old one has gone to retirement. And even more: the new IBF code is much better that the old Srtm2Osm one, the contours are now placed properly on the map, the contour generator now knows how to correctly ignore data voids and the contour files are much smaller.
I also made changes to GroundTruth to cut the produced IBF tiles exactly around the specified map boundary.
Oh yes, the download links:
Enjoy! And if you find the stuff I’m making useful, please consider a small donation. It will be used for books, software and equipment, all for the benefit of producing even better stuff in the future: