Proposal: Detaillierteres Tagging für Pflastersteine

Hallo zusammen! Ich habe in den letzten Wochen über die Möglichkeiten nachgedacht, surface=paving_stones mit zusätzlichen Subtags zu versehen. Ergebnis ist dieses Proposal:

Paving stone details

Der Status quo ist ja, dass einige wenige Pflasterarten (Kopfsteinpflaster, Rasengittersteine) ein eigenes surface-Tag haben, alle anderen Varianten werden unter paving_stone zusammengefasst. Für viele Anwendungen reicht das, weshalb ich daran auch nichts ändern möchte. Über Subtags würde aber die Möglichkeit entstehen, anspruchsvolle Anwendungen (z.B. 3D-Rendering) mit Zusatzinformationen zu füttern.

Die bestehenden und stark umstrittenen surface-Werte “paving_stones:30” und “paving_stones:20” würde ich dabei gern zusammen mit ähnlichen Varianten aufs Altenteil schieben.

Ich bin sicher, ich spreche im Namen der Mehrheit der Forenteilnehmer, wenn ich sage: Wir sollten dringend darüber nachdenken, Pflastersteine als Flächen zu mappen!

Uneinigkeit besteht noch in der Frage, ob die Fugen zwischen den Pflastersteinen tatsächlich leer bleiben sollen (oder nach Bedarf natural=moss etc.), oder ob es zulässig ist, die Ränder von nebeneinanderliegenden Pflastersteinen zu “verkleben”.

Bye
Frederik

der war gut :laughing:

grüße von lutz

Ich persönlich bin ein Fan davon, die Pflastersteine als Multipolygone zu mappen. So können sich jeweils zwei Pflastersteine einen Way teilen. Außerdem lassen sich so auch Rasengittersteine modellieren! :wink:

Humor beiseite: Ich bin mir im Klaren, dass das Proposal den Mainstream-Mapper wenig tangiert. Wie immer gilt: Jeder mappt, was ihn interessiert, und mappt nicht, was ihn nicht interessiert.

Die Rolle eines solchen Proposals sehe ich deswegen auch darin, dass diejenigen Mapper, die sich für eine bestimmte Nische interessieren, sich auf eine gemeinsame Tagging-“Sprache” einigen können. Wen das Thema nicht interessiert, der kann es getrost ignorieren.

Interessiert mich wenig, aber finde das Anliegen gut. Hab mal was auf der Talk-seite hinterlassen.

Endlich kann ich meine Einfahrt detailliert mappen :smiley:
Ach und alle Gewege :laughing:

schon witzig, kann aber tatsächlich auch nutzen. Ich fahre mit Inline-Skates deutlich lieber auf Pflastersteinen, die die Fugen 45° zum Weg haben. Bei Fugen entlang des Weges, besonders bei den großen quadratischen Steinen, komme ich leicht mal mit den (90er-)Rollen in die Fuge, die erheblich größere Reibung hat mich schon ein paar mal fast aus dem Gleichgewicht gebracht.

Direction relativ zum Weg als alternative Möglichkeit zur absoluten Direction wäre meiner Meinung nach nicht schlecht.

Gibt es Bezüge zu surface=cobblestone? die sind ja in gewissem Sinne auch spezielle paving_stones, nur mit z.B. smoothness=bad.

hab kurz In meiner Bildersammlung gekramt und runde Pflastersteine und eine Art inverse Rasengittersteine (bei Feuerwehrzufahrten) gefunden, sowie Pflasterung mit abwechselnd quadratischen und rechteckigen Steinen in einer Reihe (ohne Bild) und etwas zwischen half_bond unf quarter_bond, wäre auch nicht ganz genau third_bond. vielleicht ja golden_ratio_bond. :wink: Aber man kann das wirklich tief ins Detail treiben…

Bilder:
http://i57.tinypic.com/23qyrfb.jpg (rund)
http://i62.tinypic.com/ib9h8k.jpg (bond?)
http://i58.tinypic.com/11i1eeb.jpg (Feuerwehr)
http://i61.tinypic.com/xnw481.jpg (unreines double t)

Ich finde auch, daß ein solcher Detailierungsgrad durchaus wichtig ist.

Wünschen würde ich es mit auch beim behauenen Natursteinpflaster. Gerade die Größe entscheidet, ob es angenehm zu laufen/ zu fahren ist (Mosaiksteinpflaster, Kleinsteinpflaster) oder ob es ein zu einer Qual werden kann (z.B. schlecht verlegtes oder ausgefahrenes Großsteinpflaster).
Auch das OSM- Wiki ist bei surface, was die Beispiel-Fotos nicht gerade hilfreich.

Sven… in dessen Heimatstadt alle drei Pflasterarten regelmäßig vorkommen.

+1

Ist cobblestone:flattened eigentlich das gleiche wie sett? (Bin ich letzte Woche drüber gestolpert).

Lol, hoffentlich nicht hingefallen :wink:

Gruss
walter

Vielleicht ein Wörtchen mehr dazu: In den Neunziger hatte ich mit einem Professor der Bundeswehr Uni in Hamburg über 3D Stadtmodelle diskutiert.
Er zeigte mir die 3D Simulatoren die für den Training verwendet wurden. Für solche Zwecke wurden schon damals fiktive Stadtmodelle gebaut. Sie hatten natürlich Texturen für Wege und sonstige Flächen. Die Beschreibung war so ähnlich wie Tordanik das vorgeschlagen hat.

Ich habe dieses Thema nicht anfangen wollen, um nich zusätzlich unter Beschuß der Traditionalisten zu kommen. Mit Straße als Fläche gibt es bereits genug Diskussionen.

Aus Distanz betrachtet durchleben wir bei OSM mit solchen Themen eine hochinteressante Phase: Eine “GIS” Karte wie OSM geht vorsichtig so weit ins Detail dass sie Themenbereiche abdecken kann die bisher für hoch detaillierte Umgebungsmodelle reserviert waren. Eine Annäherung von GIS, 3D Modelling und CAD ist nirgendwo so weit fortgeschritten wie bei OSM.
Dadurch werden wir zunehmend für “Randgruppen” interessant für die OSM bisher fremd war.

Dass die Traditionalisten dies nicht mögen, ist ja klar. Wir brauchen aber eine Zukunftsvision und dieses Thema gehört sicherlich dazu.

Grüße,
Marek

Nachdem es eine Erweiterung des bestehenden Mappingschemas ist, spricht aus meiner Sicht nichts dagegen.

Zum Glück ist OSM ein Freiwilligenprojekt. Wer will, soll. Wer nicht will, muss nicht.

PS: Ich muss jetzt mit dem GPS ausrücken und den “Sackerl fürs Gackerl”-Spender erfassen …

Danke für die zahlreichen Rückmeldungen. :slight_smile: Ich fasse mal meine Antworten zu den diversen Anregungen in einem Post zusammen.

Ja, es wäre gut, solches Subtagging auch bei anderen surface-Werten zu haben. Dabei würde man vermutlich Schlüssel wie cobblestone:width etc. verwenden? Muss ich mir überlegen, ob ich das vielleicht noch direkt im Proposal unterbringen kann.

Fällt dir da vielleicht ein guter Schlüsselname ein? Würde ich dann gern einbauen.

Mit dem *_bond wird es wahrscheinlich noch diverse andere Werte geben, ja. Aber das würde ich einfach der Community überlassen: Man schaut sich an, was öfters verwendet wird, und dokumentiert es dann.

Was die Muster angeht bin ich selber kein Experte. Ich habe halt ausgiebig im Netz recherchiert, was es so an gängigen Mustern gibt, die einen klaren englischen Namen haben. Da fehlt sicher noch einiges. Runde Steine, Kreismuster und der “europäische Fächer” wären z.B. so Kandidaten, die ich noch ergänzen könnte. Zumindest beim Kreismuster bräuchte man zum Rendern allerdings noch den Mittelpunkt…

Die Farbe des Pflasters könnte man auch erfassen.

Auch gibt es Mosaikpflaster z.B. https://commons.wikimedia.org/wiki/File:B%C3%A4ckerei_Lay.jpg in Freiburg im Breisgau.

Für die Farbe habe ich paving_stones:colour vorgesehen. Mehrfarbige Muster sind allerdings schwierig abzubilden, und Mosaike dürften den Rahmen von OSM sprengen. Außer wir nehmen Frederiks Vorschlag an. :wink:

+1

Ich bin auch der Meinung, dass der Detailierungsgrad bei der Oberfläche verbessert werden sollte. Danke Tordanik für Deine Arbeit.

Ich möchte noch die Erfassung des Materials und der Kantenform/Fase mit anregen.

Material:
Das Material bei paving_stones wird in der überwiegenden Mehrzahl der Fälle Beton sein. Es gibt aber auch viele Beispiele, bei den Keramik, Klinker, Holz und noch vieles anderes verlegt wurde und wird.
Wenn die Flächen mit einer Textur versehen werden sollen, ist das verwendete Material hilfreich.
Ich würde hierfür:

paving_stones:material

vorschlagen.

Kantenform/Fase:
Die verwendeten Steine haben eine unterschiedliche Fase. Je nach Ausbildung der Steine ohne Fase, mit kleiner oder großer Fase lassen sich die Belege unterschiedlich gut befahren. Bei großen Fasen ist der Rollwiederstand deutlich höhe und es besteht die Gefahr mit kleinen Rollen z.B. Inliner in den Kanten hägenzubleiben.
Ich würde hierfür:

paving_stones:phase

vorschlagen.

eher chamfer (oder bevel?)

spontanes Brainstorming: direction:relative fände ich nicht gut, da es ja keine Unterkategorie für direction ist.
rel_direction ist blöd wegen abkürzung, relative_direction sehr lang. paving_stones:angle wäre sehr allgemein und kann verwechselt werden.
yaw von der Lagebeschreibung https://de.wikipedia.org/wiki/Roll-Nick-Gier-Winkel bedeutet eher was komplett anderes.
Wie wärs mit paving_stones:rotation? Gefällt mir aber auch nicht ganz.

Edit:
noch einer, als ich ins Wiki der Dachformen geschaut habe:
→ paving_stones:orientation?
ist nicht ganz neu, da es auch als roof:orientation benutzt wird, als Richtungsangabe relativ zur langen Seite, along oder across.
Hier könnte es relativ zum Weg liegen, along oder across kann verwendet werden, Gradangaben (von der Wegrichtung aus im Uhrzeigersinn) sollten dann aber auch erlaubt sein along also 0° (oder 180°), across 90° (oder 270° oder -90°)