OpenStreetMap

imagico has commented on the following diary entries

Post When Comment
Germanwings Flight 9525 response 3 days ago

Rock glaciers are mapped with natural=glacier + glacier:type=rock - see http://wiki.openstreetmap.org/wiki/Proposed_features/Glaciers_tags

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

Germanwings Flight 9525 response 5 days 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

http://www.openstreetmap.org/way/334530242

http://www.openstreetmap.org/way/334561139

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 about 2 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 about 2 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.

imagico.de relief rendering Maritime Alps

Sentinel-2 satellites imagery can be used for OSM 4 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 5 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 7 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.

http://mc.bbbike.org/mc/?lon=-13.91534&lat=17.05309&zoom=15&num=2&mt0=bing-satellite&mt1=mapnik

http://mc.bbbike.org/mc/?lon=-9.61456&lat=16.66121&zoom=14&num=2&mt0=bing-satellite&mt1=mapnik

http://mc.bbbike.org/mc/?lon=-12.70895&lat=22.67912&zoom=15&num=2&mt0=bing-satellite&mt1=mapnik

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

http://mc.bbbike.org/mc/?lon=-12.57525&lat=16.03655&zoom=10&num=2&mt0=bing-satellite&mt1=mapnik

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:

http://wiki.openstreetmap.org/wiki/DE:Armchair_mapping

intermittent streams in arid environment 8 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 9 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 9 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 9 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 10 months 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 10 months 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 11 months ago

This looks much better.

Attributing OpenStreetMap 11 months 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 osm.org that people can link to from their own non-Mapbox maps.

Attributing OpenStreetMap 11 months ago

It should be noted that attribution that requires a user action before it is actually shown is quite clearly in violation of the ODbL:

You must include a notice associated with the Produced Work reasonably calculated to make any Person that uses, views, accesses, interacts with, or is otherwise exposed to the Produced Work aware that Content was obtained from ...

Even if the ©OpenStreetMap is shown by default this is not the recommended form of linking as per

http://wiki.osmfoundation.org/wiki/License#How_should_I_attribute_you.3F

It is really not conceivable to me why you would not link ©OpenStreetMap separately to the OSM copyright page (well except for channeling more people to the Mapbox pages which however seems kind of lame to me).

An additional advantage of http://www.openstreetmap.org/copyright in comparison to the Mapbox page is that it is localized in a lot of different languages making it much more comfortable for international users.

Elevation carving using OSM waterway data 12 months ago

Looks interesting, i am not sure how your approach ensures a hydrographically correct elevation model, according to my understanding your smoothing step will inevitably create local minima along the course of the streams.

My own attempts in that direction (see here for lakes and here for rivers) work by enforcing the hydrographic condition locally in an iterative process which then converges to a hydrographically sound elevation model. Depending on the source data it makes sense to implement additional constraints, for example in case of SRTM elevation along rivers is nearly always overestimated. One major problem with all such techniques is you inevitably also use detail from the original data.

The most serious problems when using OSM data for this purpose are the inconsistencies in the data, especially of course wrong direction of streams but also lack of clear differentiation between level water surfaces (lakes) and flowing water.

When does share alike kick in? about 1 year ago

I think that's a very clear explanation on how share-alike works for OSM in most cases.

One thing that always bothered me about share-alike in the ODbL are the severe restrictions on what i can charge someone for making available a derivative database to him (namely only costs of physical reproduction, none in case of internet distribution). OSM data has significant volume and combining it with other data can make it much larger. When you generate a produced work based on a high volume derivative database this is a serious problem. You either have to keep the data (at significant costs, no matter if anyone ever wants it or not) or you have to be prepared to re-create the derivative database at your own cost since you cannot charge for the work. The only practically feasible way in such cases seems to be to make available the algorithm used - which however you might not want to for some reason.

Mapbox and the lake of attribution to OSM about 1 year ago

Mapbox as a US company can make use of the fair use principle and this is usually considered to cover example images like screenshots etc. in such a context.

This is of course just the legal side - it can certainly be argued that mentioning OSM more prominently on such a showcase page would be nice if the vast majority of examples shown uses OSM data. I would however consider it much more important that prominent attribution is shown in deployed maps - which has occasionally been lacking in case of Mapbox maps like http://forecast.io/quicksilver/

Attribution and all that (a rant) about 1 year ago

@SimonPoole you do not have to accuse them of anything, just state disapproval of the fact they are using OSM data (which should be possible to verify beyond reasonable doubt) without making their customers aware of it in a way the creators of this data would like them to. If you want to make a stronger statement accuse them of disrespect for the 1.5 million OSM contributors the OSMF represents (OK, that would be quite a stretch but legally this is completely harmless).