OpenStreetMap

imagico has commented on the following diary entries

Post When Comment
dlr data help 16 days 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 16 days 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 27 days 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 2 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 2 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 2 months ago

This looks much better.

Attributing OpenStreetMap 3 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 3 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 3 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? 4 months 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 5 months 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) 6 months 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).

Attribution and all that (a rant) 6 months ago

I must say i am with Martin here - it is not quite reasonable to complain about lack of attribution by small users of OSM data when the big violations of the license are essentially ignored. And like Martin i think taking action here does not necessarily mean legal action since bad publicity is often a much more effective way especially in case of big companies and institutions.

I understand it is difficult to actually do something about the big violations but addressing the small scale users of data instead because this is more likely to achieve visible results is not the way to go i think.

A clear and prominent statement by the OSMF that condemns the way Apple handles use of OSM data would be a start...

von Spitzbergen und Luftbildern 8 months ago

Der Kommentar kommt etwas verspätet - ich hab diesen Beitrag erst jetzt gesehen.

Schön zu sehen, dass sich beim Mapping der Polarregionen was tut - trotz der diversen Probleme, die dabei auftreten - Du hast ja ein paar schon genannt.

Ein paar Ratschläge und Hinweise, die vielleicht von Nutzen sein können:

  • Meiner Erfahrung nach ist es an schwierigen Stellen recht nützlich, mehrere Bilder beim Mapping zur Verfügung zu haben. Beispielsweise vom Frühsommer (mit Meereis und Schnee aber ohne lange Schatten) und vom Spätsommer (wenig Eis und Schnee aber dafür ungünstigere Beleuchtung). Mehrere Bilder helfen auch, die in diesen Regionen oft erheblichen Lageabweichungen der Bilder einzuschätzen (laut USGS-specs sind das für L1G-Szenen 250m RMS)
  • Wenn man wg. Schatten und ähnlichem an den Farben drehen muss empfiehlt es sich natürlich, die Originaldaten und nicht nur die JPEGs herunterzuladen, was aber den Aufwand des Ganzen natürlich erheblich in die Höhe treibt.
  • Die Seen kann und sollte man als natural=water & water=lake taggen, die sind im Allgemeinen dauerhaft - im Winter halt zugefroren.
  • Auch die Gletscher kann man auf Basis von (aktuellen) Landsat-Bildern durchaus erfassen, dafür sind allerdings Bilder vom optimalen Zeitpunkt und etwas Augenmerk bei der Unterscheidung zwischen Gletschern und (ggf. mehrjährigem) Schnee nötig. Gerade hierbei ist es wichtig sich auf Basis mehrerer Bilder aus verschiedenen Jahren ein gutes Bild von der Gegend zu machen.
  • Von Interesse sein könnte auch http://wiki.openstreetmap.org/wiki/User:Imagico/Coastline_Mapping_from_Landsat_Scenes