Re: [Talk-de] Bürgersteige und Eigenschaften
Hallo Astrid, Astrid Müller schrieb: > Bordsteine über den Schlüssel border zu taggen finde ich eine gute Idee und > besser als mit dem Tag Sloped_curb=yes. Somit ist der Schlüssel allgemeiner > gehalten und man hat die Möglichkeit einzelne Werte wie Höhe und Breite hinzu > zu fügen. Bisher wurden Bordsteinhöhen auch noch nicht getaggt? nein, aber ich habe auch schon erwogen dies mit einem Zollstock zu tun. Ist für vielerlei Dinge nützlich, z.B. Rollstühl-Navi oder Straßenreinigung. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Am 29. März 2009 12:28 schrieb "Astrid Müller" : > Hallo Martin, > >> oder für einen 25 cm hohen Bordstein: >> border=curb >> border:height=0,25 >> >> oder für eine Mauer >> border=wall >> border:width=0,5 >> border:height=5 > > Bordsteine über den Schlüssel border zu taggen finde ich eine gute Idee und > besser als mit dem Tag Sloped_curb=yes. Somit ist der Schlüssel allgemeiner > gehalten und man hat die Möglichkeit einzelne Werte wie Höhe und Breite hinzu > zu fügen. Danke. Weitere Kommentare zum Vorschlag Übergangs-/Border-relation (s.Post oben)? Ist sowas einfach auswertbar mit Routing-Programmen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Hallo Martin, > oder für einen 25 cm hohen Bordstein: > border=curb > border:height=0,25 > > oder für eine Mauer > border=wall > border:width=0,5 > border:height=5 Bordsteine über den Schlüssel border zu taggen finde ich eine gute Idee und besser als mit dem Tag Sloped_curb=yes. Somit ist der Schlüssel allgemeiner gehalten und man hat die Möglichkeit einzelne Werte wie Höhe und Breite hinzu zu fügen. Bisher wurden Bordsteinhöhen auch noch nicht getaggt? Grüße, Astrid -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Markus schrieb: > Hallo Tobias > > >> * der chaotischen Semantik von ":" >> * der daraus und aus der unklaren Reihenfolge resultierenden >> umständlichen Auswertbarkeit >> > > Wie könnte die Alternative aussehen? > > Gruss, Markus > Alternative Lane-Relation -> http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group eindeutige Syntax. eindeutige Zuordnung. Einfache Eingabe mit dem Lane-Tool für JOSM. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Sebastian Hohmann schrieb: > Sicherlich wird der Doppelpunkt auch schon für andere Dinge genutzt, die > nicht unbedingt mit diesem Schema übereinstimmen, aber in einem offenen > Projekt wie OSM kann man sich da sowieso nie sicher sein. Innerhalb der > footway/cycleway-Syntax wäre es dann immerhin einheitlich und könnte > automatisch ausgewertet werden. Ich bin mir immer noch nicht im klaren darüber, wie sich die Offenheit in OSM genau wiederspiegelt. a) jeder darf machen wie und was er will oder b) jeder darf mitmachen und etwas dazu beitragen Wenn "a" richtig wäre, dürfte ich "hauptstraße = yes" mappen, was in meinen Augen aber eher destruktiv wäre (ja, Frederik ... ich weiß!). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
André Reichelt schrieb: > Martin Koppenhoefer schrieb: >> Eine Alternative hat er ja schon benannt: separat mappen. > > Das ist aber eine schlechte Alternative. Ich war früher auh dieser > Meinung, aber bin jetzt eher auf der Seite der zusätzlichen > Straßen-Tags. Warum? Unser Datenmodell besteht aus Ways und diese haben > genau einen Anfangs- und einen Endpunkt. > > Die echte Welt besteht jedoch ausschließlich aus Flächen. Wie > beschreibst du beispielsweise, dass man jederzeit von dem Weg auf die > Straße kann. Relation um alle parallelen Wege, zwischen denen man sinnvoll wechseln kann? > Wie definierst du einen abgesenkten Bordstein? Wie machst du das mit Tags? Und vor allem, ohne den Weg zu unterteilen und zu einem "Schreckensobjekt" zu machen? Wenn man unbedingt jede einzelne Absenkung mappen will (und nicht oft genug welche kommen für die o.g. abstrahierende Relation und auch nicht nur an -- s.u. -- Übergängen), könnte man hier einen Mini-Way zwischen die Autospur und den Geh-/Radweg machen mit noch zu erfindendem Tag. > Wir machst > du dem Navi klar, dass man hier oder da die Straße überqueren kann? Wie macht man das jetzt? Üblicherweise mit einem "highway=crossing"-Node, oder? Mach das Tag an einen quer zur Straße verlaufenden und die passenden Spur-Ways verbindenden Crossing-Way statt einen Node und fertig ist die routerverständliche Verbindung. (Jetzt nur mal als Gedankenspiel, nicht unbedingt als konkreter Taggingtipp.) Man beachte, dass der Router dann sogar auf echten Ways arbeiten kann und sich nicht zusätzlich eine "fiktive" (nicht OSM-physisch vorhandene) linke und rechte Radspur anlegen braucht. Ich würde naiv für eine Navigationssoftware jedenfalls lieber mit direkt gemappten Spuren arbeiten. > Meiner Meinung geht das nicht, da ein Weg eben ein Weg ist und keinen > Bezug zu der parallel verlaufenden Straße hat. "Bezug" schreit m.E. nach "Relation". ;-) Siehe oben. > Die Straßen werden früher oder > später zu unüberschaubaren Schreckensobjekten, da ich immer nur zwischen > zwei Nodes Informationen eingeben kann aber nie "von Streckenkilometer x > bis y". Das ließe sich prinzipiell durch geeignete Tools lindern (Markieren von bis über bis o.ä. wäre nicht mal so schwierig). Ich habe auch den Eindruck, dass das eher bei einer Tag-basierten Lösung zum Problem wird. Wenn ich crossings, Bordsteinabsenkungen* u.ä. durch eigene Ways modelliere, brauche ich den eigentlichen Way ja grade nicht auftrennen. Tobias Knerr * ich will damit nicht behaupten, dass man die wirklich in naher Zukunft mappen muss... *g* ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
2009/3/27 André Reichelt : > Martin Koppenhoefer schrieb: >> Eine Alternative hat er ja schon benannt: separat mappen. > > Das ist aber eine schlechte Alternative. Ich war früher auh dieser > Meinung, aber bin jetzt eher auf der Seite der zusätzlichen > Straßen-Tags. Warum? Unser Datenmodell besteht aus Ways und diese haben > genau einen Anfangs- und einen Endpunkt. > > Die echte Welt besteht jedoch ausschließlich aus Flächen. Wie > beschreibst du beispielsweise, dass man jederzeit von dem Weg auf die > Straße kann. Wie definierst du einen abgesenkten Bordstein? Wir machst > du dem Navi klar, dass man hier oder da die Straße überqueren kann? abgesenkter Bordstein: way, also 2 Nodes. Solche linienhaften Übergänge wären für Spuren auch hilfreich, für Gehwege, etc. . Man könnte Sie als Relationen definieren, bräuchte aber wohl, um nicht den Überblick zu verlieren, entsprechende grafische Unterstützung. Die Relationen könnten so was sein wie type=transition und ein paar tags dazu, die den Übergang beschreiben: border=none für gleichmäßigen Übergang border=grass border:width=0,3 (=30cm) oder für einen 25 cm hohen Bordstein: border=curb border:height=0,25 oder für eine Mauer border=wall border:width=0,5 border:height=5 und dann 2 ways als member. Oder einen Schritt weiter: man erlaubt mehr als 2 ways aber gliedert die in 2 Gruppen, A=way_xx A=way_xy B=way_xz und für diese Ways gilt dann die oben in der Relation definierte Grenze (also zwischen A und B). Natürlich muss man da alle Nas' lang die ways aufteilen, woraus für das Bearbeiten etwas mehr Geduld erforderlich ist, aber so schlimm ist es ja auch nicht, wenn man bei einer Einbahnstraße mal mehrere Segmente hintereinander zusammenclicken muss, um die zu ändern. [[[randbemerkung]]] Vielleicht könnte man die Einbahnstraßen auch über Relationen lösen? Einfach Ways, Start- und Endnode bezeichnen, und die Richtung der Einbahnstraße ist unabhängig von der Richtung der ways. Problem ist halt, wenn diese Node gelöscht werden oder nicht mehr zu einem der ways gehören, eigentlich müsste man wohl an die Nodes ein Flag hängen, dass die Relation upgedated wird, falls der Node gelöscht wird. Mit API 0.6 könnten auch alle nodes plus die ways in die Relation rein, wobei die Nodes geordnet wären. Die ways braucht man vermutlich nämlich trotzdem, da man ja die Relation updaten muss, wenn nodes eingefügt oder gelöscht werden. [[[/randbemerkung]]] Eine andere Variante wäre, dass man nicht nur A und B als way angibt, sondern auch noch C: die Grenze selbst. So könnte man abgesenkte Bordsteine als Way zwischen A und B mappen, und müsste A und B nicht zerschneiden. In diesem Fall würde man die Tags zur Grenze nicht in die Relation packen sondern direkt an die jeweiligen ways. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Martin Koppenhoefer schrieb: > ja, und wenn sich die Richtung der Einbahnstraße bzw. die Richtung des > Ways aus einem anderen Grund ändert, erfordert es entweder hohe > Konzentration des Mappers, oder es wird falsch. Das automatische > "Tagumdrehen" dürfte auch nicht für jeden Fall so einfach umzusetzen > sein (neben left und right gibt es ja mittlerweile auch forward, > backward), das mit den Richtungen ist eine Sache, die sollte man > entweder nicht nutzen, oder sie ist fest in der API integriert, so > dass _alle_ editoren es automatisch nur richtig machen können, weil > sie sich gar nicht darum kümmern müssen. JOSM kann das schon seit einigen Monaten. Bei Merkaartor bin ich mir nicht sicher. Das ich Potlach für eine Beleidigung halte, habe ich hier schon zu genüge kund getan. Alle anderen Editoren haben einen solch geringen Nutzeranteil, dass man sich nicht zwingend darum kümmern muss. Da sollte man an die Autoren treten. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Martin Koppenhoefer schrieb: > Eine Alternative hat er ja schon benannt: separat mappen. Das ist aber eine schlechte Alternative. Ich war früher auh dieser Meinung, aber bin jetzt eher auf der Seite der zusätzlichen Straßen-Tags. Warum? Unser Datenmodell besteht aus Ways und diese haben genau einen Anfangs- und einen Endpunkt. Die echte Welt besteht jedoch ausschließlich aus Flächen. Wie beschreibst du beispielsweise, dass man jederzeit von dem Weg auf die Straße kann. Wie definierst du einen abgesenkten Bordstein? Wir machst du dem Navi klar, dass man hier oder da die Straße überqueren kann? Meiner Meinung geht das nicht, da ein Weg eben ein Weg ist und keinen Bezug zu der parallel verlaufenden Straße hat. Mir fielen da spontan nur zwei Lösungen neben der aktuell genannten ein: 1. Man ersetzt nach und nach alle Wege in der Datenbank durch Areas. Dies ergibt aber mit unseren Messmethoden wohl eher wenig sinn und bringt auch aktuell noch keine wirklichen Vorteile. Wenn man nicht gerade jedes Schlagloch einzeln erfassen möchte, wäre es doch stark übertrieben. 2. Man arbeitet mit Relations: Der Gehweg wird zu einem virtuellen Objekt und hangelt sich an Straßen entlang. Übergangsmöglichkeiten können als Ways oder Nodes definiert werden. Beide Methoden haben den Nachteil, und diesen schließen auch die anderen Beiden nicht aus, dass unser Datenvolumen unglaublich aufgebläht wird. Man braucht unmengen an weiteren Nodes. Die Straßen werden früher oder später zu unüberschaubaren Schreckensobjekten, da ich immer nur zwischen zwei Nodes Informationen eingeben kann aber nie "von Streckenkilometer x bis y". André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Am 27. März 2009 17:03 schrieb Sebastian Hohmann : > Astrid schrieb: >> Hallo, >> ich möchte gerne Bürgersteige taggen und ihnen Eigenschaften zuordnen. >> Für Bürgersteige habe ich das Proposal zu footway=both/left/right/none >> (http://wiki.openstreetmap.org/wiki/Proposed_features/Footway) gefunden. >> Auf der Seite "Germany roads >> tagging" (http://wiki.openstreetmap.org/wiki/DE:Germany_roads_tagging) >> wird dieser Tag ebenfalls für Bürgersteige empfohlen. >> Allerdings kann ich hiermit dem Bürgersteig noch keine Eigenschaften wie >> Breite und Oberflächenbeschaffenheit etc. zuweisen. >> >> Ein Vorschlag wäre z.B. footway:left=surface:cobblestone; >> footway:left=width:2; footway:right=surface:paving_stones >> >> Wie könnte ich das sonst machen? >> > > Zum Beispiel so [1]: > > footway:left.surface=paved > footway:right.surface=unpaved > > In dieser Syntax ist ':left' ein Parameter für 'footway' und '.surface' > ein Attribut für 'footway:left'. > > Ganz einfach gesagt: > * Der Wert von footway:left=* bezieht sich auf den *Fußweg* > * Der Wert von footway.surface=* bezieht sich auf die *Oberfläche* > > footway:left.surface=* ist einfach die Kombination aus beidem. Der Wert > bezieht sich also auf die Oberfläche des Fußwegs auf der linken Seite. > > Sicherlich wird der Doppelpunkt auch schon für andere Dinge genutzt, die > nicht unbedingt mit diesem Schema übereinstimmen, aber in einem offenen > Projekt wie OSM kann man sich da sowieso nie sicher sein. Innerhalb der > footway/cycleway-Syntax wäre es dann immerhin einheitlich und könnte > automatisch ausgewertet werden. > > Gruß ja, und wenn sich die Richtung der Einbahnstraße bzw. die Richtung des Ways aus einem anderen Grund ändert, erfordert es entweder hohe Konzentration des Mappers, oder es wird falsch. Das automatische "Tagumdrehen" dürfte auch nicht für jeden Fall so einfach umzusetzen sein (neben left und right gibt es ja mittlerweile auch forward, backward), das mit den Richtungen ist eine Sache, die sollte man entweder nicht nutzen, oder sie ist fest in der API integriert, so dass _alle_ editoren es automatisch nur richtig machen können, weil sie sich gar nicht darum kümmern müssen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Am 27. März 2009 16:54 schrieb Markus : > Hallo Tobias > >> * der chaotischen Semantik von ":" >> * der daraus und aus der unklaren Reihenfolge resultierenden >> umständlichen Auswertbarkeit > > Wie könnte die Alternative aussehen? > > Gruss, Markus > Eine Alternative hat er ja schon benannt: separat mappen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Astrid schrieb: > Hallo, > ich möchte gerne Bürgersteige taggen und ihnen Eigenschaften zuordnen. > Für Bürgersteige habe ich das Proposal zu footway=both/left/right/none > (http://wiki.openstreetmap.org/wiki/Proposed_features/Footway) gefunden. > Auf der Seite "Germany roads > tagging" (http://wiki.openstreetmap.org/wiki/DE:Germany_roads_tagging) > wird dieser Tag ebenfalls für Bürgersteige empfohlen. > Allerdings kann ich hiermit dem Bürgersteig noch keine Eigenschaften wie > Breite und Oberflächenbeschaffenheit etc. zuweisen. > > Ein Vorschlag wäre z.B. footway:left=surface:cobblestone; > footway:left=width:2; footway:right=surface:paving_stones > > Wie könnte ich das sonst machen? > Zum Beispiel so [1]: footway:left.surface=paved footway:right.surface=unpaved In dieser Syntax ist ':left' ein Parameter für 'footway' und '.surface' ein Attribut für 'footway:left'. Ganz einfach gesagt: * Der Wert von footway:left=* bezieht sich auf den *Fußweg* * Der Wert von footway.surface=* bezieht sich auf die *Oberfläche* footway:left.surface=* ist einfach die Kombination aus beidem. Der Wert bezieht sich also auf die Oberfläche des Fußwegs auf der linken Seite. Sicherlich wird der Doppelpunkt auch schon für andere Dinge genutzt, die nicht unbedingt mit diesem Schema übereinstimmen, aber in einem offenen Projekt wie OSM kann man sich da sowieso nie sicher sein. Innerhalb der footway/cycleway-Syntax wäre es dann immerhin einheitlich und könnte automatisch ausgewertet werden. Gruß [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_cycleway ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Hallo Tobias > * der chaotischen Semantik von ":" > * der daraus und aus der unklaren Reihenfolge resultierenden > umständlichen Auswertbarkeit Wie könnte die Alternative aussehen? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
On Fri, 27 Mar 2009 16:33:20 +0100, Tobias Knerr wrote: > Gerrit Lammert schrieb: >> "Logischer" fände ich es, das Schlüssel-Wert-System beizubehalten. Also >> in diesem fall: >> footway:left:surface=cobblestone > > Gefällt mir alles ganz und gar nicht. Das sind alles wirklich gute Punkte. Mein Hauptanliegen war jedoch, dass "surface" (und die anderen Schlüssel) links vom "=" stehen sollten. Über Reihenfolge und allgemeines Aufbauschema müsste man sich tatsächlich mal kümmern. Einzelne Tags haben allerdings den Nachteil, dass sie nicht immer eindeutig zuordnenbar sind: highway=residential footway=both width=2m Breite des Fußweges oder der Straße? Eine Lösung mag hier sein, alle Hierarchieebenen explizit hinzuschreiben, also statt: footway:left:surface=cobblestone dann footway=yes footway:left=yes footway:left:surface=cobblestone Aber das ist auch suboptimal :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Gerrit Lammert schrieb: > "Logischer" fände ich es, das Schlüssel-Wert-System beizubehalten. Also > in diesem fall: > footway:left:surface=cobblestone Handhabbarer als die Wert-Variante ist es definitiv, wenn auch nicht zwingend -- z.B. sagen wir ja nicht de:name, sondern name:de (mit dem "eigentlichen" Key am Anfang), so dass man auch surface:footway:left durchaus vertreten könnte. Allerdings ist das mal wieder eine der Stellen, wo man sich fragen muss, ob man nicht doch besser eigene Objekte dafür machen sollte, denn genau das simuliert man hier doch hier notdürftig: Ein footway-Objekt mit Zusatztags. Ich habe zwar in der Frage der bedingten Access-Tags [1] auch erst eine Doppelpunkt-Lösung für besser gehalten, aber so langsam bin ich mir da nicht mehr so sicher. Das liegt an verschiedenen Dingen, unter anderem * der chaotischen Semantik von ":", das alles mögliche heißen kann (a:b etwa "b im Namensraum a", "a, wenn b gilt", "das Attribut b des Objekts a", "das durch b identifizierte Exemplar der verschiedenen Objekte vom Typ b" und so weiter) * der daraus und aus der unklaren Reihenfolge resultierenden umständlichen Auswertbarkeit * der Inkompatibilität mit dem bisherigen Wiki-Dokumentationsschema, mit Tagwatch und vergleichbaren Anwendungen * der Länge der entstehenden Tags Gefällt mir alles ganz und gar nicht. Tobias Knerr [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Gerrit Lammert schrieb: > On Fri, 27 Mar 2009 15:07:19 +0100, Astrid wrote: >> Ein Vorschlag wäre z.B. footway:left=surface:cobblestone; >> footway:left=width:2; footway:right=surface:paving_stones > > "Logischer" fände ich es, das Schlüssel-Wert-System beizubehalten. Also > in diesem fall: > footway:left:surface=cobblestone > footway:left:width=2 > footway:right:surface=paving_stones +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
On Fri, 27 Mar 2009 15:07:19 +0100, Astrid wrote: > Ein Vorschlag wäre z.B. footway:left=surface:cobblestone; > footway:left=width:2; footway:right=surface:paving_stones "Logischer" fände ich es, das Schlüssel-Wert-System beizubehalten. Also in diesem fall: footway:left:surface=cobblestone footway:left:width=2 footway:right:surface=paving_stones Denn "surface" oder "width" ist ja nicht der Wert, sondern eine Becshreibung des Schlüssels. Anders sieht es aus bei natural=wood:oak Dieses wäre nur eine "Verkürzung" von natural=wood wood=oak Der Unterscheid ist, dass natural=wood auch für sich sinnhaftig ist, footway:left=surface jedoch nicht. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
