BrainCrunch

The problem with OpenStreetMap multipolygons

Sun, 31 Mar 2013 20:07:20 +0200

Here’s a very simple example of why I think OpenStreetMap multipolygons are a disaster.

Let’s say you download a data extract of an area and you get a relation that has six member ways (all of them in outer role). The way most extracts work, you only get those ways that cross (or are inside) the download bounding box, in our case there are only two such ways:

What now? In normal situations you would be able to clip the two ways using the bounding box and then connect them along the box. But the trouble is, you have two different (and equally valid) possibilities:

How do you decide which is the correct solution, is the body of the polygon in the center between the two ways or is it on opposite sides? Let’s see what options we have:

Orientation of ways: no help here - ways (and rings) can be oriented any way you like in OSM multipolygons. Usually in GIS and graphics polygons follow a clockwise/anti-clockwise rule, but in OSM this practice was abandoned. The only reason for this I could think of is to make it easier for the mappers to edit maps.
Member roles: in this case the outer/inner roles don’t help very much.
Tagging: I wouldn’t want to get into that mess. And there’s no general tagging solution for this problem, as far as I know.
Requiring that extracts contain all the relation’s members: OSM has a lot of very large relations that span hundreds of kilometers and even whole continents. Why would I want to have all of the Russia’s coastline when I download the extract of, say, small part of Estonia?

Don’t be fooled by the simplicity of my example into thinking that this is a rare case. Lately I’ve been working a lot with extracts of cities and I get into these kinds of problems all the time: riverbanks, forests, administrative boundaries are typical examples of multipolygons that tend to be big and become ambiguous when used in extracts.

Basically, OSM multipolygons are a disaster. The “rules” (a.k.a. “recommendations”) on the wiki page change often, and not for the better. There’s a tendency to recommend very liberal ways of constructing multipolygons - nothing’s really mandatory and it is left to the consumer of the data to deal with the headaches. This is a very shortsighted approach, in my opinion, and it will hurt the project and the community in the (not so) long term. If the data cannot be used by “ordinary” users without complex toolchains and expensive hardware resources, then what is the purpose of it all?

Data hoarding for the sake of it?

Hi, I was following your 10 steps, and I am stuck at the 9th one where I am trying to do ftp-upload. I get an error when I do that. I have created a local ftp site and I can access it from the browser, but when I give the same in maperitive I get a log list of error, the first one of which is: SystemAggregateException: One or more errors occurred SocketException: The requested name is valid, but no data of requested type was found. Can you help me with this issue... Thanks

Fri, 24 Aug 2012 20:07:55 +0200

Googling for “The requested name is valid, but no data of requested type was found” tells me it’s some network-related issue. Maybe your ftp-upload command line is wrong - make sure the host parameter points to a valid IP or host name (without the port number).

Maperitive: Alpenglow Effect Using A Custom Shader

Sat, 30 Jun 2012 06:22:00 +0200

The latest release comes with a new Python script called Alpenglow.py which renders a hillshading relief adding some yellowish tint to illuminated high slopes to enhance the 3D effect. It was inspired by the “See the light: How to make illuminated shaded relief in Photoshop 6.0” article on the excellent shadedrelief.com site.

You can run the script by executing

run-python Samples/Python/Alpenglow.py

The script generates the hillshading for a fixed map area in Switzerland, but you can change this quite easily in the script. You can also change other parameters, like shading (and alpenglow) colors, elevation ranges etc.

The script also demonstrates the power of writing a custom shader. A shader transforms a small part of the digital elevation model (DEM) into a pixel color, based on the elevation, aspect and the slope of that part of the DEM. This way you can write your own hillshading effects function and then supply it to the generator. Here’s how it’s done for Alpenglow.py:

# Execute the hillshading
bitmap = ReliefUtils.generate_relief_bitmap(dem, relief_bbox, Srid.WebMercator, 1, alpenglow)

The last parameter of the generate_relief_bitmap function is the shader function, in our case called alpenglow:

# The actual shader function which is called for each pixel of the hillshading bitmap.
# It receives the elevation, the aspect (orientation) of the slope and the steepnes (slope).
def alpenglow(elevation, aspect, slope):
    sin_slope = math.sin (slope)

    nx = math.cos(aspect) * sin_slope
    ny = math.sin(aspect) * sin_slope
    nz = math.cos(slope)

    direction = dotproduct(nx, ny, nz, lx, ly, lz)

    direction = (direction - minDirection) / (1 - minDirection);
    if direction < 0:
        direction = 0

    # This is how we can mix two colors together.
    shade_color = shade_base_color.mix (light_color, direction)

    if direction > 0.0 and elevation > min_alpenglow_elevation:
        elevation_factor = min((elevation - min_alpenglow_elevation) / delta_alpenglow_elevation, 1);

        alpenglow_factor = math.pow(direction, 4)
        return shade_color.mix (alpenglow_color, elevation_factor * alpenglow_factor).argb;

    return shade_color.argb;

Mercator's Egg

Thu, 24 May 2012 16:40:00 +0200

UPDATE: my math was buggy, the eggs look a bit different after the correction. Note that the formula fails on very large distances (> 2000 km).

A little Maperitive Python script I was playing with today, showing the line of distance of 3000 km (larger egg) and 2000 km (smaller egg) from my home town of Maribor, drawn on the standard Web Mercator projection map:

Here’s the script:

from maperipy import *
import math

location = Point(15.6530555556, 46.5575)
distance = 3000000

layer = Map.add_custom_layer()

symbol = PolygonSymbol("circle", Srid.Wgs84LonLat)
symbol.style.pen_width = 8
symbol.style.pen_color = Color("blue")
symbol.style.pen_opacity = 0.5
symbol.style.fill_opacity = 0

earth_circumference = 6371000 * math.pi * 2;
points = []
arc = distance / earth_circumference * 360;

for angle in range(0, 360):
    radians = math.radians(angle)
    y = location.y + math.sin(radians) * arc
    lat_factor = math.cos(math.radians(y))
    x = location.x + math.cos(radians) * arc / lat_factor
    points.append(Point(x,y))

circle = Polygon(LinearRing(points))
symbol.add(circle)

layer.add_symbol(symbol)

11 Things You Should Learn Before Learning To Code

Wed, 16 May 2012 20:07:08 +0200

Here’s a list of ten skills that are much more important to get you through life than learning to code (in order of priority, set by me):

Learn how to swim.
Learn how to stay healthy and in shape.
Learn the basics of food energy intake.
Learn how to cook a decent (and healthy) meal.
Learn how to use your mother tongue.
Learn how to keep your personal finances in order. Think Greece & subprime loans.
Learn a foreign language.
Learn how to ride a bike.
Learn how to drive a car.
Learn how to use a washing machine.
Learn how to find stuff on the internet.

Maperitive: Walking Papers-Like Script

Sat, 05 May 2012 09:17:19 +0200

The latest Maperitive 2.0 beta release comes with a new script which can generate a grid of bitmap exports similar to walking papers. The added value is that you can do walking papers for your own vector data and map styles, not just prerendered web tiles.

How To Use

A brief description of how to generate your own walking papers exports.

1. Define Map Area

In Maperitive, place printing bounds on the map area you’re interested in. The printing bounds do not have to match the dimensions of standard paper sizes.

I choose the center of Ljubljana for this sample:

2. Set Export Parameters

There are a few settings in the Samples/Python/WalkingPapers.py script which you can use to control the exporting process (see the detailed instructions in the script itself):

map scale: this is the map scale for individual exported page. I choose 10,000, which in my case will result in a 2x3 pages grid.
paper size and orientation: you can leave the default A4 landscape, if you like.
paper margins: the default is 5 mm on each side of the page.
page overlap: this is a factor (from 0 to 0.25) which tells Maperitive how much adjacent pages should overlap. 0.25 means 1/4 of the page (on each side) will overlap. The default set in the script is 0.1 (10%).

3. Run The Script

… either by drag & dropping it into Maperitive or by executing

 run-python Samples/Python/WalkingPapers.py

Sample Results

Here’s one of the exported pages:

Future Improvements

You will be able to supply command-line parameters to these kinds of scripts in the future, so manual editing of the script before running it will no longer be necessary.

Oxford Bus & Cycle Map in print

Fri, 04 May 2012 13:35:27 +0200

I’ve just received the “Oxford Bus & Cycle Map” from Richard Mann (thanks, Richard!). The interesting thing is that it was made from OpenStreetMap data using Maperitive. It’s a stunning beauty, Richard has put a lot of effort into it.

Online versions of the maps are here: http://www.transportparadise.co.uk/maps/

Results Of The Maperitive Survey

Fri, 04 May 2012 10:41:53 +0200

Last week I posted a quick survey for Maperitive users. The basic motivation was to see how many people are still using Windows XP SP2, so I can decide whether I can migrate Maperitive to .NET 4.0 (which is not available on SP2). But I added a few more questions in the mix, just for the fun of it.

I got 138 reponses so far, which is much more than I expected, so thanks for everyone who participated.

The results (I just copy&pasted charts from Google Docs, sorry for the labels cut-off):

What operating system(s) are you using to run Maperitive?

Participants could choose multiple answers - in fact about 1/4 of participants were using Maperitive on multiple operating systems. About 4% of people marked they are using Windows XP SP2 - I am wondering what is the reason they haven’t upgraded to SP3 (my guess is they are using Maperitive in corporate environments which tend to be slow on upgrades).

Two things that I think are important from these results:

I can start work on migrating to .NET 4.0. For those unfortunate few who will be left out by this I can only say: try to upgrade to Service Pack 3. The official .NET 4.0 has been released two years ago (and first beta was released back in 2009) and it’s increasingly hard to support development on older versions of .NET framework. 3rd party libraries Maperitive depends on have mostly migrated to .NET 4.0 and this means missing out on new features and bugfixes.
A lot (50%) of people are using Maperitive on Linux and Mac. This is much more than I expected and it means I will still have to keep Maperitive running on Mono. This is sometimes hard, since not everything is supported by Mono correctly. It also means a lot of people are willing to put up with an inferior user interface (due to Mono porting issues) for the sake of the functionality Maperitive offers. This is complimentary.

What it is the main reason you’re using Maperitive?

No surprises here, other than that at least 1/3 of users find Maperitive simple to use. This is a high number, given the fact that the documentation is not that good.

There’s one interesting (and a little bit surprising) answer:

We can use OSM offline, without prerendering thousands of tiles. It is very helpful for emergency services, because you cannot rely on a mobile internet connection everywhere or in the case of a disaster.

What kind of a user do you consider yourself to be?

Looks like the main audience of Maperitive are users who like to hack. Only 18% of participants in the survey consider themselves to be non-technical. I guess that explains the large “simple to use” percentage in the previous question :)

I use Maperitive mainly to…

Another question with multiple possible answers. I’m pleased that a lot of you are using Maperitive’s “power tools” like tile generation and exporting. I’m also pleased that at least 37% of participants are using the SVG export functionality, which I worked hard to implement.

I use Maperitive mainly for…

I guess I shouldn’t be surprised that most of you are doing hobby mapping with Maperitive. As OpenStreetMap reaches more people (and companies), I think the percentage of non-profit and commercial usages will increase.

Conclusion

The survey is still open (I think I will keep it open for some time), so you’re welcome to have your say. There will be more surveys in the future - this one was done as an experiment, in just 5 minutes. Again, thanks for participating!

Maperipy sample: generate tiles and then optimize with OptiPNG

Sun, 29 Apr 2012 10:05:16 +0200

The latest (2.0.28) Maperitive beta now comes with a sample Python script showing how you can override the default behavior of Maperitive tile generation process. The sample collects the generated tile files and then executes OptiPNG on them to reduce the file size (OptiPNG is now included in Maperitive package) of PNGs.

Some more info about this release: http://groups.google.com/group/maperitive/browse_thread/thread/492671b461f1e1da

Here’s the source for the sample, I think it’s self explanatory:

from maperipy import App
from maperipy import Map
from maperipy.webmaps import Tile
from maperipy.tilegen import TileGenCommand

def func1 (zoom, x, y, tiles_horizontal, tiles_vertical):
    # Demonstrates how to control which tiles get rendered
    # note that Maperitive generates tiles in batches
    # (defined by tiles_horizontal x tiles_vertical count).
    # So for example, 3x3 (=9) tiles are generated in a single bitmap 
    # and then later they are split into individual tiles.

    # In this case we just print some info to Maperitive's command log window.
    print "Generating tile batch: {0}/{1}/{2} ({3}x{4} tiles)" \
        .format(zoom, x, y, tiles_horizontal, tiles_vertical)

    # In this case we return True to signal that we want 
    # these tiles to be rendered.
    return True

def func2 (tile):
    # Demonstrates how to control the saving of a tile to disk.
    # At this point we could do some postprocessing of the tile bitmap
    # or store it somewhere else (and then return False to prevent
    # Maperitive from saving it to the default location).
    print "Saving tile: {0}/{1}/{2} (file: {3})" \
        .format(tile.zoom, tile.tile_x, tile.tile_y, tile.file_name)

    # You could, for example, store tiles into a database instead
    # of writing them to disk.

    # In this case we return True to signal that we want 
    # the tile to be saved to the default location.
    return True    

def optimize_tiles():
    args = []

    # Turn on backup files (just to compare sizes with optimized tiles).
    #args.append ("-backup")

    # Set the OptiPNG optimization rate (0 to 7), 7 being very slow.
    optimization_rate = 2
    args.append ("-o{0}".format(optimization_rate))

    # We don't want any OptiPNG output text to clutter Maperitive.
    args.append ("-quiet")

    args.extend(tiles_to_optimize)

    # This is one way to execute external programs.
    App.run_program("tools/OptiPNG/optipng.exe", 100, args)

    # Clear the list.
    del tiles_to_optimize[:]

def collect_tiles (file_name):
    # Demonstrates how to collect the list of generated tiles.
    # You could, for example, use this function to upload
    # tiles to a Web server.

    # In this case we collect the file names to a list...
    tiles_to_optimize.append(file_name)

    # ... and then we call OptiPNG when the list gets full.
    if len(tiles_to_optimize) >= 10:
        optimize_tiles()

tiles_to_optimize = []

# Generate tiles for the currently set geometry bounds and the current zoom level
# (Map.position.zoom, Map.position.zoom) -> min.zoom, max.zoom
cmd = TileGenCommand(Map.geo_bounds, Map.position.zoom, Map.position.zoom)

# This is how we override TileGenCommand with custom functions.
cmd.tile_generation_filter = func1
cmd.tile_save_filter = func2
cmd.after_tile_save = collect_tiles

cmd.execute()

# Run the optimization again for any left-over tiles.
optimize_tiles()

New OSM License, Some Practical Implications And Gray Areas

Mon, 19 Mar 2012 20:40:00 +0100

Occasionally I make digital maps for customers based on OpenStreetMap data. Sometimes they request the maps in form of bitmaps, and sometimes they need a vector format like SVG or PDF in order to be able to edit the maps in Adobe Illustrator. Of course, the issue of license always pops up and often have to explain the stipulations of CC BY-SA 2.0 to them.

Soon OSM will switch to a new ODbL license. I have to admit I mostly stayed away from the numerous legal talks that were going on various OSM channels, simply because I feel much more productive coding than participating in endless strings of emails. But now that the new license is here, I need to get acquainted with it from the perspective of someone trying to make (some) living out of OSM data. “I’m not a lawyer” is the usual phrase you can see in OSM legal discussions, but waiting for one to give you some solid information is like waiting for Godot, so I’ll make judgements based on my own understanding and some common sense instead, and simplify things when I feel like it. If anyone objects, they can twitter me with their objections and I’ll try to correct things.

So let’s say a customer requests an SVG map of my home town and I decide to use OSM data for it. For the sake of simplicity the map will be based purely on OSM data, so no other sources. Let’s first look at some of the important definitions in ODbL (emphases are mine):

“Database” – A collection of material (the Contents) arranged in a systematic or methodical way and individually accessible by electronic or other means offered under the terms of this License.

“Derivative Database” – Means a database based upon the Database, and includes any translation, adaptation, arrangement, modification, or any other alteration of the Database or of a Substantial part of the Contents. This includes, but is not limited to, Extracting or Re-utilising the whole or a Substantial part of the Contents in a new Database.

“Contents” – The contents of this Database, which includes the information, independent works, or other material collected into the Database. For example, the contents of the Database could be factual data or works such as images, audiovisual material, text, or sounds.

“Produced Work” – a work (such as an image, audiovisual material, text, or sounds) resulting from using the whole or a Substantial part of the Contents (via a search or other query) from this Database, a Derivative Database, or this Database as part of a Collective Database.

“Substantial” – Means substantial in terms of quantity or quality or a combination of both. The repeated and systematic Extraction or Re-utilisation of insubstantial parts of the Contents may amount to the Extraction or Re-utilisation of a Substantial part of the Contents.

So the first open question: is an SVG map a Produced Work or a Derivative Database? Or both? SVG map is an XML file that contains projected geographical data (together with visual styling attributes). OSM XML file can safely said to be a database. If you say SVG is not a database, where do you draw the line? What about KML or GML files?

This question is important because of the next clause:

Access to Derivative Databases. If You Publicly Use a Derivative Database or a Produced Work from a Derivative Database, You must also offer to recipients of the Derivative Database or Produced Work a copy in a machine readable form of:

a. The entire Derivative Database; or

b. A file containing all of the alterations made to the Database or the method of making the alterations to the Database (such as an algorithm), including any additional Contents, that make up all the differences between the Database and the Derivative Database.

If the SVG map file is not considered a Derivative Database, then you have an option of supplying the original OSM data (OSM XML file, PBF file or even a database snapshot) together with the SVG file or providing a description of how you derived the Derivative Database.

On the other hand, I can argue that SVG is a Derivative Database because it is “arranged in a systematic or methodical way and individually accessible” and “includes any translation, adaptation, arrangement, modification, or any other alteration” of the original OSM data. So in that case simply publishing the SVG file (and only that file) would cover the license requirements.

I should note that the SVG map has to be released under the ODbL or a compatible license.

Now let’s go one step further. Let’s assume (as I do) SVG is a Derivative Database. What if I then generate a PNG bitmap (or a Web map, for that matter) from the SVG file using Adobe Illustrator and want to publish that, too? One could argue that a bitmap is a Produced Work and since we already published the Derivative Database that produced this Work, we are covered.

But what if I didn’t generate the Web map from the SVG, but used a tool like Mapnik or Maperitive and generated it directly from an OSM extract instead? Let’s say that for practical purposes I don’t want to publish 1 GB of OSM data and I choose to go down the path of describing the “method of making the alterations” I did to generate the bitmap. What are the options here?

I could write a detailed description of steps I performed to generate the Web map. Osmosis, Mapnik with all the batch scripts etc. I could even post the source code of the program(s) I used.
On the other hand, I could just describe the process in a sentence or two. I could also say I used a special filter in Photoshop.

I can partly understand the spirit of the “method” clause - to enable access to the interesting derivations of the original data. But I see several holes in the “method” definition:

What if I produced the map by arranging a lot of the map elements manually, by hand? This is quite a common case when you have to place map labels in order to avoid label conflicts. How would I describe the “method” other than saying that I did it by hand? How would that help anyone?
What if I used an expensive proprietary software (like Illustrator or Photoshop)? Or even a piece of code that I haven’t released to anyone else? In that case nobody else would be able to reproduce the method. Does the “Contents” cover source code as well? It doesn’t mention the source code explicitly. If it does, then that implies you can only use open source software with OSM data, which would be silly.
What about complex algorithms? How detailed the description would have to be for someone to be able to reproduce the algorithm? I’ve tried reproducing various algorithms from long scientific articles and I can tell you it’s not an easy task even if you have a detailed description.

Frankly, I don’t see how the “method” clause could be enforced in practice.

(UPDATE: now that I thought about it once more, the clause only talks about describing the method of arriving to the Derivative Database and not to the Produced Work itself. So I could just say “I downloaded the OSM extract from Geofabrik” and that would be it.)

One final question: does extracting OSM data for a city amount to a “substantial part” of the original OSM database?

Usability and Open Source Software

Mon, 20 Feb 2012 21:57:58 +0100

Related to my yesterday rant about QGIS and usability: I’ve been reading an article called “Usability and Open Source Software” article and it has a lot of interesting points. It’s a little bit dated (year 2002), but I think most issues remain the same even now after 10 years.

Here are some highlights I find interesting (but you should read the whole article):

If this [desktop and application design] were primarily a technical problem, the outcome would hardly be in doubt. But it isn’t; it’s a problem in ergonomic design and interface psychology, and hackers have historically been poor at it. That is, while hackers can be very good at designing interfaces for other hackers, they tend to be poor at modeling the thought processes of the other 95% of the population well enough to write interfaces that J. Random End-User and his Aunt Tillie will pay to buy. (Raymond, 1999)

…

The ‘personal itch’ motivation creates a significant difference between open source and commercial software development. Commercial systems development is usually about solving the needs of another group of users. The incentive is to make money by selling software to customers, often customers who are prepared to pay precisely because they do not have the development skills themselves. Capturing the requirements of software for such customers is acknowledged as a difficult problem in software engineering and consequently techniques have been developed to attempt to address it. By contrast, many OSS projects lack formal requirements capture processes and even formal specifications (Scacchi, 2002). Instead they rely on understood requirements of initially individuals or tight-knit communities.

The relation to usability is that this implies that OSS is in certain ironic ways more egotistical than closed source software (CSS). A personal itch implies designing software for one’s own needs. Explicit requirements are consequently less necessary. Within OSS this is then shared with a like-minded community and the individual tool is refined and improved for the benefit of all – within that community. By contrast, a CSS project may be designing for use by a community with different characteristics.

….

Many kinds of commercial software have been criticised for its bloated code, consuming ever greater amounts of memory and processor cycles with successive software version releases. There is a commercial pressure to increase functionality and so to entice existing owners to purchase the latest upgrade. … There are similar pressures in open source development, but due to different causes. Given the interests and incentives of developers, there is a strong incentive to add functionality and almost no incentive to delete functionality, especially as this can irritate the person who developed the functionality in question.

….

The process of ‘release early and release often’ can lead to an acceptance of certain clumsy features. People invest time and effort in learning them and create their own workarounds to cope with them. When a new, improved version is released with a better interface, there is a temptation for those early adopters of the application to refuse to adapt to the new interface. Even if it is easier to learn and use than the old one, their learning of the old version is now a sunk investment and understandably they may be unwilling to relearn and modify their workarounds.

…

‘Software bloat’ is widely agreed to be a negative attribute. However, the decision to add multiple alternative options to a system may be seen as a positive good rather than an invidious compromise. We speculate that freedom of choice may be considered a desirable attribute (even a design aesthetic) by many OSS developers. The end result is an application that has many configuration options, allowing very sophisticated tailoring by expert users, but which can be bewildering to a novice (Nielsen, 1993, p. 12). The provision of five different desktop clocks in GNOME (Smith et al., 2001) is one manifestation of this tendency; another is the growth of preferences interfaces in many OSS programs (Thomas, 2002).
Thus there is a tendency for OSS applications to grow in complexity, reducing their usability for novices, but with that tendency to remain invisible to the developers who are not novices and relish the power of sophisticated applications. Expert developers will also rarely encounter the default settings of a multiplicity of options and so are unlikely to give much attention to their careful selection, whereas novices will often live with those defaults.

On QuantumGIS And User Experience

Sun, 19 Feb 2012 18:54:45 +0100

Intro

Looks like my morning rant tweet “QGIS needs a usability expert. Or a whole team of them.” has caused a little storm in the GIS community. I haven’t really expected any feedback on this, so i guess I can say that Twitter is the King. I’ve already e-mailed some of my views to the first QGIS person that contacted me (Nathan Woodrow), but for the sake of open discussion, I’ll expand on these thoughts in this post.

First of all, some disclaimers: I’m an occasional QGIS user. I only use a very limited subset of its functionality (mainly viewing shapefiles, since I think it’s the best shapefile viewer out there). I’m not really a GIS professional, at least not in the traditional sense. Half of my work time evolves around developing Maperitive, a cartography software mostly based on OpenStreetMap. The other half is doing work as a professional programmer in an IT company. And I’m not a usability expert, so what I’m writing here is based on my personal experience.

Usability Issues

OK, so let’s open QGIS. The first thing users will probably notice is a fair number of toolbar icons displayed at the top:

Don’t get me wrong: I’m not against toolbars. In fact, QGIS doesn’t even have a lot of icons, compared to some other apps (I use VisualStudio a lot, and it has a lot more toolbar icons). But there are some usability issues with toolbars:

Image-only toolbars

Image-only toolbars are difficult for users to comprehend. It is difficult for most users to remember all those images and associate them with functions. This is contrary to what most designers/developers think when they use toolbars in their apps. Yes, there are some classic icons that get reused all the time (diskette icon, undo/redo, cut, copy, paste), but these are exceptions to the rule. Most of the toolbar icons are application-specific, they tend to be small and look similar to each other. Icons are great enhancers of the information, but they are not the main information.

Possible solutions:

Instead of putting all of the icon groups to the top, separate them physically. Move map-oriented icons (like zooming) closer to the map, possibly arranging them vertically instead of horizontally. I know users can move them by themselves, but that’s not the point.
For more important icons, add the text description. Yes, this takes more space, but usability takes precedence over screen real estate.
Alternatively, think about using ribbons. I hate what Microsoft did to Office, BTW, but that’s because they chose to use ribbons as a replacement of menus, instead of just an additional way to access commands.

Microsoft introduced ribbons because the number of commands in Word menus grew and grew and it became more and more difficult for users to find things.

Some references:

Mouse Bias

One of the greatest productivity enhancements an application can offer is to provide users with the ability to accomplish their tasks using the keyboard instead of forcing them to use the mouse even for repetitive and frequent commands. That’s why it is very annoying to find that QGIS doesn’t have keyboard shortcuts for the most basic stuff like “Pan Map” and “Select * Features” commands. As I explained to Nathan, I find JOSM’s user experience on this much more satisfying.

Also, the toolbar tooltips must display the keyboard shortcuts together with the command description. This is about discoverability.

One other thing (this is a response to Nathan): I would avoid assigning important functionality (like map panning) to the middle mouse button. Maybe it’s just me, but I can’t remember when was the last time I owned a mouse with a proper middle button. Most mouses these days seem to have abandoned those for mouse wheels, which may be pressable, but that experience is lousy - the wheel itself is usually not ergonomically designed for pressing and it also tends to cause the wheel to move a notch or two.

Mouse-Pointed Zoom

Come on, people. We’re in 2012. All respectable graphics editors/GIS programs should zoom to the point indicated by the mouse and not the current map center. Don’t make me zoom and pan and zoom and pan and zoom and …. It’s 2 lines of code. The fact that QGIS actually has a user setting to switch mouse-pointed zoom makes it even worse. Why doesn’t it do that by default? If people can do it in JavaScript (Google Maps, OpenLayers, etc etc), Android, iOS, how come it’s not there in QGIS? Heck, even Garmin’s MapSource can do it (just tested it)!

“User Can Configure That By Herself” Mantra

Having a user setting for everything and anything is not a good alibi for not making the right design choices from the start. Someone once wrote (I can’t find the source now) something to the effect that each user setting represents a decision the developer didn’t want or couldn’t make, so she left it to the poor user.

So I cannot accept argument that users can assign missing keyboard shortcuts or extend the functionality via scripting. You’re assuming two things:

All of the people who want to use the program have the level of technical experience comparable to you (as a designer of the application).
All of the people will be willing to study the complete functionality of the program before actually using it for the purposes they came here in the first place. Most of them won’t and will instead put up with having no keyboard shortcuts or will go somewhere else.

Yes, having the ability to assign shortcuts or write extension scripts is great. But this will be used by a tiny percentage of your users. As I mentioned before, I use VisualStudio a lot and so do my colleagues. But I can tell you that I’m having problems trying to find somebody that assigns their own shortcuts in VisualStudio or uses other advanced customization functions. And they are all bright and technically savvy people (heck, they can even write some code). That’s not to say they wouldn’t benefit greatly from such customization, but most users seem to accept things as they are (even if they are unhappy with them). Call them lazy, but that’s the way it is.

On Open Source

I realize QuantumGIS is an open-source project. I understand realities of working in an open source project - I’ve done some OS work myself. But I don’t see that as an excuse for not taking user experience seriously. After all, the purpose of these projects is to make life easier for its users. And you don’t really need big investments to improve the usability - my talk of “usability experts” should not be taken too literally. There are a lot of things that can be done without too much time & money:

Take a look at some UX guidance documents. Here’s a good one from Microsoft. There are a lot of other good ones.
Visit some good UX Web sites, like designinginterfaces.com or even read some user interface books.
Participate in ux.stackexchange.com. Ask questions and advice. Ask people who never used QGIS before to evaluate your design.
Instead of implementing a new shiny XY functionality for the next release, invest that time to fix some usability issues.
And of course, ask your users.

Maperitive Beta: Subpixel Accuracy

Mon, 28 Nov 2011 19:16:00 +0100

Even though most of Maperitive work I’m doing lately is done in a separate branch that will come out as a brand new Maperitive 2.0 release some time in the beginning of 2012, I do occasionally implement some quick enhancements to the currently “unofficially” released Maperitive beta. I’ve just uploaded a new beta version with a couple of neat features, one of which I will describe in this post (the other will have to wait for the next post).

Subpixel Accuracy

This is an important, although probably not very well known feature Mapnik provides. What is subpixel accuracy? Simply put, it is the ability to set the thickness of the line in fractions of a pixel (image stolen from AGG’s site):

Up until now this was not really possible in Maperitive. Well, you could specify the thickness as, say, 1.3 pixels, but it would be rendered as a line with thickness of one pixel, ignoring the fraction. The reason is simple: Maperitive uses GDI+ library for rendering, which doesn’t do subpixel accuracy (it does support antialiasing, but that’s not enough). Mapnik, on the other hand, uses superior Anti-Grain Geometry (AGG) library (you can read more about it in AGG’s Introduction page, which is very interesting).

Why is subpixel accuracy important? Certain map features require delicacy. In his Cartographic Relief Presentation book Eduard Imhof gives very precise recommendations for elevation contour lines thicknesses. 0.05 to 0.08 mm for black normal contours for map scale 1 : 50,000, as an example. Without subpixel accuracy it is very difficult to come even close to such measures and then you end up with both normal and index contours (the thicker ones) having the same thickness in the rendering:

So given that I cannot directly render lines with subpixel accuracy and using AGG in Maperitive is not a practical solution because of various technical reasons I won’t go into, I’ve more or less given up on this.

The Solution

… Until I came up with a simple but effective trick to achieve subpixel accuracy: render the whole map scaled to (say) three times and then downsample the whole image back to the “normal” scale. Before I delve into details, here’s how the same map looks like using this technique:

I think the difference is obvious: you can now see two distinctive contour line types. Index lines are 1.25 wide, while normal lines have a width of 0.65 pixels.Don’t worry about these numbers, subpixel accuracy is not that precise, but it is precise enough.

The Details

Subpixel accuracy can be tuned for three Maperitive commands:

export-bitmap
export-3d
generate-tiles

All of them have a new subpixel parameter which accepts a positive integer value. This value is used as a scaling factor when rendering. Once the rendering is done, Maperitive uses Supersampling algorithm to resample (downsample actually) the rendering to the scale factor of 1. So for example if you want to generate tiles using subpixel accuracy, you type in something like

generate-tiles minzoom=10 maxzoom=12 subpixel=3

Caveats

What is the best value for subpixel parameter, you may ask? I’ve been experimenting with the value of 3. You could try larger values, although I doubt there will be a noticeable increase in the quality of rendering. The downside of larger values is that Maperitive takes longer to render. This could considerably slow down your tiles generation, so there is a trade-off between the quality and speed (isn’t there always?). Measurements of tile generation speed show that by increasing subpixel value by 1 halves the speed of tile generation. In future this should be mitigated by allowing Maperitive to render tiles using multiple processors.

You should also be aware that if you intend to use subpixel accuracy for exporting large bitmaps, Maperitive has to actually allocate a much bigger bitmap in the process of rendering. So for example if you want to create a 4000x4000 bitmap using subpixel=3, Maperitive will want to allocate a 12000x12000 bitmap in the process and will probably fail due to limitations of GDI+ bitmap size. So there is no free lunch (at least until I figure a way around this problem ;) ).

One final note: interactive map does not use subpixel accuracy since this would make the map rendering pretty slow. In future versions Maperitive will provide some kind of “map quality” / “level of detail” setting, so you’ll be able to control this.

Enjoy!

Maperitive: 3D Export

Wed, 19 Oct 2011 14:24:00 +0200

The latest Maperitive beta (download it from here) now contains a new command called export-3d, which generates a 3D mesh using the digital elevation model and places the map texture on top of it. The 3D model is exported into a COLLADA format, which can be imported into various 3D programs (Google SketchUp is the one I mostly used, it’s free).

Quick How-To

The quickest/easiest way to generate a 3D export is to move the map to the area you’re interested in and simply select the Tools | Export To 3D menu command. Maperitive will then generate files in the output/Maperitive3D directory of your Maperitive installation. If you do not load your own OSM vector layer, Maperitive will use OSM tiles, the same ones used to show tne OSM web map.

NOTE: be careful to keep the map area fairly small, otherwise you’ll end up with a 3D model that you won’t be able to import into other software, especially if you don’t have a top-of-the-line computer at your disposal.

Importing Into SketchUp

After opening SketchUp, choose **File | Import…” menu command. NOTE: Before browsing for the file, click on the Options… button and make sure Validate COLLADA file is turned off:

Validation should be disabled because it makes importing unbearably slow, especially for larger models. After you’ve done this, browse to your generated Maperitive3D.dae file and open it.

Depending on the size of your model, you might have to wait for some time for the importing to finish. Sometimes I even have to resort to killing the SketchUp process and regenerating a simpler model.

Configuring SketchUp

After the model has been successfully imported, you may want to tweak a few settings in SketchUp to make the rendering look better:

View | Edge Style | Edge - uncheck this so the edges of surfaces are not shown.
View | Face Style - choose Shaded With Textures to get the best effect.
View | Shadows - check this to turn on the sun shadows.

Tweaking The 3D Model

export-3d command provides additional parameters we can tweak. Type in help-command export-3d into the command prompt and you’ll get the list of those parameters:

COMMAND NAME: export-3d 
DESCRIPTION: generates a 3D map from the current map view and saves it to the disk 
PARAMETERS: 
  output-dir=<the directory where output files will be saved> (text, optional)
  mesh-points=<the maximum number of points the terrain TIM mesh should have> (integer, optional)
  tin-error=<the maximum allowed elevation difference (in meters) when simplifying the terrain TIN mesh (default is 1 meter)> (real number, optional)
  width=<bitmap width> (value, optional)
  height=<bitmap height> (value, optional)
  map-scale=<map scale to use when exporting> (value, optional)
  scale=<graphics scale to use when exporting> (value, optional)
  dpi=<DPI to use when exporting> (value, optional)
  zoom=<zoom level to use when exporting> (value, optional)

Better Bitmap Texture

By setting various bitmap parameters you can increase the resolution of the bitmap and/or the zoom level of the underlying OSM bitmap.

TIN Tweaks

To increase performance, Maperitive uses Garland-Heckbert’s TIN simplification algorithm to simplify the terrain triangulated irregular network (TIN). There are two command parameters that affect the simplification process:

tin-error: this is the maximum error (tolerance) allowed between the actual DEM elevation and the generated model, in meters. The default value is 1 meter and if your model becomes too big to handle, I suggest increasing the tolerance value.
mesh-points: this is the maximum number of points (vertices) the TIN should have. The simplification algorithm starts from a very simple model (just two triangles) and incrementally adds new points to it. Upon reaching the maximum number of points, the algorithm stops (regardless of the tin-error setting). This is a safeguard against the model going wild with too many points. So I suggest experimenting with those two values to get something workable for your case.

Setting The Map Area More Precisely

Instead of relying on the map window to act as your area of interest, you can specify printing bounds (right click on the map) and move them to an exact position of your choice.

Final Notes

This 3D export function is by no means of the same quality as some other OSM 3D projects - you don’t get any 3D objects apart from the terrain model, so don’t expect to see any 3D buildings, trees etc. It is, however, a very simple tool to use (I hope) and it produces an output in a fairly open standard (COLLADA) which can then be tweaked with other software.

The next logical step would be to include the things like roads and buildings as actual 3D objects, but I will leave that for the future since my task list already very full with other features.

Please send me feedback if you find this feature useful (or indeed if you find it crappy). Since all this is beta, expect to find bugs. Also, if you’re more of an expert in 3D field than me, a question for you: can you recommend any (preferably free) tool for raytracing which can consume COLLADA files generated by Maperitive?

Maperitive: maperipy Progress

Tue, 11 Oct 2011 08:45:38 +0200

WARNING: this is one of those teaser-posts - you get to hear about the cool new features, but you won’t be able to try them out, at least not very soon.

Introduction

In the last few weeks since the beta release I’ve been working on a custom job involving Maperitive. I won’t go into details about the job itself, but the important thing is that this job was an opportunity for maperipy Python API to be extended with some new features. I’ll go through some of them, together with sample Python code.

Geometries

maperipy provides classes for basic geometries (compatible with OGC’s Simple Features Specification) like Point, LineString, LinearRing, Polygon, MultiPolygon etc. I’ve tried to stick to the syntax and semantics used by shapely library (unfortunately shapely itself cannot be used directly because it won’t run in IronPython - it depends on some C code in the backstage, but more about this some other time).

Custom Layers

maperipy now allows users to create their own custom map layers which can be programmatically filled with map symbols using geometries described previously:

# we first create a custom layer on a map
layer = map.add_custom_layer()

# create a simple geometry
line = LineString([(0, 0), (0, 10), (10, 10), (10, 0)])

# add a symbol for it...
symbol = LineSymbol("my_line", (line, ))
# ... and define the visual style
symbol.pen_width = 5
symbol.pen_color = Color("red")

# now we add the symbol to the layer
layer.add_symbol(layer)

Shapefiles

The custom job required the data to be loaded from shapefiles and then rendered on a map based on geometry attributes. This can now be achieved in maperipy:

# first we read the shapefile...
land_use = store.load_shapefile(r"LandUse.shp")

# ... and add polygons for a specific land use type
symbol = PolygonSymbol(
    "forest", 
    land_use.find_polygons(lambda p : p["land_use_type"] == 4000))
symbol.style.fill_color = symbol.style.pen_color = Color("green")
layer.add_symbol(symbol)

Rasters

maperipy supports several types of raster grid file formats: SRTM HGT, ESRI ASCII grid and XYZ. They can now all be used to generate hillshadings or relief contours.

Example code which reads a set of XYZ files, merges them together and then generates hillshading image from them:

parts = []

dem_dir = r"DEM"

for file_name in os.listdir(dem_dir):
    grid = store.load_xyz_grid (os.path.join (dem_dir, file_name))
    parts.append(grid)

whole_dem = Raster.merge(parts)

hillshader = IgorHillshader()

hillshadingBitmap = HillShadingProcessor.shade(whole_dem, hillshader, Color("black"), 1)
hillshadingBitmap.save("dem.png")

Spatial References

One of the biggest pieces of coding I had to do was to introduce SRIDs into the picture. This allows consuming of data sources which use spatial reference systems different from the WGS 84 lon/lat used by OSM. The next step will be to actually support different SRS-es, including different coordinate systems and different map projections.

When?

This is all very nice, but when will you get to use it? Well, maperipy needs a lot more work (what I’ve shown here is just a start!) and so does the main Maperitive code. I also need to write some documentation about the API. So my guesstimate would be a couple of months. Given that a lot of new functionality has been introduced since the last “official” release, I’m thinking of naming the next major release as “Maperitive 2.0” and this will include all the stuff introduced in the September beta release.

Maperitive Beta Update

Wed, 21 Sep 2011 22:34:00 +0200

DOWNLOAD LINK: http://maperitive.net/beta/Maperitive-1.1.2001.zip

I’ve just released an update of the Maperitive beta (it’s the same download link and build number).

This update has a few nasty bugs fixed and a couple of new features.

Label Collision Detection

Maperitive now detects if two or more labels overlap. In case of overlaps the label with lower priority is removed. Priority is determined by the order of the features and rules in the rules file - rules near the beginning of the file have a higher priority than the ones near the end.

A sample rendering of UK cities and towns (the first image is from the old Maperitive and the second was generated using the latest beta):

This is a very simple system and it covers only horizontal labels (so street names can still overlap). A better system will be implemented in the future.

TileJSON

generate-tiles command now generates an accompanying TileJSON file. TileJSON is an invention of MapBox developers and it is used to hold some basic information about the generated tiles, like:

map name, description and attribution,
minimum and maximum zoom,
map boundaries.

The benefit of this file is that certain JavaScript mapping libraries (like Wax) can read it and automatically configure themselves based on its data. Compare that to the last step in my web map tutorial where you needed to do it manually.

Here’s a sample TileJSON file generated by Maperitive:

// Generated by Maperitive v1.1.2001
// For more information about TileJSON format, visit https://github.com/mapbox/tilejson#readme
// TODO: Update the 'tiles' to reflect your actual path on the Web server
// TODO: Update the default map location (longitude, latitude, zoom)
{
    "tilejson":"1.0.0", 
    "name":"Maperitive Web Map", 
    "description":"Maperitive Web Map", 
    "attribution":"Map data © OpenStreetMap (and) contributors, CC-BY-SA", 
    "tiles":
    [
            "tiles/{z}/{x}/{y}.png"
    ], 
    "minzoom":9, 
    "maxzoom":13, 
    "bounds":
    [
        -1.2254669867114432, 
        51.041883339771708, 
        1.5044914337393456, 
        52.076449581817052
    ], 
    "center":
    [
        0.13951222351395121, 
        51.55916646079438, 
        9
    ]
}

Note the “TODO”s: make sure you have the proper values before uploading the file to your web server.

UPDATE: there was a bug in the generated TileJSON files, “tiles” is actually an array (thanks to @kkaefer for pointing this out). I’ve updated the beta release.

New Maperitive Beta Release

Sun, 18 Sep 2011 20:15:00 +0200

DOWNLOAD LINK: http://maperitive.net/beta/Maperitive-1.1.2001.zip

A new release of Maperitive (branded as build 2001) is finally here - albeit in beta form. I wanted to release the new stuff I was working on since May, but I didn’t want to wait for everything to be totally finished. But let’s start with some…

Notes about this release you should be aware of

NOTE 1: This beta release will not appear as an update when running the “standard” Maperitive release. It will also not be possible to later auto-update it with a new release when it arrives. I’m working on a revamped auto-updating system and the old updating mechanism has been turned off in beta (that’s why it’s beta). So you will have to download the beta manually, unzip it somewhere, and run Maperitive.exe (on Windows) or Maperitive.sh (on Linux/Mac). I do not recommend overwriting the previous installation, so keep that as your backup.

NOTE 2: there have been some changes in certain Maperitive script commands, so you may need to update your scripts. The changes are mostly in how the bounds are specified when exporting bitmaps or SVGs. More on that later.

NOTE 3: there wasn’t any major bug fixing done for this release. You can see the list of open bugs (it’s not the full list, some old bugs are reported in other places - I will migrate/fix those soon).

NOTE 4: the new GUI features like map elements selection and editing may be a little bit buggy. A lot of time has been invested in making them work as there were some fundamental problems that needed to be solved. Users running Maperitive on Linux/Mac may especially notice certain problems, due to the fact that Maperitive is running through Mono. In any case, please report any problems if you see them and I will do my best to fix them.

New Features

First let me say there aren’t any revolutionary new features in this beta. Most of the work I did was done on the infrastructure code, which will help me introduce cool new things in next releases.

What is new is the way how bounds are specified (bounds specify the geographical extents of Maperitive commands). Up until now, there was only one bounds parameter, but from now on you have geometry bounds and printing bounds.

Geometry Bounds

These are more or less the “old” bounds - you use them to specify the map area to download OSM data for (as an example). Geometry bounds are defined in terms of “min longitude, min latitude, max longitude, max latitude” coordinates. They are shown as a red rectangle with diagonal hatching (see the screenshot above).

Maperitive commands that act on geometry bounds have been renamed to dump-geo-bounds, geo-bounds-use-source, reset-geo-bounds, set-geo-bounds. I haven’t updated the Maperitive documentation for these yet, but you can still use help-command to get the list of supported arguments, like:

help-commands set-geo-bounds

Printing Bounds

Printing bounds are used by export-bitmap and export-svg commands to control the exported map area. What is cool about the printing bounds is that you can specify them in terms of paper size, paper orientation, paper margins, map scale and DPI resolution. This was one of the most requested features - to be able to export a map in terms of physical paper dimensions.

Printing bounds work in two modes: fixed paper mode and free-size mode. In free-size mode you are not bound to a particular paper size, so you can define the bounds in the old way (just like geometry bounds).

Printing bounds are shown as blue dashed rectangle:

New printing bounds commands are set-print-bounds-geo, set-print-bounds-paper and set-print-bounds-view. There is also a new command for setting the paper properties: set-paper.

Why Two Boundary Types?

It may seem a bit complicated two introduce two types of boundaries, but it is necessary precondition for me to be able to introduce map rotation in Maperitive (and support for different map projections). Why? Because once you rotate the map, the geometry bounds rotate, too, so they are useless for any kind of printing boundaries (which need to be rectangles parallel with the screen).

Editing Bounds Visually

There is no need to specify bounds using the command line interface, because there are a couple of new GUI features (which gave me the greatest headache). More on that follows.

Map Context Menu

Yes, the map now has a context menu (finally). So if you want to specify printing bounds, simply right-click on the map and choose Place Printing Bounds Here. Now you have printing bounds placed on the map and selected…

Selecting And Manipulating Map Elements

If you click on the geometry or printing bounds, you can select them - small yellow selection handles appear. You can drag the handles to resize the bounds. If you hold the Shift key, the resizing will maintain the aspect ratio. Hold the Control key and you will be able to resize while maintaining the center point.

Move the mouse a little bit more inside the bounds box and you will be able to move the whole bounds across the map.

Properties Window

The last major new GUI “thingy” is the Properties window. If you right-click on the printing bounds and choose Properties, a tool window will appear that lets you edit the properties. This means you don’t need to mess with command line to specify the paper size, for example.

What Comes Next

As I’ve already mentioned, Maperitive is getting a new updating system. The next “official” release will start using semantic versioning, like 2.4.2 and the old build numbering will be consigned to history. This will enable a more transparent updating system - users will be able to choose whether they want to install unstable releases or wait for the next stable/tested one.

Of course, I plan to fix some bugs too (including the ones that I’m sure you’ll report for this beta release).

Next major features: a better labeling mechanism (collision and duplicates detection, abbreviations…) and maperipy, the Python API and integrated Python scripting.

That’s really. I hope you’ll try the new beta and enjoy it. And don’t hesitate to send me your feedback (positive and/or negative)!

maperipy: Maperitive API for Python - A First Glimpse

Tue, 13 Sep 2011 17:10:34 +0200

A few days ago I started implementing maperipy, a Maperitive API for Python. It turns out to be a quite uncomplicated thing to do, compared to all infrastructure stuff I’m working on for the next Maperitive release, so it’s a kind of a relaxation between all the hard work.

The API is still very young and unsophisticated, but I’m very excited about it, because it could provide a whole new dimension of functionality to Maperitive users.

Here’s a simple Python script that clears the map and then adds a custom Web map to it (with custom copyright text):

from maperipy import MapLayer

map.clear_map();
layer = map.add_web_map_custom(
        "my hiking map", 
        ["http://beta1234.com.sunflower.arvixe.com/maps/tiles"])
layer.copyright = "it's made by me"
layer.opacity = 0.75

Another one, which scrolls the map along the X-axis:

from maperipy import MapPosition
import time

pos = map.position;

for n in range(10):
    map.position = MapPosition(15 + n/10.0, pos.y, 11)
    app.refresh_map()
    time.sleep(0.3)

First versions of maperipy will probably be available after I finish the work on the next major release of Maperitive. Hopefully some time in October.

Maperitive Tutorial: Generating OSM Map For Adobe Illustrator In Seven Easy Steps

Thu, 08 Sep 2011 05:57:00 +0200

In this tutorial you will learn how to produce a vector map based on OpenStreetMap data and then export it to SVG format suitable for editing in Adobe Illustrator. SVG export is one of the most useful features Maperitive provides and I’ve spent a lot of time tweaking the code so that Illustrator can handle the exported SVGs.

NOTE: the tutorial has been written for Maperitive build 1228. Some things will change in the near future, so please visit http://maperitive.net for any updates.

First things first: start Maperitive (if you don’t already have it, you can download it from here). Unzip the package somewhere on your disk and run Maperitive.exe (on Windows) or Maperitive.sh (on Linux/Mac).

Step 1: Setting Your Map Limits

Currently Maperitive uses your computer’s memory to store map data, so there is a limit of how large a map it can work on. Because of that, we need to tell Maperitive what area we’re interested in, so all the operations will limit themselves on that area.

There are several ways to set the limits. The easiest is to move the map to the area, zoom in our out appropriately to cover all the area you want, and then use the Map / Set Bounds menu function.

I will do this manually by entering a following command in the command prompt (at the bottom of the screen):

bounds-set -74.03,40.7,-73.96,40.72

I suggest you do the same for the purposes of this tutorial, so our map areas would match. The area in question is lower end of Manhattan.

Step 2: Loading OSM Data

Now we need to get the vector OSM data for our map. There are several ways of doing this.

The easiest one is to use the Map / Download OSM Data menu function, which contacts an OSM server to fetch the data. Try it out. If it fails, try it a couple more times. The problem is that these servers are sometimes overloaded and unresponsive.

If this doesn’t work, another option is to use JOSM or the Export tab on the OSM Web Map site. In that case you will get an OSM XML file, which you need to save on your disk (using .osm extension!) and then load into Maperitive using the File / Open Map Sources menu function (or simply drag and drop the file into Maperitive).

Once the OSM data is in, we can proceed with the next step…

Step 3: Removing The Web Map

Now that we have some vector content of our own, we don’t really need the OSM web map anymore. Select the Web Map (OSM Mapnik) in the Map Sources window at the bottom of the screen and then click on the “X” button to remove it:

Step 4: Changing The Map Style

The default map style resembles the standard OSM Web map layer (generated using Mapnik). But just to show off, we will switch to something that looks like Google Maps. Choose Map / Switch To Rules / googlemaps menu function. After a second or two of processing, the map will change its style.

Step 5: Deciding The Map Scale

Depending on your needs, you can export the map using different map scales. Map scale is directly linked to the zoom level and together they determine what type of content is visible on the map and how the content is rendered. In the case of our Google Maps-like style, the street names are starting to appear on zoom level 15 and higher, so if you need them in your export, you will have to use the zoom level 15 or higher.

The zoom level value is displayed at the bottom of the screen:

The map scale is shown at the bottom left of the map itself, together with the bar scale indicator:

For this tutorial I’ve decided the zoom level 16 is the one I want. Try it out, you can set your own later.

Step 6: Exporting To SVG

The easiest way to export would be to use Tools / Export to SVG (For Adobe Illustrator) menu function. But since we need to specify the zoom level in our case, we will type the export-svg command manually into the Command Prompt:

export-svg compatibility=illustrator zoom=16

We instructed Maperitive to export the current map to a SVG file suitable for Adobe Illustrator and to use zoom level 16. After a couple of seconds a new file called output.svg should appear under the output directory of your Maperitive installation.

Step 7: Import Into Adobe Illustrator

Now that you have a SVG file, open up your AI and import it. If it complains about “roundtrips to Tiny”, simply ignore that.

Adobe Illustrator vs. Inkscape

You may wonder why you had to specify the compatibility=illustrator argument in the Step 6. I will just quote Maperitive documentation on this:

Due to the pretty buggy support which Adobe Illustrator provides for loading SVG files, it is not possible to have the same SVG optimally shown in both Illustrator and Inkscape. In other words, if you plan to use the SVG file in Illustrator, you should specify compatibility=illustrator parameter. Maperitive will in this case do some tweaks to the SVG file which allow it to be shown without any problems in Illustrator (tested in CS5). But do not expect this file to be usable in other SVG viewers/editors.

On the other hand, if you need a SVG file which can be shown in various Web browsers and editable in Inkscape, you should specify compatibility=inkscape parameter. Again, do not expect this file to be usable in Illustrator.

Conclusion

This tutorial shows only the basic workflow, but there are many ways of how the workflow can be customized and even automated (by putting everything into a Maperitive script). Visit http://maperitive.net for more information.

Good luck and enjoy mapping!

Maperitive Tutorial: A Hiking Web Map In Ten Easy Steps

Wed, 07 Sep 2011 19:08:00 +0200

UPDATE (24th February 2013): I’ve updated the tutorial to conform to the latest Maperitive release.

I’ve been asked a lot of times to write some tutorials for Maperitive, so I finally decided to write one.

In this tutorial you will learn how to make a hiking web map (like this one hosted on MapBox) with OpenStreetMap data and SRTM DEM data for hillshading and relief contours. Don’t worry - it is not that difficult to do.

First things first: start Maperitive (if you don’t already have it, you can download it from here).

Step 1: Setting Your Map Limits

There are several ways to set the limits. The easiest is to move the map to the area, right-click on the map and choose Place Geometry Bounds Here from the context menu. When the red rectangle appears, you can move it and resize it to the area of your choice.

I will do this manually by entering a following command in the command prompt (at the bottom of the screen):

set-geo-bounds 15.42,46.44,15.62,46.55

I suggest you do the same for the purposes of this tutorial, so our map areas would match. The area in question is Pohorje mountain in Slovenia (I hike there very often).

Step 2: Generating Hillshading

This one is very easy: use Tools / Generate Hillshading (Igor) menu function. The program will contact NASA’s SRTM server and download all the appropriate DEM tiles for the area. After that it will generate a new map source containing the hillshading bitmap. You can see all the happenings in the Commander log.

Step 3: Turning Off The Web Map

Now that we have some content of our own, we don’t really need the OSM web map anymore. Select the Web Map (OSM Mapnik) in the Map Sources window at the bottom of the screen and then click on the “X” button to remove it:

Step 4: Generating Relief Contours

A proper hiking map should have relief contours, which is another easy step to do: choose Tools / Generate Relief Contours menu item and voila, now you have the contours.

Step 5: Loading OSM Data

Now we need to get the OSM data to have the map filled with useful hiking information. Again, there are several ways of doing this.

The easiest one is to use the Map / Download OSM Data (Overpass API) menu function, which contacts an OSM server to fetch the data. Try it out. If it fails, try it a couple more times. The problem is that these servers are sometimes overloaded and unresponsive. Alternatively, you could try using the other download option, the Map / Download OSM Data (Overpass XAPI) menu function.

Once the OSM data is in, you will get a map that resembles the basic OSM Web map (Mapnik layer). This map style isn’t really appropriate for hiking maps, so we need to change it…

Step 6: Changing The Map Style

Choose Map / Switch To Rules / hiking menu function. After a second or two you will get the final hiking map using the hiking style which comes with Maperitive. Now we need to transform it into a Web map…

Step 7: Generating Map Tiles

Web maps consist of a multitude of map tiles, which are 256x256 pixels bitmaps. So we need to generate tiles for our hiking map before we can upload them to our Web server.

Maperitive offers you two basic choices when it comes to tiles:

Generating each tile as a separate file. This is the standard way of dealing with tiles. The advantage is that its pretty easy to set up a web map with this approach. The disadvantage is that you have to transfer a lot of small files to your web server, which can take a long time.
Generating tiles as a single MBTiles file. MBTiles is a SQLite database containing all the generated tiles and which can be handled as a single file. The only thing is, you need to have a Web map server that supports MBTiles. If you’re planning to publish your maps on MapBox, that’s not a problem (simply upload the generated file using their web application).

Step 7a: Generating tiles as separate files

Generating tiles as separate files is done using the generate-tiles command. Enter the following command:

generate-tiles minzoom=12 maxzoom=14

and you should get the output in the Commander log similar to this one:

For the sake of this tutorial we generated tiles just for three zoom levels (12, 13, 14). The tiles have been stored in the Tiles subdirectory of your Maperitive installation, in the structure that is suitable to be used by OpenLayers (we’ll get to that part in a moment, don’t worry). I’ll leave you some time to check the tiles out…

Step 7b: Generating MBTiles

Alternatively, to generate MBTiles file, use the analogous command:

generate-mbtiles minzoom=12 maxzoom=14

Step 8: Uploading Tiles To Web Server

You can use do whatever way you feel most comfortable with to upload these map tiles to your Web server. Maperitive comes with the ftp-upload command which can make this job very easy. Example:

ftp-upload host=myftp.com user=me pwd=secret remote-dir=mywebmap

will upload all the generated tiles to the mywebmap directory on the FTP server. Before executing this command, you will need to enter your own host, user and password, of course.

Step 9: Preparing HTML

If you decided to your web map on your own web server using individual web map tiles, you now need to prepare a simple HTML landing page for our map.

In the past I used OpenLayers as a client-side JavaScript mapping library. You can still use it, but for simplicity’s sake I would recommend trying out Leaflet.js instead. It is much easier to get started and has all the basic features you will need for a decent web map. The documentation is good and there are a lot of samples on the web. If you want to see a working Leaflet map, check out ScalableMaps, one of my other projects. Feel free to use the JavaScript code if you want.

Step 10: Test The Map

This should be it! Visit your Web map using a browser and check that everything is working correctly.

This tutorial shows only the basic workflow, but there are many ways of how the workflow can be customized and even automated (by putting everything into a Maperitive script and even running it in the headless Maperitive console). Visit http://maperitive.net for more information.

Good luck and enjoy mapping!