Umap GeoJson Export API Support

Upload of Umap files exported manually via the Umap web interface has been supported by my MapOSMatic instance for quite a while, and the MapOSMatic API has also supported submitting a Umap file via an URL instead of uploading an actual file.

There’s also a (so far inofficial) export URL for exporting an Umap for exporting a map directly, without manual browser interaction.

See this Umap Github issue for a more detailed description.

The basic idea is that for a map with Id 123 the stable web access URL would be:

https://umap.openstreetmap.fr/m/123

and the inofficial map export URL

https://umap.openstreetmap.de/en/map/123/geojson

Unfortunately the export file retrieved this URL is not yet complete though, as unlike the manualy exported file unsing “Export all data” in the web interface, it only contain the maps meta data, and references to the actual data layers, but not the actual layer data itself.

So when processing a file exported this way, we first need to check the “urls” dictionary from the map properties for the datalayer_view URL path, and combine this with the protocol and host part from the maps own export URL.

For the original Umap instance the datalayer_view looks like this:

/en/datalayer/{pk}/

and so the full URL template becomes

https://umap.openstreetmap.de/en/datalayer/{pk}/

The {pk} placeholder needs to be replaced with the Ids from the datalayers list entries, which e.g. look like this:

{
"name": "Layer 1",
"id": 123456,
"displayOnLoad": true
}

So we need to download actual layers data from URLs like

https://umap.openstreetmap.de/en/datalayer/123456/

which returns JSON data we need to append to the layers list to form a complete export file.

Once we fetched and merged all data layers we can then process the resulting JSON document the same way as the JSON exported from the web frontend.

This should allow a more direct integration between Umap and MapOSMatic servers, to automate the process of creating printed representations of maps generated with Umap.

An API request to render an umap with Id 123 would then simply look like this:

{
    "umap_url": "https://umap.openstreetmap.fr/en/map/123/geojson/"
}

In actual PHP code for example launching a map rendering job for this umap would look like this:

<?php
require_once 'HTTP/Request2.php';

header("Content-type: text/plain");

define('BASE_URL', 'https://print.get-map.org/apis/v1/');

$data = ['umap_url' => 'https://umap.openstreetmap.fr/en/map/123/geojson/'];

$request = new HTTP_Request2(BASE_URL . "jobs");

$request->setMethod(HTTP_Request2::METHOD_POST)
        ->addPostParameter('job', json_encode($data));

$response = $request->send();
$status   = $response->getStatus();

if ($status < 200 || $status > 299) {
    print_r($response->getBody());
    exit;
}

$reply = json_decode($response->getBody());
echo "Result URL: ".$reply->interactive."\n";

UTM Grid Overlay (Experimental!)

Over the years there were requests for UTM support in my MapOSMatic instance every once in a while.

I now spent most of the first day of this years FOSSGIS Summer Camp on the topic, and I’m now happy to announce a first exeprimental implementation of an UTM grid overlay.

The screenshot shows the grid overlay only for clarity, it shows the grid for transition between two UTM zones, and the not-yet-perfect label placing:

If you are interested in further progress on this feature you may wat to subscribe to the Feature Request

Duplex layout with index on extra page

So far for the single page layouts the street index could only be rendered on the side or the bottom of the same page.

Now it is possible to have the index rendered on a second page in PDF output. So it is now possible to duplex print a map with the actual map on the front side and the street index on the back side of the same sheet of paper.

As the other output formats do not support multi page output there will no extra index page be generated for these. Choosing the “index on extra page” layout these formats will have the grid added to them again though, which can be used in combination with the generated street index file in CSV format.

Translation system

The original MapOSMatic project used Transifex as its web translation frontend.

As my fork diverged over time, and as Transifex became less open, I have been thinking about an alternative for quite a while now. So far none of the alternatives I’d been looking at really convinced me though.

Now yesterday I stumbled across Weblate, and almost fell in love immediately. Almost everything I ever wished for, supports self hosting, and is even easy to setup.

So translations can now be maintained on https://translate.get-map.org/projects/maposmatic/

The only thing from my wish list that’s still missing now is OpenStreetMap OAuth support, but as the project already supports other OAuth providers this should be easy to add over the next weekend, if not earlier.

Where the streets have no name …

I had requests for maps using the default style, but without street names, in the past already. Now such a request has come up again, for a school project where pupils are expected to collect street names for their neighbourhood themselves.

For a brief time I even had a patched version of the default style onlne to offer this, but it turned out that keeping such a forked style maintained was taking some effort.

As Mapnik provides the possibility to turn of layers of a loaded style file, I now extended the renderer configuration file by an option “exclude_layers=…” to make use of this feature.

This now allows me to easily create a copy of an already supported style with some rendered featuers removed, without having to actually copy and modify the stylesheet itself.

So now there’s a “CartoCSS OSM style without street names” style entry in the “Special interest” section of the style selection dropdown, and it is going to work with future version updates of the default style easily, without any further maintenance cost (as long as layer names stay the same).

Hillshading – finally!

I was able to add the contour line overlay quite a while ago, with the actual contour line data generously provided by OpenSnowMap.

Unfortunately I couldn’t also provide hillshading data offered by OpenSnowMap, too, back then, as storage space on my previous server had already almost completey been used up.

I moved to a server with more storage space a little while ago already, and I now finally got to making hill shading work.

While I was on it I also added a variant of the contour line overlay that only renders contour lines for each 100m increment of height, instead of each 10m, so that maps don’t get overloaded by contour lines in mountaneous areas.

align=right

Small changes

Some small changes from last weekend:

  • The “Recreate” button was not really visible as a button, after changing the bootstrap button class it now is
  • The map list and detail pages now show the duration a request had to wait in the queue, and the actual time it took to render, in addition to the absolute submission, render astart, and end times
  • Most map styles use sans-serif fonts only, and so does the renderer for most map decorations, too. The only exception were index section headers, which was slightly visually disturbing. These have now been changed to use a sans-serif font, too.