Wo finde ich die Regeln, welche Schlüssel bei Objekten zulässig bzw. verboten sind und in welcher Kombination? Einzelbeispiele: Wann wird eine Kirche als **Punkt **{{Tag|buildings|place of warship}}, wann als **Fläche **{{Tag|buildings|place of warship}} und wann sowohl als Punkt und Fläche {{Tag|buildings|place of warship}} bezeichnet? Das ist bei allen anderen Gebäuden ebenfalls unklar. Ziel ist, dass das Gebäude sowohl als Fläche gerendert wird, als auch das Symbol dargestellt wird. Bei Flüssen steht, man solle (müsse? dürfe?) sie mit {{Tag|layer|-1}} auszeichnen. Aber anderswo steht, man solle das nicht tun. Die gleiche Verwirrung mit **Layer **gibts bei Brücke und Tunnel. Bei den Strassen und Wegen ist nicht klar, wann eine Linie ein Weg und wann eine Strasse ist und wieso das unterschieden wird. Bei **Küstenlinie **und Fluss ist nicht klar wo das eine anfängt und das andere aufhört. Dasselbe Problem gibt es zwischen Fluss und See. Unklar ist auch die Trennung von Meer und See, bzw. zwischen Festland und Insel, sowie zwischen Festland und Insel im See. Ich suche übergeordnete Regeln, also nicht einzelne Beschreibungen einzelner Schlüssel. Gruss, Markus
Hier findest du eine Liste mit der OSM Legende. Alle aktuelle Objekte mit Key und Value sind dort aufgeführt. Auch kannst du dich dort durchklicken um die möglichen zusätzlichen Attribute einzusehen. http://wiki.openstreetmap.org/index.php/De:Map_Features Nach dieser Liste wird eine Kirche übrigens nur als Punkt bezeichnet.
Layer geben ja nur an was oben und was unten liegt. Das kann bei jedem Objekt in Bezug zu seiner direkten Umgebung sehr unterschiedlich sein. Beispielsweise hatte ich hier neulich die Situation das inmitten eines größeren Waldgebietes ein Friedhof lag. Den Friedhof habe ich einfach in den Wald reingezeichnet und mit Layer=1 ausgezeichnet und der Wald ist layer=0.
Das ist doch auch wieder der jeweiligen Situation vor Ort geschuldet. Als Beispiel sei mal genannt eine Straße ist für PKW eine Sackgasse aber an deren Ende können Fußgänger und Radfahrer noch über einen Weg weiter.
In der Natur sind diese Übergänge zwischen den einzelnen Formen meistens fliessend. So gibt es auch zum von dir beschriebenen Problem vom Übergang von Küste / Fluss eine Diskussion dieses entsprechend umzusetzen. http://wiki.openstreetmap.org/index.php/Tidal_Rivers
Hi, ich glaube du denkst, bzw. versuchst viel zu strukturiert zu denken. Jedenfall strukturierter als es OSM (im Moment) zulässt.
MapFeatures ist ein Hinweis, genauso die ganzen anderen Wikiseiten, die du schon kennst. [Tagwatch Tagwatch - OpenStreetMap Wiki](Tagwatch Tagwatch - OpenStreetMap Wiki) gibt dir Auskunft was für Tags benutzt werden. Erlaubt, bzw. verboten gibt es in dem Sinne nicht. Nur Tags die weit verbreitet sind und auch vom Renderer/Router/sonstwas ausgewertet werden und andere die jemand neu erfunden hat.
Die Kirche als Punkt ist eine größere Vereinfachung als eine Kirche als Fläche. Wenn du nur sagen willst: Da ist eine Kirche, mach einen Punkt hin. Wenn du genauer sein willst, dann zeichne den Grundriss nach. Fläche und Punkt würde ich nicht setzen. Imho soll die Software lernen auch Flächen als POI zu erkennen.
Die Layer geben die relative Lage der Objekte an. Da Flüsse üblicherweise unter allem drunter durch fließen steht da was von layer=-1, so lange der Fluss auf freiem Feld unterwegs ist störts niemanden. Dient halt der Klärung bei sich Kreuzenden Objekten, welches jetzt oben und unten liegt. Bei einer Brücke über einen Fluss isses ein bisschen doppelt, aber auch nicht falsch. Layer 1 liegt nun mal über Layer -1.
??? Eine Linie ist eine Linie. Wenn die Linie einen Weg darstellen soll, kann man sie im übertragenen Sinne auch Weg nennen. Gleiches bei Straßen. Ist, denke ich, nur eine sprachliche Geschichte. Im englischen heissen die (OSM-)Linien ways, daher wird manchmal Weg verwendet. Viele Linien/Ways/Wege stellen Straßen dar (alles mit highway Tag), also wird auch Straße gesagt. Andere Linien, zb. die von landuse stellen keine Straßen dar, sind also irgendwie von highways zu unterscheiden. Ich hoffe ich konnte bisschen helfen. Gruß zorque Edit: zu langsam 
Hallo Zorque,
Na ja - es ist doch ein Prinzip von Regeln, dass sie strukturiert sind?! Am Beispiel “Kirche”: Kirche ist bei den Schlüsseln nur als Punkt beschrieben. Wird mit einem schönen Symbol gerendert. Kirche ist aber eigentlich eine Fläche. Wird aber als solche weder beschrieben noch angezeigt. Und höchstens die Kirchturmspitze als Peilmarke wäre ein Punkt. Soll ich also einfach eine neue Schlüssel-Beschreibung für Fläche={{Tag|buildings|place of worship}} machen? Und hinschreiben, man möge Fläche bevorzugen und nicht gleichzeitig Punkt setzen? Zumindest beim Parkplatz steht es so. Und wo informiere ich dann, dass es sinnvoll wäre ab Zoomlevel 13 das Symbol anzuzeigen und ab ZL 15 den Grundriss? Und wie ist das in Bamberg oder Rom, wo es mehr oder weniger wichtige Kirchen gibt? Und wäre es nicht sinnvoll, alle Schlüssel in einer Datenbank zu sammeln? Damit sie beliebig sortiert und abgefragt werden können? Damit keine Redundanz gepflegt werden muss? Damit einmal gefundene Regeln nicht woanders anders beschrieben werden oder verloren gehen? Und wäre es nicht sinnvoll, die **Vorlagen **der Editoren aus dieser Datenbank zu generieren? Damit Tippfehler durch händische Eingaben (wird grad bei Wegen in der Mailingliste diskutiert) vermieden werden? Und wem müsste man das wo sagen? Wer kann sowas umsetzen?
hm - aber es *gibt *doch “Regeln”? Und die könnte man doch auch in einer zentralen DB dokumentieren?
Aber auch da wäre es doch für die Programmierer einfacher, wenn sie eine zentrale Regelbasis hätten, wo drin steht: “am Montag wurde geändert: Kirche gibts jetzt als Fläche”?!
Das gibt im Bahnhof von Zürich bestimmt ein ziemliches Durcheinander…
Man könnte doch festhalten: Tunnel immer drunter, Layer nicht erforderlich Brücke immer drüber, Layer nicht erforderlich Fluss immer ebenerdig/Furt (wenn nicht in Tunnel/Röhre oder Brücke darüber)
Das sprachliche Problem ist einfach zu lösen: Punkt, Linie, Fläche = geometrische Kartenelemente Weg = reales Objekt Verwirrend finde ich die zwei Klassen “Strasse” einerseits und “Weg 1-5” andererseits. Was ist denn der qualitative Unterschied? Auf der Mailingliste wird “Weg” grad wild diskutiert. (uff - merke grad, dass das gar keine “zwei Klassen” sind, sondern beides unter "highway läuft. Mein Irrtum kommt daher, dass in JOSM zwischen “Strasse” und “Weg” unterschieden wird - und erst bei genauerer Analyse der generierten Schlüssel erkennt man, dass das dann doch wieder zusammengelegt wurde) Ich glaube, etwas mehr Struktur, etwas sorgfältigere Dokumentation, und eine zentrale Regel-Datenbank würden dem Projekt gut tun. Gruss, Markus PS: danke auch Mikrokosmonaut fürs Mitdenken.
Hi,
Zumindest ein Regelwerk sollte strukturiert sein. Ich hab nie gesagt das OSM hier keine erheblichen Schwächen hat
Kirche ist vor allem Gebäude und dafür ist eine Fläche vorgesehen. Wegen mir spricht nix dagegen die Kirchen-Optionen auch auf Flächen, bzw Buildings zuzulassen.
Da findest du wahrscheinlich am ehesten auf der Mailingliste jemanden. Für Mapnik schreibst du den Engländern, weiss aber grade nicht wer genau das ist. Soweit ich weiss sind die/ist der aber relativ resistent gegen Vorschläge aus D, aber wer weiss.
Soweit ich weiss gibt es keine Hierarchie für Kirchen, bzw. Unterscheidung in Kirche/Dom/sonstwas.
Wo siehst du den Mehrwert gegenüber dem Wiki und Tagwatch? Und wie willst dus pflegen? Automatisch? Dann kriegst du Tippfehler mit rein. Von Hand wäre wohl ein gewaltiger Aufwand.
Ich würd meine Sachen gern weiter von Hand eintragen. Und dabei passieren auch mal Tippfehler.
Du könntest im Forum oder auf der Mailingliste darüber reden, oder es einfach selber machen.
Es gibt einen Konsens bei vielen Sachen, an den sich viele halten.
MapFeatures?!
Und wenns ihm egal ist, dann pfeifft er drauf…
Ich kenn den Bahnhof in Zürich nicht, aber da gibts sicher verschiedene Ebenen auf denen alles Abläuft. Mit den Layern hast du von -5 bis 5 11 solcher Ebenen mit denen du arbeiten kannst. Das sollte auch - unbekannterweise - für Bahnhöfe in der Schweiz reichen, ich vermute dass auch dort die Gleise nicht kreuz und quer verlaufen und es keine plangleichen Kreuzungen von Schienen gibt.
Es gibt auch Brücken und Tunnels in mehreren Etagen übereinandern. Vielleicht sogar in Zurüch. Und Layer=1 hilft schonmal zu zeigen, dass es ganz normal ist und nicht, dass keine Information vorhanden ist. Vgl. maxspeed=100 auf ganz normalen Landstraßen.
Axo, daher kommts. Ich benutze die Presets nicht, daher ist mir das noch nie aufgefallen. Gruß zorque
@zorque: subscribe!! (mal wieder :D) Also gerade die Unterschiede zwischen Weg und Straße sind IMHO in den Features eigentlich hinreichend dokumentiert und das sogar mit Fotos. Georg
Zum Beispiel der Kirche: - Zunächst mal ist sie ein Gebäude, kann also gezeichnet und mit building=yes getagged werden. So wird es ja häufig mit auffälligen Gebäuden gemacht. - Dann ist sie zufällig auch noch ein POI, nämlich ein “place-of-worship”. Das kann dann natürlich zusätzlich eingezeichnet und als POI entsprechend getagged werden. Das ist zwar etwas inkonsistent wenn man es mal mit Parkplätzen vergleicht, die ja auch als Fläche ihr Parkplatzsymbol bekommen, letztere sind aber auch was größer und werden daher eher flächenmässig erfasst. Ein place-of-worship kann ja auch ne Winzkapelle, eine Mauer, ein Marterls an einem Pfad, etc sein, das man beim besten Willen nicht flächenmässig erfassen wollen wird. Deshalb macht es hier imho auch Sinn, die Fläche des Gebäudes vom POI (Kirche) zu trennen.
Aber warum den POI zusätzlich einzeichen? Kann nicht einfach der Mittelpunkt der Fläche für das Symbol benutzt werden? (Wie bei Parkplätzen halt auch) Die größe spielt da meiner Meinung nach keine Rolle. Wenn die Kirche so klein ist, dass man kein Gebäude einzeichnet, dann kann man ja ein POI machen. Genauso auch bei anderen Gebäuden. Viele Gebäude in Berlin haben ein extra POI, damit ein Symbol angezeigt wird. Das könnte man sich doch sparen. Außerdem wär es dann auch möglich z.B. Kirchengebäude anders zu rendern als Wohnhäuser. Daher brauchen meiner Meinung nach die Gebäude dringend auch die entsprechenden Tags.
Vorschlag: unspezifische Gebäude 1. Als **Fläche **gezeichnete unspezifische Gebäude werden mit {{Tag|building|yes}} ausgezeichnet und vom Renderer schattiert. besondere Gebäude 2. Als **Punkte **gezeichnete besondere Gebäude werden durch einen besonderen und eindeutigen Haupt-Schlüssel ausgezeichnet und bekommen vom Renderer ein besonderes Symbol. 3. Als **Fläche **gezeichnete besondere Gebäude werden durch einen besonderen und **eindeutigen Haupt-Schlüssel **ausgezeichnet und vom Renderer auffälliger schattiert und bekommen vom Renderer ein besonderes Symbol. 4. Alle Schlüssel, die explizit für Gebäude verwendet werden, werden automatisch als “building” gewertet und vom Renderer einfach oder besonders schattiert. (Kirche, Rathaus, Feuerwehr, Polizei, Krankenhaus, Gericht, Schule, Supermarkt, Museum, Hallenbad, …) Grundsatz 5. Gebäude werden entweder als Punkt **oder **als Fläche eingezeichnet. 6. Bei Flächen entscheidet der eindeutige Haupt-Schlüssel, ob die Fläche ein Gebäude (Kirche, Schulhaus, Bahnhof, Parkhaus), oder ein Bereich (Friedhof, Schulgelände, Bahnhofsgelände, Parkplatz) ist. 7. Bei gröberen Zoomstufen wird vom Renderer statt der Fläche nur das Symbol angezeigt, bei groben Zoomstufen nur noch besonders wichtige Objekte (Hauptbahnhof, Dom, Regierungssitz, …) Gruss, Markus
So fänd ichs sinnvoll! Danke Markus!
Zustimmung insbesondere zu Punkt 5. Was noch einiger Präzisierung bedarf, ist der „eindeutige Haupt-Schlüssel“. (was ist ein „Haupt-Schlüssel“ überhaupt?) Da kann ich mir nicht wirklich etwas darunter vorstellen.
Das heißt genau was? Derzeit würde ich z. B. (subjektiv!) ein einzelnes Universitätsgebäude mit building=yes, amenity=university taggen. Ein Universitätsgelände dagegen wäre amenity=university sowie name=bla etc., die einzelnen Gebäude dann noch building=yes. (Mit der Option, das amenity, den Namen etc. vielleicht später mal in eine Relation zu packen, die auch auf die Gebäude und die Fläche verweist.) Wie wäre deine Vorgehensweise in diesem Beispiel?
Hallo Tordanik, Bisher gibit es ja ca. ein Dutzend “Hauptschlüssel” mit so illustren Namen wie “manmade” oder “amenity”. Für mich sind das keine Schlüssel, sondern eher eine Art “Kategorien” aber selbst dann verstehe ich deren Sinn nicht wirklich. Unter eindeutiger Hauptschlüssel verstehe ich beispielsweise “Kirche”. Da weiss jeder was das ist. Und die Details (Name, Grösse, Religion, etc) werden dann in Unterschlüsseln angegeben. Dass eine Kirche ein Gebäude ist, ein öffentliches (wenn nicht ein Geheimorden dahinter steht), und sinnigerweise eine auffälligere Grundstücksfarbe bekommt als ein “normales Gebäude”, das ist irgendwie jedem klar. Weitere eindeutige Hauptschlüssel könnten sein: Schule, Krankenhaus, Bahnhof, Wald, Hafen, Flugplatz, etc. Es gäbe also viele solcher Hauptschlüssel. Und keiner bräuchte mehr überlegen, ob jetzt der Wald “manmade” oder “natur” oder “amenity” ist. Und wenn man wissen will, wie man **Wald **auszeichnet, dann sucht man nach “Wald” und findet alles was man in OSM damit machen kann. Und möglichst wenig hierarchisch-kategoriale Systeme. Also nicht “Bildungseinrichtung” und darunter Schule, Uni, Kiga - sondern einfach Schule, Uni und Kindergarten. Und wenn das Krankenhaus einen Heli-Landeplatz hat, dann heisst das nicht “Flugplatz ganz klein”, sondern einfach “Helikopterlandeplatz”. Ich finde, “Übliches” sollten die Renderer von selbst richtig darstellen (dass die Uni auf der Wiese steht und nicht umgekehrt), Layer braucht man nur für seltene Spezialfälle und nur in spezifischer Situation (wenn die Uni in einem Bunker ist und dieser unter der Wiese). Und auch “Relationen” finde ich eher kompliziert. Der Renderer soll beim Unigelände schauen, wieviele Gebäude es gibt, und den Uni-Namen nur einmal ausgeben, aber vielleicht die Mensa anschreiben und den Haupteingang. Mit “amenity” hat das alles sowieso nichts zu tun, höchstens wenn der Mensakoch wirklich gut kocht (aber auch da wäre {{Tag|Kochmützen|5}} geeigneter). Und dass ein Gebäude kein See ist und umgekehrt, ist doch auch klar, selbst wenn das Gebäude ein Grasdach hat oder das Dach undicht ist.
Die ganzen Schlüssel mal zentral zusammenfassen, vereinfachen, vereinheitlichen, klare Regeln definieren. alles in eine Datenbank packen. Dann allen erzählen, dass es jetzt eine zentrale Anlaufstelle gibt und man dort mit einfachen Stichwörtern alles findet was man braucht. Und später dann einen Bot lossschicken, wenigstens den gröbsten Wildwuchs zu korrigieren. - Also nicht Einzelfalllösungen, sondern bessere Struktur, Organisation, Information. Und jedes neue Objekt wird wieder mit einem sprechenden Namen als weiterer Hauptschlüssel aufgenommen. Gruss, Markus
Also in dem Punkt, dass es viele “unlogische” key´s gibt, gebe ich dir recht. Jedoch sollte man überlegen das vieles aus der englischen Übersetzung stammt und deshalb nicht immer eins zu eins auf die deutsche Sprache passt. OSM wurde nun mal nicht in Deutschland erfunden. Aus diesem Grund wird es wohl auch bei den englischen key´s und values bleiben. OSM ist international und welche Sprache als die englische eignet sich da besser? Die Schlüssel für jedes Land zu übersetzen wäre wohl des guten zuviel, wer soll das noch bearbeiten? Auch die Admin´s machen das ganze in ihrer Freizeit!! Und es gibt noch eine weitere Überlegung, stell dir mal die ganzen “Hauptschlüssel” vor die entstehen wenn man alle “Unterkategorien” weg lassen würde. Wer soll das noch überblicken? Wie gesagt das einiges neu, anders oder besser “einsortiert” werden könnte, ok. Aber alles andere halte ich für illusorisch. Georg
Wenn man mal in die Mailingliste schaut, wird man die Ansicht finden, dass es irgendwann zu lokalen Schlüsseln kommen wird, also in lokaler Sprache. Das hat dann aber wenig damit zu tun, dass bestimmte Leute kein Englisch können. Das ist für mich sowieso kein Grund. Erstens gehört das heute zur Allgemeinbildung, und zweitens muss man noch nicht einmal Englisch können, sondern nur ein paar Begriffe, die nun zufällig auf Englisch sind. Insofern könnte es meinetwegen auch auf arabisch sein, auch wenn´s anfangs anstrengend wäre. Nein, der Grund ist vielmehr, dass es bestimmte landestypische Dinge gibt, die entweder schlecht übersetzbar sind oder/und eine andere Bedeutung haben im Sinne der Gewichtung. Ich denke, dass man zumindest in der westlichen Welt beim Englisch bleiben sollte. Da bricht sich keiner einen ab, und die paar lokalen Spezialitäten werden dann halt hinzugefügt. Ist ja auch kein Problem, weil man ja normalerweise nur im eigenen Land taggt und andersrum niemand darüber stolpern dürfte (z.B. ein Japaner, der von Tokio aus einen See in Mecklenburg bearbeiten will). Wichtig ist an der Stelle, dass das lokale Rendering funktioniert, sprich, dass man deutsche, englische, chinesische, … Karten erstellen kann. Übrigens kann man mal einen Blick auf Japan werfen oder Indien. Da sind die Namen häufig in Landessprache und auf Englisch gerendert. Ob die dafür so ein lokales Template verwenden, weiß ich nicht, denn die Objekte, die ich hier in Deutschland mehrsprachig getaggt habe, erscheinen trotzdem nur auf Deutsch - zum Glück 
Gerendert wird halt der “name”-Tag. Der sollte immer in Landessprache sein. Andere (z.B. “name:de”, “name:en” oder “name:ru”) werden halt nicht gerendert. (Zumindest nicht von Osmarender oder Mapnik). Irgendwo hab ich auch schonmal “int_name” gesehen, für internationale Namen. Und “nat_name” für nationale Namen. Ich seh grad, das war Armenien. Dort wird transkribiert. Im “name”-Tag stehen dort beide Varianten, darum wird auch beides gerendert.
Wir sprechen grad von drei Ebenen: a) die Systematik der Objekte, ihrer Schlüssel und Eigenschaften b) ggf. landesspezifische Einführung besonderer Objekte und/oder besonderer Schlüssel c) die Verwendung von Englisch als Grund-Sprache und deren Übersetzung Ich sprach ausschliesslich von a) b) halte ich für problematisch. Wenn man grenzüberschreitende Karten will, müssen die Objektbeschreibungen konsistent sein. Auch wenn es in D keinen Urwald gibt, und im Urwald keine deutsche Autobahn. c) halte ich für selbstverständlich. Sowohl eine einheitliche Basissprache, als auch die Übersetzung der Schlüsselbegriffe. a) und c) lassen sich in einer Datenbank übersichtlich und einfach pflegen. Der von mir propagierte “eindeutige Schlüssel” ist bestimmt durch die Eigenschaften. Bei der “Autobahn” werden sie grad auf der Mailingliste diskutiert. Angenommen es kommt raus: kreuzungsfrei + fahrbahngetrennt + mehrspurig, dann ist alles was diese Eigenschaften aufweist eine “Autobahn” egal ob hier oder im Urwald. Und der Begriff “Autobahn” kann dann beliebig in alle Sprachen übersetzt werden, Hauptsache die Eigenschaften sind immer die gleichen. Gruss, Markus
Um Begriffsverwirrungen zu vermeiden: Die derzeitige Terminologie von OSM ist ja: [1] Schlüssel/Key ist der erste Teil des Tags (amenity in amenity=toilets). Wert/Value ist der zweite Teil des Tags (toilets in amenity=toilets). Tag ist ein Paar aus Schlüssel und Wert (amenity=toilets). Verwendest du „Schlüssel“ in diesem Sinn? Wenn nein, bitte ich um Klarstellung.
Und noch hierzu: Wenn wir schon landessprachlich taggen, wäre es dann nicht sinnvoller, die Begriffe in ihrer Bedeutung an die örtlichen Gegebenheiten anzupassen? Für Straßen also etwa einige Eigenschaften definieren, die für Renderer, Router und sonstige Software interessant sind (maxspeed, minspeed, Designation, so ziemlich alles unter access [2] …). Dann landesspezifische Straßentypen definieren, deren Set von Eigenschaften in idealerweise maschinen- und menschenlesbarer Form verfügbar ist, so dass wir hier etwas als „verkehrsberuhigter Bereich“ oder „Autobahn“ taggen können, und ein Programmierer/Renderregeldesigner/… trotzdem nur auf internationale Straßeneigenschaften zurückgreifen müsste. Wenn er etwa Fahrradrouting macht, findet die Software für de:Autobahn die Information bicycle=no. [1] http://wiki.openstreetmap.org/index.php/Data_Primitives [2] http://wiki.openstreetmap.org/index.php/Key:access
Hallo Frank, ja, das mit der Sprache hier ist nicht immer so eindeutige (sorry wenn ich manchmal auch nachlässig bin - ich bemühe mich um klare Ausdrucksweise). Objekt = Kurzform für “Objektklasse”, siehe “data primitives” Schlüssel = erster Teil des Eigenschaften-Paares “Schlüssel=Wert” auch Kurzform für “Eigenschaften-Paar” - präziser dafür wäre der Begriff “Eigenschaft” Haupt-Schlüssel = erster Teil des hierarchisch höchsten *sinnvollen *Eigenschaften-Paares “Schlüssel=Wert” einer Objektklasse. Beispiel: Autobahn, Wald, See (wie auch immer das dann in Englisch heisst) Baggersee ist zwar ein See, kann aber einfacher direkt beschrieben werden. Damit erspart man sich die Inkonsistenz von hierarchischen Systematisierungsversuchen.
Genau.
genau. Und wie Du sagst: es kommt auf die Eigenschaften an. Und bei definierten Objektklassen brauchen bestimmte Eigenschaften nicht immer händisch hinzugefügt werden: Autobahn:bicycle=no (Ausnahme: Autofreier Sonntag). Mit einem definieren Set von Eigenschaften kann der Programmierer dann gut arbeiten, beispielsweise Routing-Regeln aufstellen. Gruss, Markus
@ Markus: Ich hab jetzt noch nicht ganz verstanden, wie du es haben willst. Mein Vorschlag dazu wäre, den Hauptschlüssel unabhängig von den anderen Schlüsseln zu machen, ohne die Kategorien (wie amenity, highway oder man_made), und dann die Eigenschaften
Ja, so meine ich das. “Hauptschlüssel” ist datebanktechnisch eine Objektkategorie. Einzelne Objekte bekommen dann in dieser Kategorie einen Schlüssel und ein Set von Eigenschaften. Gruss, Markus