Da es nirgendwo besser hinpasst: Weiß jemand, ob man CC-BY-SA 3.0-Daten in die Odbl-OSM importieren kann?

Nein, 3.0 ist weder mit 2.0 kompatibel noch mit odbl.

Moment, ich habe gerade noch einen Fehler in pbftoosm entdeckt. Dieser tritt bei sich überschneidenden Polygonen auf. Wenn dieser behoben ist, dürfte auch das mit Thailand wieder stimmen.

Nach genauerer Analyse nicht unbedingt ein Fehler des Programms. Es ist schlicht so, dass überlappende Polygone innerhalb einer Polygondatei nicht vorgesehen sind. In der Formatbeschreibung für Polygon-Dateien ist nicht festgelegt, wie damit umgegangen werden soll. Was zum Beispiel, wenn innerhalb der Schnittfläche von zwei Positiv-Polygonen ein Negativ-Polygon existiert? Fällt der Bereich dann raus? Oder bleibt er drin?

Je nach Art der Programmierung gehen die Programme unterschiedlich damit um. Wenn das gewünschte Ergebnis rauskommt, dann ist das eher Glücksache. :slight_smile:

Der beste Weg wäre es, saubere Polygondateien zu verwenden. Es ist wie bei “landuse=residential”. Man kann solche Bereiche überlappen lassen, aber wehe, es lässt jemand eine Statistik drüber laufen, wie viel Wohnbaufläche in einer Stadt existiert. Dann stimmt die Rechnung nicht mehr.

Falls es sehr viele solche unkorrekten Polygon-Dateien gibt, sollte entweder das Programm angepasst werden (aber dann zuerst festlegen, wie Spezialfälle zu behandeln sind) oder ein extra Programm geschrieben werden, das aus solchen unklaren Dateien korrekte zaubert.

Mehrere Polygone in einer Polygondatei sind sinnvoll zum Beispiel bei Exklaven. Dann hat man Beispielsweise Russland und seine Exklaven alle in einer Polygondatei.

Sich überschneidende Polygone sind allerdings wirklich etwas komisch. Die gab’s halt damals bei Cloudmade, und da ich mich damals mit der ganzen Sache noch so gut wie gar nicht auskannte, habe ich diese einfach verwendet.

Dass Osmosis alle sich überschneidenden Polygone vereinigt ist vielleicht gar nicht so gut, denn so kann man keine Dinge aus einem Polygon A mittels eines anderen Polygons B rausschneiden. Beispielsweise könnte Polygon A Brandenburg sein und Polygon B Berlin. Mit pbftoosm kann man ganz einfach diese beiden Polygone in eine Polygondatei stecken und pbftoosm gibt nur Brandenburg OHNE Berlin aus. Osmosis würde einfach Berlin+Brandenburg ausgeben.

Gibt es hier 'nen Osmosishacker? Ist das ein vergessenes Detail? Oder gibt es da irgendeine Option, um das Verhalten zu ändern?

Meine Lösung wird sein: Ich werde mit JOSM die zu osm-Dateien umgewandelten Polygondateien korrigieren, also alle sich überschneidenden Polygone vereinen. Oder gleich neue Polygone verwenden. Mal sehen.

Die Welt ist durchgelaufen und sieht deutlich vernünftiger aus.

Allerdings scheint mir die Zahl meiner Relationen immer noch zu niedrig. Das war allerdings schon bei Deutschland so (421 am 9. Mai und 326 am 17. Mai). Davor ging das eher langsam mit 10-30 Relationen weniger zwischen zwei Rechnungen (Maximalwert: 528 Relationen am 15. Februar).

Edbert (EvanE)

Wenn jemand anders die Relation zwischenzeitlich angefasst hat, ist das nicht mehr Deine…ob das hier der Fall ist, weiß ich nicht. Eventuell mal mit osmosis nach Deiner ID & Relationen filtern.
“how did you contribute” zeigt 326 an http://hdyc.neis-one.org/?EvanE

meine db exaktomang:

select count(id) from relations where user_id=184969;
 count 
-------
   326
(1 Zeile)

Zeit: 916,693 ms

Gruss
walter

Also für Deutschland von der Geofabrik erhalte ich:

pbftoosm -i=germany.osm.pbf | grep '<relation' | grep -c 'EvanE'
328

Grüße,
Erik

PS: Meine lokale germany.osm.pbf ist ein paar Tage alt, daher wohl der Zahlenunterschied.

Es war mir klar, dass nur die Objekte, die ich als letzter bearbeitet habe, für mich gezählt werden (außer bei der Full History Auswertung). Ich bin halt verblüfft, dass in knapp über einer Woche rund 25% ‘meiner’ Relationen von anderen bearbeitet wurden, während das sonst so um die 5% waren.

Wie die Auswertungen von wicking und wambacher gezeigt haben (Danke dafür), scheint das aber so zu sein.
Fazit: Zumindest was mich betrifft, kein Fehler mehr in der Auswertung.

Edbert (EvanE)

Die Rundmail an alle contributor um sie zu beten die neuen CT zu akzeptieren wird nun wohl gerade verschickt.

Naja, genauer gesagt sind es wohl zunaechst einmal nur alle contributor die seit dem 12ten Mai letztes Jahr edits in OSM gemacht haben aber noch nicht zugestimmt oder abgelehnt haben.

Accounts die schon laenger inaktiv sind werde dann wohl in einer zweiten Runde angeschrieben.

Der Text der mail kann man unter http://wiki.openstreetmap.org/wiki/ODBL/2011_May_Letter_Translations ansehen.

Die Auswirkung der Mail ist deutlich zu erkennen:

http://ni.kwsn.net/~toby/OSM/license_count.html

Ausgerechnet jetzt, da es spannend wird, ist die Leipziger Karte http://osm.informatik.uni-leipzig.de/map/ offenbar tot. Weiß jemand, was da los ist?

Die Karte war nicht “aktuell”, also zeigte immer einen älteren Stand. Evtl. wird von Fabian gerade daran gearbeitet. Nur die Kreisdiagramme waren wohl aktuell.

Für AT sind eine Menge Detailstats verfügbar. Danke Flaimo fürs Bereitsstellen der osm Ways der Grenzen

http://odbl.de/special/burgenland.html
http://odbl.de/special/carinthia.html
http://odbl.de/special/graz.html
http://odbl.de/special/linz.html
http://odbl.de/special/lower_austria.html
http://odbl.de/special/salzburg.html
http://odbl.de/special/styria.html
http://odbl.de/special/tyrol.html
http://odbl.de/special/vienna.html
http://odbl.de/special/upper_austria.html
http://odbl.de/special/vorarlberg.html

In der index-Datei sind sie nicht zu finden, da muss ich auf Wicking warten. Wobei mir zwei Sachen nicht klar sind. Ich zitiere mal Flaimos Mail:

es gibt zwei spezialfälle:

  1. wien befindet sich komplett innerhalb der grenzen von
    niederösterreich. ich habe im entsprechenden osm file jetzt mal eine
    relation drinnengelassen, die wien als inner-member definiert.
  2. tirol besteht aus zwei unabhängigen flächen.

was passiert nun nach:


osm2poly.pl tyrol.osm > tyrol.poly
osmosis --read-xml file=austria.osm.bz2 --bounding-polygon file=tyrol.poly --write-xml file=tyrol.osm
In dem anderen Spezialfall halt tyrol mit lower_austria austauschen.

?

Weiß das zufällig jemand? Wenn nicht, schaue ich mir das mal mit JOSM an.

Wen Tirol aus 2 unabhängigen Ringen besteht, dann sind auch beide Ringe drin. Eine Fläche von einer anderen Ausschneiden geht nicht. Niederösterreich wir also immer Wien mit enthalten.

Danke Henning. Übrigends ist DE gerade fertig geworden. Die Mailing-Aktion hat sehr viel gebracht. Es gibt kaum noch “Nichts-Sager”. Ich werde auch mal DE-Full-History anstossen um ein besseres Bild zu bekommen. Allerdings sind die OSM Daten vom 12.05., users_agreed und users_disagreed aber von heute.

Deutschland Full History (BBox 6.43,47.19,15.11,55.19, kein BP) http://odbl.de/special/germany_full_history.html
Achtung 26MB!

Hier eine Visualisierung der BBox
http://www.openstreetmap.org/?minlon=6.43&minlat=47.19&maxlon=15.11&maxlat=55.19&box=yes

Naja, etwa 85’000 von 120’000 (weltweit, nicht allein auf DE bezogen) haben noch keine Entscheidung getroffen, und die Rate hat inzwischen wieder deutlich abgenommen. Der ganz große Durchbruch waren die beiden Mailaktionen eher noch nicht, auch wenn sich beim “sicheren” Datenvolumen schon einiges getan hat.

Naja, aber da gehen immer noch ca. 50% der v1-Daten den Bach herunter, trotz der Mailaktion. Mal sehen wie es sich entwickelt, aber die “toten” User sind das Hauptproblem.