igorbrejc.net

A new version of GroundTruth has finally been released! I covered new features in previous posts:

• GroundTruth: Relief Contours
• GroundTruth Contours: Final Testing

I’ve already updated the GroundTruth For Dummies page on OSM wiki with some basic instructions, I’ll update the manual in the next few days.

DOWNLOAD LINK: http://downloads.igorbrejc.net/osm/groundtruth/

Licensing & Sources

GroundTruth is released under GPL v3 license. You can find the sources on this link.

Enjoy! And if you find the software useful, please consider a small donation to the author:

Thanks!

While testing contours generation in GroundTruth, I wanted to find out which values for the following cgpsmapper settings are optimal:

• TreSize
• SimplifyLevel
• PreProcess

SimplifyLevel

This setting specifies the simplification level for Douglas-Peucker simplification algorithm used by cgpsmapper. The value range is from 0.1 (maximum simplification) to 10 (no simplification). Of course, more the map features are simplified, the smaller the IMG file will be, but you loose data quality. After experimenting with this value, here are my conclusions:

• The simplification level does not affect the cgpsmapper’s speed of generating IMG files.
• There is no real noticeable difference in map quality between level 10 and 1.
• There is a noticeable difference in map quality between level 1 and 0.1 (see screenshots below).
• Total map sizes: 53 MB (level 10), 44 MB (level 1), 25 MB (level 0.1)

Conclusion: SimplifyLevel 1 seems to be the best compromise between the map size and its quality.

PreProcess

This setting specifies what kind of preprocessing of data will be done by cgpsmapper (generalizations, intersection detections…). I did not notice any real difference when using any one of possible options. The map size is the same, so is the generating speed and map quality.

Conclusion: I’ll leave this setting to be specified by the user.

TreSize

This one is hard – I don’t really know exactly what this setting is really all about. To quote cgpsmapper’s manual:

Maximum allowed region size. A higher value increases the allowable region size, but may decrease the map performance; a lower value may increase the map size.

As I stated in previous post, TreSize value of 4000 caused generation of certain map tiles to fail. The failed tiles contained a lot of contour data. So I lowered it to 2500 and then it worked without problems. When I tried TreSize of 1000, it generated a little bit larger map and took a little bit more time.

Conclusion: I think TreSize=2000 is the best compromise value.

Contours with SimplifyLevel value of 1:

Contours with SimplifyLevel value of 0.1. Notice how contour lines at the top of the map now have much sharper edges:

I did some testing of relief contours generation before the official release of GroundTruth v1.3. I generated 10m interval contours for area of Slovenia and its neighboring regions, and here are some numbers:

• Area: minlat:45, minlng:13, maxlat:47, maxlng:17
• IBF file size: 28 MB (IBF file contains contours information in a binary form). My estimate is that the equivalent Srtm2Osm-generated OSM XML file would be at least 350 MB large.
• Time taken to generate Garmin IMG files from IBF file: 15 minutes on my machine
• Total size of generated IMG files: 53 MB
• Total IMG files count: 125 files

As you can see from the first screenshot below, the contour files are split into a 15′ grid. You can therefore choose which of the tiles you want to upload to your GPS unit.

I had some problems with cgpsmapper reporting “Too Big RGN Table Structure” error for grid cells with a lot of contours. To overcome this, I reduced the cgpsmapper’s TreSize setting from 4000 to 2500 and then it worked without problems.

I’ll also try to experiment with the SimplifyLevel setting (currently no simplification is used) in order to reduce IMG file sizes and (possibly) rendering speed on GPS units.

All in all, I’m very pleased with results. I hope to be able to release the new version real soon!

photo credit: Matthew Fang

UPDATE: there’s a temporary workaround for this problem suggested by cgpsmapper’s author, please read his comment below.

Looks like the latest 0098 version of cGPSmapper (more precisely its cpreview.exe) has a bug: cpreview breaks down when generating GroundTruth preview maps. I’ve reported the bug to cGPSmapper’s author, hopefully it will be fixed soon. In the meantime, I recommend using the previous version of cGPSmapper…

BTW: you can still generate main IMG files – the process breaks down after that. But you won’t be able to import maps into MapSource (well not automatically, anyway).

Just a little teaser before going to bed. The screenshots show relief contours generated by GroundTruth using SRTM3 data. The map area is progressively zoomed in: first you can see the 100m contours, then also 20m ones and finally 10m contours are visible.

Expect it in the next release of GroundTruth.

photo credit: pt

I’ve decided to take some time and fix GroundTruth bugs which were kindly reported by users in the past month. Nothing revolutionary, but there are also some minor improvements. Here’s a complete list:

• added the “-nocgp” option to just generate the polish files, without using cgpsmapper. This will be useful for those who would like to tweak the polish file before actually generating an untweakable? IMG file.
• “-osmfile” option is now used instead of “-osmfiles”. If you need to specify more than one OSM file, use “-osmfile” multiple times (together with “-mapname” option for each of these OSM files). This is actually an interface change and also a bug fix: looks like MapSource doesn’t like having two maps with the same name. Look at few lines below…
• GT now generates registry file for deleting the map from MapSource (in addition to the existing “add” one). So you can destroy those ugly looking GroundTruth maps and they won’t appear in MapSource again… ever…
• BUGFIX: GT now requires that each OSM file has its own map name.
• BUGFIX: the type IDs are now always written as hexadecimal values. There was some problem with using decimal values (thanks for reporting, Frederico)
• BUGFIX: problems with OSM objects which are used by more than one relation. Now there shouldn’t be problems
• BUGFIX: “DummyPath.img” is now always looked for in the GroundTruth’s directory, not the current one. BTW DummyMap.img is used to “reset” the GPS unit before sending the actual map using SendMap.

The download location (as always): http://downloads.igorbrejc.net/osm/groundtruth/

That’s it for now. I’ll try to add isohypses/contours support soon.

If you find GroundTruth and other software I’m developing useful, please consider sending me a small donation via Paypal. I’ll put it to good use (hmmm should I buy a Ferrari or a Porsche?).  And thanks again to those that contributed in these times of recession…

photo credit: euart

As I mentioned few days ago, I’m currently finishing the Isohypse Binary File (IBF) functionality, which I intend to include both in the next versions of GroundTruth and of Kosmos.

The upcoming 2.5 version will probably be the last in the 2.* series. After its release I plan to do a major overhauling of the source code. The plan is not to add any major new features, but instead reorganize and clean up the code, since it has become more and more difficult to add new functionality in the existing code organization.

History

In order to explain this, let me first give a few historic facts. Kosmos 1.* series was a simple Windows desktop application which was started as a simple prototype for testing the map rendering concepts. It slowly grew fatter with new features, but the GUI code was very difficult to work with and almost made it impossible to create a user friendy interface. So a year ago (looks like I get these “ideas” each spring ) I decided this had to change, so I started working on a new GUI framework which would support multiple document interface (MDI) with runtime-configurable menu structure and actions. That’s how 2.* series started.

Separating The Domain Layer

Now that the code is old enough, I decided to take a look back at it. My conclusion is that there was too much emphasis on GUI and application infrastructure and that the domain logic (mainly OSM map rendering) was too intertwined with the rest of the code. Since I began reading the excellent Domain-Driven Design book (DDD) few days ago, this gave me a new perspective on things and convinced me of the need for the change.

The basic idea behind DDD is a principle of separation of the domain layer from the other layers in the software (user interface, application and infrastructure). In the case of Kosmos, the domain code would be the translation of OSM data into visual elements (and some other stuff). If this separation does not exist or if it is poorly enforced, all sorts of problems start to happen with the project. Including the types of problems I’m having now with Kosmos . When you start mixing UI code, domain code and the application code, it is very difficult to track changes when you implement new features. Basically the software becomes a huge beast that cannot be comprehended even by its author .

So my plain is to drag the map making code out and probably create a separate library for it. The added benefit would be that such a library could later be reused for other software too: instead of trying to fit everything and anything into Kosmos, there could be separate applications for

• map editing (JOSM-style)
• trip planning and analysis (something like this or this)
• … you name it.

All Very Nice, But We Want New Features

Me too. I want to have a integrated visual rules editor, ability to view GPX data, routing (its actually already half-implemented, but it waits for the GUI support), 3D and a lot more. But in the present state of things, bloating the code even more in an unstructured way would only produce a lot of bugs and not a lot of working functionality. Which means that nobody will be satisfied with the results. I’d rather leave Kosmos as it is than to have a buggy-crappy tool.

So I guess the spring will be the time for some house-cleaning. Hopefully it will not take as much time as I spent in introducing Kosmos 2.0. So let me finish this post with a quote from Zen monks:

If you don’t have patience, if you can’t endure, well, don’t bother, because you won’t get very far.

photo credit: ~jjjohn~

Well, sooner or later it was bound to happen. I’ve decided to put the yellow “Donate” buttons on my blog.

Although I did consider it for quite a while, I never really got to doing it. I guess I was lazy or a little bit apprehensive about asking people to donate their money. But today I got a notification that my bandwidth monthly quota for the igorbrejc.net Web hosting has reached 80%, and it’s only 10th in the month. I guess all the software downloads lately have slowly eaten away my quota.

BTW I’m not paying anything for the hosting (except for the domain registration), since it was generously awarded to me by my friend Boris and he was even kind enough to extend my bandwidth quota several times. But I guess it’s time to give him something back for his help (a six pack at least).

So anyway, if you find the stuff I’m developing (Kosmos, GroundTruth, etc) useful, please consider making a small donation to my effort. The money will be put to a good use, buying:

• Books that will extend my knowledge
• Tools that will help me develop new (and hopefully better) stuff
• Extra bandwidth, if it is needed  
• An occasional beer or two

And here’s the button (I will post it occasionally in blog posts):

All donations will be kept anonymous (unless you want it known). Thanks!

Status Update

As a side note: I’m currently in final stages of developing a new tool for generating relief contours based on a new Isohypse Binary File (IBF) format I’ve conceived. The main benefit of IBF (as opposed to holding the contours in OSM XML format) is the size – an experiment showed it used only 1% of the space compared to OSM XML. The data is split up into tiles, so a user can have a relatively large area covered with a single file and then pick and choose which tiles he/she needs. The IBF contours will be available both in Kosmos and GroundTruth in the short future.

I have just generated Garmin maps for Slovenia using GroundTruth. Here are some performance results (my machine is Intel E6400, 4 GB RAM):

• Source OSM data: 330 MB OSM file (non-compressed)
• Time to generate: 8 minutes
• Maximum RAM usage: 1.1 GB

This is for the hiking map which currently contains more rules than the driving map (driving map generation took “only” 3 minutes). The actual performance bottleneck is cgpsmapper, most of the time and memory consumption is caused by it. If you’re planning to generate even larger maps, I suggest splitting OSM files (using tools like osmosis) before giving them to GroundTruth. You can generate multiple IMG files by supplying several OSM files in a comma-separated list.

photo credit: Matthew Fang

Ah the beauty of new software. Especially if you like killing bugs:

• The latest version seems to be working on Linux. See OSM wiki page for more information.
• The Characters conversion table on OSM Wiki had the wrong section name (my mistake), so it was being ignored by GroundTruth.
• Labels for line types are now automatically converted to uppercase – there were problems with showing lowercase letters on some Garmin units.

I’m also slowly adding content to the GroundTruth Manual.