imagico has commented on the following diary entries

Post When Comment
Top OSM Rank: The Big Imports about 3 hours ago

Nice summary of the big imports.

You however only looked at the formal cleanup of the nodes. There is also substantial cleanup in tagging required, in Tiger that is obvious but with Canvec this is also a real problem. To give an example: Canvec imports tag all waterways as stream. There are nearly 3 million waterway=stream ways with a source=NRCan* tag right now but only 774 (!) waterway=river with such source tag, 63 of which have been touched since the beginning of the year, 285 last year.

Making a very generous estimate and assuming the same number of rivers have been retagged removing the source tag (which is more difficult to determine, but it is unlikely there are this many - source tags usually remain untouched in later edits) and assuming only ten percent of the waterways would actually qualify for waterway=river (in reality it is more) it would still take ~500 years to fully evaluate waterway tagging in Canvec data even if we'd stop importing further streams right away.

By the way, CanvecImports only accounts for ~15% of the ways with a source=NRCan* tag, extrapolating from that for the nodes there would be more than 250 million Canvec nodes at the moment.

Humantarian Map - Correction Required 4 days ago

The whole situation including the different claims is fairly well mapped in that area, see:

Charging stations (carto v2.30.0) *rolling tumbleweed* 6 days ago


Note however the practical usefulness is right now fairly hypothetical. If you have an electric vehicle right now the chances that when you go to one of the places tagged amenity=charging_station in OSM with it you can actually charge it there are probably slim - just have a look at the number of sockets shown on the wiki page - not to mention the contractual difficulties of being allowed to use it. Electric charging is still lightyears away from fossile fuel 'charging' where you can usually be sure that you can (a) technically fuel your vehicle and (b) pay with at least either cash or credit card at any fuel station.

map styles: Default OSM vs Google Maps 20 days ago

The biggest difference in road rendering between Google and OSM standard style to me seems to be that at z13/14 Google uses thin plain lines for all but the largest roads while the OSM style draws them with casing. Apart from that the road rendering in Google is generally more subtle. This is not necessarily a good thing - i am in general a proponent of rendering things clearly visible or not at all. But the dark gray at low zooms and the bright white at high zooms for the lower importance roads in the OSM style is of course quite extreme.

Also Google in general draws roads thinner than the OSM standard style (except for the highest zoom levels where OSM draws them thinner than reality). This helps them avoid things like

although a better approach might be making the drawing width depend on local map scale rather than zoom level. This might be something you could try - AFAIK this would also be a first for any web map.

How good (bad) is water represented in OpenSteetMap? about 1 month ago

Nice to see waterbody mapping and use of OSM waterbody data gathering attention outside OSM itself.

Looking at your presentation it seems however your methodology has quite a few issues, both in detail and en large - some of them will likely 'bite you in the back' when you try to use that approach in other areas.

The most basic one probably is that the techniques you compare do very different things. In OpenStreetMap we map bodies of water, either standing or flowing. When analyzing Landsat images you map surface water and when analyzing elevation data you map potential drainage lines. It should be obvious that these three methods - even if all of them work perfectly - will produce diverging results.

Your approach to Landsat/SRTM reminds me of something i did several years ago. You are lucky you do not have snow and glaciers or frozen lakes in Australia...

Germanwings Flight 9525 response 2 months ago

Rock glaciers are mapped with natural=glacier + glacier:type=rock - see

They are difficult to map though since they often look similar to scree and moraines in images.

Germanwings Flight 9525 response 2 months ago

You effort for providing useful information is meritorious but may i suggest you somewhat more carefully verify what you map. Aerial images are often difficult to interpret, especially if you don't know the area from first hand experience and this is further aggrevated in mountain areas by irritating shadows and the distortions resulting from orthorectification.

For example

are clearly wrong (the glacier has mostly vanished except for a small rock glacier and the cliff would have a stream flowing uphill across it).

SRTM 1arc v3 4 months ago

If by dammed you mean that smooth looking slope, yes, of course

I mean there is a barrier in the valley's profile, the river seems to flow uphill. This is a very common side effect of simple interpolation void fill.

I would like to know which data are you using.

The shown image is based on the 1 arc second and 3 arc seconds SRTM as well as Jonathan's data and OSM waterbody data.

Flattening of lakes is to make sure the contours do not intersect the water areas.

SRTM 1arc v3 4 months ago

There are systematic differences between SRTM and Jonathan's 1 arc second data so plainly replacing void pixels with that data is going to fail of course.

Your approach essentially has two major problems:

  • The USGS 1 arc second files contain bad quality void fill in some tiles that would need to be detected and removed for good quality results.
  • The void filled 3 arc seconds data from the USGS/NGA vary strongly in quality of the void fill, in Europe they mostly just interpolate (slightly better than your gdal_fillnodata attempt but essentially similar). You can see that for example in your final image where the valley at the bottom appears dammed near Mollières.

Here for comparison a rendering of my current basic processing in that area with OSM lakes flattened. Note this still has all artefacts of the USGS data in the non void areas included which are more difficult to address. relief rendering Maritime Alps

Sentinel-2 satellites imagery can be used for OSM 6 months ago

There are a few aspects that should probably be kept in mind before getting too excited about this:

  • As it is the cited license would not allow use of data covered by it for OSM - it requires all derivative works to include a note 'contains Copernicus data' which cannot be ensured in OSM.
  • So far the release under open license is only an intention - it is not clear when this will happen (the satellites are not even launched yet), what processing level the data will have and if the data is really freely distributable or if you have to sign an agreement before you get access to it. The ESA track record in this regard is - to put it nicely - not that great.
  • Experience with use of automated land cover classification as a data source for OSM as suggested in the cited blog post has been very bad in the past. The very concept of automated classification into a fixed set of classes is at odds with the basic principles of OSM.

None the less should this imagery become freely available it will be a welcome addition to existing sources for mapping.

The trouble with the ODbL - summarized 7 months ago

Just a few quick notes:

  • Of the points listed above at least 2, 4, 5 and 6 are not specific to the ODBL (meaning they would apply for many other licenses likewise). Before you say PD would not have these issues remember that true PD does not exist in most jurisdictions.
  • 1 and 3 are issues of EU database law and not specific to the ODBL either. Short of giving away all data without limitations there is no solution for this. It seems to me the authors of the paper you cite are not really familiar with the legal basis of data and database rights in Europe.
  • You probably should point the National Park Service to NASA which apparently has no such issues.
  • The case of Yale University seems to be based on the misconception that any license can force you to give away other data and force you to violate other obligations. The only thing the ODBL can do is forbid you to use OSM data under certain circumstances, it has no power to change your other legal or contractual obligations.
  • Generally citing people who do not use OSM data because of certain fears without analyzing if those fears are well-founded seems inappropriate and misleading. The key words in all your case examples are 'could', 'might', 'concerned', 'worried' etc. and the text makes no attempt to analyze the validity of these concerns.
  • Frankly i am somewhat appalled by the fact that you do not acknowledge the LWG efforts with the community guidelines to shed light on unclear and difficult to understand aspects of the ODBL. If you really want to help data users to use OSM data and resolve their concerns you should support these efforts by helping to communicate them to potential data users.
Afrika 9 months ago

In Mauretanien sind viele Ortschaften nicht detailliert erfasst - wo hochauflösende Bilder verfügbar sind, lässt sich da viel machen, z.B.

Im Süden fehlen auch flächendeckend die meisten Gewässer, z.B. hier:

da ist aber die Abdeckung mit aktuellen Bildern recht lückenhaft und die Landsat-Bilder in Bing sind im Grunde zu alt für sinnvolles Mapping.

Was Du auf keinen Fall machen solltest ist, die Wüstengebiete mit natural=desert-Polygonen zu pflastern.

Entscheidend ist beim Mapping auf die Ferne immer eine solide Kenntnis der Gegend - nur damit kann man nämlich Luft- und Satellitenbilder auch angemessen interpretieren, unbedingt lesen:

intermittent streams in arid environment 10 months ago

A more fine grained characterization of intermittent waterways makes only limited sense since it can rarely be expected from the mapper to know how frequently a stream carries water. You could add ephemeral=yes in addition to intermittent=yes if you have this information. Also you could have intermittent=yes and seasonal=no to indicate there is no seasonal pattern.

Generally the characterization 'ephemeral' is often extremely vague - it can mean anything from 'frequent but short presence of water for example after rain' to 'no water for decades and possibly permanently dry due to climate change'.

dlr data help 11 months ago

DLR is primarily funded by the taxpayer <sigh> but as usual in publicly financed research in Germany these days the management has a strong incentive to get additional money or non-monetary support from the private sector which in case of the DLR is often done by selling exclusive rights to the data to private companies.

There is no effective general obligation for public institutions in Germany to make their data publicly available.

dlr data help 11 months ago

The DLR is kind of the Antichrist of Open Data so it is unlikely you can get anything substantial from them.

OSM Node Density 2014 11 months ago

Very nice. Maybe you could publish the color scales for the different zoom levels, i.e. what color represents how many nodes per web mercator square kilometers.

Converting the data to real densities should be relatively easy by multiplying with the area scaling function of the projection. This would lighten up the polar regions quite a bit, Greenland for example is is fact mapped with similar node density in the north and south.

Redundanz bei OSM-Daten about 1 year ago

@4rch - ich sehe nicht, dass das Argument 'die Berechnung ist kompliziert' etwas an der Situation ändert, nämlich dass die redundante Erfassung von Informationen zwangsläufig zu Widersprüchen in den Daten führt.

Dass es auch im maritimen Bereich Grenzen gibt, die nicht durch Distanz von einer Basislinie definiert sind, sondern durch bilaterale Abkommen oder anderweitig definierte unilaterale Ansprüche ändert eigentlich auch nichts - solche explitzit definierten Grenzen sollten natürlich immer auch explizit erfasst werden und hier besteht keine Gefahr der Redundanz oder Widersprüchlichkeit - außer natürlich bei Konflikten zwischen verschiedenen Ansprüchen, was aber ein anderes Thema ist.

Indem man die redundante Erfassung als alternativlos deklariert (was brogo explizit nicht getan hat) macht man sich die Sache zu einfach. Man sollte sich immer klar machen, dass man sich durch eine solche Entscheidung auch große und im gewählten Beispiel eben auch sehr deutlich in der Karte sichtbare Nachteile einhandelt.

Kurz - redundante Erfassung von Informationen ist niemals zwingend notwendig und es gibt wie erläutert durch durchaus gute prinzipielle Gründe, so etwas zu vermeiden. Dass man dennoch zu dem Schluss kommen kann, Dinge trotz der Nachteile redundant zu erfassen, will ich dabei garnicht bestreiten.

Redundanz bei OSM-Daten about 1 year ago

Das Vermeiden von Redundanzen dient nicht nur der Effizienzsteigerung. Das größte Problem ist vielmehr, dass Redundanzen meist zwangsläufig zu Widersprüchen führen, denn die verschiedenen Versionen der selben Information müssten permanent von irgendjemandem synchronisiert werden, was nicht passiert.

Bestes und beim Betrachten der Karte offensichtlichstes Beispiel finde ich immer die maritimen Grenzen (i.a. also die 12-Meilen-Zone), welche explizit gemappt wird, obwohl sie eigentlich eine berechnete Linie darstellt (berechenbar auf Grundlage der Basislinie, welche meist nicht durchgehend erfasst ist). In der Praxis führt dies dazu, dass die gemappte Grenze oft im Widerspruch zum Rest der Karte steht (sie müsste sich definitionsgemäß immer mindestens 12 Meilen vor der Küstenlinie befinden).

Der Grund, trotzdem diese Grenze zu erfassen ist klar, denn es ist ein praktischer und einfacher Weg, die Grenze eines Landes zu schließen und es ist gleichzeitig die Linie, die man in der Karte darstellen möchte. Der wesentlich sauberere Weg wäre hier jedoch, für alle Anwendungen, die dies benötigen, diese Grenze aus den anderen Informationen in der Datenbank zu berechnen. Zu fordern, dass solche Informationen aus Komfortgründen für den Auswerter in der Haupt-OSM-Datenbank liegen müssen (was die automatische Aktualisierung ja wirkungsvoll verhindert) halte ich für problematisch.

Connecting Communities With Improved OpenStreetMap Credits on Mapbox Maps about 1 year ago

This looks much better.

Attributing OpenStreetMap about 1 year ago

@RobJN - i do not want to start mincing words here but 'making a person aware of something' is usually understood as being distinctly different from 'making some information available to someone'. According to my understanding it has been the generally accepted interpretation of the cited section that the attribution has to be in plain sight to comply with this.

I understand and agree this can be a nuisance when you produce maps based on a lot of data sources and especially if OSM data plays only a very minor role. But these are the rules and it IMO is a matter of fairness that every data user is bound by those in the same way. And again i see no good reason why not to separately link ©Mapbox to the Mapbox page (with all other sources and showing off Mapbox products) and ©OpenStreetMap to the OSM copyright page.

But with all the criticism i should not forget to mention that the 'Improve this map' link and the corresponding page are a great idea and well executed. It would be nice to have something similar on that people can link to from their own non-Mapbox maps.