Fantasia
Creative Commons License photo credit: spitfirelas

Today Maperitive celebrates its first birthday! It has been a productive year and Maperitive has learnt a lot of new stuff.

This post is dedicated to my wishes and plans for features I want Maperitive to learn in its next year. Some of these features I planned even before I started working on the software, while others are more fresh and indicate a shift in focus. My initial goal was to concentrate more on the GUI and less on the features, but as time passed the GUI became less and less important. This is mostly due to my decision to implement scripting support, which made a lot of things easier to implement through command-line than by writing GUI code.

This doesn’t mean the GUI will be totally forgotten. It does however mean I will prioritize other things over it. My general goal is for Maperitive to become a tool for making high-quality maps with emphasis on scripting and automation.

So the following subsections describe some major things I want to see in Maperitive in the near future.

Better OSM Relations Support

This is something I’ve already started working on. The idea is to provide a better way to work with OSM relations. I’m still in the brainstorming phase on this one, but I can give a some examples of things I want users to be able to do:

  • If an OSM way is shared by two or more relations, I want the way to be treated as a single entity. Think way which represents both a country and a municipal boundary. I want only the country boundary to be shown in this case.
  • Aggregate OSM tags for two or more relations sharing the same way. Think 5 bicycle route names drawn in a single box for such a way.

Extensibility

I’ve started playing with IronPython as a way to allow users to specify custom code for various parts of the rendering pipeline. Some examples pop up in my mind:

  • Custom painting of the map (after the map elements have been rendered). This would allow drawing user-defined grids, labels, logos, legends etc.
  • Individual map element customization, like setting the color of the line based on value of some OSM tag. Or setting the width of the line based on how many bicycle routes cross a way.

I already did some testing with IronPython and it looks very promising.

Improved Scripting

IronPython could also be used to make the existing Maperitive scripting much more powerful. The current script language (if you can call it like that) is just too limiting – no variables, no loops, no branches etc.

I also plan to add a pure console application for headless scripting, so you won’t need to look at the GUI when running scripts.

Automatic Label Placement

This is the Holy Grail of cartography – having map labels arrange themselves in a nice looking way. I plan to devote a lot of time on this one.

Label Abbreviations

Closely related to label placement, I’ve actually implemented some parts of this feature. But before releasing it to the public, there is a lot more to be done.

Other Map Projections

It’s time to cut the ropes Mercator has tied us with. Mercator projection is nice for Web maps, but there is a lot of other interesting map projections that can be used to show OpenStreetMap data. Implementing this won’t be as simple as it sounds – Mercator projection has some pretty nice properties which make rendering on screen much easier than some other projections. And this is important for real-time renderer like Maperitive. But I guess it can be done.

Data Mining

Planet.osm is getting bigger and bigger and increasingly difficult to consume. I want to create a toolset for extracting data from large OSM files. Yes, I know there’s osmosis, but I want to have a good integration of data mining with Maperitive. And this is another point of entry for Python: writing custom filter code. Still in brainstorming phase.

Using Databases

I’ve played with spatialite and PostGIS back in 2009 and I managed to do some integration with Kosmos. I expect this to be one of the harder things to implement. I want to avoid hacky approach Mapnik uses for storing OSM data in a database – my wish is to keep the data structure in the original form.

Conclusion

That’s it, really. I don’t like writing long posts. I guess you’ll have to be patient and some of the things mentioned above will start to trickle in. Have a good day!