[Talk-at] Gehsteige (war: das 'new barrier types' proposal)

[adry]

Da sehe ich kein Problem.
Es müssten nur zusätzliche tags erschaffen werden. Dann steht halt bei 
dem entsprechenden Node z.B. sideway:barrier=bollard.
Dies mag zwar für Menschen schwerer lesbar sein, die Raw daten werden 
jedoch von Computern z.b. Renderer interpretiert und nicht von Menschen.

Für eine abgesenkte Gehteigkante genau so: sideway:kurb=no oder so etwas 
in der Art als Beispiel.

Man sieht, hier ist nur ein tag mehr dazu gekommen. Bei einer extra 
Linie wird wesentlich mehr Speicher verbraucht.

Man kann für so gut wie alles tags erschaffen und kein Programm wird 
Schwierigkeiten haben diese zu interpretieren, da sie ja genormt sind.

Noch ein Beispiel: Wenn mehrere Wege als parallele Linien gemapped sind, 
sieht das im Editor vl leichter verständlich aus für Menschen, aber ein 
Renderprogramm wird dabei verzweifeln.
Es müsste jedes mal überprüft werden ob eine parallele Linie existiert 
und wie breit diese ist, um ein überlappen beim gerenderten Bild zu 
verhindern. Das ist nur eins der vielen Probleme.


On 04.09.2011 18:32, Tobias Knerr wrote:
> Schon bei der Lage von Fuß- und Radweg zueinander hört es mit solchen
> Tags auf: Das kann man nur noch auf Grundlage seines Wissens über die
> lokalen Gepflogenheiten im Straßenbau entscheiden. Und wie trägst du ein
> Hindernis (z.B. Poller) ein, das sich nicht auf der Autofahrbahn,
> sondern auf dem Gehsteig befindet?
>
>> >  Nun eine Querungsstelle (ohne Querstraße):
>> >  - Im ersten Fall ein einzelner Knoten mit highway=crossing.
>> >  - Im zweiten Fall der eben erwähnte Knoten und zusätzlich ein neuer Weg.
> Und an dem neuen Weg kann man gleich noch nützliche Informationen wie
> einen nur einseitig abgesenkten Bordstein unterbringen, für die ein
> einziger Knoten weniger geeignet wäre.
>