Dimitri Junker schrieb:
>> Vielleicht ist es garnicht so gut möglich eine allgemeine Methode zu
>> definieren, da es allgemein bei den Tags keine festgelegte Systematik
>> gibt, sondern eben alles so gemacht wird wie es gerade passt.
>
>
> Wenn man einerseits
> key:left=value
> und andererseits
>
Hallo,
>Wie soll ich das machen? Das Ganze basiert doch darauf.
ich meine daß Du Dich erstmal nicht darauf festlegst wo das right/left/both
stehen soll, also einfach irgendeine Form wählen mit dem Hinweis daß Du es
ggf noch anpaßt.
>Du meinst also genauso wie in meinem Proposal?
Klar, desha
Dimitri Junker schrieb:
>> Und wo steht das?
>
>
> Nirgendwo, aber es gibt Indizien. 1. Ist alles in OSM symetrisch es sei denn
> es ist speziell markiert. Jedem Mapper war bisher klar, daß wenn er
> cycleway=track setzt ein Router diese Info für beide oder für keine
> Richtung nutzen kann, es
Hallo,
>Und wo steht das?
Nirgendwo, aber es gibt Indizien. 1. Ist alles in OSM symetrisch es sei denn
es ist speziell markiert. Jedem Mapper war bisher klar, daß wenn er
cycleway=track setzt ein Router diese Info für beide oder für keine
Richtung nutzen kann, es also besser ist bei nur eins
Dimitri Junker schrieb:
> Hallo,
>
>
>> Mein Proposal hat doch überhaupt nichts mit Einbahnstraßen zu
>> tun.
>
>
> Bisher bedeutet AFAIK cycleway=track bei normalen Straßen, daß beidseitig
> ein Fahrradweg vorhanden ist, bei Einbahnstraßen, daß nur einer vorhanden
> ist, auf der rechten Sei
Hallo,
>Mein Proposal hat doch überhaupt nichts mit Einbahnstraßen zu
>tun.
Bisher bedeutet AFAIK cycleway=track bei normalen Straßen, daß beidseitig
ein Fahrradweg vorhanden ist, bei Einbahnstraßen, daß nur einer vorhanden
ist, auf der rechten Seite (links in GB,...).
Sind bei Einbahnstraße
Dimitri Junker schrieb:
> Hallo,
>
>
>> Würdest du also statt einfach footway=left lieber immer explizit
>> footway=left:track schreiben wollen?
>
>
> Entsprechend meines right/left Proposals würde ich die Keys/values
> seitenunabhängig lassen wie bisher und bei Bedarf, also wenn er nur
> ein
Hallo,
>Manchmal verstehe ich nicht, warum die Leute so komplitziert denken ;-)
ganz Deiner Meinung
>Guten Rutsch euch allen :-)
Auch von mir allen ein gutes neues Jahr.
Dimitri
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openst
Hallo,
>Würdest du also statt einfach footway=left lieber immer explizit
>footway=left:track schreiben wollen?
Entsprechend meines right/left Proposals würde ich die Keys/values
seitenunabhängig lassen wie bisher und bei Bedarf, also wenn er nur
einseitig vorkommt ein right oder left hinzufüg
der Workaround mit dem JOSM-lane-plugin wäre
- Weg auswählen.
- lane links hinzufügen
- lane rechts hinzufügen
- attribute setzen
- fertig
und damit hätten wir eine ziemlich genaue Darstellung der Realität im
Rahmen der möglichen Genauigkeit (>5m)
Dann könnte man jeder Spur Atrribute wie Breite,
Dimitri Junker schrieb:
> Hallo,
>
>
>> Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich
>> zu footway=right/left/both das auch Teil des Proposals ist
>
> cycleway=track/lane ist aber schon etabliert, deshalb würde ich versuchen
> dieses Schema auf footway auszuweiten st
Hallo,
>Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich
>zu footway=right/left/both das auch Teil des Proposals ist
cycleway=track/lane ist aber schon etabliert, deshalb würde ich versuchen
dieses Schema auf footway auszuweiten statt es ganz neu zu machen. Aber von
mir
Dimitri Junker schrieb:
>> Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg
>> liegt. Oder bemängelst du damit, dass man zusätzlich noch
>> cycleway.type=lane angeben muss?
>
>
> Bisher haben wir zum Key cycleway u.a. track und lane. Das von Dir
> vorgeschlagene right/left is
>Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg
>liegt. Oder bemängelst du damit, dass man zusätzlich noch
>cycleway.type=lane angeben muss?
Bisher haben wir zum Key cycleway u.a. track und lane. Das von Dir
vorgeschlagene right/left ist keine Alternative dazu sondern ein Z
Dimitri Junker schrieb:
> Hallo,
>
>
>> Leider scheinen sich dafür aber wenige zu interessieren.
>
>
> Mangelndes Interesse kann man mir ja nicht nachsagen, aber selbst bei mir
> ist Dein Vorschlag noch nicht angekommen. Gibt es eigentlich eine
> Mailingliste für Proposed_features, wo also ei
Hallo,
>Leider scheinen sich dafür aber wenige zu interessieren.
Mangelndes Interesse kann man mir ja nicht nachsagen, aber selbst bei mir
ist Dein Vorschlag noch nicht angekommen. Gibt es eigentlich eine
Mailingliste für Proposed_features, wo also eine Kurze Nachricht kommt:
neuer Vorschalg
Hallo,
>Sicher, nur diesen einfachen fall gibt es in der realität nur selten.
Also hier in Aachen besteht dieser einfache Fall fast ausschließlich.
>Das ist aber für dich kein problem; denn du hast ja bereits verkündet,
>dass dich die wirkliche kreuzungssituation nicht interessiert.
Der genau
Dimitri Junker writes:
> Auch für den Mapper ist es einfacher einzugeben: da ist ein Fahrradweg
> unmittelbar neben der Straße, also z.B. ein
> cycleway=track
> als einen 2. Weg zu zeichnen.
Sicher, nur diesen einfachen fall gibt es in der realität nur selten.
Das ist aber für dich kein proble
Dimitri Junker schrieb:
>> Und ich glaube es macht nicht wirklich Sinn hier einen Normalfall fest
>> zu legen.
>
>
> Doch, damit man weis welche zusätzlichen Tags/Relations man noch definieren
> muß. Derzeit haben wir das Problem, daß wir kein funktionierendes System
> haben, und solange die gr
Hallo,
>Genau daran glaube ich nicht. Niemand wird sowas Programmieren,
Laß das die Programmierer entscheiden.
>weil es schnell zu Inkonsistenzen führen wird.
Wieso? Gib mir ein Bsp wo das nicht klappen würde.
>Auch das Datenmodell muss einfach sein. Sonst akzeptieren es die
>Programmierer
Am Sonntag, 28. Dezember 2008 19:24 schrieb Dimitri Junker:
> >Ich kann Deine Argumente alle verstehen. Ich hoffe du verstehst meine
> >auch.
>
> 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 zert
>Ich kann Deine Argumente alle verstehen. Ich hoffe du verstehst meine
>auch.
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
Wie gesagt kann man anders lösen.
>und ein komplexes Tagging
Hallo,
>Wenn man nämlich zwecks querung (sic!) auf einmal mit den fußgängern
>gleichgeschaltet wird
bei cycleway=track dürfte das fast immer der Fall sein
>und womöglich gar nicht dorthin kommt, wo man hin will (z.b. nach links
>abbiegen)
dann setzt Du eine turn-restriction mit
no_left_turn
ex
Dimitri Junker writes:
> Und die oft genannten Verätze an einer Kreuzung sind auch nicht
> unbedingt so interessant.
Im gegenteil, diese dinge sind sehr interessant. Wenn man nämlich
zwecks querung (sic!) auf einmal mit den fußgängern gleichgeschaltet
wird und womöglich gar nicht dorthin kommt,
Am Sonntag, 28. Dezember 2008 12:59 schrieb Dimitri Junker:
> Hallo,
>
> Sag mir nur einen einzigen Vorteil. Irgendetwas das Software nicht
> automatisch genau so gut erstellen könnte.
Okay, es ist mal wieder Zeit meine Vorteile heraus zu kramen, aber ich möchte
eigentlich nicht das wir wieder e
Hallo,
Sag mir nur einen einzigen Vorteil. Irgendetwas das Software nicht
automatisch genau so gut erstellen könnte. Wenn der Fahrrad und/oder
Fußgängerweg parallel in geringem Abstand neben der Straße verläuft kann
Software einfach den Straßen-Weg parallel verschieben und erhält einen genau
s
Hallo Dimitri,
Am Samstag, 27. Dezember 2008 13:14 schrieb Dimitri Junker:
> >Wenn das so im Wiki steht, und wir uns einig sind das ein Bordstein
> >keine bauliche Trennung ist, was nach meiner Meinung nicht der Fall ist,
> >dann sollten wir das ändern!
Wir sind uns in diesem Punkt nicht einig. Au
27 matches
Mail list logo
