Proposal: Detaillierteres Tagging für Pflastersteine

Tordanik wrote:

Ich habe in den letzten Wochen über die Möglichkeiten nachgedacht, surface=paving_stones mit zusätzlichen Subtags zu versehen.

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 🤣

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! 😉

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.

Tordanik wrote:

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 😄
Ach und alle Gewege 🤣

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. 😉 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).

chris66 wrote:

Bin ich letzte Woche drüber gestolpert

Lol, hoffentlich nicht hingefallen 😉

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. 🙂 Ich fasse mal meine Antworten zu den diversen Anregungen in einem Post zusammen.

streckenkundler wrote:

Wünschen würde ich es mit auch beim behauenen Natursteinpflaster.

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.

jlcod wrote:

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

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

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

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 … ei_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. 😉

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

paving_stones:phase

eher chamfer (oder bevel?)

Tordanik wrote:

jlcod wrote:

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

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

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°)

OPerivar wrote:

paving_stones:phase

eher chamfer (oder bevel?)

Oh ja paving_stones:phase ist vollkommen falsch.

Ob aber jetzt chamfer oder bevel besser ist, kann ich als nicht englischer Muttersprachler schlecht entscheiden. Laut der verlinkten Beschreibung in der Wikipedia würde ich eher zu bevel tendieren. Aber keine Anhnung ob ich da richtig liege.

Gibt es Vorschläge oder Hinweise von Personen die besser die engliche Sprache beherschen als ich?

Eisenspleiszer wrote:

Gibt es Vorschläge oder Hinweise von Personen die besser die engliche Sprache beherschen als ich?

In solch einem Fall würde man auf Tagging nachfragen. Dort lesen genug britische Muttersprachler mit (Tags sollten in BE sein). Es kann jedoch passieren, dass dir drei Muttersprachler vier Meinungen präsentieren. 😄

Dumme Frage eines Anfängers: Was ist mit

würde man auf Tagging nachfragen

gemeint?

news.gmane.org/gmane.comp.gis.openstreetmap.tagging

@Eisenspleiszer: Die Erweiterung ums Material wäre einfach, das gibt es ja analog auch für Gebäude. Allerdings frage ich mich, wo die Grenze von surface=paving_stones liegt – fällt Holz oder Keramik noch darunter oder ist das dann z.B. surface=wood? Was meinen die anderen hier?

jlcod wrote:

-> paving_stones:orientation?

Klingt gut, das nehme ich. 🙂

Ne Kleinigkeit vielleicht noch: Im Proposal würde ich das hier mit paving_stones:orientation=across beschreiben (wenn der Weg in dem Fall nach oben ginge), analog zu den Dachformen. Lange Seite der Steine entlang dem Weg als along, kurze Seite entlang dem Weg als across. Standardmäßig also eher across, bei Flächen dann z.B. direction 0° absolut, da es keine Bezugslinie gibt.

Moin,

Tordanik wrote:

@Eisenspleiszer: Die Erweiterung ums Material wäre einfach, das gibt es ja analog auch für Gebäude. Allerdings frage ich mich, wo die Grenze von surface=paving_stones liegt – fällt Holz oder Keramik noch darunter oder ist das dann z.B. surface=wood? Was meinen die anderen hier?

Euch geht es ja teilweise eher intentiös um die Pflasterung und deren Eigenheiten - nur, dann müsste man eher einen neuen Oberbegriff einführen, der dann aber auch paving_stones, cobblestone, sett u. a. umfassen müsste. Aber ob dass noch was wird ... halte ich für aussichtslos.
Auch wird in surface an sich ja auch schon (wiedermal) Material, Ausformung, (Korn-)Größe in einem Wert erfasst - sicherlich aus vormalig praktischen Gründen, aber eben einer Systematisierung in getrennten tags abträglich.

Ich finde, bei dem Begriff paving_stones ist das (Grund-)Material - auch gemäß Wiki - bereits vorgegeben: Stein in regelmäßiger Form mit glatter, ebener Oberfläche und Kanten, ggf. noch Platten mit unregelmäßiger Kante.
Edit: Keramik ist ja auch Steinzeug, Kunststein fällt m. E. auch noch unter Stein.

Holz hat ja schon seinen eigenen surface-Begriff, da macht es keinen Sinn das hier mit unterbringen zu wollen - wonach soll der Mapper dann entscheiden, was er nehmen sol?
(Hochofen-)Schlacke gibt es wohl auch in regelmäßiger Pflasterung - aber ob das hier passt ... m. E. eher nicht.

Zur orientation:
Wie erfasst man dann quadratische Formen oder schräge Verlegung - wohl auch durch °?

Gruß
Georg
(der allerdings wohl niemals diesen Detailgrad erfassen wird ...)

Naja, man könnte die Tags auch statt paving_stones:* einfach paving:* nennen und für verschiedene surfaces zulassen. Dann kann man auch surface=wood mit Informationen über die Pflasterung ausstatten, wenn's eine gibt, und wenn nicht, lässt man's eben weg.

errt wrote:

Naja, man könnte die Tags auch statt paving_stones:* einfach paving:* nennen und für verschiedene surfaces zulassen. Dann kann man auch surface=wood mit Informationen über die Pflasterung ausstatten, wenn's eine gibt, und wenn nicht, lässt man's eben weg.

Oder eben paved:... als allgemeinste Variante.
Hab ernsthaft auch schon Muster ohne Pflastersteine gesehen, die (Zier-)Fugen wurden dann mit einer Art Schablone auf den noch weichen Beton gedrückt.

GeorgFausB wrote:

Wie erfasst man dann quadratische Formen oder schräge Verlegung - wohl auch durch °?

bei quadratischen Formen bedeutet ja in der Praxis across das selbe wie along und 0° das selbe wie 90°. schräge Verlegung wäre dann z.B. 45°+n*90° mit n Element von Z. 😉

Tordanik wrote:

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! 😉

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.

Wenn sich dadurch der Download deutlich verlängert, interessiert das schon. 🙁

Ich gewinne den Eindruck, dass die Erweiterung des Proposal für paving_stones auf sett und cobblestone sinnvoll ist.

Der Ansatz von Tordanik für paving_stones mit
* paving_stones:width
* paving_stones:length
* paving_stones:shape
* paving_stones:pattern
* paving_stones:colour
* paving_stones:direction
* paving_stones:orientation
* paving_stones:material
* paving_stones:chamfer/bevel

lässt sich sehr gut auf sett übertragen. Er würde dann lauten.
* sett:width
* sett:length
* sett:shape
* sett:pattern
* sett:colour
* sett:direction
* sett:orientation
* sett:material

Ebensogut passt es auch für cobblestone
* cobblestone:width
* cobblestone:length
* cobblestone:shape
* cobblestone:pattern
* cobblestone:colour
* cobblestone:direction
* cobblestone:orientation
* cobblestone:material

Wie Chris66 ist mir die Verwendung von cobblestone:flattened nicht so recht klar. Ich sehe auch keinen so richtigen Anwendungsbereich.

Nachdem ich in den letzten Tagen intensiver mit dem Wikiseite DE:Key:surface auseinander gesetzt habe, bin ich zu der Ansicht gekommen, das die Punkte cobblestone und sett konkreter formuliert werden sollten.

Farbe sollte meiner Meinung nach surface:colour sein. Die Farbe ist ja nicht nur auf paving_stones beschränkt (sondern auch auf asphalt, Holz anwendbar). Außer man möchte den Fugen wirklich noch eine andere Farbe zuweisen.

Sorry dafür dass es hier eine Weile nicht weitergegangen ist, ich war eine Woche krank und dann auf Dienstreise, darum konnte ich nur sporadisch ins Forum schauen. Ich werde aber mit der Abstimmung noch warten, damit wir vorher alle offenen Fragen klären können.

jlcod wrote:

Im Proposal würde ich das hier mit paving_stones:orientation=across beschreiben (wenn der Weg in dem Fall nach oben ginge), analog zu den Dachformen. Lange Seite der Steine entlang dem Weg als along, kurze Seite entlang dem Weg als across. Standardmäßig also eher across, bei Flächen dann z.B. direction 0° absolut, da es keine Bezugslinie gibt.

Hm, das Thema kam auch auf der Wiki-Diskussionsseite schon auf, die "Richtung" eines Musters scheint also nicht selbsterklärend zu sein. Das Beispiel im Bild ist für mich nämlich längs zum Weg, d.h. along. Generell habe ich die Bilder zu den Mustern immer so gedreht, dass die Richtung nach oben geht. Die Logik über die lange bzw. kurze Seite hat aber auch was...

Gibt es hier oder zu den anderen offenen Themen vielleicht weitere Meinungen?