Kombination von Schlüsseln

Markus_B · 2008-07-27T14:07:24.000Z

Hallo Zorque,

zorque:

du versuchst viel zu strukturiert zu denken

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?

Erlaubt, bzw. verboten gibt es in dem Sinne nicht. Nur Tags die weit verbreitet sind und andere die jemand neu erfunden hat.

hm - aber es *gibt *doch “Regeln”? Und die könnte man doch auch in einer zentralen DB dokumentieren?

Imho soll die Software lernen auch Flächen als POI zu erkennen.

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”?!

Die Layer geben die relative Lage der Objekte an.

Das gibt im Bahnhof von Zürich bestimmt ein ziemliches Durcheinander…

ein bisschen doppelt, aber auch nicht falsch

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)

zorque:

Bei den Strassen und Wegen ist nicht klar, wann eine Linie ein Weg und wann eine Strasse ist und wieso das unterschieden wird.

??? Eine Linie ist eine Linie. Wenn die Linie einen Weg darstellen soll, kann man sie im übertragenen Sinne auch Weg nennen.

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.

zorque · 2008-07-27T15:08:26.000Z

Hi,

Markus B:

Na ja - es ist doch ein Prinzip von Regeln, dass sie strukturiert sind?!

Zumindest ein Regelwerk sollte strukturiert sein. Ich hab nie gesagt das OSM hier keine erheblichen Schwächen hat

Kirche ist aber eigentlich eine Fläche.

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.

Und wo informiere ich dann, dass es sinnvoll wäre ab Zoomlevel 13 das Symbol anzuzeigen und ab ZL 15 den Grundriss?

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.

Und wie ist das in Bamberg oder Rom, wo es mehr oder weniger wichtige Kirchen gibt?

Soweit ich weiss gibt es keine Hierarchie für Kirchen, bzw. Unterscheidung in Kirche/Dom/sonstwas.

Und wäre es nicht sinnvoll, alle Schlüssel in einer Datenbank zu sammeln?

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.

Damit Tippfehler durch händische Eingaben (wird grad bei Wegen in der Mailingliste diskutiert) vermieden werden?

Ich würd meine Sachen gern weiter von Hand eintragen. Und dabei passieren auch mal Tippfehler.

Und wem müsste man das wo sagen? Wer kann sowas umsetzen?

Du könntest im Forum oder auf der Mailingliste darüber reden, oder es einfach selber machen.

aber es *gibt *doch “Regeln”?

Es gibt einen Konsens bei vielen Sachen, an den sich viele halten.

Und die könnte man doch auch in einer zentralen DB dokumentieren?

MapFeatures?!

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”?!

Und wenns ihm egal ist, dann pfeifft er drauf…

Das gibt im Bahnhof von Zürich bestimmt ein ziemliches Durcheinander…

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.

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)

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.

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.

Axo, daher kommts. Ich benutze die Presets nicht, daher ist mir das noch nie aufgefallen. Gruß zorque

Hobby_Navigator · 2008-07-27T15:18:27.000Z

@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

Stefan_Rothe · 2008-07-28T22:11:58.000Z

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.

TEL0000 · 2008-07-28T22:33:51.000Z

Stefan Rothe:

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.

Markus_B · 2008-07-30T10:31:31.000Z

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

TEL0000 · 2008-07-30T13:05:18.000Z

So fänd ichs sinnvoll! Danke Markus!

Tordanik · 2008-07-30T13:37:17.000Z

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.

Bei Flächen entscheidet der eindeutige Haupt-Schlüssel, ob die Fläche ein Gebäude, oder ein Bereich ist.

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?

Markus_B · 2008-07-30T18:45:24.000Z

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.

Wie wäre deine Vorgehensweise in diesem Beispiel?

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

Hobby_Navigator · 2008-07-30T18:56:54.000Z

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

krza · 2008-07-30T21:36:38.000Z

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

TEL0000 · 2008-07-30T22:37:04.000Z

krza:

Ü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.

Markus_B · 2008-07-30T22:40:16.000Z

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

Tordanik · 2008-07-31T10:58:05.000Z

Markus B:

Der von mir propagierte “eindeutige Schlüssel” ist bestimmt durch die Eigenschaften.

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 der Begriff “Autobahn” kann dann beliebig in alle Sprachen übersetzt werden, Hauptsache die Eigenschaften sind immer die gleichen.

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

Markus_B · 2008-07-31T14:05:35.000Z

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.

der Begriff “Autobahn” kann dann beliebig in alle Sprachen übersetzt werden, Hauptsache die Eigenschaften sind immer die gleichen.

Genau.

wäre es nicht sinnvoller, die Begriffe in ihrer Bedeutung an die örtlichen Gegebenheiten anzupassen?

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

TEL0000 · 2008-07-31T15:59:44.000Z

@ 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

Markus_B · 2008-07-31T18:14:27.000Z

TEL0000:

Hauptschlüssel unabhängig von den anderen Schlüsseln: - River - name=Oder - width=50 - boat=yes

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

Hobby_Navigator · 2008-07-31T18:51:53.000Z

Einspruch euer Ehren eine Autobahn mit den bespielhaft genannten Eigenschaften

kreuzungsfrei + fahrbahngetrennt + mehrspurig, dann ist alles was diese Eigenschaften aufweist eine “Autobahn” egal ob hier oder im Urwald. …Hauptsache die Eigenschaften sind immer die gleichen.

ist eben nicht überall eine Autobahn, bzw. die Eigenschaften einer Autobahn unterscheiden sich doch sehr. Selbst in Europa ist nicht immer eine bauliche Trennung gegeben. Sogar in den USA dem Land der Highways gibt es teilweise auf diesen die Möglichkeit zu wenden und die andere Richtung zu befahren.

Autobahn:bicycle=no

Ich habe schon Eselsfuhrwerke auf der “Autobahn” gesehen. Nein nicht in Deutschland. Obwohl…

Auch wenn es in D keinen Urwald gibt

Wer sagt das denn? Schau mal nach unter Nationalpark Kellerwald, Bayerischer Wald, Urwald Sababurg u.u. Ja, diese Bereiche sehen etwas anders aus als der tropische Regenwald, aber sie sind für unsere Verhältnisse durchaus als Urwald zu bezeichnen, werden auch bewußt so bezeichnet und irgendwann in ein paar Jahrzehnten sehen sie auch wieder so aus wie vor tausenden von Jahren. Also, so ganz einfach kann man sich das “über einen Kamm scheren” dann doch nicht machen. Lieber sollte man versuchen etwa falsch einsortierte values richtig unterzubringen. Was spricht denn gegen die Verwendung der z.B. von TEL0000 genannten “Anhäufung” von Tags? Nur weil die Renderer derzeit noch nicht damit umgehen können? Ja, jetzt kommts wieder, … wir zeichnen nicht… Georg

Markus_B · 2008-07-31T21:22:22.000Z

Hallo Georg,

Hobby Navigator:

Was spricht denn gegen die Verwendung der “Anhäufung” von Tags?

Nichts - solange alles im Haufen Sinn macht, und solange alles was Sinn macht im Haufen ist. Und was “Sinn” macht - das muss m.E. erst gesucht und gefunden und dann durch Regeln beschrieben werden. Und diese Regeln müssen dann irgendwo zentral so gespeichert werden, dass sie von jedem der sucht schnell, verständlich und erschöpfend gefunden werden. Gruss, Markus PS: meine “Beispiele” waren nur “zur Anschauung” gedacht. Es liessen sich sicher stringentere finden.

Tordanik · 2008-07-31T21:46:35.000Z

Hobby Navigator:

Was spricht denn gegen die Verwendung der z.B. von TEL0000 genannten “Anhäufung” von Tags?

Nun: 1. Dass das nicht ins derzeitige Dateiformat passt und deshalb nur durch Developer, nicht durch Mapper angepasst werden kann. Man betrachte einen Ausschnitt aus einer .osm:

  <way id='10048964' timestamp='2008-04-02T10:49:40+01:00' user='Tordanik' visible='true'>     <nd ref='38450176' />     <nd ref='38450179' />     <tag k='created_by' v='JOSM' />     <tag k='noexit' v='yes' />     <tag k='highway' v='residential' />     <tag k='name' v='Rotkreuzstraße' />     <tag k='maxspeed' v='30' />   </way>

Wie leicht zu erkennen ist, enthält das jeweils sowohl einen '‘k’'ey als auch einen '‘v’'alue. Man könnte natürlich irgendetwas wie k=object_type v=River nehmen, um TEL0000s Vorschlag zu simulieren. k=River v=yes ginge auch. Damit würde aber immer noch die Möglichkeit des Zuordnens mehrerer „Hauptschlüssel“ zu einem Node/Way fehlen. (Mit Relationen bekäme man das schon heute hin, aber die finden ja sicher wieder alle zu kompliziert.) 2. Es ist anders als die „althergebrachte“ Methode, und es gibt in solchen Belangen immer eine gewisse Trägheit – vor allem (verständlicherweise), wenn keiner der Vorschlagenden sich bereit erklärt, auch die nötige Programmierarbeit zu erledigen. Ich denke, es wäre nicht sinnvoll, das separatistisch anders zu machen, da muss man schon etwas Überzeugungsarbeit leisten. Erst mal auf talk-de und dann international … das Forum hier hat kaum die nötige Reichweite. Prinzipielle Einwände sähe ich momentan nicht dagegen, zumindest die für meine Begriffe kaum aussagekräftigen amenity, natural, man-made, leisure etc. abzuschaffen und die Hierarchie damit abzuflachen.