Sven S.
Messenger: sven...@yahoo.de
sven1971sommerk...@gizmo5.com
Voip: sip: 17472402163
Am Montag, 29. Dezember 2008 13:00:01 schrieb
talk-de-requ...@openstreetmap.org:
> Am Sonntag, 28. Dezember 2008 19:24 schrieb Dimitri Junker:
> > >Ich kann Deine Argumente alle verstehen. Ich hoffe du verstehst meine
> > >auch.
Dein Argument scheint zu sein, das es grafisch einfacher zu editieren ist?
> >
> > Ich verstehe Deine W?nsche, sehe aber nicht, da? daf?r ein eigener Weg
> > n?tig ist.
> >
> > >das Ergebnis ist, das du den Main-Highway in Tausend St?cke zerteilst
Ich denke, dafür gibt es Relationen?
> >
> > Wie gesagt kann man anders l?sen.
> >
> > >und ein komplexes Tagging erfinden musst
> >
> > Wenn das vern?nftig von JOSM & Co unterst?tzt wird ist mir das egal. Man
> > k?nnte z.B. eine Tastenkombination einf?hren bei der aus einem
> > Highway=residential mit 2 Fahrradwegen automatisch 3 Linien gezeichnet
> > werden, die kann man dann einzeln anklicken und Tags setzen. Dies wird
> > dann in die komplizierten Tags umgesetzt.
Wäre eine gute grafische Möglichkeit
>
> Genau daran glaube ich nicht. Niemand wird sowas Programmieren, weil es
> schnell zu Inkonsistenzen f?hren wird. Auch das Datenmodell muss einfach
> sein. Sonst akzeptieren es die Programmierer nicht, die enstcheiden, ob sie
> es in den Renderer und Editor aufnehmen.
>
> > Nein, aber egal wie Fahrradwege (neben einer Stra?e) getaggt werden
> > sollen, sollten B?rgersteige ?hnlich getaggt werden. Denn alle Argumente
> > f?r abgesetzte Fahrradwege gelten genau so f?r diese.
> >
> > >Das stimmt nicht. F?r Blinde ist es ein Mehrwert sich das ansehen zu
> > >k?nnen wie z.B. eine Kreuzung aufgebaut ist (aha ich muss also erst an
> > >der Telefonzelle vorebei ...)
> >
> > Interessant, mal abgesehen von dem unpassenden "ansehen" frage ich mich
> > wie der Blinde die Telefonzelle erkennt wenn nicht gerade jemand anruft.
>
> z.B. indem sie mit dem Blindenstock dagegen sto?en. Ich hab im Zivildienst
> mit Blinden gearbeitet. Blinde "sehen" anders, aber man sollte das nicht
> untersch?tzen. Und gerade Wegpunkte auf dem Gehweg sind sehr Hilfreich f?r
> Sie: Du solltest mal h?ren wie ein Blinder einen anderen Blinden den Weg
> beschreibt. Aber das ist eigentlich egal, wir Mappen ja nicht f?r (nur) f?r
> Blinde ;-)
Wie stellt ein GPS eigentlich einem Blinden etwas dar, so das es ihm hilft?
>
> > >Naja es gibt ja die GPS-Me?genauigkeit und dann meine
> > >Beobachtungsgenauigkeit und die sagt mir die Telefonzelle ist rechts vom
> > >Briefkasten obwohl die beiden 2 m von einander entfernt sind.
> >
> > Eben und das GPS sagt Dir wenig ?ber den Verlauf von Fahrradweg und
> > Stra?e, da hilft nur die Beobachtungsgenauigkeit: "Der Fahrradweg
> > verl?uft unmittelbar neben der Stra?e)" Aber diese Info kann ich in 1
> > Byte speichern, da macht es keinen Sinn bei einer langen krummen Stra?e
> > zig Nodes zu erfinden.
>
> In einem Byte wirst du das nicht speichern k?nnen. Ich glaube wir sollten
> unseren Entwurf f?r OSM auch nicht an Bytes und Plattenplatz orientieren
> sondern am Mapper und (aber erst an zweiter Stelle) am Karten-Nutzer
> (?blicherweise Software).
Naja, es ist wohl wieder die Frage was wir mit den Daten tun wollen..
Die Meisten sehen OSM nicht als Beschäftigungstherapie an, sondern haben einen
Gedanken, was man damit anfangen könnte.
Sehr viele wollen die Daten für Navis und Gedruckte Karten oder dergleichen
nutzen.
Und dafür muß man gewisse Dinge konsistent und effizient mappen.
Und vielen übrigen Anwendungen käme diese Arbeitsweise ebenso entgegen!
> F?r mich ist es wesentlich ?bersichtlicher einen
> Weg auch plastisch auf dem Bildschrim zu haben als mir irgendwas
> vorzustellen wie okay da kommt jetzt eine Busspur und ein Gr?nstreifen und
> den Briefkasten muss ich jetzt da hin setzen...
Es wurde schon vorgeschlagen den Editor so zu programmieren, das er das
graphisch besser darstellt.
>
> > >Gut wenn das Konsens ist, darfst du die h?lfte der Motorways wieder
> > >l?schen.
> >
> > Der Gr?nstreifen ist meist breiter als die GPS-Me?genauigkeit.
>
> Ja, die Leitplanke zwischen zwei Autobahnspuren auch.
>
> > Mit dem Argument k?nnten die Autofahrer dann auch sagen "wenn die
> > Fahradfahrer 2 Wege bekommen m?chten wir auch 2 haben". Wir h?tten dann
> > f?r jede Spur einen einzelnen Weg -> 2 Autospuren, 2 Fahrradspuren und 2
> > Fu?g?ngerwege statt eines.
>
> Ich denke darauf wird es wahrscheinlich auch irgendwann hinaus laufen. F?r
> gute Navi-Unterst?tzung braucht man sowas ja auch (bitte rechts einordnen).
Es gab und gibt meines Wissens ein Tagging welches festlegt wieviele Spuren
ein Weg hat.
Ist also auch dort nicht nötig Extrawege anzulegen.
>
> > Sollst Du, mich st?ren ja nur die wo es keinen Mehrwert liefert. Und
> > bisher funktionieren beide Methoden nicht, sei es weil laneabh?ngige Tags
> > fehlen oder weil Relationen o.?. fehlen die die Wege verbinden. Und bevor
> > man sich da was ?berlegt mu? man entscheiden was der Normalfall sein
> > soll, 1 Weg f?r alles oder einer pro Spur.
>
> Bei OSM wird IMHO nichts Entschieden, sondern ?berzeugt (Es gibt keine
> Entscheidung statt footway jetzt path zu benutzen, statt oneway=true lieber
> oneway=yes zu benutzen statt amenity=supermarket shop=supermarket zu
> benutzen etc.). Und ich glaube es macht nicht wirklich Sinn hier einen
> Normalfall fest zu legen.
Ich wünsche mir das erst überzeugt wird und dann eine Entscheidung daraus
wird.
Alles andere ist Chaos und das wollen wir wohl nicht?
>
>
> Wenn jemand ?berzeugende Argumente hat, wird ein Schuh draus. Aber nur zu
> sagen: Paralel verlaufende Radwege sollen nicht mehr gemappt werden ist f?r
> mich keine L?sung des Problems.
Es wurden schon einige Argumente geliefert, siehe die vorausgehenden Mails!
> Status Quo ist: wir haben highway=cycleway
> und den darf ich benutzen. Genauso status Quo ist: cycleway=track. Der ist
> f?r h?here Zommstufen genial, f?r kleinere manchmal eben nicht und kennt
> keine Stra?enseite, Breite etc.
>
>
> Gru?
> Sven
Gruß Sven S.
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
