Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am 29. Juni 2009 14:54 schrieb Heiko Jacobs : > Du vergisst bei dem Thema ständig, dass die cycleway=*-Variante > eine derzeit zulässige Variante ist, auch wenn Dir diese Variante > nicht gefällt. Solange sie zulässig ist, sollte alles getan werden, > die Unterstützung durch Router zu verbessern. Zulässig ist alles, was nicht schadet, diese Grenze hast Du hier überschritten. Das "übersiehst" Du. Ich habe natürlich überhaupt nichts dagegen, das Routing zu verbessern, aber bitte nicht dadurch, dass der Leidensdruck durch Zerstören funktionierender Lösungen erhöht wird. >>> Entweder brauchen wir völlig neue Renderer, ansonsten können >>> wir vernünftiges Radwegerendering vergessen (in beiden Modellen, >>> einseitige im einen Modell, nichtüberlappend im anderen Modell) >> >> solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm > > ... was eine ziemlich radfahrzentrierte Sichtweise ist. wenn Du Dir den Post ansiehst, ging es mir um Radfahrerkarten. Bei den anderen Karten liegt der cycleway AFAIR immer unten. >> und bin mir nicht sicher, ob eine verschobene Geometrie in allen >> Fällen "vernünftiger" wäre. Schon eher sicher bin ich mir, dass ich in >> einem Radwege-rendering eher die Straße verschieben würde als den >> Radweg. > > Auch das ist ein eziemlich radfahrzentrierte Sicht, ja, ist doch berechtigt, wenn wir von Fahrradkarten sprechen, oder? > die schon dann nicht mehr funktioniert, wenn beiderseits Radwege existieren... kommt auf die Straßenbreite und die Zoomstufe an. In niedrigen Zoomstufen könnte auch die Mittellinie beider Radwege interpoliert werden und von dieser aus jeweils ein Offset nach aussen (geht ja aber sowieso derzeit nicht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Martin Koppenhoefer schrieb: > Am 26. Juni 2009 17:15 schrieb Heiko Jacobs : >> Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu >> anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch >> spontanes zurücktaggen nicht verbauen ;-) > > m.E. sollte man solche autodidaktischen Versuche offline machen, und > nicht in den Daten aller löschen, mal sehen was passiert, und wenn > sich einige Gegenstimmen mit berechtigten Argumenten melden, > weilterhin Beharrungsvermögen zeigen. Du vergisst bei dem Thema ständig, dass die cycleway=*-Variante eine derzeit zulässige Variante ist, auch wenn Dir diese Variante nicht gefällt. Solange sie zulässig ist, sollte alles getan werden, die Unterstützung durch Router zu verbessern. >> Entweder brauchen wir völlig neue Renderer, ansonsten können >> wir vernünftiges Radwegerendering vergessen (in beiden Modellen, >> einseitige im einen Modell, nichtüberlappend im anderen Modell) > > solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm ... was eine ziemlich radfahrzentrierte Sichtweise ist. Ein Autofahrer dürfte sich durch eine solche Darstellung ziemlich gestört fühlen... Für die opencyclemap ist das Problem so meinetwegen gelöst, aber für die halbwegs an alle gerichtete slippy map geht das so nicht. So wie bisher ist es aber auch nicht optimal... > und bin mir nicht sicher, ob eine verschobene Geometrie in allen > Fällen "vernünftiger" wäre. Schon eher sicher bin ich mir, dass ich in > einem Radwege-rendering eher die Straße verschieben würde als den > Radweg. Auch das ist ein eziemlich radfahrzentrierte Sicht, die schon dann nicht mehr funktioniert, wenn beiderseits Radwege existieren... Deswegen verdrängt man normalerweise von der Mitte her. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin, > > Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu > > anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch > > spontanes zurücktaggen nicht verbauen ;-) > > m.E. sollte man solche autodidaktischen Versuche offline machen, und > nicht in den Daten aller löschen, mal sehen was passiert, und wenn > sich einige Gegenstimmen mit berechtigten Argumenten melden, > weilterhin Beharrungsvermögen zeigen. sein Posting hat mich sehr verärgert. Da wurde eine Menge Text in die Mailingliste eingestellt, ohne dass es zu einer Verbesserung des Zustandes gekommen wäre. @Heiko: Könntest Du die Änderungen rückgängig machen? Ich möchte ungern selbst tätig werden müssen. Deine Routerhärtetests kannst Du auch mit einer privaten OSM-Datei ganz hervorragend durchführen, bzw. Dir andere Ecken suchen, in denen cycleway=track vergeben ist. Auf jeden Fall braucht es dazu keine Brücke, und schon gar nicht muss es die Karlsruher Rheinbrücke sein. [...] > > könnte man per Relation gleich die ganze Brücke erfassen anstatt > > dass wie heute 4 separate Brücken gezeichnet werden > > (den Nachteil des Separat-Modells habe ich ja ganz vergessen ;-) ) > > ja, die Information, dass es sich um eine Brücke handelt, und nicht um > 4 parallele ist sicher wichtig und sollte auch in Zukunft mal > irgendwann abgebildet sein (z.B. durch eine zusammenfassende > Relation). Das Abbilden von Brücken ist generell schwierig (von einfachen Bauwerken mal abgesehen). Das ist aber kein Argument dafür, den Radweg an die Straße 'drankleben zu wollen. Denn es ist auch dort schwierig, wo es um Straße und Gleise u.ä. geht. highway=tertiary, railway=track? Wohl kaum. Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am 26. Juni 2009 17:15 schrieb Heiko Jacobs : > Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu > anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch > spontanes zurücktaggen nicht verbauen ;-) m.E. sollte man solche autodidaktischen Versuche offline machen, und nicht in den Daten aller löschen, mal sehen was passiert, und wenn sich einige Gegenstimmen mit berechtigten Argumenten melden, weilterhin Beharrungsvermögen zeigen. > dann näher spezifiziert z.B. für die halbe Rheinbrücke > (andere Hälfte negativ, 0 als Mite): > > 0.segregrator=crash_barrier > 1.landuse=green > 1.width=0.5 > 2.lane=trunk > 2.width=3 > 3.segregrator=dashed_line > 4.lane=trunk > 4.width=3 > 5.segregrator=dashed_line > 6.lane=trunk > 6.width=3 > 2-6.surface=asphalt > 7.segregrator=curb > 7.segregrator=crash_barrier > 8.lane=cycleway > 8.foot=no > 8.width=1.5 > 9.segregator=solid_line > 10.lane=footway > 10.bicycle=no > 10.width=1.5 > 11.segregrator=handrail > 12.water=deep ;-) ich finde man sieht an diesem Beispiel schon, dass das nur schwer funktionieren kann: viel zu unübersichtlich, schreckt die meisten schon beim Anblick ab und spielt die Stärken unserer _Geo_-datenbank (grafische Eingabe und Darstellung im Editor) nicht aus. Oder man macht alles als separaten way: > - Das Grün in der Mitte als area, die Leitplanke darauf als line > - jede Fahrspur einzeln, wie die gestrichelte Linie dazwischen > - Leitplanke zwischen Radweg und Fahrbahn > - Radweg > - Gehweg > - ... > > ... und packt alles in eine Relation Straßenraum zusammen, in > der wiederum womöglich durchnumeriert werden muss, damit man weiß, > was neben was liegt etc. ja, m.E. in diese Richtung könnte man das weiter verfeinern, auch wenn die Daten viele Zwecke gar nicht so genau gebraucht werden. > könnte man per Relation gleich die ganze Brücke erfassen anstatt > dass wie heute 4 separate Brücken gezeichnet werden > (den Nachteil des Separat-Modells habe ich ja ganz vergessen ;-) ) ja, die Information, dass es sich um eine Brücke handelt, und nicht um 4 parallele ist sicher wichtig und sollte auch in Zukunft mal irgendwann abgebildet sein (z.B. durch eine zusammenfassende Relation). > Entweder brauchen wir völlig neue Renderer, ansonsten können > wir vernünftiges Radwegerendering vergessen (in beiden Modellen, > einseitige im einen Modell, nichtüberlappend im anderen Modell) solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm und bin mir nicht sicher, ob eine verschobene Geometrie in allen Fällen "vernünftiger" wäre. Schon eher sicher bin ich mir, dass ich in einem Radwege-rendering eher die Straße verschieben würde als den Radweg. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin
Kam die Tage nicht zu ausschweifenden Antworten, daher erst heute ;-)
> Die Rheinbrücke ist ein Spezialfall, da ist Streit vorprogrammiert.
In der Tat ;-)
> Aber ich sehe es so wie Sven, Martin und Du: Speziell an der Rheinbrücke bin
> ich der Meinung, dass es bei getrennten Wegen bleiben sollte. Und das sollte
> Heiko respektieren. Wenn die Diskussion hier nicht dazu führt, dass in
> Potlatch fleissig die Taste »u« gedrückt wird, war sie, äh, vergebens :) .
Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu
anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch
spontanes zurücktaggen nicht verbauen ;-)
> Heiko möchte, soweit ich ihn verstehe, gerne die Radwegesituation in unseren
> Daten verbessern. Das ist mehr als wünschenswert.
Das ist irgendwo ein mittel- bis langfristiges Ziel, ja.
"Kurzfristig" habe ich mir schon abgeschminkt ;-)
> Vor diesem Hintergrund stellt sich die Frage, was wir primär abbilden wollen:
> Die Topologie ("Hier ist ein extra Radweg") oder die STVO ("Hier ist ein
> straßenbegleitender Radweg"). Da ich das Projekt viel mehr als Geodatenbank
> und weniger als nur ein (Staßen)kartenprojekt auffasse, komme ich zu dem
> Schluß, dass primär die Topologie und sekundär die STVO abgebildet werden
> sollte.
Beides gehört irgendwo zusammen. Die StVO (und Waldgesetze etc.) hat
einen Einfluss darauf, wer wo fahren darf. Nur mit dieser kommt man
in speziellen Fällen zu einer korrekten Topologie bspw. für Radfahrer.
Und es hängt auch von der Definition der Topologie ab, wann sie korrekt
abgebildet ist oder nicht.
Bspw. bei
highway=path foot=designated bicycle=designated segregated=yes
highway=trunk lanes=3
haben wir ja "in klein" die selbe Topologie für diesen Weg, wie "in groß" für
highway=trunk cycleway=yes
d.h. man fasst was zusammen und betrachtet diese dann topologisch
als Einheit "Bordsteinweg" oder "Fahrbahn" im kleinen oder "Straße"
im großen.
> Unsere Daten verfeinern sich immer mehr. Manche beschreiben das mit "Zumüllen
> der Datenbank". Ich sehe dem relativ gelassen entgegen. Im Falle eines
> straßenbegleitenden Radweges heißt das, dass jemand auch den Grünstreifen
> zwischen Fahrbahn und Radweg einzeichnen können soll. Eine gute Sache, trotz
> der Fragen (speziell bezüglich des Renderings) die das aufwirft.
Rendern würde nur in höchsten Vergrößerungen Sinn machen...
> Ich persönlich komme daher zu dem Schluss, dass in einer Geodatenbank die
> Topologie wichtiger ist als die STVO, die wie eine Glasglocke über die
> Topologie gestülpt ist. Relationen sind eine umständlich zu handhabende
> Sache. Dennoch tendiere ich aus obigen Gründen dazu, dass die STVO durch eine
> Relation zwischen dem Radweg und der Straße abgebildet werden sollte, so
> ähnlich wie das ja auch bei Abbiegeverboten gehandhabt wird.
Man könnte eigentlich jedes Modell erweitern.
Im "Straßenraum"-Modell generalisiert:
highway=trunk
cycleway=track
dann näher spezifiziert z.B. für die halbe Rheinbrücke
(andere Hälfte negativ, 0 als Mite):
0.segregrator=crash_barrier
1.landuse=green
1.width=0.5
2.lane=trunk
2.width=3
3.segregrator=dashed_line
4.lane=trunk
4.width=3
5.segregrator=dashed_line
6.lane=trunk
6.width=3
2-6.surface=asphalt
7.segregrator=curb
7.segregrator=crash_barrier
8.lane=cycleway
8.foot=no
8.width=1.5
9.segregator=solid_line
10.lane=footway
10.bicycle=no
10.width=1.5
11.segregrator=handrail
12.water=deep ;-)
Oder man macht alles als separaten way:
- Das Grün in der Mitte als area, die Leitplanke darauf als line
- jede Fahrspur einzeln, wie die gestrichelte Linie dazwischen
- Leitplanke zwischen Radweg und Fahrbahn
- Radweg
- Gehweg
- ...
... und packt alles in eine Relation Straßenraum zusammen, in
der wiederum womöglich durchnumeriert werden muss, damit man weiß,
was neben was liegt etc.
... oder macht Mischlösungen:
- die 2 Fahrbahnen als je ein way, aber mit spurabhängigen tags, evtl.
wie oben, und den Geh- und Radweg als 2 ways, auch ggfs. wieder
mit spurabhängigen tags für Geh- und Radweg.
> Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine
> Geschwingigkeitsbeschränkung (oder auch eine einfache Brücke) zu modellieren.
Da man Relationen nun sortieren kann (in potlatch anscheinend noch nicht?)
wäre der Vorschlag, der kürzlich zu lesen war von irgendwem (vergessen,
wer's war), mit Relationen von Knoten zu Knoten für bspw. Brücken
statt unterteiltem way eine nette Idee.
Router brauchen diese Infos nicht, Renderer könnten damit evtl.
eines Tages besser zeichnen.
Mit
node 1 role=Fahrbahn1
node 2 role=Fahrbahn1
node 3 role=Fahrbahn2
node 4 role=Fahrbahn2
node 5 role=Geh-Radweg
...
könnte man per Relation gleich die ganze Brücke erfassen anstatt
dass wie heute 4 separate Brücken gezeichnet werden
(den Nachteil des Separat-Modells habe ich ja ganz vergessen ;-) )
Die Frage ist: was passiert, wenn der way auf der Brücke durch
weitere Knoten verfeinert wird, dann fehlt der ja in einer
Nur-Node-Relation...
> Wäre die U
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin, > NACK. Wie ich oben schon schrieb, ich hätte Dich bzw. den relevanten Mapper > den ich in der History sehe angemailt. "Warum hast Du das und das so und so > erfasst, ich finde das wäre hier und hier besser, was sasgt Du dazu?" es spricht ja nichts dagegen, dass Du das so machst. Es soll aber auch ohne möglich sein. Denn sonst führt das dazu, dass jemand eine Verbesserung vornehmen könnte, es dann aber dann doch bleiben lässt, weil es ihm zu aufwändig ist, die Sache, die er _jetzt_ in wenigen Minuten erledigen könnte, erst tagelang abstimmen zu müssen. Cheers, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am Dienstag 23 Juni 2009 22:59:57 schrieb Christoph Eckert:
> ich möchte anmerken, dass mir die Brücke nicht gehört. Ich wende mich nicht
> dagegen, dass Heiko dort editiert und Änderungen vorgenommen hat. Ich
Natürlich nicht. Ich verändere auch ab und zu Dinge, die Andere angelegt
haben. Vor gravierenden Lösch- bzw. Umtagaktionen schreibe ich dem Anderen
aber üblicherweise vorher oder parallel eine erklärende Mail, ggf. kann man
dann darüber diskutieren.
> möchte vorsichtshalber auch darauf hinweisen, dass Heiko in Karlsruhe schon
> eine Menge Verbesserungen zusammengetragen hat. Die Rheinbrücke ist ein
> Spezialfall, da ist Streit vorprogrammiert.
Auch das ist unbestritten. Der "Streitfall" am konkreten Beispiel entsteht
IMHO auch, weil "jeder macht was er will". Es keine zentrale Instanz gibt, die
Regeln festlegt. Das ist für den lokalen Mapper, der "seine Gegend"
bearbeitet, äußerst angenehm. Er kann mit tags zur Verfügbarkeit von Kuchen am
lokalen Bäcker um sich werfen und keinen stört es. Langsam hat OSM aber Maße
erreicht wo uns dieses Prinzip beginnt im Weg zu stehen.
> Heiko möchte, soweit ich ihn verstehe, gerne die Radwegesituation in
> unseren Daten verbessern. Das ist mehr als wünschenswert.
ACK.
> nicht davor zurückschreckt, auch an kniffeligen Stellen die Finger in die
> Daten zu stecken, ebenfalls. Denn eine "Huch, nein, ich könnte ja was
> kaputt machen"-Mentalität führte sicher nicht dazu, dass das Projekt
> weiterkommt.
NACK. Wie ich oben schon schrieb, ich hätte Dich bzw. den relevanten Mapper
den ich in der History sehe angemailt. "Warum hast Du das und das so und so
erfasst, ich finde das wäre hier und hier besser, was sasgt Du dazu?"
> Vor diesem Hintergrund stellt sich die Frage, was wir primär abbilden
> wollen: Die Topologie ("Hier ist ein extra Radweg") oder die STVO ("Hier
> ist ein straßenbegleitender Radweg"). Da ich das Projekt viel mehr als
Natürlich die Topologie. Schon mal vor dem Hintergrund das OSM weltweit
funktionieren soll und die STVO nur lokal gilt. Das ein Renderer oder Router
dann lokale Gegebenheiten, die er an den Ländergrenzen erkennt,
berücksichtigen wird ergibt sich später von alleine.
> eine Relation zwischen dem Radweg und der Straße abgebildet werden sollte,
Das sehe ich anders. Topologisch hat der Radweg mit der Straße nichts
gemeinsam, die Gemeinsamkeit ist ein Konstrukt der STVO. Besser wäre die
Editoren würden Linienbündel an Kreuzungen oder beim Verschieben usw. besser
unterstützen, damit man die vielen Kreuzungspunkte nicht händisch pflegen muß.
> Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine
> Geschwingigkeitsbeschränkung (oder auch eine einfache Brücke) zu
> modellieren.
Warum nicht? Man kann die zerhackstückten Teile, wenn man logische
Informationen die zu mehreren Teilen des Weges gehören (name, ref), in eine
Relation stecken.
> Mapnik Osmarender, openrouteservice.org, gosmore oder Navit heute mit
> unseren Daten zurechtkommen oder nicht, ist zweitrangig. Das lernen die
> schon noch. Und zwar umso schneller, je einheitlicher das Radwegemapping
> umgesetzt wird.
ACK.
Tschaui, Jörg
signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin,
> Genau so sehe ich das auch. Auch ich verfolge den Thread aufmerksam weil
> mich das Radrouting derzeit am Meisten beschäftigt. Und das Heiko, ohne den
> Mapper der den Radweg angelegt hat zu kontaktieren, einfach dessen Arbeit
> löscht finde ich auch nicht ok.
ich möchte anmerken, dass mir die Brücke nicht gehört. Ich wende mich nicht
dagegen, dass Heiko dort editiert und Änderungen vorgenommen hat. Ich möchte
vorsichtshalber auch darauf hinweisen, dass Heiko in Karlsruhe schon eine
Menge Verbesserungen zusammengetragen hat. Die Rheinbrücke ist ein
Spezialfall, da ist Streit vorprogrammiert.
Aber ich sehe es so wie Sven, Martin und Du: Speziell an der Rheinbrücke bin
ich der Meinung, dass es bei getrennten Wegen bleiben sollte. Und das sollte
Heiko respektieren. Wenn die Diskussion hier nicht dazu führt, dass in
Potlatch fleissig die Taste »u« gedrückt wird, war sie, äh, vergebens :) .
Unabhängig von obigem Streitfalle möchte ich gern ein paar Dinge loswerden.
Openstreetmap ist IMO primär eine gewaltige Geodatenbank.
Heiko möchte, soweit ich ihn verstehe, gerne die Radwegesituation in unseren
Daten verbessern. Das ist mehr als wünschenswert. Dass er dabei nicht davor
zurückschreckt, auch an kniffeligen Stellen die Finger in die Daten zu
stecken, ebenfalls. Denn eine "Huch, nein, ich könnte ja was kaputt
machen"-Mentalität führte sicher nicht dazu, dass das Projekt weiterkommt.
Vor diesem Hintergrund stellt sich die Frage, was wir primär abbilden wollen:
Die Topologie ("Hier ist ein extra Radweg") oder die STVO ("Hier ist ein
straßenbegleitender Radweg"). Da ich das Projekt viel mehr als Geodatenbank
und weniger als nur ein (Staßen)kartenprojekt auffasse, komme ich zu dem
Schluß, dass primär die Topologie und sekundär die STVO abgebildet werden
sollte.
Unsere Daten verfeinern sich immer mehr. Manche beschreiben das mit "Zumüllen
der Datenbank". Ich sehe dem relativ gelassen entgegen. Im Falle eines
straßenbegleitenden Radweges heißt das, dass jemand auch den Grünstreifen
zwischen Fahrbahn und Radweg einzeichnen können soll. Eine gute Sache, trotz
der Fragen (speziell bezüglich des Renderings) die das aufwirft.
Ich persönlich komme daher zu dem Schluss, dass in einer Geodatenbank die
Topologie wichtiger ist als die STVO, die wie eine Glasglocke über die
Topologie gestülpt ist. Relationen sind eine umständlich zu handhabende
Sache. Dennoch tendiere ich aus obigen Gründen dazu, dass die STVO durch eine
Relation zwischen dem Radweg und der Straße abgebildet werden sollte, so
ähnlich wie das ja auch bei Abbiegeverboten gehandhabt wird.
Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine
Geschwingigkeitsbeschränkung (oder auch eine einfache Brücke) zu modellieren.
Wäre die Unterstützung für Relationen in unseren Editoren besser, würde ich
für die im Verlaufe der Diskussion schon erwähnten "Segmented Tags" plädieren
(mit denen könnten übrigens auch straßenbegleitende Radwege recht gut
beschrieben werden, aber das vielleicht besser nur am Rande ;-) .
Jeder von uns mappt, ob er will oder nicht, natürlich auch für "den Router"
und "den Renderer". Dagegen ist erstmal nichts einzuwenden. Aber die Comsumer
sollten IMO nicht zur obersten Maxime beim Mappen werden. Ob Mapnik
Osmarender, openrouteservice.org, gosmore oder Navit heute mit unseren Daten
zurechtkommen oder nicht, ist zweitrangig. Das lernen die schon noch. Und
zwar umso schneller, je einheitlicher das Radwegemapping umgesetzt wird.
Wer eine Verbesserung erreichen möchte, muss sich mit einer Reihe von Leuten
zusammensetzen, die eine halbwegs einheitliche Vorgehensweise erarbeiten,
vorschlagen und aktiv in den Daten und (vor allem) den Consumern umsetzen
können. Genau so haben wir es in Karlsruhe mehrfach gemacht (komplexe
Kreuzungen, Hausnummern, ÖPNV) und andere haben es übernommen.
Ich glaube ehrlich gesagt kaum, dass ein solcher Vorschlag zur Modellierung
von Radwegen zu Zusatztags an Trunks raten würde. Aber ich lasse mich da
gerne vom Ergebnis eines Workshops überraschen. Es sei denn, Heiko wäre der
einzige Teilnehmer ;-) .
HTH und schönen Abend,
ce
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
