On 04.05.2011 16:20, Peter Wendorff wrote:
Am 04.05.2011 15:45, schrieb Felix Hartmann:
und bei jeder Querstraße Ampeln sind, die die Geschwindigkeit
mindern (bzw fehlen uns halt Möglichkeiten, "Grüne Wellen" zu
taggen - im Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für
Fußgänger, Radler, usw, nicht machbar, da sich die
Geschwindigkeiten relativ viel stärker unterscheiden wie bei
Autofahrern).
Ein eigenständig gemapptes Trottoir enthält genauso viele
Querstraßen bzw. Ampeln (Crossing-Informationen) wie die Straße, die
das Subtag tragen würde - vorausgesetzt, das Subtag der Straße
enthält überhaupt die Seiten-Information, sonst gaukelt es ggf.
zuviele Querstraßen vor - nämlich die, die auf der anderen Seite
einseitig sind.
falsch, die Fallen rauß, es gibt ja Turn Restrictions. Die sind
leicht auszuwerten. Dazu fehlen alle Daten über die Straße selber
(was für eine Straße, speed limit der Straße, und und und).
Was haben jetzt Turn-Restrictions mit Fußgängerrouting zu tun?
Die Daten der Straße wären für die Einschätzung des Bürgersteigs
halbwegs sinnvoll, ja; aber nicht besonders dringend, solange nicht
gequert wird.
Das sehe ich anders. Ich finde diese Daten 10mal wichtiger wie kerb=yes
oder die relative Lage (absolut bringen wird dadurch ja meist eine
Verschlechterung der Genauigkeit)
Klar laufe ich lieber an einer Straße in der 30er-Zone entlang als an
einer Stadtautobahn bei Höchstgeschwindigkeit 70 - aber notwendig ist
diese Info nicht unbedingt.
finde ich schon.
Das Grüne-Welle-Problem ist eh grundsätzlich schon ein
Daten-Problem, aber ansonsten unabhängig vom Mapping-Stil.
Es wird hierdurch noch schlimmer. Weil ich anhand der Straßendaten
berechnen kann, wie es sich für einen Fahrradfahrer ausgeht (etwa
maxspeed=30, da schaffe ich es als sportlicher Radler easy im Verkehr
mitzuschwimmen, bzw sogar schneller zu sein.
Das kannst du auch weiterhin.
Ist der Fahrradweg getrennt, so fehlen mir hier die relevanten
Informationen über die Straße selber (und noch komplizierter, über
Relationen welche auf der Straße liegen).
Ist der Fahrradweg getrennt, so sollte er entsprechend auch eine
Höchstgeschwindigkeit tragen, wenn diese hier zur Anwendung kommt.
Abgesehen davon ist es auch weiterhin Sache der Routing-Konfiguration,
ob Straßen mit Höchstgeschwindigkeit <30 fürs Radrouting mit
berücksichtigt werden sollen oder nicht.
Die Informationen, die auf den Radweg zutreffen, sollen natürlich am
Radweg getagged werden. Ob das aber zutrifft oder nicht, ist damit
erstmals explizit tagbar, während bisher die Unterscheidung eben nicht
möglich ist, außer vielleicht über maxspeed:bicycle=*
Wenn Du aber über den Verlust von Informationen redest, dann bring ich
jetzt den Rennradfahrer, der den doofen gepflasterten Radweg nicht mag
und deshalb die Straße lieber ganz meidet, sobald der Radweg mit
StVO-Z 237, 240 oder 241 gekennzeichnet ist, weil er dann den Radweg
benutzen MUSS.
Grade als Rennradfahrer, ist es mir wichtig die Abhängigkeit von der
Straße möglichst exakt zu wissen. Aber in AT brauch ich am Rennradel eh
nicht den beschissenen Radweg am Randstein benutzen.
Die hier WICHTIGE Information über unterschiedliche Beläge von Radweg
und Fahrbahn gehen aber üblicherweise verloren (oder willst du jetzt
solche Tag-Monster wie sidewalk:left:surface..... aufbauen?).
wüsste nicht was an sidewalk:left:surface=blablabla auszusetzen ist,
genauso wenig wie an sidewalk:left:width=.... usw. Tagging Monster sind
es nur, solange die Editoren es nicht vernünftig unterstützen.
Das separate Mappen von Fahrradwegen am Trottoir, macht derzeit
genausoviel Sinn wie das separate mappen von Fahrspuren. Nächmlich
gar keinen Sinn. Uns fehlt hierfür ganz einfach ein vernünftiges
Datenmodell.
Dass das Datenmodell dafür nicht ideal ist, dem stimme ich zu.
Wann aber ändert sich ein Datenmodell?
Wenn der Bedarf da und der Druck groß genug ist.
Mir ist bisher kein sinnvolles Datenmodell eingefallen, das
mehrspurige Straßenprofile sowie Querungen unterstützen könnte, dabei
aber für den Mapper handhabbar bleibt.
Das Mapping imer wieder totzudiskutieren, weil kein Datenmodell genau
passt, ist aber der falsche Weg.
Das sehe ich anders, lieber gar nicht als falsch. Und genau der Weg wird
mit dem separaten Mapping gepushed. Es braucht einfach eine klare
Separation von visueller Gestaltung, und zugrundeliegenden Daten. Auch
das Datenmodell an sich, muss halt verbessert werden, aber wenn wir
dauernd lieber informationen halbrichtig eintragen, wird da kein Druck
entstehen, Editoren vernünftig aufzubauen, um Fahrspuren gut eintragbar
zu machen, ohne Informationen zu verlieren. Dazu kann man dann ja noch
separat rein für die Anzeige ein visual:highway:sidewalk:cycleway
einzeichnen, für jene die meinen das zu brauchen (Verdrängung - macht es
nicht grade einfach).
Vorschläge sind immer willkommen.
Wenn sie Änderungen an der OSM-Datenbank erfordern, dann ist das eben so.
Vernünftige Vorschläge sollten in Betracht gezogen und bei Bedarf
umgesetzt werden.
In diesem Sinne: immer her damit.
Gruß
Peter
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
