DE:Any tags you like

From OpenStreetMap Wiki
Jump to navigation Jump to search
Any tags you like - Other languages

Fühlen Sie sich frei, neue Tags zu erfinden! Wenn Sie etwas markieren wollen, das nachprüfbar und in OpenStreetMap kartierbar ist, es aber kein bestehendes Tagging-Schema dafür gibt - dann können Sie neue Tags erfinden und verwenden. Sogar Tags, die heute populär sind, wurden irgendwann einmal zum ersten Mal verwendet, sehr oft ohne einen Proposal-Prozess zu durchlaufen.

Allerdings heißt es nicht "Sie können gerne bestehende Kennzeichnungsschemata ignorieren und Apotheken mit unicorn=parking_lot kennzeichnen". Es ist auch nicht in Ordnung, falsches Tagging für den Renderer zu verwenden. - missbrauchen Sie keine gut etablierten Tags, nur um ein bestimmtes Verhalten bei einem Datenkonsumenten zu erzwingen.

Hinweis: Viele Merkmale von allgemeinem Interesse befinden sich bereits auf Map Features und es wird empfohlen, die dort angegebenen Tagging zu verwenden. Andernfalls könnten andere Benutzer Ihre Beiträge so umwandeln, dass sie in dieses Schema passen.

Dokumentieren von Tags, die nicht in Map Features enthalten sind

Hauptartikel: Creating a page describing key or value

Sie sind der Good Practice gefolgt und haben das Wiki, Map Features, Proposed features, Rejected features, Proposed Relations und mailing lists' archives durchsucht und können immer noch kein Tag für das finden, was Sie abbilden möchten? Taginfo ist wahrscheinlich die nützlichste Sammlung von Tag-Vorschlägen. Sie listet die tatsächlich in der Datenbank verwendeten Tags auf und wie oft sie verwendet wurden. Es werden auch andere Tags aufgelistet, die in Kombination mit einem bestimmten Tag für ein einzelnes Objekt verwendet wurden.

Denken Sie daran, dass OpenStreetMap keine inhaltlichen Beschränkungen für Tags hat, die Knoten, Wegen oder Gebieten zugewiesen werden können. Du kannst beliebige Tags verwenden, aber bitte dokumentiere sie hier im OpenStreetMap-Wiki, auch wenn sie selbsterklärend sind.

Das Dokumentieren ermöglicht es anderen, Ihre Merkmale zu finden oder sogar Kartierungsfehler zu korrigieren, auf die sie in Ihrer Nähe stoßen.

Das Dokumentieren ist besonders nützlich, wenn später jemand ein Tagging für die Obermenge des Features vorschlägt, das Sie hinzugefügt haben. Dann können Ihre Erfahrungen und Merkmale in den Vorschlagsprozess einfließen und im äußersten Fall sogar in das neue Schema umgewandelt werden, wenn es angenommen wird.


Auswahl der zu verwendenden Tags Wenn Sie zum Beispiel alle Nester des gefährdeten Sibirisches Flughörnchen auf Wikipedia kartieren wollen, erstellen Sie einfach eine Seite endangered_nest=Siberian_flying_squirrel und dokumentieren auf diese Seite, wofür sie gedacht ist. Seien Sie nur darauf vorbereitet, dass jemand anderes später ein anderes und strukturierteres Schema für die Dokumentation anderer Aspekte des Lebens gefährdeter Arten vorschlagen könnte, eine Kennzeichnung, die es erlaubt, auch Funde von deren Kot zu dokumentieren - ein Fall, der dazu dient, Gebiete vor jeglicher Bebauung zu schützen - und Sie würden Ihre alten Einträge umwandeln.

Sie können z. B. die IOF Standards für die Klassifizierungsstandards von OL-Karten konsultieren, um zu sehen, ob diese hilfreich sind und ob Ihre neue Markierung mit den Bedürfnissen (dieser) Benutzer kompatibel sein könnte. Wahrscheinlich gibt es noch weitere ähnliche Dokumente.

Wann sollte man ein Proposal (Vorschlag) erstellen

Sie sollten ein Proposal für Ihr Feature erstellen, wenn:

  1. Ihr Feature von allgemeinem Interesse ist, oder
  2. Sie unsicher sind, wie Sie es modellieren sollen, oder
  3. Die zuletzt vorgeschlagene Form der Kennzeichnung abgelehnt wurde, oder
  4. Sie die Bedeutung eines bereits verwendeten Tags ändern wollen
  5. Sie möchten Feedback von anderen Kartierern einholen, auch von Leuten aus anderen Regionen.

(Beachten Sie, dass die Erstellung eines Vorschlags weder eine Voraussetzung dafür ist, dass Ihr Feature auf der Hauptkarte erscheint, noch ist ein erfolgreicher Vorschlagsprozess eine Garantie dafür, dass Ihr Feature auf die Hauptkarte kommt. Wenn Ihr Feature jedoch den Vorschlagsprozess durchlaufen hat und von einer Mehrheit akzeptiert wurde, werden natürlich viel mehr Leute darum bitten, dass das Feature auf der Hauptkarte angezeigt wird, wodurch sich die Chancen erhöhen, dass das Feature auf der Hauptkarte dargestellt wird).

Was nicht kartiert werden soll

Entitäten in der OpenStreetMap-Datenbank sollten sich auf eine geografische Eigenschaft oder ein Objekt mit geografischen Eigenschaften beziehen.

So ist es z.B. akzeptabel, den Standort einer WLAN-Hotspot-Basisstation hinzuzufügen, aber es ist unerwünscht, viele Knoten in der Umgebung mit den wahrgenommenen Signalpegeln zu markieren. Solche Informationen sollten besser in einem separaten Dienst gespeichert werden.

Bitte beachten Sie den auf der Seite Good Practice dokumentierten Konsens der Gemeinschaft bezüglich der Überprüfbarkeit. Kartieren Sie keine historischen, temporären oder hypothetischen Merkmale, meinungsbildende Daten wie Bewertungen oder Rechtsvorschriften.

Beachten Sie DE:Limitations on mapping private information.

Wie man neue Tags benennt

Dies ist ein Versuch, die bestehenden Konventionen zu dokumentieren, die von Leuten verwendet werden, die neue Tags erfinden, basierend auf aktuellen Map Features-Tags und aktuellen Vorschlägen. Korrekturen und zusätzliche Formen, die weit verbreitet sind, werden gerne akzeptiert!

Ein Tag ist ein von der Software festgelegtes (Schlüssel, Wert) Paar von Unicode-Zeichenfolgen, in Diskussionen oft als key=value (Schlüssel=Wert) notiert.

Je nachdem, ob das, was Sie wollen, in eine bereits definierte Kategorie passt, können Sie einen neuen Hauptschlüssel, einen neuen Wert für einen bestehenden Schlüssel, eine neue Eigenschaft, die eine oder mehrere Schlüssel/Wert-Kombinationen verändert, oder eine neue Methode der Verfeinerung definieren.

Wenn Sie im Zweifel sind, ob Sie etwas völlig Neues definieren oder eine bestehende Kombination mit neuen Eigenschaften oder Verfeinerungen verwenden sollen, bedenken Sie:

  • Neue Eigenschaften sollten etablierte Merkmale nicht in einer Weise verändern, die den Erwartungen des gesunden Menschenverstands widerspricht
  • Sofern es sich nicht um eine sehr spezifische Definition mit kulturellen und geografischen Grenzen handelt, die in einem anderen Land keinen Sinn ergeben würde, versuchen Sie, eine weltweite Sichtweise im Auge zu behalten (nicht europazentriert, nicht zentriert auf Großbritannien, nicht zentriert auf die USA, ...), um zu verhindern, dass daraus ein faules oder missverstandenes Attribut wird (siehe (en)Skunked tags).

Syntaktische Konventionen für neue Tags

Für die Zeichenketten, die für den key-Teil gewählt werden, gibt es einige konventionelle Formen:

  • Idealerweise ist ein key ein Wort, in Kleinbuchstaben, wenn möglich in britischem Englisch.
  • Wenn das nicht der Fall sein kann, sollte ein key ein Konzept sein, dessen Wörter durch Unterstriche getrennt sind. Dies vermeidet einige Leerzeichenprobleme und ist im Allgemeinen entstanden, weil die OSM-Leute auch dazu neigen, Programmierer zu sein und die Syntax mögen.
  • Einige komplexere Schlüssel sind aus mehreren Wörtern oder Konzepten getrennt durch Doppelpunkte aufgebaut. Diese sollten natürlich von links nach rechts lesbar sein; eine Handvoll Muster sind bereits weit verbreitet:
    1. Einfache Namespace-Präfixe, ähnlich wie in einigen Programmiersprachen. Bündelt lose zusammenhängende Informationen auf eine Weise, die nicht mit anderen OSM-Tags kollidiert. Ideal für Datenimporte aus anderen Quellen!
    2. Bündel von eng zusammenhängenden Informationen, die zusammen einen einzigen Sachverhalt ausdrücken, der aus mehreren Feldern besteht. Fast wie eine Eigenschaft. Hervorragend geeignet für Adressen und ungewöhnliche Benennungsmuster.
    3. Qualifikationen nach Sprachcode. Siehe DE:Names#Internationale Schreibweisen
      • name:en=*, name:cy=* - die englischen und walisischen Namen für ein Merkmal
      • note:ja=* - eine Notiz speziell auf Japanisch
    4. Relativ ungewöhnlich. Muster 2, aber in einer generativen Art und Weise, bei der sich die Unterteile auf andere definierte Schlüssel beziehen. Das ist fast Meta-Tagging. Fast.

Syntaktische Konventionen für neue Werte

Das Format und die Konventionen hängen davon ab, ob das Tag ein Merkmal oder eine Eigenschaft darstellt.

  • Ein Tag kann entweder ein separates Merkmale (wie highway) oder eine Eigenschaft eines Merkmals (wie width).
  • Eigenschaften können eine große Anzahl möglicher Werte haben oder numerisch sein (z.B. width=2).
    • Namen sind ein Beispiel für einen Eigenschaftswert (z.B. das Tag name=*), und diese Werte sind unstrukturiert und flexibel und enthalten häufig gemischte Groß- und Kleinschreibung, Leerzeichen und andere Sonderzeichen.
  • Merkmale nehmen oft Werte an, die die Kategorie des Kartenmerkmals weiter verfeinern (z. B. highway=motorway).
    • Für Merkmal-Tags folgt der Wert ähnlichen Formatierungskonventionen wie die für Schlüssel verwendeten:
    • Idealerweise ist der Wert eines Feature-Tags ein Wort, in Kleinbuchstaben, wenn möglich in britischem Englisch.
    • Wenn das nicht der Fall sein kann, sollte der Wert eines Merkmals-Tags ein Konzept sein, dessen Wörter Unterstriche getrennt sind.

Verfeinerung und Namensräume

In vielen Tagging-Schemata gibt es ein gängiges Muster der iterativen Verfeinerung, das den Vorteil hat, dass das Schema im Laufe der Zeit immer beschreibender werden kann und trotzdem rückwärtskompatibel bleibt:

office=government
government=emergency

Achten Sie auf conflicts with other tagging schemes, wenn Sie diesem Muster folgen. Die Verfeinerung kann auch mit Hilfe von Namensräumen erfolgen.

Zeichen

Die Datenbank akzeptiert alle Unicode-Zeichen (UTF-8) für Schlüssel und Werte. Es empfiehlt sich jedoch, für Schlüssel (z. B. highway) und Klassifizierungswerte (z. B. trunk_link) kleine ASCII-Zeichen, Unterstriche und Doppelpunkte zu verwenden. Es ist eine gute Idee, Zeichen zu vermeiden, die in verschiedenen Programmen für diese Zeichenketten Probleme verursachen können:

  • Leerzeichen: Sie sollten Unterstriche '_' anstelle von Leerzeichen verwenden, vermeiden Sie Leerzeichen am Anfang und Ende von Schlüsseln
  • <>&/+?#%'"\ Sonderzeichen in XML, HTML und/oder URLs oder für Anführungszeichen sollten vermieden werden
  • = Da es an vielen Stellen als Trennzeichen zwischen Tag-Schlüssel und Tag-Wert verwendet wird, sollte das Gleichheitszeichen vermieden werden.
  • Die Verwendung von Semikolons ist in der Diskussion.

Für Freiformwerte (z. B. für den Schlüssel name) können Sie jedes erdenkliche Zeichen verwenden. Vermeiden Sie Leerzeichen am Anfang und Ende der Werte.

Style Guide?

Sie können diese Seite als Style Guide betrachten, wenn Sie wollen, aber das ist sie wirklich nicht. Letztlich bleibt die Interpretation dem Benutzer überlassen, und das einzige Prinzip, das wirklich gilt, ist KISS-Prinzip auf Wikipedia ("Keep It Simple, Silly"), oder alternativ: "Tue das Einfachste, was möglich ist". Je sauberer und einfacher, desto besser, wenn Sie wollen, dass mehr Menschen Ihren Tag/Vorschlag annehmen.

Siehe auch

v · d · e
Allgemeine OSM-Regeln
Allgemeine Regeln
Ein Objekt, ein OSM-Element · Mappe nicht für den Renderer · Benutze nicht den name=* Tag um Dinge zu beschreiben · Daten sollten überprüfbar sein · Kartiere Dinge so wie sie in der Realität sind · Mappe keine historischen Ereignisse und ehemalige Objekte · Erfasse keine Vorschriften, die nicht durch Gegenstände vor Ort repräsentiert werden · Korrigiere Fehler · Erhalte die Chronik eines Elements · Don't mix the history · Lasse gerade Wege gerade · Kurven mit einer angemessenen Anzahl von Punkten einzeichnen · Mittele GPS-Tracks · Luftbilder vor dem Abzeichnen ausrichten · Nicht von veralteten Luftbildern abzeichnen · Markiere deine Schätzungen mit fixme · Lösche keine Attribute die du nicht verstehst · Relationen sind keine Kategorien · Eigene Attribute dokumentieren


Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=DE:Any_tags_you_like&oldid=2626404"