igorbrejc.net

I received this request a long time ago and it was finally time to implement it:

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 put together a simple home page for Maperitive: http://maperitive.net/. It will be improved, once I send it to a proper web designer.

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).

This morning I’ve made a an announcement on Twitter about Maperitive finally being released. You can download it from here.

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.

I’ve read recently in some forum post that you couldn’t select all ways in Kosmos and render them, even if they have no tags at all. Well, this evening I implemented support for this in Maperitive:

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.

A screenshot from my yesterday’s Maperitive paper prototyping session:

Tools of the trade:

The second part of the rules:

rulefor : railway

    define

        min-zoom : 13

    define

        line-color : gray

        line-width : 2

        curved : false

    draw : line

    define

        line-style : dashlong

        line-color : white

        line-width : 2

        border-style : solid

        border-color : gray

        border-width : 25%

        curved : false

    draw : line

rulefor : road.*

    define

        line-join : round

        line-start-cap : none

        line-end-cap : none

        curved : true

    for : motorway

        define

            min-zoom : 12

            line-color : #849BBD

            border-style : solid

            border-color : #849BBD black 20%

            border-width : 15%

        for : link

            define

                line-width : 12:3;13:4;16:5;18:6

        else

            define

                line-width : 12:5;13:7;16:10;18:12

        draw : line

    elsefor : trunk

        define

            min-zoom : 12

            line-color : #96D296

            border-style : solid

            border-color : #96D296 black 20%

            border-width : 15%

        for : link

            define

                line-width : 12:3;13:4;16:5;18:6

        else

            define

                line-width : 12:4;13:6;16:8;18:10

        draw : line

    elsefor : road primary

        define

            min-zoom : 11

            line-color : #ECA2A3

            line-width : 7:1;9:1.5;10:2;12:5;13:7;16:10;18:12

            border-style : solid

            border-color : #ECA2A3 black 20%

            border-width : 15%

        draw : line

        define

            min-zoom : 7

            max-zoom : 11

            border-style : none

        draw : line

    elsefor : road secondary

        define

            min-zoom : 12

            line-color : #FDCC8B

            line-width : 7:1;9:1.5;10:2;12:4;13:5;16:8;18:10

            border-style : solid

            border-color : #FDCC8B black 20%

            border-width : 15%

        draw : line

        define

            min-zoom : 9

            max-zoom : 12

            border-style : none

        draw : line

    elsefor : road tertiary

        define

            min-zoom : 13

            line-color : #FEFEB2

            line-width : 7:1;9:1.5;10:2;12:4;13:5;16:8;18:10

            border-style : solid

            border-color : #FEFEB2 black 20%

            border-width : 15%

        draw : line

    elsefor : (.*residential)|(.*unclassified)

        define

            min-zoom : 13

            line-color : white

            line-width : 13:2;15:10;18:12

            border-style : solid

            border-color : white black 50%

            border-width : 20%

        draw : line

        define

            min-zoom : 15

            font-family : Arial

            font-size : 15:7;18:10

        draw : text

    elsefor : road track

        define

            min-zoom : 12.5

            line-color : #9D7517

            line-width : 1.5

            line-style : dash

            border-style : solid

            border-color : white

            border-width : 100%

            border-opacity : 0.3

        draw : line

    elsefor : road footway

        define    

            min-zoom : 13

            line-color : #F68474

            line-width : 1.5

            line-style : dot

            border-style : solid

            border-color : white

            border-width : 100%

            border-opacity : 0.3

            curved : false

        draw : line

    else

        stop

rulefor : river

    define

        line-color : #B5D0D0

        line-width : 7:1;8:2

    draw : line

rulefor : national park

    define

        fill-color : #8DC56C

        fill-opacity : 0.2

        line-style : none

    draw : fill

    define

        line-color : #8DC56C black 20%

        line-opacity : 0.5

        line-width : 3

        line-style : dash

        font-size : 3:3;12:12

        text-halo-width : 3

    draw : line

    draw : text

rulefor: parking

    define

        icon-image : http://wiki.openstreetmap.org/images/9/9a/Parking20.png

        min-zoom : 15

        icon-width : 16

    draw : icon

rulefor: contours.*

    define

        line-color : #7f3300

        line-opacity : 0.5

    for : contours major

        define

            line-width : 2

    draw : contour

Since rendering rules parsing and processing has more or less been implemented a few weeks ago, I think it’s time to show how these rules look like.

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…

In the previous post I mentioned my work on the command-line interface for the new Kosmos v3 GUI. I’m more and more excited with the possibilities this feature opens. A lot of things which can be tedious to code because of the required GUI widgets can now be provided fairly quickly through the command line (this doesn’t mean there won’t be any GUI, but certain functions are better served through a textual interface).

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.