> Message: 2 > Date: Mon, 23 Jan 2012 22:53:38 +0100 > From: Holger Sch?ner <[email protected]> > > Doch, mir ist zumindest ein Fall bei mir in der N?he, n?mlich die Kaarstra?e > in Urfahr, bekannt (http://osm.org/go/0JhNO8VTp--). Die hatte ich vor ein > paar Monaten (Stra?enbahn-)zweispurig gemappt; die Stra?e habe ich dann, > trotz (weitgehend) fehlender Trennung in zwei Ways, f?r jede Richtung einen, > zerlegt. "flaimo" hat die Stra?e wohl letztens wieder zu einem Way > zusammengefasst.
> @flaimo: Was sprach denn gegen die Zweiteilung der Kaarstra?e? In deinem > Changeset-Kommentar sprichst du von "unn?tige aufplittung Kaarstra?e wieder > auf einen highway zusammengef?hrt (richtungen sind nicht physisch > getrennt)". Zum einen ist diese in einem Teilst?ck an einer > Stra?enbahnhaltestelle zumindest durch einen Bordstein physisch getrennt, > zum anderen lassen sich durch die Richtungsfahrbahntrennung, finde ich, die > tats?chlichen Verh?ltnisse ganz gut abbilden. So lange man darauf achtet > (was ich dachte getan zu haben), dass die Abbiegerelationen richtig gesetzt > sind, ist das Routing auch nicht problematisch, und f?r die Fu?g?nger (f?r > deren Routing) waren glaube ich auch die relevanten Fu?g?nger-?berwege > eingetragen, oder? Und auch (nicht nur ;-) ) das Rendering hat nach meinem > Empfinden gut gepasst. > wenn wirklich in der mitte der straße eine bordsteinkante ist (was auf den linzer orthofotos nicht erkennbar ist), wäre es theoretisch richtig, wobei glaube ich, die richtlinie gilt, dass selbst bei kurzen blockierungen von der größe einer verkehrsinsel eigentlich noch keine trennung stattfinden sollte und man im falle eines falles drüberfahren könnte (zB bei umleitungen). ich vermute mal, dass hier bei jeder hausausfahrt und einmündenden straße diese blockade zusätzlich auch unterbrochen wird. wenn in der mitte gras wäre, wäre der fall klar. ich persönlich habe das eher als eine asphaltfläche eingestuft und demnach zusammengelegt (und in dem zuge die routenrelationen korrigiert, die durch die aufsplittung kaputt waren). weiters schaut es so aus als ob die schienen nicht genau in der mitte der asphaltfläche liegen sondern eine schiene genau in der mitte liegt und die zweite auf der fahrspur richtung umkehrschleife. auf der fahrspur richtung brücke ist anscheinend gar keine schiene. somit würde sich das auch mit nur einer eingezeichneten schienenspur auf dem highway nicht richtig abbilden lassen. das ganze areal rund um den hinsenkampplatz ist leider ein echter grenzfall insofern denke ich, dass die zeit und zukünftige applikationen die anforderungen an das mapping definieren werden und dementsprechend dann ja umgemappt werden kann. ev bauen sie ja auch die linie 2 unterirdisch, dann löst sich das problem an dieser stelle später von selber auf. die zwei fahrspuren für die bim sind auf jeden fall physisch voneinander getrennt. die straßenbahn kann nicht mal so schnell auf die andere spur "rüberhupfen". später, bei der umkehrschleife, geht eine der schienen genau in der mitte der straße. dort wurde diese auch auf die gleichen nodes gelegt. die bushaltestellen waren auch noch falsch, da die stops auf den tram schienen, statt dem highway waren. ich vertrete weiterhin die meinung, dass – sofern die informationen gewünscht sind – die zusammengehörigkeit zwischen straße und schiene (und ev gehsteigen) über eine relation gelöst werden sollte. einen wirklichen mehrwert dieser information konnte ich bis jetzt aber eh nicht finden (im gegensatz zu exakten crossings). die reindlstraße war ein ähnlicher fall. zwei highways und in der mitte nicht verbunden eine schiene. das hab ich, nach rückspache im IRC auf eine fahrbahn mit darüberliegender schiene umgeändert (hier ist wirklich nur eine schiene in der mitte der straße). > Aber auch im aktuellen Zustand finde ich das noch sinnvoller, als die > Stra?enbahn immer (oder immer bei Verlauf auf Stra?en) nur einspurig zu > taggen. Es gibt einfach Details, die sich damit nicht darstellen lassen, > gerade der Verlauf von Schienen, Fahrbahnen und Fu?g?nger?berwegen an > Kreuzungen, aber auch an Stra?enbahnhaltestellen. Und das mag (nur als ein > Beispiel) f?r Karten f?r Sehbehinderte recht wichtig sein. weitere anwendungsfälle sind offi-karten bzw fahrplanaushänge mit umgebungsplan. abgesehen davon ist das durchgängige mappen eines stils mit eigenständigen ways auch einfacher wartbar, weil man nicht auf abhängigkeiten rücksicht nehmen muss. > Message: 5 > Date: Tue, 24 Jan 2012 09:45:00 +0100 > From: "Andreas Uller" <[email protected]> > Zusammengefasst meine Meinung: Solange Stra?en nur als 1 Linie dargestellt > sind (und das ist dzt. Standard und mangels Alternativkonzept auch gut so), > sollten auch Stra?enbahnstrecken, die direkt auf der Fahrbahn fahren, auch > nur als 1 Linie (n?mlich als die selbe) dargestellt werden. weil du von der, meiner meinung nach, fälschlichen premisse ausgehst, dass der railway key genauso gehandhabt werden muss wie der highway key obwohl die zielgruppen komplett unterschiedliche anforderungen haben. die möglichkeit des spurtreuen mappings wird sogar explizit auf der wikiseite beschrieben: "When modeling multi-track parallel railway lines in close proximity they can either be modeled as a single way with tracks=*, or as a number of parallel ways." (http://wiki.openstreetmap.org/wiki/Railways#Railway_lines) > Message: 6 > Date: Tue, 24 Jan 2012 09:51:38 +0100 > From: "Stefan Schiffer" <[email protected]> > > Ich mache aktuell an der JKU mit Wirtschaftsinformatikstudenten ein Projekt > im Rahmen von Apps4Linz zur Visualisierung der Stra?enbahnen und Busse. Die > Studenten hatten ziemliche M?he, den eingleisigen Datenbestand der Linz AG > so aufzubereiten, dass sich die Stra?enbahnen bei den Umkehrschleifen und > anderen Stellen mit unterschiedlicher F?hrung der Fahrtrichtungen richtig > bewegen (siehe http://goo.gl/NEEhc - noch ein Prototyp; Feedback > willkommen). schaut super aus! wie verhält sich das system wenn eine diskrepanz zwischen eingezeichneter strecke und tatsächlicher strecke vorhanden ist? (weil zB eine neue streckenführung noch nicht nachgezogen wurde)? die umstellung auf das neue public transport schema ist nämlich schon über ein jahr her und da werden vermutlich nicht alle daten fehlerfrei sein, noch dazu wo ich das zu einer zeit gemappt habe wo es weder bing noch geoimage bilder gegeben hat. > Message: 8 > Date: Tue, 24 Jan 2012 10:28:57 +0100 > From: Boris Cornet <[email protected]> > > Das Datenbankmodell von OSM f?hrt nicht baulich getrennte Stra?en - > egal mit wie viel Spuren - als einen Strang. Es ist nicht logisch, > dass Schienen, die Teil der Fahrbahn sind, unabh?ngig davon > eingezeichnet werden sollten. Daher werden Schienen, die Teil der > Fahrbahn sind, eben als genau das, n?mlich TEIL DER FAHRBAHN > eingetragen, und die Zahl der Schienenpaare angegeben. wie man am beispiel der echtzeitanzeige der öffis in linz sieht besteht für applikationen aber die notwendigkeit von durchgängiger spurentreue. da macht es keinen sinn dogmatisch an einem theoretischen konzept festzuhalten, was sich vor zig jahren mal ausgedacht hat. besser ist es hier ein neues schema anzudenken und zu verwenden (wiederum stichwort "relationen"). wenn es nur um das visuelle geht, dann bietet die route_master-relation aus dem öffi-schema genug informationen um aus zwei linien links und rechts eine linie in der mitte zu zaubern. für autofahrer hat die info eigentlich keinen mehrwert ob schienen in der straße sind oder nicht, höchstens noch für radfahrer, aber da werten ja routingprogramme noch nicht mal die elementarsten dinge aus, geschweige denn schienen in einer straße. insofern hat natürlich die applikation die zuerst rauskommt und ihre anforderungen präsentiert einen vorteil. _______________________________________________ Talk-at mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-at
