[Talk-de] Bürgersteige und Eigenschaften

Martin Koppenhoefer dieterdreist at gmail.com
Fr Mär 27 18:09:15 UTC 2009


2009/3/27 André Reichelt <andre-r at online.de>:
> 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




Mehr Informationen über die Mailingliste Talk-de