Herkunft eines gerenderten Namens ermitteln?

misterboo · 2012-03-08T17:11:51.000Z

ich sehe gerade:

type=boundary

Da es in Deutschland nur sehr wenige Grenzen gibt, die so getaggt sind, darf man die in

type=multipolygon

umwandeln damit es einheitlich ist ?

http://www.openstreetmap.org/browse/relation/62456/history

ajoessen hatte das umgetagged letztes Jahr von multipolygon zu boundary. Was war der Grund damals für diese Änderung ?

Meine Statistik der administrativen Grenzen in Deutschland sagt:

292 x type=boundary

12126 x type=multipolygon

wambacher · 2012-03-08T17:37:15.000Z

misterboo:

Meine Statistik der administrativen Grenzen in Deutschland sagt:

292 x type=boundary

12126 x type=multipolygon

Das such dir mal irgend ein anderes Land aus und fahre die Statistik neu. Osm ist ein internationales Projekt.
Gruss
Walter

misterboo · 2012-03-08T17:43:00.000Z

wambacher:

misterboo:

Meine Statistik der administrativen Grenzen in Deutschland sagt:

292 x type=boundary

12126 x type=multipolygon

Das such dir mal irgend ein anderes Land aus und fahre die Statistik neu. Osm ist ein internationales Projekt.
Gruss
Walter

Darum geht es mir ja nicht … mir geht es darum das man bestimmte Sachen einheitlich macht, wie - ist mir im Grunde egal.
Wenn jemand die ganzen Grenzen einheitlich per Bot auf boundary umstellt, wäre das natürlich auch OK.

Das gleiche mit dem amtlichen Gemeindeschlüssel. Die meisten ohne Leerzeichen, manche mit Leerzeichen. Auch hier gilt: ein einheitliches Schema würde die Auswertung erleichtern.

ajoessen · 2012-03-08T18:25:23.000Z

misterboo:

wambacher:

misterboo:

Meine Statistik der administrativen Grenzen in Deutschland sagt:

292 x type=boundary

12126 x type=multipolygon

Das such dir mal irgend ein anderes Land aus und fahre die Statistik neu. Osm ist ein internationales Projekt.
Gruss
Walter

Darum geht es mir ja nicht … mir geht es darum das man bestimmte Sachen einheitlich macht, wie - ist mir im Grunde egal.
Wenn jemand die ganzen Grenzen einheitlich per Bot auf boundary umstellt, wäre das natürlich auch OK.

Das wird nur in Deutschland anders gehandhabt als im Rest der Welt, weil jemand aus der Geofabrik das so in seinen OSM inspector eingebaut hat.

Das gleiche mit dem amtlichen Gemeindeschlüssel. Die meisten ohne Leerzeichen, manche mit Leerzeichen. Auch hier gilt: ein einheitliches Schema würde die Auswertung erleichtern.

Darauf brauchst du als Auswerter nicht zu hoffen. Jeder macht es halt so, wie er es für richtig hält. Das muß bei Telefonnummern ja auch funktionieren.

BTW: wie hättest du denn gerne den Regionalschlüssel für Landkreise? mit Nullen auf 12 Stellen aufgefüllt? Steht im Wiki nämlich (leider) anders, und bei destatis haben auch nur die Gemeinden 12 Stellen.

Gruß,
ajoessen

misterboo · 2012-03-08T18:43:46.000Z

ajoessen:

misterboo:

wambacher:

Das such dir mal irgend ein anderes Land aus und fahre die Statistik neu. Osm ist ein internationales Projekt.
Gruss
Walter

Darum geht es mir ja nicht … mir geht es darum das man bestimmte Sachen einheitlich macht, wie - ist mir im Grunde egal.
Wenn jemand die ganzen Grenzen einheitlich per Bot auf boundary umstellt, wäre das natürlich auch OK.

Das wird nur in Deutschland anders gehandhabt als im Rest der Welt, weil jemand aus der Geofabrik das so in seinen OSM inspector eingebaut hat.

Das gleiche mit dem amtlichen Gemeindeschlüssel. Die meisten ohne Leerzeichen, manche mit Leerzeichen. Auch hier gilt: ein einheitliches Schema würde die Auswertung erleichtern.

Darauf brauchst du als Auswerter nicht zu hoffen. Jeder macht es halt so, wie er es für richtig hält. Das muß bei Telefonnummern ja auch funktionieren.

BTW: wie hättest du denn gerne den Regionalschlüssel für Landkreise? mit Nullen auf 12 Stellen aufgefüllt? Steht im Wiki nämlich (leider) anders, und bei destatis haben auch nur die Gemeinden 12 Stellen.

Gruß,
ajoessen

ich denke, nur die die Gemeinden sollten 12 Stellen haben.

Aber: Eine Gemeinde, die auch Kreislevel haben … also die ganzen kreisfreien Städte die auch korrekt mit admin_level=6 getaggt sind sollten mit Nullen aufgefüllt werden (so ist auch im amtlichen Gemeindeverzeichnis)

zum type=* bei den Grenzen:

Wie es dazu gekommen ist, warum nur in Deutschland type=mulipolygon genommen wird für Grenzen, ist im Grunde egal. Man kann gut damit leben wenn ein komplettes Land einheitlich (auch wenn das anders sein sollte als in anderen Ländern) getagged ist, genauso kann kann man gut damit leben, wenn man sich den internationalen Gegebenheiten anpasst und alles einheitlich ändert.

Blöd ist nur, wenn jetzt jeder macht was er will und das ehemals einheitliche Schema (auch wenn es anders ist) nun zerstört wird.

Also entweder type=multipolygon einheitlich oder type=boundary einheitlich in Deutschland, der Mix macht absolut keinen Sinn und ist unnötig.

noch etwas zum Regionalschlüssel obwohl wir das besser im AGS Thema diskutieren sollten:

Der allgemeine Gemeindeschlüssel ist ja nun seit ein paar Tagen für alle Gemeinden in Deutschland vorhanden. Es wäre also absolut unnötige Arbeit, dass man nun von Hand anfängt, den Regionalschlüssel zu ergänzen. Das wäre eine perfekte Arbeit für einen Bot, der das fehlerfrei erledigen könnte. Ich kenne mich leider noch zu wenig aus mit der Materie, um das erledigen zu können.

monotar · 2012-03-08T18:49:03.000Z

Ich habe etwa 10 boundary für Ortsteile selbst erstellt. Irgendwann hats einer auf multipolygon umgestellt. Nur blöd, dass multipolygon eigentlich gar nicht mit label und admin_centre umgehen kann und das ist auch mein Hauptkritikpunkt an multipolygon der direkt zum Threadthema führt. Wie bereits gesagt, OSMI usw. blabla, alles schon 1000 Mal disktutiert und unnötig hier nochmal zu tun

ich lass bei dem Thema nur noch alle 10 gerade sein - mir doch egal was da gerendert wird: OSM: Von Amateuren für Amateure

misterboo · 2012-03-08T18:51:35.000Z

monotar:

Ich habe etwa 10 boundary für Ortsteile selbst erstellt. Irgendwann hats einer auf multipolygon umgestellt. Nur blöd, dass multipolygon eigentlich gar nicht mit label und admin_centre umgehen kann und das ist auch mein Hauptkritikpunkt an multipolygon der direkt zum Threadthema führt. Wie breits gesagt, OSMI usw. blabla, alles schon 1000 Mal disktutiert und unnötig hier nochmal zu tun

warum unnötig ?

Wenn type=boundary Standard ist international und auch logische Vorteile hat (z.B. admin_centre), warum können wir das dann nicht einfach umstellen ?

monotar · 2012-03-08T18:56:36.000Z

Es wird bei der Diskussion nichts rauskommen, alleine der Vorschlag sowas zentral umzustellen wird wieder ellenlange Diskussionen nach sich ziehen, da sowas sowieso nicht gerne gesehen ist. Der Validator ist ohnehin auf der multipolygon-Seite und viele User haben nun auch diese Meinung usw. Also ich gebe sowas auf, genauso wie z.B. die Fahrspurdiskussionen die nie enden werden.

ajoessen · 2012-03-08T18:57:07.000Z

misterboo:

ich denke, nur die die Gemeinden sollten 12 Stellen haben.

Aber: Eine Gemeinde, die auch Kreislevel haben … also die ganzen kreisfreien Städte die auch korrekt mit admin_level=6 getaggt sind sollten mit Nullen aufgefüllt werden (so ist auch im amtlichen Gemeindeverzeichnis)

Gut. Ist für NRW admin_level 6 jetzt so komplett in der Datenbank.

zum type=* bei den Grenzen:

Also entweder type=multipolygon einheitlich oder type=boundary einheitlich in Deutschland, der Mix macht absolut keinen Sinn und ist unnötig.

Da mir niemand einen vernünftigen Grund für einen deutschen Alleingang nennen konnte, bleibe ich bei dem international üblichen boundary.

Du musst halt geauso wie route=foot und route=hiking beides auswerten. oder nur boundary=adminstrative.

noch etwas zum Regionalschlüssel obwohl wir das besser im AGS Thema diskutieren sollten:

Der allgemeine Gemeindeschlüssel ist ja nun seit ein paar Tagen für alle Gemeinden in Deutschland vorhanden. Es wäre also absolut unnötige Arbeit, dass man nun von Hand anfängt, den Regionalschlüssel zu ergänzen. Das wäre eine perfekte Arbeit für einen Bot, der das fehlerfrei erledigen könnte. Ich kenne mich leider noch zu wenig aus mit der Materie, um das erledigen zu können.

Ich fürchte, das geht nicht. Weil die Zugehörigkeit zu Verbandsgemeinden aus dem AGS nicht ablesbar ist. Trifft für mich in NRW zum Glück nicht zu.

Gruß,
ajoessen

misterboo · 2012-03-08T19:03:23.000Z

monotar:

Es wird bei der Diskussion nichts rauskommen, alleine der Vorschlag sowas zentral umzustellen wird wieder ellenlange Diskussionen nach sich ziehen, da sowas sowieso nicht gerne gesehen ist. Der Validator ist ohnehin auf der multipolygon-Seite und viele User haben nun auch diese Meinung usw. Also ich gebe sowas auf, genauso wie z.B. die Fahrspurdiskussionen die nie enden werden.

Meinen Validator meinst du aber nicht, denn ich ich werte das gar nicht aus. Ich bin nur ein Verfechter von zumindest einigen einheitlichen Regeln. Und wenn es eine internationale Regel gibt und die sich auch durchgesetzt hat mit type=boundary, sehe ich keinen Grund, warum man nicht nochmal darüber diskutiert und auch die Grenzen bei uns umstellt.

misterboo · 2012-03-08T19:07:33.000Z

ajoessen:

Ich fürchte, das geht nicht. Weil die Zugehörigkeit zu Verbandsgemeinden aus dem AGS nicht ablesbar ist. Trifft für mich in NRW zum Glück nicht zu.

Gruß,
ajoessen

Sicher ist die ablesbar … jede Gemeinde mit einem 8 stelligen Gemeindeschlüssel ist eindeutig und hat auch einen eindeutigen Regionalschlüssel, der ja im amtlichen Gemeindeverzeichnis bei destatis.de angegeben ist.

monotar · 2012-03-08T19:09:39.000Z

Nein, ich meine den von OSMI, das sollte klar sein…
Du kannst die Umstellung ja versuchen, wünsche dir viel Glück

misterboo · 2012-03-08T19:11:30.000Z

ajoessen:

Da mir niemand einen vernünftigen Grund für einen deutschen Alleingang nennen konnte, bleibe ich bei dem international üblichen boundary.

Du musst halt geauso wie route=foot und route=hiking beides auswerten. oder nur boundary=adminstrative.

Wie gesagt mir persönlich ist es egal was man macht, ich finde es nur nicht gut, wenn es durcheinander ist.

ajoessen · 2012-03-08T19:12:55.000Z

misterboo:

Sicher ist die ablesbar … jede Gemeinde mit einem 8 stelligen Gemeindeschlüssel ist eindeutig und hat auch einen eindeutigen Regionalschlüssel, der ja im amtlichen Gemeindeverzeichnis bei destatis.de angegeben ist.

Ja gut, wenn du die destatis-Tabelle verwendest. das macht den Bot aber aufwendiger.
Allein aus den tags in OSM ist es jedenfalls nur umgekehrt möglich.

Gruß,
ajoessen

misterboo · 2012-03-08T19:21:28.000Z

ajoessen:

misterboo:

Sicher ist die ablesbar … jede Gemeinde mit einem 8 stelligen Gemeindeschlüssel ist eindeutig und hat auch einen eindeutigen Regionalschlüssel, der ja im amtlichen Gemeindeverzeichnis bei destatis.de angegeben ist.

Ja gut, wenn du die destatis-Tabelle verwendest. das macht den Bot aber aufwendiger.
Allein aus den tags in OSM ist es jedenfalls nur umgekehrt möglich.

Gruß,
ajoessen

Ich denke gegen die Verwendung der destatis Tabelle dürfte nichts sprechen für einen automatisierten Import des Regionlaschlüssels … DD1GJ könnte ja bitte mal noch sicherheitshalber nachfragen.

“Vervielfältigung und Verbreitung, auch auszugsweise, mit Quellenangabe gestattet.” steht bei den amtlichen Daten.

Auf jeden Fall wäre der Abgleich mit der amtlichen Tabelle bei über 12000 Gemeinden fehlerfreier als einzelne das bei 12 stelligen Nummern machen könnten.

Fabi2 · 2012-03-08T20:34:10.000Z

misterboo:

Wie es dazu gekommen ist, warum nur in Deutschland type=mulipolygon genommen wird für Grenzen, ist im Grunde egal.

Hat jemand mal witerführende Links/Threads dazu? Hat das nachvollziehbare Gründe gehabt?

misterboo:

Man kann gut damit leben wenn ein komplettes Land einheitlich (auch wenn das anders sein sollte als in anderen Ländern) getagged ist, genauso kann kann man gut damit leben, wenn man sich den internationalen Gegebenheiten anpasst und alles einheitlich ändert.

“Die Grenzen bitte. Nein, ich wollte doch kiene Häuser, Wälder und Seen! Die darf ich jetzt alle noch extra auf boundary=*, parsen lassen. Kaffee hol”
Warum wird dieser Blödsinn denn nicht einfach geändert, zumal man da noch nicht mal alles abbilden kann! Der OSM-Inspektor muß dann eben angepaßt werden und die anderen Anwendunden kann man ja versuchen zu informieren bzw. werden die es sonst schon merken. Es kann aus meiner Sichr nicht sein das die ganze Welt einen einheitlichen und besseren Standard dafür hat und man hier unbedingt sein eigenes Süppchen kochen muß. Gibt es überhaupt nachvollziehbare Gegenargumente das nicht umzustellen?

ajoessen · 2012-03-08T21:03:06.000Z

misterboo:

Ich denke gegen die Verwendung der destatis Tabelle dürfte nichts sprechen für einen automatisierten Import des Regionlaschlüssels

Nö, höchstens der Mehraufwand gegenüber simpler Zeichenersetzung.

Auf jeden Fall wäre der Abgleich mit der amtlichen Tabelle bei über 12000 Gemeinden fehlerfreier als einzelne das bei 12 stelligen Nummern machen könnten.

Für NRW brauchts keinen Bot mehr. Admin_level 8 ist jetzt auch komplett regionalverschlüsselt. Wer Fehler findet, darf sie behalten…

Und die Borderquote sieht jetzt auch besser aus

Gruß,
ajoessen

SunCobalt · 2012-03-08T21:06:52.000Z

manchmal ist es besser, wenn man nicht alles ausdiskutieren will und es einfach macht. (ausser wenn es Bäume betrifft). Vielleicht sagt Walter noch was dazu. Er hat recht viel Erfahrung mit Grenzen. Im OSMI werden auch OSM konforme Dinge angemeckert, weil sie “sanft” in Richtung GIS-Standards bewegt werden sollen.

chris66 · 2012-03-08T21:25:50.000Z

Fabi2:

misterboo:

Wie es dazu gekommen ist, warum nur in Deutschland type=mulipolygon genommen wird für Grenzen, ist im Grunde egal.

Hat jemand mal witerführende Links/Threads dazu? Hat das nachvollziehbare Gründe gehabt?

Siehe:
http://forum.openstreetmap.org/viewtopic.php?id=11283

Chris

Seoman · 2012-03-09T08:13:54.000Z

Oli-Wan:

http://www.openstreetmap.org/browse/relation/62456

Danke für die schnelle Info!
Dann ist es ein Fehler des Renderers, sowohl diesen Namen als auch den “Duisburg”-Node (ID: 240055326) zu rendern (beide gleichzeitig nur in Zoom 14). Leider scheint sich da bei Mapnik nichts zu tun, das entsprechende Ticket http://trac.openstreetmap.org/ticket/3069 wurde vor 21Monaten eröffnet …

Seoman