Verwendung place=suburb

Dort finde ich aber nur die Großgemeinde an sich und nicht die Ortsteile. Haben die Ortsteile in Hessen keinen Schlüssel sondern nur in Bayern? Das Problem ist ja die Zuordnung von verstreuten Ortsteilen zu einer Flächengemeinde. Dafür wäre es natürlich praktisch, wenn man das an einem zentralen Ort nachschlagen könnte und nicht jedes mal die Webseiten oder den Wikipedia-Eintrag der Gemeinden durchsuchen müsste. Gruß, dgdg

Man müsste die Links auch mal lesen. Steht doch da, dass Bayern eigene Teilkennziffern für kleinere Strukturen hat. Da Bayern nunmal Bayern und nicht Hessen oder Sachsen ist, gibt es diese Teilkennziffern auch nur in Bayern. Logisch das er dann Kleinkleckersdorf in Hessen nicht in der Datenbank hat. Um ein bisschen Sucharbeit kommst du so oder so nicht herum. Es läuft ja auch keiner los, schreibt Straßennamen usw. auf und schmeißt dir das ganze fertig in den Briefkasten. Da heißt es loslaufen oder auf jemanden warten, der die Arbeit macht. Ein bissel Arbeit ist nunmal dabei. :smiley: Gleich noch eine ganz “originelle” Idee. Frage doch die Gemeinden, ob sie dir Daten zur Verfügung stellen. Mehr als nein kann da nicht kommen. Oft lohnt die Anfrage aber auch. Manche geben nur Straßenverzeichnisse heraus, andere gleich ganze Shapes oder POIs. Die müssen aber erstmal von dir und dem Projekt wissen, die kommen nicht zu dir.

Naja, man wird ja nochmal nachfragen dürfen.

Ach so? :slight_smile:

Hallo dgdg, leider gibt es dort nur die Großgemeinden bzw. Städte. Ich bin mir auch nicht sicher ob Hessen die Teilnummern für die Stadt-/Ortsteile offiziell vergeben hat? Laut WIKIPEDIA scheinbar nicht. Aber das Problem ist doch gar nicht mehr so groß. Wenn alle Stadtteile (incl. der “Hauptstadt”) den gleichen Schlüssel haben, ist doch klar das sie zusammen gehören. Das abzufragen ist doch DIE Aufgabe für eine DB-Abfrageroutine überhaupt. Der Aufbau des Gemeindeschlüssels wird doch hier http://de.wikipedia.org/wiki/Gemeindeschl%C3%BCssel#Aufbau sehr gut beschrieben. Die Bezeichnungen town,city ect. könnten dann, wie o.g. in eine neue Struktur überführt werden und schon passt es. Oder es gäbe noch die Möglichkeit hier mit Relationen zu arbeiten und denen den AGS zu verpassen. Ich habe aber eine Idee, diese kann ich aber leider erst am 05.01. überprüfen. Wir verwenden bei der Arbeit eine Software die, wenn ich mich nicht gewaltig täusche, mit der Teilnummer auf Ortsteilebene arbeitet. Eventuell kann ich über die Softwareschmiede näheres erfahren. Zu deiner Frage mit den Nodes bzw. Flächen… Eventuell hilft dir das hier weiter: http://toolserver.org/~kolossos/osm/index.php Georg

Hallo Mirko, es will (und soll) natürlich keiner eine kleine Ortschaft plötzlich zur Stadt erheben. Aber genau darum ging es doch an Anfang des Treads. Die “Vorgaben” in den Features sind eben nicht passend so wie sie im Moment sind, auch oder gerade wenn sie der Orientierung dienen sollen. Auch kann man die Schlüssel nicht von der Einwohnerzahl abhängig machen. In Berlin gibt es Stadtteile die deutlich mehr Einwohner haben, als eine Mittelgroße Stadt sonstwo. Aber es geht auch anders herum. Ich kenne “Städte” (mit und ohne Marktrecht :wink: ) wo die Kernstadt gerade mal 3.000 EW hat und alles zusammen nicht mehr als 9.000. Das bedeutet das es Zeit wird die z.Zt. grobe Struktur zu überdenken. Zum Thema “is_in”, dass ist ein Relikt aus den Anfängen von OSM und schon lange nicht mehr Zeitgemäß. Inzwischen wird laut darüber nachgedacht hier etwas zu ändern und das tun wir doch gerade hier. Das mit dem Relikt ist übrigens nicht von mir, sondern stammt aus berufenem Munde von einem der Leute die in der OSM-DB richtig tief drin stecken. Deinen Einwand, das Rad nicht neu zu erfinden, kann ich zwar verstehen jedoch wird uns das in OSM noch öfter so gehen. Wer hat denn z.B. vor 2 Jahren etwas von Relations gewußt?? :confused: Das Ganze bedeutet ja auch nicht das sofort alles geändert werden soll oder muß. Aber darüber nachdenken sollten wir hier schon mal (dürfen). Georg

Da braucht es doch keine neuen Strukturen. Wenn du is_ in für die die Hauptgemeinde auswerten kannst, kannst du dir auch alles was daran hängt ausgeben lassen. Denn in den Ortsteilen ist jeweils auch der Name der Hauptgemeinde drin. Ist nichts anderes wie der Gemeindeschlüssel. ís_in muss eben eingetragen sein, genau wie ein Gemeindeschlüssel auch. Im Gegensatz zum Gemeindeschlüssel hat is_in aber bereits eine gute Abdeckung. Die Hauptgemeinden hatte die Geofabrik schon angelegt. Den Rest habe ich nachgetragen. Ich sehe das Problem irgendwo nicht. Hier fehlen noch grundelegende Daten, wie eben sowas banales wie Verwaltungsrenzen. Die habe ich bei uns zum Glück einbringen können. Nur kriegt man einen zuviel, wenn sich mitten in der eigentlichen Datenerfassung alle Minuten etwas ändert, siehe kürzlich admin_level. Lasst die Leute doch erstmal erfassen. Ansonsten ist man ja mehr mit Änderungen beschäftigt, als mit der annähernden Vervollständigung der Karte. Ich fummle an knapp 1.000 km² mit 50 Gemeinden fast alleine. Manches geht mit JOSM ja leicht zu ändern. Aber bei solchen Dingen wie einen individuellen Schlüssel zu vergeben, musst du jeden Ort einzeln per Hand anfassen. In der Zeit kannst du sämtliche Beschränkungen einer Landstraße taggen. Wenn es denn nun schon wieder sein muss dann arbeitet das bitte einmal richtig aus, um nicht wieder alles umwerfen zu müssen und gebt den nötigen Key bitte so früh wie möglich raus. Die entsprechenden Gemeindeschlüssel habe ich schon, ich brauche nur den Key. Wenigstens bin ich diesmal vorgewarnt. Zu den Realationen sage ich mal nichts. Das wurde auch nicht ganz zuende gedacht. Nett für zusammenhängende Wege, für Flächen und Einzelobjekte unzulänglich. Die lassen sich nämlich nicht automatisch auf Lücken überprüfen. Genau das wird aber bei der späteren Datenpflege nötig. Wenn irgendwann die Vandalen kommen und das werden sie leider, kannst du dir dann z.B. bei fehlenden Adressen einen Wolf suchen.

Mmmh, vielleicht stehe ich gerade auf dem Schlauch. :wink: Wenn ich die Ortsteile in der Datenbank vom Statistischen Bundesamt nicht finde, dann weiss ich doch gar nicht, welchen Schlüssel sie haben und kriege auch nicht raus, ob sie zusammen gehören!? Ich will das Problem jetzt auch nicht dramatisieren. Für die drei bis vier Gemeinden, die im Moment für mich relevant sind, kriege ich das auch über die Homepages der Gemeinden raus. Aber eine generelle hessen- oder deutschlandweite Lösung wäre natürlich sinnvoll. Gruß, dgdg

Also im ersten Moment sollte man auch nur die Daten der Gemeinden anfassen, bei denen man sicher ist das sie zusammengehören. Du hast ja schon die Möglichkeiten genannt das heraus zu finden. WIKIPEDIA und/oder die Ortsseiten der Städte und Gemeinden. Da sollte man in diesem Fall eventuell zuerst nachsehen, den Gemeindenamen finden und dann sehen welche Orte dazu gehören. @ Mirko…Das Ganze sollte auch nur ein Lösungsvorschlag sein und nicht eine sofortige 180° Wendung. Vor allem wird eigentlich nichts ohne Proposal geändert. Angewendet in der Regel allerdings schon. Irgendwie reden wir aneinander vorbei glaub ich. Es ging doch um das value -suburb- und die in den Features dazu genannte Übersetzung. Dazu kamen dann noch Einwände wegen der Einwohnerzahlen… Ein weiteres Problem sind scheinbar die eben nur unzureichenden Einträge bei is_in. Manche schreiben nur die Stadt/Großgemeinde rein andere noch den Landkreis und dann Schluß. In diesem Fall muß leider auch jeder “Ort” noch einmal angefasst werden und der is_in Eintrag auf Vollständigkeit geprüft und ggf ergänzt werden. Des Weiteren ist es wohl DB-technisch erheblich aufwändiger und langsamer einen ellenlangen “textschlüssel” (is_in) auszuwerten, als einen numerischen (Relation). Da sich eh alle über die Unzureichende DB-Geschwindigkeit beschweren, wurde wohl auch darüber diskutiert. Von der potentiellen Tippfehlern einmal gnaz abgesehen.

Ok, wenn es aber der DB-Pflege dient?! Ich denke das sollten wird den Admins überlassen. Was nützen uns Vorgehnsweisen die irgendwann die Maschinen die damit laufen zum Stillstand bringen, weil der Aufwand zu groß geworden ist? Bitte stell mich nicht als Urheber des Gedankens hin, das bin ich nicht. Ich lese nur ab und zu mal in der Mailingliste mit und filtere das für mich relevante heraus, was nicht immer leicht ist. Außerdem gehöre ich nicht zum Kreis der Admins, dass möchte ich auch noch einmal klarstellen. Georg

Dann wollen wir mal das Beste hoffen. Ein Stadtgebiet (ein Zwischenschritt zwischen Stadt und Stadtteil) könnte auch nicht schaden. Grüße.

Bei den is_in Einträgen hilft dieser Link: http://autobug.osm.lab.rfc822.org/ Nachtrag: Der Link hilft natürlich nur bei groben Fehlern. Ob die Hierachie wirklich stimmt oder sinnvoll ist, zeigt er natürlich nicht. :slight_smile: Ich habe gerade mal überlegt, wie der “is_in”-Eintrag für den Ortsteil Fronhausen vollständig aussehen müsste: Gemeinde Fronhausen Kreis Marburg Regierungsbezirk Gießen Hessen Bundesrepublik Deutschland Europe Bevor man das alles für jedes Dorf einträgt, müsste man sich wirklich erstmal über den übergeordnete Struktur einigen. Das möchte ich später nicht alles nochmal korrigieren müssen. :slight_smile:

Ich schreibe mal meine persönliche Motivation: Hier in Nordhessen sind viele Dörfer erst wenig erfasst. Wenn ich Zeit und Lust habe, dann möchte ich das gerne in die OSM eintragen. Außerdem möchte ich gerne Wanderwege eintragen. Mit de:Relation:route (Thema im Forum) geht das wunderbar. (Mein Aufzeichnungsgerät ist ein Garmin eTrex Vista HCx.) Aber wenn ich mir die Mühe schon mache, dann möchte ich das auch später in der Karte sehen, und zwar auch auf den entsprechenden Detailstufen. Leider werden so Sachen wie shop=beverages oder power=sub_station (Thema im Forum) auf keiner Karte (Mapnik, Osmarender, Cycle Map, tiles@home) angezeigt, auch nicht in der detailliertesten Stufe. Das frustet, deshalb werde ich aus dem Getränkeladen meines Heimatortes einen Supermarkt machen (das Trafohäuschen ist mir egal). Wenn später die Renderer angepasst wurden, dann ändere ich das wieder zurück. In anderen Orten mache ich nichts. Jetzt mal konkreter zu place=suburb und place=village: Ich möchte das gerne so machen, wie es im Wiki geregelt ist. Aber ich möchte es auch auf der Karte sehen, konkreter: ich möchte eine Detailstufe haben, wo Städte und Gemeinden angezeigt werden, und eine andere detaillierte, wo dann auch Dörfer oder Ortsteile angezeigt werden. Dass Gemeinden in der Karte erst erscheinen, wenn auch alle kleinen Dörfer anzgezeigt werde, finde ich unbefriedigend. Noch konkreter: Beispiel Schwalmstadt: Früher gab es einmal die Städte Treysa und Ziegenhain. Daraus hat man dann Schwalmstadt gemacht, Treysa und Ziegenhain sind jetzt Stadtteile. Bis gestern war das in der OSM falsch eingetragen. Ich habe nun den Punkt name=Schwalmstadt in die Wiese zwischen den beiden Orten verschoben (place=town habe ich natürlich nicht geändert). Fälschlicherweise hatte dieser Punkt nämlich in Treysa gelegen. Den Punkte name=Treysa habe ich erst erstellt, weil es ihn noch nicht gegeben hat und habe ihn auf den Marktplatz in Treysa gesetzt. Bei Treysa und Ziegenhain habe ich place=suburb und is_in=Schwalmstadt ergänzt. Zwischen den beiden Stadtteilen liegt der Ort Ascherode. Den lasse ich auf place=village, denn ich will ja nicht alles durcheinanderbringen oder Bill Tuer überfahren, der den Ort erfasst hat. Ich habe nur is_in=Schwalmstadt hinzugefügt. (InformationFreewayKarte) Ich bin übrigens in Treysa zur Schule gegangen (nur, falls jemand jetzt gleich schreiben will, ich solle nicht in fremden Gegenden rummachen). Hinweise, wie ich das besser machen soll, nehme ich dankbar an. Und natürlich will ich mich auch an die Vogaben und Regeln halten. Aber weil es sich um eine Landkarte handelt, deren Ziel die Orientierung ist, sollte dieser Aspekt nicht vernachlässigt werden. Vielleicht kann sich mal einer der Administratoren dafür einsetzen, dass Mirko KÄ1/4ster einen Teil der Spendensumme von wikipedia bekommt, bevor er unter der Last der Arbeit und Verantwortung zusammenbricht. Wenn man sieht, wie schnell dort die 6 Mio $ zusammen kommen, da sollte man schnell mal anklopfen, bevor sie das Geld wieder an die Spender zurücküberweisen, weil die Summe schon erreicht wurde. @Mirko KÄ1/4ster: Danke, dass Du das mal so schreibst, denn oft genug wird der Einsatz der im Hintergrund stattfindet überhaupt nicht gesehen und gewürdigt. Diesen Absatz meine ich kein Stück ironisch (nur damit keine Missverständnisse beim Lesen entstehen). Gruß, Oktober

@Oktober: Ich denke über kurz oder lang wird es einen frei konfigurierbaren Renderer geben (müssen), wo man selber einstellen kann, welche tags man wie gerendert haben will. @Oktober und Mirko: Ich habe nicht dieses Bild von der OSM-Community, dass da

@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. :slight_smile: 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