Noch ein paar Fragen zu Stadtteilen, Ortsteilen und Gemeinden

Communities Deutschland (Germany)
1

Hallo,

Irgendwie tue ich mich immer noch schwer bei den kleineren Einheiten der Städte und Gemeinden. So eine richtige einheitliche Linie gibt es da scheinbar noch nicht, oft hört man dann: mach es wie du es für richtig hälst. Das machen dann wohl viele auch so, was dann allerdings eine Auswertung der Daten recht schwierig macht. So richtig verstehe ich auch noch nicht den Weg der Community, zu einem einheitlichen System zu kommen, manchmal habe ich sogar das Gefühl ein einheitliches System ist gar nicht mal richtig gewünscht.

Zum eigentlichen Problem:

http://wiki.openstreetmap.org/wiki/DE:Key:place

“Normale” Städte mit den Stadtteilen finde ich einleuchtend mit dem tag place=suburb

Etwas unsicher bin ich immer wenn die Stadtteile eingemeindete Orte sind die dann auch oft noch etliche Kilometer von der Stadt entfernt sind, soll man da auch suburb verwenden ?

Weiter geht es mit recht kleinen Gemeinden, die aus mehreren Dörfern bestehen, z.B hier:

http://de.wikipedia.org/wiki/Holving

Wie würdet ihr das mappen ? suburb passt nicht mehr richtig, einige mappen aber auch die Gemeindeteile damit.

Dann die Frage, wie es mit den Flächen aussieht, manche beschriften die komplette Gemeindegrenze mit dem Namen, manche zusätzlich noch einen extra place node, manche keinen extra place node, manche beschriften landuse=residental mit dem Ortsnamen, obwohl ja nicht nur das Wohngebiet zum Ort gehört, auch hier wieder manche mit extra place node, manche ohne, dadurch erscheinen manche Orte ja dann 2 fach, 3 fach oder noch mehrmals auf der Karte und eine Auswertung fällt da recht schwer. Gibt es da Tendenzen zu einer Vereinheitlichung ?

Letztes Problem: is_in wird zumindest in meiner Gegend kaum verwendet, manchmal mit einer kompletten Hierarchy, manchmal aber auch nur vereinfacht als is_in=Germany, Europe. Auch hier fällt dann die Auswertung recht schwer. Im Wiki hat jemand ja vorgeschlagen, z.B is_in:town, is_in:village oder andere entsprechende Tags zu verwenden, was ich für recht schlüssig halte und eine Auswertung erleichtern würde, allerdings auch hier: solange es keinen einheitlichen Weg gibt, finde ich die Auswertung der Tags recht umständlich.

Das bringt mich dann als Neuling zur letzten Frage: OSM ist ja nun nicht mehr ganz neu, in vielen wichtigen Sachen scheint es mir aber immer noch keinen einheitlichen Weg zu geben, was mich dann zu der etwas kritischen Einschätzung kommen lässt: hier gibt es ein tolles Mapping und Geodatenprojekt wo man kleinlichst über Lizenzen diskutiert aber in wichtigen Sachen immer noch keinen einheitlichen Weg hat, wie man bestimmte Sachen mappen sollte.

2

Ja! Suburb sorgt dafür, dass ein kleinerer Vorort niemals das größere Stadtzentrum von der Landkarte verdrängt.

Ein place node ist leider notwendig, damit der Ortsname in der Karte angezeigt wird.

is_in ist zwar altmodisch, aber in vielen Fällen recht nützlich. Beispielsweise wird damit an der deutsch-schweizerischen Grenze die Staatszugehörigkeit dokumentiert. (Deutsche Straße vs. Schweizerstrasse)

Es gibt zwar verschiedene Vorschläge, aber noch keinen, der sich durchgesetzt hat.

Gruß FK270673

3

Quatsch. Wie misterboo richtig schrieb, werden aufgrund verschiedenere Kriterien Ortsnamen auf der Karte dargestellt und nicht nur dort, wo place=* steht.
Der Trend geht weg vom place=* und auch vom is_in-tagging. Beides sind veraltete Verfahren aus der Zeit “vor den Admin-Boundaries”

und hier die Sosse: das Thema “in welchem Land liegt diese Straße denn?” wurde vor einiger Zeit ausführlich diskussiert. Ergebnis: unklare und unscharfe Boundaries haben das verursacht.

Gruss
Walter

4

Jein. Wenn der Mittelpunkt der admin_boundary irgendwo in der Pampa liegt, möchte man mit dem place-node schon ausdrücken, wo die Häuser stehen, zu denen der Anfragende höchstwahrscheinlich hinwill.
Schau dir z.B. Wetter an der Ruhr an. Da liegt der eigentliche Ort hart am Rande der Stadtfläche.

Gruß,
ajoessen

5

:slight_smile: ich sehe schon die Problematik, 3 Antworten = 3 verschiedene Meinungen

Ich sehe eigentlich auch die Problematik bei den boundaries: der Name wird von den Rendererern dann in den Mittelpunkt oder den Schwerpunkt des Polygons gesetzt, das kann bei manchen “unförmigen” Orten oder Städten zu seltsamen Beschriftungen führen. Trotzdem ist es mir eigentlich egal: das Projekt existiert ja nun schon einige Zeit: da sollten sich doch langsam einige feste Mapping Regeln etablieren und festgeschrieben werden.

Ich blicke da aber leider noch nicht ganz durch, gibt es da Leute, die solche festen Regel mal festschreiben, oder denkt man der anarchische Gedanke, dass im Grunde jeder Mappen kann , wie er will, wird auch in Zukunft der Größe und der Komplexität des Projektes noch gerecht werden. In der kurzen Zeit, die ich dabei bin, bin ich schon auf einige mahnende User gestoßen, die die Befürchtung haben, dass man irgendwann einen Haufen Daten hat aber diese durch die Komplexität und Menge immer schwieriger zum Auswerten werden.

Vielleicht sollte man da mal langsam beginnen gerade für die wichtigen Sachen, z.B die Namen die ja dann auch für Projekte, die sich mit der Namenssuche beschäftigen, einheitliche Regeln zu schaffen. z.B. eine weltweilt einheitliche hierarchisch gegliederte Ordnung.

Wenn man als Anfänger auf die Openstreetmap Seite kommt, steht die Karte im Vordergrund, kommt man in die Foren, erfährt man aber, dass es eigentlich scheinbar nicht um die Karte geht, sondern um die Geodaten. So richtig durchblicken tue ich da noch nicht. Zu einer Geodatenbank gehören für mich aber auch die natürlichen Gebiete, also z.B Alpen, Schwarzwald, Schwäbische Alb, Harz etc. Dafür scheint es noch gar keine Pläne zu geben wie diese Sachen gemappt werden sollen.

Eine Übersichtskarte mit geografischen Regionen konnte ich leider noch nicht mit den osm geodaten erstellen:

http://dev.misterboo.de/map/?zoom=6&lat=49.29&lon=8.14&layers=B0000TF

Auf der anderen Seite gibt es Gedanken schon Gullideckel zu mappen, da werden einzelne Bäume gemappt, da fangen Firmen an gegen Geld Firmen in die Karte einzutragen etc.

Mir fehlt da irgendwie etwas die klare Linie, in welche Richtung sich das Projekt entwickeln soll. Irgendwie passt es für mich nicht zu einer angeblichen “Geodatenbank”, dass da Landschaften und Gebiete fehlen, auf der anderen Seite nun schon Gedanken in Richtung einer weiteren Firmendatenbank gehen.

Aber im Grunde wäre das mir auch egal, wenn es eine klare strukturierte Gliederung, z.B mit featurecodes und featureclasses geben würde und eine einfache Möglichkeit, diese dann abzufragen. So könnte man z.B die komplette Infrastruktur, die Landnutzung, Siedlungsdaten in jeweils einzelne Klassen und die nochmal unterteilt zusammenfassen. Der Endanwender sollte dann eine einfache Möglichkeit haben, nur diese Klassen aus der DB abzufragen und zu extrahieren. So braucht jemand z.B. für ein Projekt nur die Landnutzungsdaten oder etwa nur Infrastrukturdaten. Das ist momentan nur mit großem Aufwand möglich und erst recht nicht einfach für einen absoluten Anfänger.

6

Im Prinzip denken wir, dass der anarchische Gedanke auch in Zukunft funktionieren wird. Es gibt für ein paar Dinge recht konkrete Regeln (z.B. admin_levels, weil da die Auswertung sonst garnicht möglich wäre, aber für viele Zwecke wichtig ist), manche Dinge sind einfach von vornherein klar (Namen werden mit name getaggt) und der Rest ist soweit frei. Trotzdem setzt sich hier meistens eine Taggingvariante durch. Das geschieht unter anderem durch den Proposalprozess, in dem einzelne unverbindliche Regeln im Wiki vorschlagen, über die dann diskutiert und abgestimmt wird. Außerdem haben die Renderer einen wichtigen Einfluss, vor allem Mapnik. Weil die meisten ihre eingetragenen Objekte natürlich auf der Karte sehen wollen, fallen Alternativen, die nicht gerendert werden, oft schnell mehr oder weniger weg. Das wir aber keine festgeschriebenen Regeln haben, hat auch viele Vorteile, zum Beispiel können wir uns immer auf Neuerungen einlassen. Stellt man sich vor, dass zum Beispiel die is_in-Tags vorgeschrieben wären, um zu bestimmen, wo ein Objekt liegt, hätte es vielleicht länger gedauert, bis die boundaries sich durchgesetzt hätten. So erkennt fast jeder schnell die Überlegenheit des neuen Systems und es setzt sich durch. Letztendlich glaube ich, dass die ganzen Tippfehler und die Leute, die Grundregeln (wie englische Tags) nicht beachten mehr Chaos für die Auswertung erzeugen als ein paar alternative Tagging-Modelle, die oft durch den Proposalprozess gegangen und damit dokumentiert und teilweise auf Kompatibilität abgestimmt sind. Nur ein paar Dauerdiskussionen machen uns zu schaffen (highway=footway vs. highway=path, separate Fuß- und Radwege vs. Tags an der Straße, etc.), aber wir können bisher damit leben und wir werden es auch in Zukunft können. Weiterentwicklungen unserer Technik werden sie vielleicht irgendwann entscheiden (z.B. API-Änderungen, die Baumstrukturen erlauben; Editoren mit einfacherer Relationenunterstützung; Renderer die Straßenflächen darstellen; etc.) oder auch nicht.

Zur anderen Sache: Ja wir sammeln Geodaten. Aber wir kommen eben aus einem Straßenkartenumfeld. Was gemeint ist, wenn ersteres ausgedrückt wird, ist einfach, dass wir uns nicht um die Darstellung auf irgendwelchen Karten kümmern, sondern alles mappen, was wir für sinnvoll halten. Wir mappen auch HKTS (Hundekottütenspender), auch wenn keine Karte die bis jetzt rendert, denn dafür sind andere zuständig. Das Problem mit natürlichen Gebieten ist, dass sie meist nicht klar umrissen sind und deshalb nur sehr schwer zu mappen. Mit Nodes ginge das ja noch halbwegs, aber wie du hier siehst gehen wir aus Genauigkeitsgründen lieber zu Flächen wie den boundaries, und da wird die Abgrenzung schwer. Wenn du aber eine total innovative Idee hast (oder auch nur eine halbwegs praktikable), dann schreib ein Proposal und wenn sie gut ist, haben wir vielleicht auch bald Gebirge, Meeresabschnitte, Heidelandschaften und was das Herz sonst noch begehrt.

7

Ein größeres Problem als fehlende Festschreibungen, sind eher schlechte oder nicht erweiterbare bzw. mehrdeutige Taggingmodelle. Ganz im Gegenteil, wäre das Projekt mit den von manchen Leuten gewünschten festen Regeln schon längst den Tod der Strukturstarrheit und Unflexibilität gestorben.

Man stelle sich mal vor vor, man hätte solche Tags wie z.B. is_in=* festgeschrieben und müßte diese kaputten Modelle jetzt für ewig benutzen, obwohl sie jeder schlecht findet. Auch wenn die Tags damals gut und ausreichend waren, kommen durch neue Einsatzideen oder technische Möglichkeiten immer wieder unvorhersehbare Entwicklungen zustande, die man eben gerade nicht planen und festschreiben kann! Da ist es wesentlich wichtiger, gut feststellen zu können wie andere das gleiche Problem gelöst haben, so daß man immer die zur Zeit, nach persönlichen Maßstäben, beste Lösung auswählen kann. Auch wenn solche Starren Modelle bei den Profimappern üblich sind, wird da nicht beachtet, daß deren Modell immer nur versuchen einen kleinen Miniausschnitt der Realität abzubilden, ohne den Anspruch wie OSM zu haben, ein möglichst gutes und allumfassendes Realitätsmodell zu bauen. Praktisch ist da eher interessant, wann man die subjektiv als Altlasten angesehen Tags an seine eigenen Wahrnehmung des “allgemein üblichen Taggings” anpassen kann. Weil es werden ja auch zu recht, sehr lange, Alttags aus Kompatibilitätsgründen noch mitgeschleppt ohne das klar ist wann man sie entfernen oder umstellen darf. OK, im Moemnt wird da im Zweifelsfall einfach bei Einzeledits angpaßt, was auch gut ist, weil es passiert sichtbar/spürbar aber nicht schlagartig wie z.B. mit Massenedits, aber es könnte passieren, das die Methode irgendwann mal evtl. nicht mehr ausreicht, weil dafür die Bearbeitungen der Objekte insgesamt zu gering sind.

Wenn du denkst das sie fehlen, dann trage sie doch ein, denn dann besteht auch die Chance, daß auch andere Leute die Sachen brauchen können. Ja, so funktioniert das hier bei OSM. Dazu mußt du auch nicht wissen, wohin sich das Projekt entwickeln wird. Weil als man in England angefangen hat, hat man ja scheinbar auch mehr an “wir machen erst mal eine freie Straßenkarte…” gedacht und nicht an Skipisten oder Hydranten.

Wenn ich es richtig verstehe, möchtest du eine Metazusammenfassung von üblichen Taggingvarianten für bestimmte Objekte haben, damit sich nicht jeder hinsetzen muß und alle Taggingvarianten z.B. für Rad- oder Fußwege wieder neu zusammen zu suchen. Dabei muß man aber auch sehen, daß das bestenfalls grob möglich ist, solche Metadatenbanken zu erstellen. Soweit ich weis, ist da MapCSS auch der erste Ansatz, einheitliche Regelsätzdefinitionen zum Rendern leicht zwischen den Programmen autauschen zu können. Das hängt im speziellen aber immer auch vom konkreten Anwendungsfall ab, welche Merkmale zusätzlich noch wichtig sind, aber so muß man wenigstens den gleichen Renderstil (z.B. Radkarte oder Wanderkarte) nicht für jeden Renderer neu in der jeweiligen Syntax zusammenbauen. Aber auch jetzt kann man ja schon Dinge aus ähnlichen Stilvorlagen für den betreffenden Renderer übernehmen.

8

… allein im deutschsprachigen Forum! Wenn Du noch mehr Meinungen hören möchtest, dann solltest Du es noch auf der deutschsprachigen Mailingliste, auf den englischen und französischen Mailinglisten, im russischsprachigen Forum usw. versuchen :wink:

Karte = sichtbare Geodaten, hinzu kommen die unsichtbaren Geodaten. Z.B. haben wir für Paris auch die Namen in allen anderen Sprachen: Lutetia, Parigi, Parijs, Pariz, Parizs, Paříž, Париж, パリ, 巴黎 usw. Sichtbar ist aber immer nur jeweils eine Sprachversion.

Um das zu verwirklichen ist wahnsinnig viel Arbeit notwendig:

    1. Eine Relation erstellen, die den ganzen Harz oder oder den ganzen Hunsrück oder den ganzen Schwarzwald oder den ganzen Taunus umfasst. Wo will man da die Grenze ziehen? Geht der Hunsrück bis zur Mosel bzw. bis zum Rhein, bis zur Flussmitte, bis zum Flussufer oder nur bis zum Waldrand? Gehört die Heidelberger Altstadt noch zur Oberrheinischen Tiefebene oder schon zum Neckartal oder schon zum Odenwald? Wenn Du diese Fragen eindeutig beantworten kannst, dann darfst Du mit Punkt 2 fortfahren.
    1. Falls die Relation, die den ganzem Schwarzwald umfasst, nach einer Woche ununterbrochener Arbeit endlich fertig geworden ist, stellt sich die Frage, wie diese Relation getaggt werden soll. name=Schwarzwald, Black Forest, Forêt Noir ist klar. Dann müsst es so etwas wie nature_level=X geben. nature_level=1 wäre dann die Kontinentalplatte, nature_level=2 wären dann die Alpen oder Karpaten, nature_level=3 wäre dann das Deutsche Mittelgebirge oder das Rheinische Schiefergebirge, nature_level=4 wären dann Eifel, Hunsrück, Taunus und Westerwald. Das müsste dann sauber aus der Fachliteratur heruasgearbeitet werden, wobei die Fachliteratur sich ständig ändert - 1930 gab es bekanntlich noch keine Kontinentaldrift. Das wäre eine Herkulesaufgabe fürs Wiki.
    1. Wenn diese Relation endlich fertiggestellt sind, dann könnte man relativ leicht alle Geodaten innerhalb dieser Relation extrahieren, wie es heute bereits mit den nationalen Paketen geschieht.
    1. Außerdem fehlen in der Datenbank noch ethnische und historische Grenzen, beispielsweise Deutschland oder Österreich-Ungarn in den Grenzen von 1914. Dann stellt sich natürlich die Frage: Wo verläuft die ethnische Grenze zwischen Deutschen und Franzosen? Soll man Elsässer und Luxemburger als eigenständige Ethnien eintragen? Soll man Dialektgrenzen eintragen?

Das dauert zehn Minuten. Eine Relation mit den Umrissen der Rocky Mountains zu erstellen dauert zehn Monate (mindestens).

Mapper zeichnen diejenigen Orte ein, die sie interessant finden. Das sind dann im Zweifelsfall eher Bordelle als Feuchtbiotope - auch wenn es an beiden Orten Feuchtgebiete gibt :wink:

Du kannst ja ein paar tausend Chinesen, Inder oder Kambodschaner fürs Mappen der Rocky Mountains bezahlen :wink:

So etwas vermisse ich auch.

Gruß FK270673

9

zu den geographischen Landschaften:

Warum sollte dies so kompliziert sein ?

http://dev.misterboo.de/map/?zoom=6&lat=49.97664&lon=7.96422&layers=B0000TF

Wenn ich die ganze Zeit nehme, die ich gebraucht habe um die recht komplizierte Toolchain von OSM zu verstehen und dann auch als eigene Karte umzusetzen, waren die geographischen Regionen eigentlich noch der Teil, der am schnellsten ging.

Nicht alles in einer Karte muss doch absolut akkurat sein. Während natürlich der Gullideckel, das Schlagloch oder der Hundekottütenspender schon recht genau sein sollten, werden die Geographischen Regionen wie Meere, Landschaften, Gebirge doch eh nur für kleiner Masstäbe verwendet und auch dann nur als Label, man braucht da ja keine absolut exakte Grenze.

Ich habe mit Hilfe von Wikipedia und der OSM Karte im Hintergrund einfach grob die Landschaften in einem GIS Programm wie Quantum GIS eingezeichnet und dann in meine OSM Datenbank importiert. Das geht recht schnell. Jetzt passe ich mir gerade den Mapnik Code noch etwas an, so dass der Schriftzug der Landschaften wie in den gedruckten Karten auch über die komplette Landschaft gelegt werden, so wie hier z.B:

http://upload.wikimedia.org/wikipedia/commons/4/40/MacedonEmpire.jpg

den Harz z.B. muss man ja nicht absolut genau wie eine administrative Grenze mit viel Aufwand genauesten erstellen, ein grober Umriss mit ein paar Nodes reicht da vollkommen für die Lage des Labels.

10

Moin Moin, Mr Boo

genauso sehe ich es auch - 10 Monate für die Rockies sind wohl etwas übertrieben.
Auch bei den “richtigen” Grenzen, wie den PLZ-Gebieten oder anderen heisst es ja auch “mach sie erstmal grob rein, Hauptsache sie sind drin”.
Und hier wird mit aller deutschen Pingeligkeit gefordert, dass man bei z.B. ethnischen “Grenzen” oder auch Einordnungen von großflächigen geographischen Gebieten absolut genau ist.
(Das mag eventuell in Belfast oder Flandern notwendig sein.)
Und solange du das nicht kannst, brauch/will sich niemand der “Kritiker” mit einem vernünftigen Tagging-Schema beschäftigen.
Wenn wir überall die Latte so hoch hängen würden, müssten z.B. die meissten Boundaries raus.

Gruss
Walter

11

Schön. Dann erarbeite doch mal ein Proposal, wie man das gescheit taggen können und schon können wir anfangen, es aufzunehmen.

@FK270673: Historische Grenzen würden wir nicht aufnehmen, da wir uns relativ einig sind, dass in OSM nur der Ist-Zustand beschrieben wird. Ethnische Grenzen wären natürlich recht interessant.

12

Dann fange ich mal mit der Badisch-Schwäbischen an… :wink: