Archive for the 'Kosmos' Category

Published by breki on 13 Mar 2010

Maperitive: Bitmap Scaling

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

Maperitive scaling

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.

Published by breki on 13 Mar 2010

Maperitive Gets Its Own Site

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

Published by breki on 12 Mar 2010

Maperitive: First Release

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.

Published by breki on 05 Mar 2010

Maperitive: Wireframe Rules

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:

Maperitive wireframe

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.

Published by breki on 20 Feb 2010

Paper Prototyping

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

Paper prototyping

Tools of the trade:

Paper prototyping - tools

Published by breki on 18 Feb 2010

Maperitive Rendering Rules, Sneak Preview (Part 2)

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

Published by breki on 18 Feb 2010

Maperitive Rendering Rules: Sneak Preview

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
                    

Published by breki on 05 Feb 2010

Poor Man’s Task Tracking Tool

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.

Published by breki on 29 Jan 2010

The King Is Dead – Long Live The King ;)

Negroni time Creative Commons License 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…

Published by breki on 05 Jan 2010

Kosmos: Querying Data

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:

KosmosQuery

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.

Next »