So what’s so special with this map? Maperitive offers the export-bitmap command, which basically exports the currently visible map portion to a bitmap file. What’s new is that you can set a higher (> 1) scale for the export:

export-bitmap scale=3

which will produce a bitmap with higher resolution, but with the rendering rules applied to the original zoom level. This can be useful for printing maps in higher quality.

In future I plan to introduce a SVG export command, which will make map post-processing even easier.

I’ve also created a dedicated Google Group for Maperitive to make discussion and help seeking easier. You are welcome to join in.

The next thing is to start to write some documentation, since I know this is the main problem right now.

And expect Maperitive updates (in fact I’ve already released one this morning).

I’d like to stress that work on Maperitive is far from finished. This release is just the first one I felt confident enough to send to the public, both in terms of stability and in terms of functionality it offers.
I’ll be posting more on how to use it, but let’s first take a look on what it currently provides and what it lacks.

The Good

OK, first some of the stuff I think you’ll find interesting:

• New rendering rules system: it’s more powerful, more flexible and (I think) easier to write.
• Linux, Mac: due to improvements in Mono and also due to the new code, Maperitive now seems to be working on Linux and Mac without any major problems.
• Scripting: everything Maperitive offers is available through scripting commands. This makes automating stuff much easier.
• Auto-updating: I’ve devoted a lot of effort on making Maperitive update itself automatically when a new version is available. There are some glitches on Mac, however.
• Querying: you can now use the same query “language” used in rendering rules to look for stuff on the maps.
• Relief contours: they’re back! Since I started working on Maperitive, I simply didn’t have any time to fix contours generation on Kosmos.

And last, but the most important: Maperitive right now is more of a framework than a finished product. What does this mean? The main reason I started rewriting Kosmos code was to make it easier to add new features. This has now been achieved, to a large extent. What comes next is actually adding these features.

The Bad

Now the bad parts:

• GUI: as you will see, it’s pretty vacant . A few months ago I decided not to spend too much effort on making Maperitive look like Kosmos. That would have taken me at least a couple of months of more work before I could actually release anything. But that doesn’t mean the user interface will not improve in the near future!
• Features: Maperitive does not offer everything Kosmos did. Again, the number one task for me right now is to add all Kosmos stuff to Maperitive.

The Ugly

Yes, it’s GUI again . Linux and Mac users will have to suffer a pretty ugly interface. I guess this is the price of cheap portability: Maperitive currently runs on different platforms with virtually the same code base (again, thanks to Mono guys). If you notice any big issues, please write (you can use send-feedback command in Maperitive to write to me directly).

Off to write some code.

The white-ish lines represent OSM ways. The green color depicts OSM areas. The rules for this are quite simple:

features
    lines
        all lines : 
    areas
        all areas : 

properties
    map-background-color : #181818

rules
    rulefor : all areas
        define
            fill-color : green
            fill-opacity : 0.1
        draw : fill

    rulefor : all lines
        define
            line-color : lightgray
            line-width : 1
        draw : line

Anyway, I’m still hoping I’ll be able to fix all the “todo” stuff from my list within few weeks, but I cannot promise. It seems that for each item I remove from the list, two new items appear. I guess I’m another victim of the Ninety-ninety rule.

Tools of the trade:

I’ve tried to mimic some of the styles and colors used for Mapnik OSM map (although this covers only about 10% of Mapnik’s rules). I won’t be explaining these rules right now because I’m interested in what you think of them at the first glance – can you understand the basic concept or not? Are the rules too verbose? Are they legible? The only hint I will give is: indentation is important!

So here it is, the first part (I have to split this into two posts, WordPress problems) :

features

    parking : amenity=parking

    contours major : contour[elevation=50]

    contours minor : contour[elevation=10]

    areas

        forest : landuse=forest OR natural=wood

        farm : landuse=farm

        fell : natural=fell

        national park : boundary=national_park

        water : natural=water OR waterway=riverbank

        residential area : landuse=residential

    lines

        river : waterway=river

        railway : railway=rail

        road motorway : highway=motorway

        road motorway link : highway=motorway_link

        road trunk : highway=trunk

        road primary : highway=primary

        road secondary : highway=secondary

        road tertiary : highway=tertiary

        road unclassified : highway=unclassified

        road residential : highway=residential

        road track : highway=track

        road footway : highway=footway

        state borders : relation[boundary=administrative AND admin_level=4]

properties

    map-background-color    : #F1EEE8

    map-background-opacity    : 1

rules

    rulefor : areas

        define

            line-style : none

        for : forest

            define

                min-zoom : 9

                fill-color : #8DC56C

        elsefor : farm

            define

                fill-color : #E9D8BD

        elsefor : fell

            define

                fill-color : #C5FF5B black 10%

        elsefor : water

            define

                fill-color : #B5D0D0

        elsefor : residential

            define

                fill-color : #DCDCDC

        else

            stop

        draw : fill

31.01.

    - indicate the command prompt has focus

    - added detection of changed OSM files

    - implemented get-info command

    - started working on the error reporting func.

02.02.

    - implemented MailService

    - implemented AppDiagnostics

    - added error reporting form, but it still needs to be beautified

    - support for polygons/polylines consolidated from relations

04.02.

    - solved the problem: why is footway drawn ABOVE residential road?

        - it's because the footway feature is defined AFTER the residential road

    - fixed: bug with form disposing        

    - if a way is used in a relation, it should be ignored elsewhere

        -written tests for this        

05.02.        

    - TODO: the rules and features should be specified in the reverse order

        - from the most important to the least important

    - TODO: how to solve layering problem?

- TODO: beautify error reporting dialog

- TODO: find an icon for Maperitive

- TODO: implement multipolygon polyline rendering

    - TODO: write tests for multipolygon rendering

This is an excerpt from Maperitive’s Todo.txt file. I use it as a log of the stuff I did for the current day and also as a “database” of the tasks I still have do. On various projects during the years I used Trac, Bugzilla, on Kosmos I used ToDoList for a while, but nothing beats the simplicity of a text file.

The history log is a recent “invention”: since Maperitive is a pet-project, the time allocated to it is very unevenly distributed – sometimes I do a lot of work in a single day (usually on weekends without find weather or hangovers), but then I have to leave it untouched for several days. So often it happens that I forget what I was working on – and this history log helps me to quickly refresh the memory. Also, it’s a good psychological tool: I take a look and the log entries and see that some work has actually been done and I’m (slowly) progressing towards the first release.

The added benefit is that I can copy&paste these log entries into SVN commit comments. And of course, Todo.txt is kept under the source control like the rest of the code.

photo credit: ????

I’ve been twitting about it for a few weeks: I’ve decided to give a new name to the upcoming Kosmos v3.

First to explain my reasons for the renaming. Let me go back to end of 2007 (huh, was it so long ago?) when I started working on a new pet project: a desktop mapping application. Back then I noticed most of the cool stuff related to OpenStreetMap had to contain “osm” in its name, so I searched for words containing “osm” on the net. I’m not mentioning other candidates, but I settled on more exotic version of “cosmos”, to improve searchability.

Well, it turns out some other people thought the same, so now we have all sorts of stuff also called Kosmos: Russian rockets, some new-age journal, a Greek car rental agency, an oil company and I don’t know what else. So when you want to find Kosmos on Google, it typically turns up on the bottom of the first results page. Which is kind of uncool

The second reason for renaming is the fact that Kosmos name had not really have to do anything with the actual purpose of the application.

So a month ago I started toying with the renaming idea. Since I wasn’t too sure if it was a good idea at all, I decided I’d stay with the old name if I couldn’t find more catchy and unique one. I have to say it was a hard search: I have a few dozen name candidates listed in my private Wiki (I’m not revealing any of these to avoid causing distress to readers) – but most of these are either a) already used for other stuff or b) just plain ugly. (As a sidenote: my friend Boris (jokingly I hope) suggested a name that would put my blog squarely in the internet XXX territory. Let’s just say it related the mapping with some human private parts, I won’t go into details on this one).

And The Name Is…

OK, I won’t bore you to death: the name I chose is Maperitive. Let me retype this without any spelling errors: Maperitive. But what does it mean, you might ask? Well, it’s a pun: a map and an apéritif. So to paraphrase a Web dictionary: it’s stimulating the appetite for mapping.

I’m not sure you’ll like the name. As a matter of fact, I’m not sure I like the name that much myself – but it’s better than the other candidates. It’s not revolutionary like iPad or MS Paint. But what I especially like about it is that at the time of me writing this post, it has an absolute zero search results on Google. So Maperitive it is. No going back.

Other News

Other than name-searching, I did a fair amount of work on the actual application, mostly on the parsing of rendering rules and the graphics. I’ll cover this in another post this weekend, but right now I’m finishing this post to go search for a good algorithm for calculating the area of a polygon on Earth surface. Next time I’ll tell you why…

I managed to implement some basic parsing for what I call spatial specifications which will be used in the new rendering rules system. An example of a spatial specification would be something like…

way[highway=footway].[barrier=gate]

…would select gates on footways.

I wanted to test this parser and so I implemented a simple find command for querying OSM data:

It’s just a prototype – I plan to add some kind of browsing of query results (both on the map and in the log window) – but it shows the possibilities of this interface. The querying could extend to GPS data, too. It could also be used to filter out GPX data (based on the date, for example). These commands could be written in a script file and reused every time you want to process your GPS logs, for example:

1. Download data from the GPS unit
2. Keep only the data from today
3. Simplify tracks
4. Save this to a GPX file
5. Upload the GPS trace to OSM

…could be fully automated.