@dgdg: Ich sehe das ebenso, es gibt keine Hirarchien in OSM. Die DB liegt offen und jeder kann sich um das kümmern was er möchte und beherrscht. Ich denke aber nicht, dass wer viel macht eher in der Kritik steht, solange er sich an die Regeln hält ist das
Anscheinend sehr zügig. Ich habe gestern einige is_in-Enträge korrigert und nach wenigen Stunden war die Fehleranzeige weg. Gruß, dgdg
Das Rad muss übrigends doch nicht neu erfunden werden. Die Open Geo DB hatte bei ihren Daten bereits den Gemeindeschlüssel mit dem Schlüssel “openGeoDB:community_identification_number” geliefert. Das muss also nur noch bei Ortsteilen und nicht erfassten Orten nachgetragen werden, der Rest hatte das ganze von Anfang an bereits an Board. Das ganze kann ein Bot kopieren, den Schlüssel nach zukünftigen Key transformieren und in die Tabelle schreiben. Der Rest ist Sache den Admins. Und was die Datenbank angeht so wird diese niemals schneller. Jedenfalls solange nicht, wie sich alles in einer abspielt. Dafür ist die Datenmenge viel zu gewaltig. Jegliche Optimierung bringt da nur Millisekunden, bei querys von 10s >. Solche Sachen wie Ortssuche usw. gehören deswegen kompakt auf eine eigene Maschine, die nur die nötigen Daten beinhaltet und nicht sämtliche dafür überflüssigen Dinge vom Landuse bis zum Mülleimer mitverwalten muss. So läuft das bei allen gleichwertigen Diensten. Das ist dass “Geheimnis” ihrer Schnelligkeit. @Oktober Ich will dafür keine Kohle haben, sowas sollte generell nicht sein. Da ärgert man sich nur. Letztens bin ich durch Zufall über eine Aktion in Bohmte gestoßen. Die haben dort bei irgendeiner Aktion 500 Schleifen für die Vermesssung ihrer Kuhbläke bekommen. Ein Gebiet was ich an zwei Wochenenden allein mit dem Fahrrad komplett bis zum Feldweg erfasse und umsetze. Und dann haben die nichtmal ein Gebäude stehen. Da kommt man schon ins grübeln. Nichts gegen die Leistung, aber es ärgert einen doch. Ich erfasse einen ganzen Landkreis bis hin zu Gebäuden. Im Urlaub habe ich große Teile der Dominikanischen Republik und dort auch einige Ortschaften und die Hauptstadt erfasst und gemappt. Da stelle ich mich auch nicht hin, hier gucke mal, was eine Leistung, nun möchte ich Anerkennung. Jeder so wie er kann. Irgendwelche Anreize wie obiger, sind da vollkommen fehl am Platz, verdirbt einem nur den Spaß. Ich möchte nur eines. Ein bisschen Usability um das ganze auch zukünftig so genau wie möglich umsetzen und vervollständigen zu können.
Hallo Miko, na das sind doch mal gute Nachrichten. So genau habe ich mir die Einträge der Open GeoDB noch nicht angeschaut. Werd ich aber gelich mal tun. 
Georg
Auf die Nodes aus der OpenGeoDB bin hier in der Umgebung schon gestossen. Die stehen irgendwo als virtuelle Nodes in der Landschaft. Leider fehlen viele Gemeinden (z.B. Fronhausen). Keine Ahnung ob die jemand gelöscht hat oder ob nicht alle Gemeinden übernommen wurden. Nächste Frage: wie taggt man nun sinnvoll den Gemeindeschlüssel? Bei diesen OpenGeoDB-Nodes findet man auch eine vollständige is_in-Hierachie mit Kreis und Regierungsbezirk (Beispiel Ebsdorfergrund): Marburg-Biedenkopf,Gießen,Hessen,Bundesrepublik Deutschland,Europe Gruß, dgdg
Die automatischen Einträge sehen in etwa so aus: Name <tag k=‘openGeoDB:version’ v='0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/’ /> Einwohner Telefonvorwahl AGS Gemeindeschlüssel KFZ Kennzeichen Siedlungsart Postleitzahl Damit wurden quasi alle vorhanden Hauptgemeinden automatisch platziert. Die Daten müssten eigentlich noch großflächig vorhanden sein, wenn nicht der eine oder andere statt die Node zu verschieben, die Node löschte, und eine jungfreuliche eigene anlegte. Die Daten sind also schon lange da, müssten nur auf kleinere Siedlungsarten übertragen und anschliessend ausgewertet werden.
Dazu noch ein Nachtrag: Der Eintrag “Gießen” für den Regierungsbezirk ist natürlich so falsch, denn er bezieht sich hier auf die Stadt Gießen. Eigentlich müsste der Regierungsbezirk als Node oder Grenze mit eigenem Namen angelegt und dann an dieser Stelle eingetragen werden. Das gleich Problem hat man bei Gemeinden, wo ein Ortsteil den gleichen Namen hat wie die Gemeinde (z.B. Gemeinde Fronhausen, Ortsteil Fronhausen). Ich habe jetzt die Gemeinde Fronhausen mit dem Namen “Gemeinde Fronhausen” angelegt und den Ortsteil mit “Fronhausen”. Einfacher ist es bei Gemeinden, die einen komplett neuen Namen bekommen haben (z.B. Ebsdorfergrund oder Lahntal). Ein durchgängiger Gemeindeschlüssel bis auf Ortsteilebene hinunter (so wie in Bayern) wäre hier sehr hilfreich. Dann könnte man die komplette Struktur alleine über den Schlüssel abbilden. Die Bayern haben hier mal wieder einen Schritt weiter gedacht. Gruß, dgdg
Das Problem bei den “nicht existenten” Gemeinden ist jedoch, dass hier zum Beispiel der “is_in - Checker” meckert. Irgendwie kommen wir nicht um einen Schlüssel der bis auf Ortsebene reicht herum… Aber die Regierungsbezirke sind doch angelegt?! http://tools.geofabrik.de/osmi/?view=boundaries&lon=8.77741&lat=50.58840&zoom=9&overlays=boundary_relations_5,boundary_ways_5 Sie müssten nur z.B. im OSM Inspector noch als Level 5 eingebaut werden, dann würde man auch mehr als nur den Schriftzug sehen… Edit: ok.ok ich bin nicht blind. Auf dem Reiter Kreisgrenzen sind die RB´s drauf und werden auch brav angezeigt. http://tools.geofabrik.de/osmi/?view=kreisgrenzen&lon=8.64008&lat=50.60758&zoom=9&overlays=boundary_relations_2,boundary_relations_4,boundary_relations_5,boundary_ways_2,boundary_ways_4,boundary_ways_5,boundary_ways_7 Georg
Aha, “Gießen Regierungsbezirk” wäre also der korrekte Name für die “is_in”-Hierarchie. Man müsste jetzt also sämtliche GeoDB-Nodes korrigieren. Und dann kommt jemand auf die Idee, und ändert die Namen der Regierungsbezirke. 
Gruß, Detlef
oder löst sie gleich ganz auf… Ups duck und weg
Änderungen werden sowieso regelmäßig fällig. Bei uns kommt alle paar Jahre eine Gebietsreform. Dieses Jahr sind einige Kreise und Gemeinden zusammen gegangen, teilweise mit neuen Kreisnamen. Da muss von den Verwaltungsrenzen bis hin zu Kuhbläken alles geändert werden. So schwer ist es aber nicht. Kann man gefiltert aus der Api ziehen und mit JOSM in einem rutsch ändern. Mit dem Gemeindeschlüssel fährt man in dem Fall aber auch nicht besser. Der ändert sich dann ebenfalls, da darin auch eine Nummer für den Kreis enthalten ist. Gleiches gilt für Regierungsbezirke, die wir zum Glück nicht haben.
Die Systematik in den “is_in”-Eintrag jeder Häuseransammlung den gesamten Pfad bis hinauf zu “Europe” einzutragen ist schon ziemlich hausbacken. Normalerweise sollte es ausreichen, jeweils nur die Zugehörigkeit zur nächsthöheren Ebene einzutragen. Beispiel Ebsdorf: Ebsdorf: is_in=Ebsdorfergrund Ebsdorfergrund: is_in=Marburg-Biedenkopf Marburg-Biedenkopf: is_in=Hessen Hessen: is_in=Bundesrepublik Deutschland Bundesrepublik Deutschland: is_in=Europe Wenn sich dann auf höherer Ebene etwas ändern (z.B. Bundesrepublik Deutschland nicht mehr in Europe ;)), muss ich nur noch eine Ebene anpassen und nicht zigtausende von towns, villages, suburbs und hamlets. Der Gemeindeschlüssel ist im Grunde genauso unflexibel wie vollständiger Pfad in einem “is_in”-Eintrag. Auch hier muss man bei strukturellen Änderungen den Schlüssel aller betroffenen Gemeinden einzeln korrigieren.
Zum Thema Renderer: Mit Kosmos kann man wirklich schon ne Menge machen. Also bitte nicht die Daten an die Renderer anpassen… Zum Thema Tags: Da es noch nicht genannt wurde. Vergesst nicht die Einwohnerzahl mit “population” anzugeben. 
Zum Thema is_in: Ich tagge ab und zu in der Ukraine. Da hab ich mir die Frage gestellt in welcher Sprache ich das Taggen soll… Ich sehe hier grad, dass alles auf deutsch aufgelistet wird, außer “Europe”, also alles was das Land betrifft in Landessprache, und den was darüber hinaus geht in Englisch? Und soll ich die Landeseigenen einträge dann auch kyrillisch schreiben? Bis jetzt hab ich das immer so gemacht: “??? ???, ??? ???” (quasi Bundesland und Landkreis) Wär das so besser: “??? ???, ??? ???, ???, Europe”?
Ich habe die Tags jetzt mal in einigen Gemeinden geändert. Also die Ortsteile mit place=suburb und die Flächengemeinde mit einem neuen Node (sofern nicht bereits durch den Import aus GeoDB vorhanden) mit place=village. Den Village-Node habe ich dann irgendwo in die Nähe des grob geschätzten, flächenmäßgen Mittelpunktes der Gemeinde gesetzt. Mapnik rendert das jetzt ziemlich blöd, weil der auch davon ausgeht, das “suburb” eine Vorstadt bzw. ein Stadtteil ist und nicht ein Ortsteil. Die Schrift der Ortsteilenamen ist jetzt groß und grau (so groß wie die Schrift von Städten) und die Gemeindenamen sind klein und schwarz. Ich weiss “wir taggen nicht…” aber trotzdem sieht das bescheiden aus. Man bräuchte eigentlich Orts- und Stadtteil-Tags, die wie bei city, town und village nochmal nach der Größe (Einwohner) unterscheiden. Mit einem einzigen suburb-Tag wird das nichts. Gruß, dgdg
Das hilft nicht. Meine Idee mit Größe nach Einwohner war Quatsch. Es bräuchte eine Unterscheidung, ob es sich um den Ortsteil einer Gemeinde oder um den Stadtteil einer Stadt handelt. Genauso wie die Namen von Städten und Gemeinden sinnvollerweise unterschiedlich gerndert werden, so müssten auch die Namen von Ortsteilen und Stadtteilen unterschiedlich gerendert werden. Gruß, dgdg
Er meinte damit wohl eher einen spezifischen Tag mit entpsrechender Darstellung und weniger die Einstufung nach und Angabe der Einwohnerzahl. Die Einwohnerzahl hat eher wenig mit der tatsächlichen Verwaltungsform zu tun und eigenet sich desshalb überhaupt nicht um danach eine Einstufung vornehmen zu können. Ich weiß nicht ob das nicht sogar Ländersache ist. Bei uns in Thüringen sind min. 5.000 für Städte vorgesehen. Es gibt aber auch welche wie unser direkter Nachbar mit nur 2.100 Einwohnern.
Des Weiteren habe ich gerade festgestellt, dass die Einträge -population- aus der GeoDB sich auf die Gesamteinwohnerzahl der Stadt/(Gesamt-)Gemeinde beziehen und scheinbar nur am Verwaltungssitz vorhanden sind. Also ist auch dieser Eintrag zu prüfen. 
Georg
Ja, genau.