[Talk-de] Liebe Renderer,
zumindest in Vorstadtbereichen mit Bahnhöfen, die dem ÖPNV dienen, sind oft Bahnsteige so an das örtliche Wegenetz angebunden, dass sie häufig auch von Nicht-Fahrgästen genutzt werden. Wir haben den Tag railway=platform. Der wird aber bisher nicht ausgewertet/gezeichnet. Daher hängen die zum Bahnsteig führenden Wege in der Luft. Kann man das nicht ändern? Oder muss man zusätzlich noch einen Fußweg taggen? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liebe Renderer,
Hallo, Norbert Kück wrote: Wir haben den Tag railway=platform. Als Fläche oder als Linie? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anwendungsbeispiele
Am Freitag 30 Januar 2009 21:58:48 schrieb Toni Erdmann: Stefan Leupers schrieb: Hallo zusammen! ... Habe gerade zufällig gesehen, dass die Insel Herrenchiemsee in Bayern sowohl auf der ÖPNV-Karte als auch auf der Cyclemap zum Teil überflutet aussieht. :-( ... Soweit ich gesehen habe, wird da mit allerlei inner und outer Multipolygonen hantiert. Gibt es in den Daten ein Problem oder klappt die Auswertung bei ÖPNV/CycleMap nur nicht ganz korrekt? Kann das aktuell leider nicht beurteilen, da ich mich mit Multipolygonen (noch) nicht auskenne. Wäre nett, wenn mal jemand nachschaut. Danke. Hallo Stefan, ja das mit den Multipolygonen ... bei Wald mit Lichtungen, die residential areas sind habe ich das hinbekommen, so dass zumindest die ÖPNV es richtig macht. Wald(way)= outer landuse=forest ... Lichtung(way)= inner landuse=forest ... residetial area = neuer way auf nodes von Lichtung(way) landuse=resi... Die innere Begrenzung sollte hier aber nicht landuse=forest sein. Das würde ja Wald im Wald bedeuten. Stattdessen sollte es so gemacht werden: Wald= outer landuse=forest Lichtung= inner landuse=residential Wenn deine Version im ÖPNV funktioniert, dann ist es wahrscheinlich nur Zufall. Ich vermute, dass Mapnik da für den inneren Ring sowohl forest als auch residential rendert, und nur zufällig das residential am Schluss, so dass es dann das forest verdeckt. Die Multipolygon-Relation vom Chiemsee ist meines Erachtens richtig. Allerdings sind die Inseln noch als natural=land getaggt, was ich zwar als Hack empfinde, was aber das falsche Rendering auf der Cyclemap nicht erklärt. Grüße, Marc Grüße, Marc 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] Liebe Renderer,
2009/1/31 Frederik Ramm frede...@remote.org Hallo, Norbert Kück wrote: Wir haben den Tag railway=platform. Als Fläche oder als Linie? Wenn ich das richtig sehe, wird momentan weder Linie, noch Fläche gerendert. Hier: http://www.informationfreeway.org/index.php?lat=50.76731645772545lon=6.091694150753029user=torstikozoom=17layers=0F0B0Fsieht man lediglich den südlichen Bahnsteig gerendert. Dieser wird jedoch als highway=footway gerendert, da hier kein area=yes gesetzt ist. Die anderen Bahnsteige haben die Tags: highway=footway, railway=platform, area=yes und werden somit gar nicht gerendert. Ebenfalls wäre es schön, wenn highway=footway area=yes in Mapnik gerendert würde. Also ein 'flächiger' Fußweg. Hier: http://www.informationfreeway.org/index.php?lat=50.586237448340974lon=6.448052363286663user=torstikozoom=17layers=0F0B0Fsieht man eine Stelle, wo so etwas vor kommt. Es handelt sich hier nicht um eine Fußgängerzone, sondern um einen Platz, an dem sich mehrere Fußwege treffen. In t...@h wird das schon korrekt dargestellt. Netter Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Bernd Wurst schrieb: Am Samstag, 31. Januar 2009 schrieb Stephan Wolff: Am Ende stellt Osmarender den Bach in gerundeten Schleifen dar und führt ihn komplett an der Minibrücke vorbei. Das kannst du einfach beheben in dem du den Bachlauf an der Stelle genauer einträgst, also zwei nodes links und rechts der Brücke so setzen, dass auch ein Bezier-algorithmus da keine ausladenden Kurven zeichnet. Dann muss ich aus einem Kreuzungspunkt, den ich grob vermessen habe, schon vier Punkte generieren. Gerade die Bachläufe kann ich nur ungenau aus den in SH sehr groben Yahoo-Luftbildern entnehmen. Dabei treten oft 10 - 30m Versatz zu meinen GPS-Koordinaten auf, so dass ich den Bach meist nur grob mit wenigen Stützpunkten einzeichne. Als Vereinfachung könnte man vereinbaren, dass Highway und waterway immer mit einer Brücke kreuzen, wenn nicht highway=ford angegeben ist. Gleiches könnte man für Autobahn und Feldweg/Fussweg/... vereinbaren, müsste aber dann zumindest über ein layer-Tag die Lage angeben. Das klingt jetzt aber arg umständlich und ziemlich Fehleranfällig. Ich möchte keinen Router schreiben müssen, der solcherlei Bequemlichkeitstagging auswerten muss. Für den Router würde sich _nichts_ ändern. Allenfalls der Renderer müsste die Kreuzungspunkte berechnen. Die zusätzliche CPU-Zeit dürfte selbst auf 10 Jahre gesehen unter meiner Brain-Zeit liegen :-) Ich halte die jetzige Konstruktion für fehleranfälliger. Wenn jemand ein Straßenteilstück um wenige Meter verschiebt, treten an der Minibrücke große Richtungssprünge auf. Bei Verschiebung in Längsrichtung um mehr als eine Brückenlänge würde die Straße sogar hin, über die Brücke zurück und wieder hin laufen. Was sollte bei impliziter Vereinbarung der Kreuzung fehleranfälliges passieren? Alternativ könnte man auch einen gemeinsamen Punkt beider Wege mit bridge=yes beschriften, um zu zeigen, dass dort _keine_ Verbindung ist. Bei Map_Features sind auf der Übersichtsseite sowohl auf der deutschen wie englischen Seite Brücken als Way und Node eingetragen. Im Text zu bridge findet sich dann aber nur noch way. Gab es schon mal Brücken offiziell als Node? Im Tagwatch sind es 1% aller Brücken. Zu der Problematik ich will meine Wege nicht zerhackstückeln kommt (das weißt du bestimmt) alle Woche mal was. Ein total toll gemeinter, revolutionärer, im Ansatz ein bisschen durchdachter Vorschlag wie man Brücken, Tunnel, Geschwindigkeitbeschränkungen, Routenzugehörigkeit oder Bodenbeschaffenheit an ein Teilstück eines Weges setzen könnte ohne den Weg teilen zu müssen. Bei diesen Dingen möchte ich eine Eigenschaft zwischen zwei Punkten auf einer längeren Strecke festlegen. Ich möchte nur sagen, dass diese Bachquerung als Brücke ausgeführt ist. Die Ortsangaben von Beginn und Ende möchte ich gerade vermeiden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Stephan Wolff wrote: Moin, immer wenn ich sehr kurze Brücken eingeben muss, ärgere ich mich über das umständliche Verfahren. Als kurze Brücken würde ist solche unter 5 Meter Länge verstehen. Ich gebe solche Brücken überhaupt nicht ein. Bach Layer=-1 und Straße Layer=0 und alles wird korrekt dargestlelt und sogar der Validator ist zufrieden. Und ein intelligentes Auswerteprogramm weiß sowieso, dass es eine Brücke sein muss, bzw. dass auf jeden Fall die Straße drüber geht. Vorteil: wenn den Bach verschiebst, passt immer noch alles, da sich Bach und Straße keinen Punkt teilen. MfG Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anwendungsbeispiele
Marc Schütz schrieb: Am Freitag 30 Januar 2009 21:58:48 schrieb Toni Erdmann: Stefan Leupers schrieb: Hallo zusammen! ... Habe gerade zufällig gesehen, dass die Insel Herrenchiemsee in Bayern sowohl auf der ÖPNV-Karte als auch auf der Cyclemap zum Teil überflutet aussieht. :-( ... Soweit ich gesehen habe, wird da mit allerlei inner und outer Multipolygonen hantiert. Gibt es in den Daten ein Problem oder klappt die Auswertung bei ÖPNV/CycleMap nur nicht ganz korrekt? Kann das aktuell leider nicht beurteilen, da ich mich mit Multipolygonen (noch) nicht auskenne. Wäre nett, wenn mal jemand nachschaut. Danke. Hallo Stefan, ja das mit den Multipolygonen ... bei Wald mit Lichtungen, die residential areas sind habe ich das hinbekommen, so dass zumindest die ÖPNV es richtig macht. Wald(way)= outer landuse=forest ... Lichtung(way)= inner landuse=forest ... residetial area = neuer way auf nodes von Lichtung(way) landuse=resi... Die innere Begrenzung sollte hier aber nicht landuse=forest sein. Das würde ja Wald im Wald bedeuten. Stattdessen sollte es so gemacht werden: Wald = outer landuse=forest Lichtung = inner landuse=residential Gut, dann war das mit Tagging(outer) == Tagging(inner) und clock-wise und counter-clock-wise wohl nur in der Anfangsphase der Multipolygone der Fall, und es scheint mittlerweile überholt zu sein. Wenn dem so ist, kann ich ja meine bisherigen Lichtungen dahingehend korrigieren (zumindest eine davon und das Ergebnis abwarten). Wenn deine Version im ÖPNV funktioniert, dann ist es wahrscheinlich nur Zufall. Ich vermute, dass Mapnik da für den inneren Ring sowohl forest als auch residential rendert, und nur zufällig das residential am Schluss, so dass es dann das forest verdeckt. Vermutlich. Die Multipolygon-Relation vom Chiemsee ist meines Erachtens richtig. Allerdings sind die Inseln noch als natural=land getaggt, was ich zwar als Hack empfinde, was aber das falsche Rendering auf der Cyclemap nicht erklärt. Gruß, Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Am Samstag 31 Januar 2009 12:19:40 schrieb Stefan Hirschmann: Stephan Wolff wrote: Moin, immer wenn ich sehr kurze Brücken eingeben muss, ärgere ich mich über das umständliche Verfahren. Als kurze Brücken würde ist solche unter 5 Meter Länge verstehen. Ich gebe solche Brücken überhaupt nicht ein. Bach Layer=-1 und Straße Layer=0 und alles wird korrekt dargestlelt und sogar der Validator ist zufrieden. Und ein intelligentes Auswerteprogramm weiß sowieso, dass es eine Brücke sein muss, bzw. dass auf jeden Fall die Straße drüber geht. Dass die Straße drüber geht ja, aber das ist eben nur ein Teilaspekt der Wirklichkeit, die wir zu modellieren versuchen. Tatsächlich kann ich mir keinen Fall denken, wo nicht entweder eine Brücke über den Bach geht, oder ein Rohr (=tunnel) unter der Straße durch. Welcher der beiden Fälle zutrifft, ist mangels expliztem bridge=yes oder tunnel=yes nicht feststellbar. Vorteil: wenn den Bach verschiebst, passt immer noch alles, da sich Bach und Straße keinen Punkt teilen. Das ist kein Vorteil, sondern eine Selbstverständlichkeit, dass man Wege, die sich nicht berühren, auch nicht verbindet. Grüße, Marc 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] Kurze Brücken
Stefan Hirschmann schrieb: Ich gebe solche Brücken überhaupt nicht ein. Bach Layer=-1 und Straße Layer=0 und alles wird korrekt dargestlelt und sogar der Validator ist zufrieden. An den Bach gehört kein Layer=-1 ran. Grundsätzlich nicht. Weil der Layer dann nämlich gern pauschal an den gesamten Bach gepackt wird, nicht nur, wie es sich eigentlich gehören würde, an das lokale kleine Stück im Bereich der Nicht-Brücke. Und wenn ich mir so die Aussagen zu diesem Validator durchlese, dann komme ich zu der Erkenntnis, dass dieser Programmteil offenbar hinsichtlich seines Regelwerks einige Monate bis Jahre hinter der aktuellen Entwicklung herhinkt. Ich würde ihm also nicht allzu große Bedeutung beimessen. Wenn überhaupt ein Layer, dann gehört layer=1 an ein Stückchen der Straße, was sich, sofern die Brücke schwer einzuzeichnen ist, gern auch unabhängig von der realen Brücke etwas weiter ausdehnen darf. Wobei ich mich immer noch frage, wo denn eigentlich das genaue Taggingproblem sein soll. Und ein intelligentes Auswerteprogramm weiß sowieso, dass es eine Brücke sein muss, bzw. dass auf jeden Fall die Straße drüber geht. Also gar nichts taggen? Vorteil: wenn den Bach verschiebst, passt immer noch alles, da sich Bach und Straße keinen Punkt teilen. Straße und Bach dürfen keinen gemeinsamen Punkt haben. Ich erkenne als Potlatch-User auch nicht, wo das Problem des Verschiebens sein soll. Ich verschiebe Punkte, daraus resultiert dann ein neuer Linienverlauf von Straße oder Bach. Und wenn ich was verschiebe, dann kann daraus selbstverständlich resultieren, dass ich Daten, die mit dem alten Verlauf zusammenhingen, ebenfalls korrigieren muss. So ist das nun mal. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JAMBA verwendet OSM
Tobias Wendorff schrieb: Schwupps ... die haben nur die kurze Version online. Kann man jemand vielleicht für Leute ohne Fernseher erklären, was hier das Problem ist? Warum Schamesröte? Haben die RTL-Nachrichten irgendwas schlechtes über OSM berichtet, was nicht direkt abzustreiten ist? Oder haben die konzeptionelle Schwächen bei uns aufgedeckt? Und was hat das alles mit Jamba zu tun? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JAMBA verwendet OSM
Hallo, Warum Schamesröte? Stimmt. Wenn Die Lizenz es nun mal alles zulässt, dann muss man auch mit unseriösen Nutzern rechnen. Verstehe die Aufregung auch nicht. Vielmehr müssten wir uns überlegen, wie man durch seriöse und leicht bedienbare Anwendungen OSM bekannter macht, damit endlich auch im ländlichen Bereich mehr als nur die Bundesstraßen erfasst werden. Wenn ich mir beispielsweise www.ace-online.de/schlaglochmelder ansehe, das wäre doch so ein Fall. So ein Formular wie dort gefordert füllt mit Sicherheit keiner aus, aber einfach nur mal einen Klecks auf die (OSM-) Karte malen, das würde man schon mal tun. Ordentlich beworben = Plus für OSM. Gruß, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] smoothness-Tag
Hatto von Hatzfeld schrieb: Schon seit einiger Zeit habe ich einen Tag gesucht, mit dem sich erfassen lässt, ob ein Weg z.B. mit Inline-Skates oder mit einem Rennrad befahren lässt. Vor kurzem bin ich auf den Tag smoothness gestoßen, der mir dafür auch recht geeignet scheint, da er angeben soll, für welche Fahrzeuge ein Weg nutzbar ist. Hier die Tabelle von Werten, wie sie in den Map Features steht: smoothness: usable by: excellent roller blade, skate board and all below goodracing bike and all below intermediatecity bike, sport car, wheelchair, scooter and all below bad trekking bike, normal cars, rickshaw and all below very_badCar with high clearance, mountain bike without and all below horribleoff-road vehicles and all below very_horrible Tractor, ATV, tank, trials bike, mountain bike with studded tires and all kind of off-highway vehicles (see also mtb_scale=*) impassable No wheeled vehicle (see also sac_scale=*) Anscheinend wurde darüber auch mit positivem Ausgang abgestimmt. Es scheint sich dann aber ein Edit-War entwickelt zu haben, in dessen Folge nun die Seite http://wiki.openstreetmap.org/wiki/Approved_features/Smoothness nach http://wiki.openstreetmap.org/wiki/Rejected_features/Smoothness verschoben wurde, wo der Status aber immer noch als Approved angeben ist. Auf http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Smoothness kann man das unten nachlesen. Ich kann nur sagen, dass mir dieser Edit-War missfällt und ich bisher keinen besseren Vorschlag als die obigen Tags (die natürlich ihre Grenzen haben) gesehen habe. Wie wird der Tag denn von den Lesern dieser Mailingliste gesehen? Der Edit-War ist natürlich unkonstruktiv. Obwohl die Abstimmung positiv verlaufen ist, wurde es einfach eigenmächtig verschoben, obwohl die Unstimmigkeiten klar waren und man einfach mal als Kompromiss es auf Proposed hätte zurücksetzen können. Es gibt kein Argument dagegen, außer dass es schlecht definiert ist (als ob alle in Benutzung befindlichen Tags so klar definiert wären). Das Problem liegt hier meines erachtens aber weniger in der Ausarbeitung des Vorschlags ansich, sondern in der Natur der Sache. Wie bewertet man die Laufruhe eines Weges objektiv? Je nach Fahrzeug in dem man sich befindet und subjektiven Empfinden dürfte die Bewertung recht unterschiedlich ausfallen. Aber das ist irgendwie auch kein Grund es garnicht zu erfassen. Letztlich sind solche Dinge doch interessant, gerade wenn man mit dem Rad oder Skates unterwegs ist. Der einzige Fehler in dem Proposal liegt meines Erachtens darin, dass immer mehr Werte zur Verfeinerung zwischenreingeschoben wurden. Bloss macht das die Werte nicht genauer sondern nur uneindeutiger. Ich wäre eher für weniger Werte (maximal 5), die sich dann auch genauer voneinander abgrenzen lassen. Zwar bleibt es subjektiv, aber das ist in OSM doch so vieles. Solange man in etwa rauslesen kann, ob der Weg jetzt komplett 'smooth' ist oder eher was für Mountainbiker, ist das schon ein Mehrwert. Zum Beispiel: grade1 Keinerlei Unebenheiten weit und breit, sehr angenehm für alle Fahrzeuge grade2 Einige leichte Bodenwellen oder flache Schlaglöcher grade3 Schlaglöcher und Bodenwellen tiefer, so dass man mit dem Rad auch gerne mal das Tempo etwas verringern möchte grade4 Tiefe Löcher, Risse oder große Steine Entsprechende Bilder müssten das Ganze noch verdeutlichen, damit man auch sicher gehen kann, dass man in etwa das Gleiche meint. Ich denke das ist schon leichter zu unterscheiden, als doppelt so viele Werte, mit so interessanten Dingen wie very_... Oder mit den bisherigen Bezeichnungen und noch einem mehr: excellent Keinerlei Unebenheiten weit und breit goodEinige leichte Bodenwellen oder flache Schlaglöcher intermediateSchlaglöcher und Bodenwellen tiefer, so dass man mit dem Rad auch gerne mal das Tempo etwas verringern möchte bad Tiefe Löcher oder Risse für die man auf normalen Rädern definitiv abbremsen muss horribleNormales Fahren nicht mehr möglich, hier sollte man genug Zeit und Lust mitbringen Genauere Einteilungen sind dann meines Erachtens nur für einzelne Verkehrsteilnehmer sinnvoll erfassbar, also bike_skale, skate_skale oder was auch immer. Das Problem dabei ist eben, dass sich weniger dafür interessieren. Deshalb eben der Vorschlag einer allgemeinen, groben Einteilung wie smoothness, die erstmal jeder benutzen kann, wenn er will. Wer es nicht für sinnvoll hält oder einfach keine Lust drauf hat, der braucht es auch nicht zu benutzen. So läuft das in OSM doch. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Sven Rautenberg schrieb: Stefan Hirschmann schrieb: Ich gebe solche Brücken überhaupt nicht ein. Bach Layer=-1 und Straße Layer=0 und alles wird korrekt dargestlelt und sogar der Validator ist zufrieden. An den Bach gehört kein Layer=-1 ran. Grundsätzlich nicht. Weil der Layer dann nämlich gern pauschal an den gesamten Bach gepackt wird, nicht nur, wie es sich eigentlich gehören würde, an das lokale kleine Stück im Bereich der Nicht-Brücke. Und wenn ich mir so die Aussagen zu diesem Validator durchlese, dann komme ich zu der Erkenntnis, dass dieser Programmteil offenbar hinsichtlich seines Regelwerks einige Monate bis Jahre hinter der aktuellen Entwicklung herhinkt. Ich würde ihm also nicht allzu große Bedeutung beimessen. Dann fass dir ein Herz, und schreib auf dem JOSM trac die Sachen mal hin, die *unstimmig* (und nicht nur aus deiner persönlichen Meinung) falsch sind. Das folgende geht jetzt nicht an dich persönlich Sven, ich hab deine Mail nur als Beispiel rausgepickt, weil deine Formulierungen gerade so schön passend waren ... Sorry, ich kann hier momentan keine wirkliche Entwicklung erkennen. Es gibt auf dieser Liste alle paar Wochen/Monate wiederkehrende Diskussionen, bei denen jeweils zum gleichen Thema auch gerne mal ein völlig anderes Ergebnis bei rauskommt. Je nachdem, wer beim Mail schreiben die längere Ausdauer hatte. Aus meiner Sicht drehen wir uns an einigen Stellen schlicht im Kreis. Ich versuche mich da rauszuhalten, weil es aus meiner Sicht keinen Sinn macht, die gleichen Diskussionen alle paar Wochen wieder und wieder zu führen. Ich sehe hier auf der Liste (nicht nur in diesem Thread) einen Haufen Meinungen, die mich inzwischen eher an Religion denn an Problemlösung erinnern. Formulierungen wie Grundsätzlich nicht oder wie es sich eigentlich gehören würde deuten so ein bisschen in diese Richtung ;-) Gruß, ULFL P.S: Ja, mir ist bewußt, daß ich in dieser Beziehung auch kein Unschuldslamm bin ;-) P.P.S: Nein, ich bin nicht der Entwickler vom JOSM Validator ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln
Ulf Lamping schrieb: Mario Salvini schrieb: Ulf Lamping schrieb: Aber bitte nicht im Nebensatz neue Behauptungen aufstellen: Wenn du 2 Einbahnstraßen draus machts, brauchst du keine turn-restrictions zusätzlich anzulegen. Die ergeben sich automatisch aus den Einbahnstraßen und ein Router wird die Einbahnstraßen schon in seine Route einbeziehen. Gruß, ULFL natürlich muss da eine turn-restriction hin, sonst könnte da links abbiegen (in die Realität übertragen also drehen). Beispielsweise z.B. hier: http://data.giub.uni-bonn.de/openrouteservice/index.php?start=6.1134704,50.7710525end=6.1163058,50.7714249pref=Fastestlang=de Sorry, da verstehe ich dich jetzt überhaupt nicht! Was ist an dieser Route falsch? Für mich sieht die - ohne Ortskenntnis - erstmal völlig ok aus! Was hat das mit dem Topic Verkehrsinseln zu tun?!? Ich sag es einfach nochmal etwas klarer: Du brauchst keine turn-restrictions zu setzen in Fällen die dich falsch herum in eine Einbahnstraße leiten. Das muß ein Router einfach erkennen und verhindern können. Wenn du hier ein Wendeverbot meinen solltest: Entweder beim Adalbertsteinweg steht das Zeichen Wendevebot[1] oder es steht da nicht. Das sollte das Kriterium sein, ob man eine turn-restriction setzt. Oder meinst du was anderes?!? Gruß, ULFL [1] http://de.wikipedia.org/wiki/Datei:Zeichen_272.svg diese Ampel da dient nur als Fussgängerüberweg. Dort kann noch darf man an dieser Stell einen U-Turn machen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JAMBA verwendet OSM
Arne Bischoff schrieb: Warum Schamesröte? Stimmt. Wenn Die Lizenz es nun mal alles zulässt, dann muss man auch mit unseriösen Nutzern rechnen. Ich verstehe immernoch das Problem nicht. Was ist wo unseriös? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln
Am 30. Januar 2009 23:15 schrieb Bernd Raichle be...@dante.de: Ein Winkel verbietet nichts, da man ja beim Mappen Flaechen zu Kanten vereinfacht. Und da kann leicht aus einer Kreuzung mit ausreichendem Abbiegeraum im Kantenmodell etwas sehr spitzwinkliges werden. ganz genau, der Winkel ist kein Kriterium, ich kann Dir auch spontan eine Stelle zeigen, wo man überhaupt nur spitzwinklig eine Straße erreichen kann, z.B. hier: http://maps.google.it/maps?hl=deie=UTF8ll=41.873148,12.514511spn=0,359.989915z=17layer=ccbll=41.873216,12.514159panoid=WqXsDF6PW_JJDR3gaIDqWgcbp=12,110.09958909087092,,0,9.622511129987869 http://www.informationfreeway.org/?lat=41.88576342226803lon=12.471718513317205zoom=13layers=B000F000F Du kannst hier nur aus der Via Latina (einbahnstr.) in die Via Mantellini abbiegen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JAMBA verwendet OSM
Hallo, Johann H. Addicks wrote: Was ist wo unseriös? Jamba ist ein Unternehmen, das Teenies ihr Taschengeld mit Handyklingeltoenen usw. aus der Tasche zieht und dabei keine Tricks ungenutzt laesst (einmal nicht aufgepasst, schon hast Du ein drei-Monats-Klingelton-Abo gekauft usw.) - imagemaessig etwa so wie Zeitschriften-Drueckerkolonnen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln
ganz genau, der Winkel ist kein Kriterium, ich kann Dir auch spontan eine Stelle zeigen, wo man überhaupt nur spitzwinklig eine Straße erreichen kann, z.B. hier: http://maps.google.it/maps?hl=deie=UTF8ll=41.873148,12.514511spn=0,359.989915z=17layer=ccbll=41.873216,12.514159panoid=WqXsDF6PW_JJDR3gaIDqWgcbp=12,110.09958909087092,,0,9.622511129987869 http://www.informationfreeway.org/?lat=41.88576342226803lon=12.471718513317205zoom=13layers=B000F000F Du kannst hier nur aus der Via Latina (einbahnstr.) in die Via Mantellini abbiegen. Gruß Martin sorry, falscher link für infofreeway, richtig: http://www.informationfreeway.org/?lat=41.87316209586825lon=12.514472915754252zoom=17layers=BF000F ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln
Hallo. Am Samstag, 31. Januar 2009 schrieb Martin Koppenhoefer: ganz genau, der Winkel ist kein Kriterium, ich kann Dir auch spontan eine Stelle zeigen, wo man überhaupt nur spitzwinklig eine Straße erreichen kann, z.B. hier: [...] Du kannst hier nur aus der Via Latina (einbahnstr.) in die Via Mantellini abbiegen. Ich rede nicht davon, alle spitzen Winkel zu ignorieren. Das von dir genannte Beispiel hat grob nach Geodreieck am Bildschirn einen Winkel von 135°. Gruß, Bernd -- Mein Homer ist kein Kommunist. Er ist vielleicht ein Lügner, ein Schwein, ein Idiot und ein Kommunist, aber ist kein Porno-Star! - Grandpa, Die Simpsons 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] Verkehrsinseln
Mario Salvini schrieb: Ulf Lamping schrieb: Wenn du hier ein Wendeverbot meinen solltest: Entweder beim Adalbertsteinweg steht das Zeichen Wendevebot[1] oder es steht da nicht. Das sollte das Kriterium sein, ob man eine turn-restriction setzt. Oder meinst du was anderes?!? diese Ampel da dient nur als Fussgängerüberweg. Dort kann noch darf man an dieser Stell einen U-Turn machen. Also du meinst was anderes. Ein wenig ausführlicher, und ich hätte eine Chance gehabt dich gleich viel einfacher zu verstehen ;-) An dieser Stelle ziehe ich meine Aussage von oben zurück - da hatte ich eine andere Art von Kreuzung im Kopf. Allerdings einfach an diesen Node eine Restriction zu hängen löst wohl das Problem nicht. Jetzt haben wir nämlich gleich mehrere Probleme :-( 1. Aus dem tagging ist nicht erkennbar, ob man mitten auf der Strecke wenden darf (Stichwort: durchgezogene Linie). Der Router kann also durchaus auf die Idee kommen ein paar Meter weiter zu fahren und dann dort wenden zu wollen. 2. Der Router könnte auf *jedem* Node auf die Idee kommen zu wenden. Jetzt aber an jedem Node der Trierer Straße zwei no_u_turn Relationen dran zu hängen halte ich persönlich für overkill. Ich fürchte, da sind durchaus noch ein paar Probleme zu lösen ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erfahrungen mit der Wanderkarte
Hallo Bernd, Leider gibt es bei den meisten Wegen keinen vor Ort erkennbaren Namen. Und sich deshalb beim Albverein um Infomaterial zu bemühen ist dann doch wirklich Arbeit. :) Für die Wanderwege des Fränkischen Albvereins steht das Verzeichnis der Wanderwege zur Verfügung. Die Inhalte dürfen entnommen werden, auch die Symbole: http://www.fraenkischer-albverein.de/wandern/wege/wegeliste.htm Bitte operator=Fränkischer Albverein e.V. eintragen. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liebe Renderer,
Hi ! nachdem vor einigen Tagen Gerrit einen Vorschlag für die Erfassung von Bushaltestellen [1] gemacht hat ist Lübeck von ihm als Testgebiet ausgesucht worden. Danach werden dann auch NODES als Platformen für die Bushaltestelle verwendet ! Sollte somit auch Berücksichtigung finden ! Gruß Jan :-) [1] http://www.mail-archive.com/talk-de@openstreetmap.org/msg32858.html Torsten Breda schrieb: 2009/1/31 Frederik Ramm frede...@remote.org mailto:frede...@remote.org Hallo, Norbert Kück wrote: Wir haben den Tag railway=platform. Als Fläche oder als Linie? Wenn ich das richtig sehe, wird momentan weder Linie, noch Fläche gerendert. Hier: http://www.informationfreeway.org/index.php?lat=50.76731645772545lon=6.091694150753029user=torstikozoom=17layers=0F0B0F http://www.informationfreeway.org/index.php?lat=50.76731645772545lon=6.091694150753029user=torstikozoom=17layers=0F0B0F sieht man lediglich den südlichen Bahnsteig gerendert. Dieser wird jedoch als highway=footway gerendert, da hier kein area=yes gesetzt ist. Die anderen Bahnsteige haben die Tags: highway=footway, railway=platform, area=yes und werden somit gar nicht gerendert. Ebenfalls wäre es schön, wenn highway=footway area=yes in Mapnik gerendert würde. Also ein 'flächiger' Fußweg. Hier: http://www.informationfreeway.org/index.php?lat=50.586237448340974lon=6.448052363286663user=torstikozoom=17layers=0F0B0F http://www.informationfreeway.org/index.php?lat=50.586237448340974lon=6.448052363286663user=torstikozoom=17layers=0F0B0F sieht man eine Stelle, wo so etwas vor kommt. Es handelt sich hier nicht um eine Fußgängerzone, sondern um einen Platz, an dem sich mehrere Fußwege treffen. In t...@h wird das schon korrekt dargestellt. Netter Gruß Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straße mit unterschiedl. Abschnitts merkmalen zur Relation machen?
Es gibt eine schmale Straße durch den Wald, Name Wartenbergweg, Gesamtlänge ca. 1 km. Der erste Teil ist eine außerörtliche unclassified-Straße mit freier Durchfahrt. Dann kommt ein Abschnitt mit gleicher Breite und gleichem Belag, dort dürfen nur Anlieger durch. Daran schließt sich ein Abschnitt an, wo der Weg unter gleichem Namen ein forstwirtschaftlicher Weg (track grade 2) ist, und zuletzt kommt wieder ein geteertes Anlieger-frei-Stück mit einigen Häusern, mit dem Auto von der anderen Seite anzufahren. Auch der Track-Teil im Wald heißt ausdrücklich so und ist hier unter diesem Namen der Bevölkerung geläufig. Macht es Sinn, diese Abschnitte zu einer Relation Wartenbergweg zusammenzufassen? Oder ist so etwas nicht nötig und/oder nicht üblich? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedl. Abschnitts merkmalen zur Relation machen?
Hi! Johannes Haller schrieb: Macht es Sinn, diese Abschnitte zu einer Relation Wartenbergweg zusammenzufassen? Oder ist so etwas nicht nötig und/oder nicht üblich? Derzeit macht es keinen Unterschied, es wird meines Wissens von jeglicher Software ignoriert. Nachdem es schwer vorherzusagen ist, wie so eine Relation aussehen muß, wenn sie irgendwann mal technisch ausgewertet werden kann, macht es auch nicht viel Sinn, sie schon mal auf Vorrat anzulegen, wahrscheinlich mußt Du sie eh nochmal anlangen. Insofern würde ich sagen: Es ist egal, ich würd's lassen. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hausnummern in Straßennamen?
Hallo zusammen, gibt es einen Konsenz für oder gegen die Aufnahme von Hausnummern in Straßennamen? An der Straße gibt es ja die öfter Schilder in abgehende Wege wie Beispielstraße 25-31. Anscheinend nehmen manche User die Regel die Namen zu schreiben wie auf den Schildern angegeben wortwörtlich. Ich find's Blödsinn, lösche aber ungerne aus dem Bauch heraus anderer Leute Arbeit. Grüße, Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedl. Abschnitts merkmalen zur Relation machen?
Hallo. Am Samstag, 31. Januar 2009 schrieb Johannes Haller: Es gibt eine schmale Straße durch den Wald, Name Wartenbergweg, Gesamtlänge ca. 1 km. Der erste Teil ist eine außerörtliche unclassified-Straße mit freier Durchfahrt. Dann kommt ein Abschnitt mit gleicher Breite und gleichem Belag, dort dürfen nur Anlieger durch. Daran schließt sich ein Abschnitt an, wo der Weg unter gleichem Namen ein forstwirtschaftlicher Weg (track grade 2) ist, und zuletzt kommt wieder ein geteertes Anlieger-frei-Stück mit einigen Häusern, mit dem Auto von der anderen Seite anzufahren. Auch der Track-Teil im Wald heißt ausdrücklich so und ist hier unter diesem Namen der Bevölkerung geläufig. Macht es Sinn, diese Abschnitte zu einer Relation Wartenbergweg zusammenzufassen? Oder ist so etwas nicht nötig und/oder nicht üblich? Ich glaube, du verwechselst da was. Die Wege-Relationen die hier intensiv diskutiert worden sind, sind Wanderwege im Sinne von Fernwanderwegen. Was du hast, ist im Endeffekt eine Straße, die Ihre Beschaffenheit bzw. Ihre Merkmale ändert. Das ist wie eine normale Wohnstraße, die ein Stck weit eine Einbahnstraße ist. Natürlich kann das auch mal Feldweg-Charakter zwischen drin haben oder auch ganz gesperrt sein. Es gibt zusätzlich die Überlegung, auch solche Wege aus mehreren Stückchen als Relation zu erfassen und alles was bei den Stückchen gleich ist, an die Relation zu taggen. Das ist momentan überhaupt nicht verbreitet, weil noch keiner so genau weiß ob das wirklich einen Vorteil bringt oder ob das nur den typisch deutschen Ordnungssinn zufrieden stellt. In deinem Fall ist das recht klar, dass ich da einfach den Namen an die Weg-Stücke hängen würde. auch Waldwege können explizite Namen haben, das macht sie aber nicht gleich zu einer Route. Gruß, Bernd -- Nehmen wir einmal an, es gäbe keine hypothetischen Situationen... 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] Hausnummern in Straßennamen?
Hallo. Am Samstag, 31. Januar 2009 schrieb Rolf Bode-Meyer: An der Straße gibt es ja die öfter Schilder in abgehende Wege wie Beispielstraße 25-31. Anscheinend nehmen manche User die Regel die Namen zu schreiben wie auf den Schildern angegeben wortwörtlich. Ich find's Blödsinn, lösche aber ungerne aus dem Bauch heraus anderer Leute Arbeit. Ich find' ebenfalls Blödsinn und würde das umtaggen. Aber nur, wenn ich die Hausnummern gleich platzieren kann, denn vielleicht war es für den betreffenden Mapper eher eine Gedankenstütze, dass dort noch diese Hausnummern zu finden sind. Dann könnte es übergangsweise auch sinnvoll sein. Dauerhaft sicher nicht. Man kann sich nach örtlichen Gegebenheiten überlegen ob diese (vermutlich) Stichstraße dann ein residential- oder ein service-Weg ist, der bekommt (wenn er ne erkennbare Länge hat) den gleichen Namen wie die namensgebende Straße und die Hausnummern werden ja eh separat erfasst. Ein Navi weiß ja dann, dass es die betreffenden Hausnummern über diese Stichstraße erreicht. Gruß, Bernd -- To do is to be - Descartes To be is to do - Sartre Do be do be do - Frank Sinatra 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] Liebe Renderer,
Jan Tappenbeck schrieb: nachdem vor einigen Tagen Gerrit einen Vorschlag für die Erfassung von Bushaltestellen [1] gemacht hat ist Lübeck von ihm als Testgebiet ausgesucht worden. Danach werden dann auch NODES als Platformen für die Bushaltestelle verwendet ! Sollte somit auch Berücksichtigung finden ! Dafür bin ich auch. Man sollte direkt die Relations auslesen. Wenn neben dem bus_stop auch noch die beiden (oder eine Platform) gesetzt ist, sollte der Node nicht gerendert werden. Man müsste vielleicht noch irgendwie angeben, dass diese oder jene Haltestalle nur eine statt zwei Haltepunkte hat, also nur links oder nur rechts und nicht beidseitig. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern in Straßennamen?
Rolf Bode-Meyer schrieb: Hallo zusammen, gibt es einen Konsenz für oder gegen die Aufnahme von Hausnummern in Straßennamen? An der Straße gibt es ja die öfter Schilder in abgehende Wege wie Beispielstraße 25-31. Anscheinend nehmen manche User die Regel die Namen zu schreiben wie auf den Schildern angegeben wortwörtlich. Ich find's Blödsinn, lösche aber ungerne aus dem Bauch heraus anderer Leute Arbeit. Ich habs auch erst gemacht, finds inzwischen aber eigentlich auch nicht sinnvoll, da es eigentlich ja nur ein Hinweis für Adressensuchende ist, nicht ein anderer Straßenname. Wo die jeweiligen Adressen liegen, kann man über das Karlsruhe Schema angeben. Man schreibt ja auch sonst die Information an die Stelle an die sie gehört, nicht an die Stelle wo sie auf einem Schild stand. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern in Straßennamen?
Hi, Am 31. Januar 2009 17:56 schrieb Sebastian Hohmann m...@s-hohmann.de: Rolf Bode-Meyer schrieb: An der Straße gibt es ja die öfter Schilder in abgehende Wege wie Beispielstraße 25-31. Anscheinend nehmen manche User die Regel die Namen zu schreiben wie auf den Schildern angegeben wortwörtlich. Ich find's Blödsinn, lösche aber ungerne aus dem Bauch heraus anderer Leute Arbeit. Ich habs auch erst gemacht, finds inzwischen aber eigentlich auch nicht sinnvoll, da es eigentlich ja nur ein Hinweis für Adressensuchende ist, nicht ein anderer Straßenname. Das ist unter anderem auch dann suboptimal, wenn man Straßenlisten extrahiert oder Routing machen möchte. Tschüss, Tim. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedl. Abschnitts merkmalen zur Relation machen?
Nop schrieb: Hi! Johannes Haller schrieb: Macht es Sinn, diese Abschnitte zu einer Relation Wartenbergweg zusammenzufassen? Oder ist so etwas nicht nötig und/oder nicht üblich? Derzeit macht es keinen Unterschied, es wird meines Wissens von jeglicher Software ignoriert. Nachdem es schwer vorherzusagen ist, wie so eine Relation aussehen muß, wenn sie irgendwann mal technisch ausgewertet werden kann, macht es auch nicht viel Sinn, sie schon mal auf Vorrat anzulegen, wahrscheinlich mußt Du sie eh nochmal anlangen. Es gibt schon Vorschläge, z.B. auch in Verbindung mit der Adresseneingabe[1]. Es ist auch nicht unbedingt falsch es zu benutzen, denn erst dann weiß man, ob es auch benutzbar ist. Natürlich könnte man es vielleicht auf ein kleineres Gebiet begrenzen (für sich selbst). Die street-Relation wurde immerhin schon 500 Mal in Europa benutzt. 1: http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Collected_Ways#Street-Relation_and_Karlsruhe_Schema Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GroundTruth Anomalien...
hi, schaut mal hier http://wiki.openstreetmap.org/wiki/Talk:GroundTruth#Problems für einige eigenartige ergebnisse auf meinem etrex legend HCx. generiert mit groundtruth. jemand eine idee? danke gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Stephan Wolff schrieb: ... Als Vereinfachung könnte man vereinbaren, dass Highway und waterway immer mit einer Brücke kreuzen, wenn nicht highway=ford angegeben ist. Gleiches könnte man für Autobahn und Feldweg/Fussweg/... vereinbaren, müsste aber dann zumindest über ein layer-Tag die Lage angeben. Alternativ könnte man auch einen gemeinsamen Punkt beider Wege mit bridge=yes beschriften, um zu zeigen, dass dort _keine_ Verbindung ist. Bei Map_Features sind auf der Übersichtsseite sowohl auf der deutschen wie englischen Seite Brücken als Way und Node eingetragen. Im Text zu bridge findet sich dann aber nur noch way. Gab es schon mal Brücken offiziell als Node? Im Tagwatch sind es 1% aller Brücken. mMn sind das sehr gute Ideen, die sich lohnen darüber mal ernsthaft zu diskutieren, um sie dann umzusetzen. Ärgern sich auch andere über diese Brückenkonstruktion oder bin ich der einzige? Nein, da bist Du bestimmt nicht der Einzigste :-( MfG Angie -- --BEGIN H*KEY BLOCK- v4sw5CPUhw5pr5FPck2ma8u7Lw3XGm1l7ELi3JNTe7t4TNDVb5Oen5g3/2ZMa4XsSr1p7 md815ac000ee3000447497af925b245955 ---END H*KEY BLOCK-- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
Hallo zusammen. Ich hatte ja die letzten Wochen bereits ab und zu etwas dazu geschrieben. Inzwischen habe ich eine ganze Anzahl von Bus-/Tram und Bahn-Strecken eingetragen und dabei (wenn ich damit nicht zuviel bestehendes kaputt mache) ein neues Schema zum Eintragen von Haltestellen verwendet. Die Erfahrungen damit waren eigentlich durchweg gut. Daher habe ich das ganze nochmal etwas formaler aufgeschrieben und stelle es hiermit zur Diskussion. Ich möchte alle, die sich für das Thema ÖPNV, Bahn etc. interessieren, bitten, sich das anzugucken und vielleicht einige interessantere Haltestellen in ihrem Gebiet entsprechend zu taggen (oder das zumindest im Kopf durchzuspielen). :) Gerrit Proposal zum einheitlichen Taggen von allen Haltestellen des öffentlichen Verkehrs Probleme der aktuellen Schemata zum Eintragen von Haltestellen: -- - Es wird Uneinheitlich getaggt. Innerhalb des Busnetzes wird meist (aber nicht immer) die Position des Haltestellenschildes/Wartehäuschens eingetragen. Bei Schienengebundenen Systemen wird in der Regel auf der Schiene getaggt. - Wenn nur ein Punkt als Haltestelle markiert wird, geht Detailinformation verloren. Wenn jeder Halt eingezeichnet wird, wird es unübersichtlich auf der Karte. - Es können nicht alle Zusammenhänge ausreichend genau abgebildet werden. - Routing und andere Anwendungen profitieren von einem einheitlichen Modell Diese Probleme (und andere) soll der unten vorgestellte Vorschlag lösen. Dabei wurde besonderer Wert auf Abwärtskompatibilität zu bestehenden Schemata gelegt. Viele Detailangaben können (erstmal) weggelassen werden, damit ist ein umtaggen bestehender Stationen recht einfach (siehe unten). Bitte beteiligt Euch alle mit konstruktiver Kritik und Vorschlägen um eventuelle Unrundheiten rechtzeitig ausmerzen zu können. Begriffsdefinition: [Haltepunkt] := Der Ort auf der Schiene/Straße (evtl. separate Busspur) wo das Gefährt anhält um Zustieg zu ermöglichen [Plattform]: Ort an dem Fahrgäste auf das Eintreffen des Fahrzeuges warten. Etwa der Bahnsteig beim Zug oder der Abschnitt des Bürgersteigs wo H-Schild, Bänke, Häuschen stehen. [Haltestelle] := Alle Elemente die relevant sind für den ÖPNV und die den selben Namen tragen zusammengenommen. Die [Haltestelle] Braunschweig Hauptbahnhof besteht etwa aus 8 [Haltepunkten] (Gleise auf denen Züge halten können) und 4 [Plattformen] (Bahnsteige). Eine einfache Bushaltestelle besteht etwa aus zwei [Haltepunkten] und zwei [Plattformen] (jeweils für eine Fahrtrichtung). Grundelemente -- 1. (relation) type=site; site=stop_area Die Relation bildet das logische Gebilde [Haltestelle] ab. Ihre Mitglieder sind also alle [Plattformen] und [Haltepunkte], die zusammengehören. 2. (node) highway=bus_stop, railway=tram_stop | halt Dieser Knoten bezeichnet einen [Haltepunkt] des entsprechenden Verkehrsträgers und liegt auf dem Way (Straße/Schiene). 3. (way | node) highway=platform An einem Way bedeutet dieser Schlüssel, dass es sich bei dem Stück um eine [Plattform] handelt. Am Knoten bezeichnet er die Position des Haltestellenschildes (mit Fahrplan etc). Weitere Details/Optionales - 1a. [Haltestelle] (also die Relation) bekommt alle Attribute, die für alle ihre Mitglieder gelten, also etwa Name, Operator, Öffnungs-/Betriebszeiten (bei Bahnhöfen), ... 1b. Zur [Haltestelle] können auch andere passende Elemente hinzugefügt werden, wie Fahrkartenautomaten, Kundeninformation, etc. 1c. Wenn die [Haltestelle] nur aus dem [Haltepunkt] besteht, kann auf die Relation verzichtet und die Attribute an diesen Punkt gesetzt werden (Relation wird erst dann erstellt, wenn weitere Elemente dazu genommen werden sollen.) 2a. [Haltepunkte] werden in die entsprechenden Routen-Relationen aufgenommen ([Plattformen] nicht!). 2b. Es können zur Vereinfachung mehrere tatsächliche Haltepunkte in einen oder wenige [Haltepunkte] zusammengefasst werden, wenn diese nicht zu weit auseinander liegen (Bsp: Eine Dorfstraße hat zwei gegenüberliegende [Plattformen] und nur einen [Haltepunkt] für beide Richtungen; Wichtig ist das für jede Route-Relation ein korrekter [Haltepunkt] existiert. Bei Bahnhöfen werden daher immer alle tatsächlichen Haltepunkte eingetragen) 2c. Übergangsweise kann ein möglichst zentral liegender [Haltepunkt] mit zusätzlichem Name-Tag versehen werden um in der Karte schon jetzt gerendert zu werden. 3a. Bei der [Plattform] wird bei Nicht-Eindeutigkeit (etwa: Bus- und Tramverkehr führt vorbei) mittels bus=yes;tram=yes oder train=no;light_rail=yes angegeben welches Verkehrsmittel an dieser [Plattform] hält. 3b. Weitere Eigenschaften (etwa Wartehäuschen) können entweder als Eigenschaften an der [Plattform] (shelter=yes) eingetragen werden oder als extra node (amenity=shelter), der in die
Re: [Talk-de] Liebe Renderer,
Hi Jan, Torsten und co. Jan Tappenbeck wrote: nachdem vor einigen Tagen Gerrit einen Vorschlag für die Erfassung von Bushaltestellen [1] gemacht hat ist Lübeck von ihm als Testgebiet ausgesucht worden. Danach werden dann auch NODES als Platformen für die Bushaltestelle verwendet ! Sollte somit auch Berücksichtigung finden ! Ich habe dazu gerade einen neuen Thread aufgemacht in dem ich meine Gedanken nochmal zusammengefasst habe. Demnach würde ich vorschlagen Ways mit highway=platform als graue Wege zu rendern (ähnlich Fußgängerzone). Einzelne Nodes mit highway=platform könnten auf der Karte als Symbol auftauchen. Notfalls als generalisiertes Haltestellenschild, idealerweise in Deutschland (z.B. öpnvkarte.de) mit den entsprechenden Symbolen für den Verkehrstyp: http://de.wikipedia.org/wiki/Datei:Zeichen_224.svg http://de.wikipedia.org/w/index.php?title=Datei:S-Bahn-Logo.svg http://de.wikipedia.org/w/index.php?title=Datei:Ubahnlogo.svg ... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
On Sat, 31 Jan 2009, Stefan Hirschmann wrote: immer wenn ich sehr kurze Brücken eingeben muss, ärgere ich mich über das umständliche Verfahren. Als kurze Brücken würde ist solche unter 5 Meter Länge verstehen. Ich gebe solche Brücken überhaupt nicht ein. Bach Layer=-1 und Straße Layer=0 und alles wird korrekt dargestlelt und sogar der Validator ist zufrieden. Und ein intelligentes Auswerteprogramm weiß sowieso, dass es eine Brücke sein muss, bzw. dass auf jeden Fall die Straße drüber geht. Ersteinmal: Ob der Validator zufrieden ist oder nicht hat nichts zu sagen. Deswegen hat der auch 3 Klassen. Fehler - Das ist wirklich falsch Warnung - Das ist in der Regel falsch Info - Das ist manchmal falsch, aber vielleicht auch nicht - Nutzer, entscheide Du. Und deshalb gibt es auch eine Ignorieren-Option. Das Eintragen von eigenen Daten daran anzupassen halte ich für fragwürdig. Wenn da eine Brücke ist, sollte man das auch eintragen. Immerhin gibt es auch andere Möglichkeiten (Rohre, Tunnel, Äquadukte, Wurmlöcher, was weiß ich). Allerdings geb ich dem Originalposter recht: Für Minibrücken wäre ein bridge=yes auf Knoten hübsch. Nur muss man dann auch die Layer-Tags setzen und dadurch laufen dann zwei verschiedene Layer in einem Punkt zusammen. Das hat auch wieder eine Menge Schattenseiten. Die Idee ist also eher doch nicht so gut und das bisherige Schma vorzuziehen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Am 31. Januar 2009 02:50 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Stephan Wolff schrieb: Moin, immer wenn ich sehr kurze Brücken eingeben muss, ärgere ich mich über das umständliche Verfahren. Als kurze Brücken würde ist solche unter 5 Meter Länge verstehen. Das sind meist Brücken über Gräben, Bäche und kleine Flüsse oder Orte, ... ... und die Schnittpunkte auf etwa 3m zusammenschieben. ... und bei mehrelementigen Wegen (Straße + Radweg) steigt der Aufwand nochmals. Am Ende stellt Osmarender den Bach in gerundeten Schleifen dar und führt ihn komplett an der Minibrücke vorbei. Ärgern sich auch andere über diese Brückenkonstruktion oder bin ich der einzige? Ich ärgere mich zumindest hier nicht ... Gruß, ULFL ich ärgere mich auch nicht. Ich finde, Du übertreibst das Problem, weil Dir kleine Brücken nicht viel bedeuten. Die Brücken werden im Laufe des Threads immer kleiner, von 5 auf 3 m und dann sollen da plötzlich mehrspurige Straßen drübergehen, ich kann das nicht direkt nachvollziehen, aber m.E. ist es sehr sinnvoll, Brücken mit ihrer Länge und nicht als Punkt abzubilden, und zwar unabhängig von der Brückenlänge. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
Hallo, Gerrit Lammert schrieb: 3. (way | node) highway=platform An einem Way bedeutet dieser Schlüssel, dass es sich bei dem Stück um eine [Plattform] handelt. Am Knoten bezeichnet er die Position des Haltestellenschildes (mit Fahrplan etc). Warum die Einschränkung auf way/node? Area ist ebenso denkbar. Sonst kannste nich meckern. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Am 31. Januar 2009 11:50 schrieb Stephan Wolff s.wo...@web.de: Dann muss ich aus einem Kreuzungspunkt, den ich grob vermessen habe, schon vier Punkte generieren. wieso 4? Eine Brücke besteht aus 2, ANfang und Ende. Gerade die Bachläufe kann ich nur ungenau aus den in SH sehr groben Yahoo-Luftbildern entnehmen. Dabei treten oft 10 - 30m Versatz zu meinen GPS-Koordinaten auf, so dass ich den Bach meist nur grob mit wenigen Stützpunkten einzeichne. das ist ja mangels besserer Daten teilweise erstmal nicht anders möglich, aber unter der Brücke sollte er halt durchfliessen, und das musst Du dementsprechend anpassen. Ich halte die jetzige Konstruktion für fehleranfälliger. Wenn jemand ein Straßenteilstück um wenige Meter verschiebt, treten an der Minibrücke große Richtungssprünge auf. Bei Verschiebung in Längsrichtung um mehr als eine Brückenlänge würde die Straße sogar hin, über die Brücke zurück und wieder hin laufen. sorry, aber die Leute, die mal eben so ganze ways verschieben, ohne an den Enden und Verbindungen hinzusehen, was sie anrichten, habe ich sowieso gefressen. Wer so grob drauf ist dem würde ich empfehlen, nur einzelne Punkte und nie den ganzen way zu verschieben oder noch besser, Openstreetbugs als Editor zu verwenden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] smoothness-Tag
Am 31. Januar 2009 13:50 schrieb Sebastian Hohmann m...@s-hohmann.de: Ich wäre eher für weniger Werte (maximal 5), die sich dann auch genauer voneinander abgrenzen lassen. Zwar bleibt es subjektiv, aber das ist in OSM doch so vieles. Solange man in etwa rauslesen kann, ob der Weg jetzt komplett 'smooth' ist oder eher was für Mountainbiker, ist das schon ein Mehrwert. Zum Beispiel: grade1 Keinerlei Unebenheiten weit und breit, sehr angenehm für alle Fahrzeuge grade2 Einige leichte Bodenwellen oder flache Schlaglöcher grade3 Schlaglöcher und Bodenwellen tiefer, so dass man mit dem Rad auch gerne mal das Tempo etwas verringern möchte grade4 Tiefe Löcher, Risse oder große Steine Entsprechende Bilder müssten das Ganze noch verdeutlichen, damit man auch sicher gehen kann, dass man in etwa das Gleiche meint. Ich denke das ist schon leichter zu unterscheiden, als doppelt so viele Werte, mit so interessanten Dingen wie very_... ja, wenige grades von 1 bis 5 halte ich auch für am Besten, allerdings sind Deine Kriterien nur an bestigten Straßen orientiert, zusätzlich müsste man für Schotterpisten, Erdboden, Sandboden, Fels, Holzbohlen, Pflaster, etc. festlegen, was das jeweils in grades bedeutet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] netzwerkspezifische Farben bei ÖPNV
moin, neuerdings hat Google einen http://maps.google.de/maps/mpl?moduleurl=http:%2F%2Fwww.gmapplets.com%2Ftransit%2Flci=transitie=UTF8ll=53.553407,9.992196spn=0.072099,0.154495z=13 siehe Hamburger Liste dieser ist nicht grade von hoher Qualität, aber es hat mich auf eine Idee gebracht: Jedes Netzwerk hat seine eigenen Farben: in Hamburg zb:S-Bahnen=grün usw diese Farben sind allerdings in vielen Städten verschieden. diese Farben werden offiziell vom Netzwerk festgelegt. Ich schlage vor diese Farbe in die routen Relationen mit aufzunehmen: zb könnte man es so taggen: network:color=* ich habe da an die css Farbdarstellung gedacht, da sie leicht verarbeitbar und eindeutig ist: die Hamburger S1 hat zb ungefähr die Farbe #33b540 dh: network:color=#33b540 über Gegenvorschläge und Anmerkungen freue ich mich Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern in Straßennamen?
On Sat, Jan 31, 2009 at 05:39:32PM +0100, Rolf Bode-Meyer wrote: Subject: [Talk-de] Hausnummern in Straßennamen? Hallo zusammen, gibt es einen Konsenz für oder gegen die Aufnahme von Hausnummern in Straßennamen? An der Straße gibt es ja die öfter Schilder in abgehende Wege wie Beispielstraße 25-31. Anscheinend nehmen manche User die Regel die Namen zu schreiben wie auf den Schildern angegeben wortwörtlich. Ich find's Blödsinn, lösche aber ungerne aus dem Bauch heraus anderer Leute Arbeit. Dann setz es um - d.h. name=Beispielstraße, note=Hausnummern 25-31. So tagge ich das wenn ich sowas finde. Muss man ggfs nich nochmal hinfahren wenn man es braucht ... Am besten ist aber gleich Hausnummern nodes zu setzen - ist klar oder? Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
Am 31.01.2009 19:30, Gerrit Lammert: (...) neues Schema zum Eintragen von Haltestellen (...) Danke, jetzt verstehe ich endlich, was du in deinen letzten Mailinglistenposts gemeint hast. Jetzt macht das auch Sinn. Ich finde es gut. Im Wiki konnte ich deinen Text noch nicht finden. Ist als Text-Mail so schlecht lesbar. Als Beispiel könntest du noch den Umstieg von meinem bisherigen Tagging darstellen. Ich habe bisher die Haltestellen in jeder Fahrtrichtung als bus_stop-Knoten *auf* dem Weg gemappt. Wenn ich es richtig verstehe wäre der Umstieg: - Platform-Nodes auf der richtigen Straßenseite für die Wartebereiche der Passagiere - Relation, die die beiden bus_stops und die beiden platform-Nodes als Haltestellen-site zusammenfasst. Korrekt? Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Linien richtig taggen?
Hallo, Diese beinhaltet die beiden Busshäuschen neben der Straße als highway=platform und die Nodes auf der Straße als highway=bus_stop. Das bringt aber nichts für asymetrische Bushaltestellen. Die Haltestelle wurde bisher ja nur neben die Straße gesetzt um aanzuzeigen, daß sie nur einseitig benutzt wird, dies erreicht man aber auch durch das forward_stop/... Würde man jetzt zu der von Dir genannten Relation übergehen müßte man ja auch wieder einen Node auf die Straße seztzen, dann ist aber der Node neben der Straße unnötig, es sei denn jemand will wirklich anzeigen wo das Wartehäuschen steht, aber darum ging es ja nicht. Lies das am Besten nochmal. Hab ich und brachte meiner Meinung nach nichts. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] BAB - Beginn der Verz?gerungsspur
Am 31. Januar 2009 01:38 schrieb Heiko Jacobs heiko.jac...@gmx.de: Wo wir es gerade vom Wiki haben... Sehe gerade, dass dort steht, goods gaebe es in .de nicht. Natuerlich gibt's Kleinlieferwagen 3,5t in .de. Sie sind blosz nirgends per Lkw-Verbotsschild ausgeschlossen. Fuer Faelle wie Lieferverkehr frei koennte man aber goods=yes oder goods=detination brauchen? was soll das bringen? Lieferverkehr ist an keine Fahrzeugklasse gebunden, das kann genausogut per Auto oder Fahrrad stattfinden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Framework für die Kartendarstellung - Existent ???
Hi ! gibt es eigentlich eine Art Framework (ich bezeichne es einmal so) bei dem nicht nur die Anzeige von Tracks und Points, wie schon aus manchen Beispielen ersichtlich, über zugehörige Navi-Schalter an der Seite erstellt werden können. Ich meine hierbei nicht die mit + aufklappbaren Leisten wie wir diese von OSM kennen - das ist für den Themen-Fremden Anwender etwas zu speziell. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MapSource_6153 - Fehlermeldung unter Vista 64bit
2009/1/30 Holger Issle hol...@issle.de: On Fri, 30 Jan 2009 18:18:29 +0100, Martin Koppenhoefer wrote: hm, bei mir tut mapsource seit dem Update ueberhaupt nicht mehr, auch dann nicht, wenn ich die Registry-Keys fuer die OSM-Karte komplett loesche. Per Hand lösche oder mit mapsettoolkit? Welche Karten hast Du installiert, und wie? Ist der update ordentlich gelaufen? Weil, hier tuts problemlos... -- soweit ich das gesehen habe, war das Update problemlos, habe ihm allerdings das nachhausetelefonieren per Firewall verboten. Ich habe inzwischen auch keine Lust mehr, mich länger mit dieser proprietären Software von/fürs Garmin auseinanderzusetzen. Habe mir mittlerweile GPS-Babel und QLandkarte installiert und wandle mit Symname2text (oder so ähnlich) die Bildchen in lesbaren Text um. So komme ich auch ohne Mapsource aus, ohne EInschränkungen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
moin, ich denke das ist ein sehr durchdachter Vorschlag, auf den mit wenig Aufwand sogar automatisch umgestellt werden könnte. (alle Haltestellen, die auf der Straße/Schiene liegen sind Haltepunkte alle die daneben liegen sind Plattformen) folgende Kritik Punkte habe ich, die allerdings meine Zustimmung zum vorschlag nicht in fragestellen: zu 2b: ich denke das währe nicht sinnvoll Haltepunkte zusammen zufassen. zu 2c: ich denke jeder Haltepunkt sollte einen Namen bekommen dürfen zb Halt 2b da teilweise mehrere Haltepunkte an einer Plattform seien können zu amenity=station: bitte stapaziere amenity nicht zu sehr und nutze einen besseren tag zb transport=station zu Plattform Rendering: da es manche Plattformen gibt, auf denen auch Fahrradfahrer fahren dürfen, sollte es so gerendert werden wie path. alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Framework für die Kartendarstellung - Existent ???
Am Samstag, den 31.01.2009, 21:54 +0100 schrieb Jan Tappenbeck: Hi ! gibt es eigentlich eine Art Framework (ich bezeichne es einmal so) bei dem nicht nur die Anzeige von Tracks und Points, wie schon aus manchen Beispielen ersichtlich, über zugehörige Navi-Schalter an der Seite erstellt werden können. Ich meine hierbei nicht die mit + aufklappbaren Leisten wie wir diese von OSM kennen - das ist für den Themen-Fremden Anwender etwas zu speziell. Hallo Jan, damit hast Du schon mal gesagt, was Du nicht haben möchtest. Was jetzt noch fehlt ist, wie Du dir das gewünschte vorstellst :-) Grüßle, detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frankenweg
Im Frankenweg gibt es fehlende Segmente von wenigen Metern Länge: http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=28417 Wer kann da mal drüberschauen, und die Fehler beheben, damit man erkennen kann, wo noch richtige Etappen kartografiert werden müssen? Danke, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM und Programmbilder
Hallo, nachdem letztens der Aufruf zum Ergänzen der Web-Links in den Objektvorlagen ein voller Erfolg war, versuche ich einen zweiten Aufruf. Die Bilder der Objektvorlagen von JOSM sind leider nicht vollständig. Wer malt also Bildchen für die fehlenden Elemente? Oder bessere für existierende Elemente? Die momentanen Bilder sind hier zu finden: http://josm.openstreetmap.de/svn/trunk/images/presets/ Idealer Zustand: Alle Elemente haben ein eigenes Bild (unterscheidbar in der Toolbar) - Das heißt die bisher doppelt genutzten Bilder werden auch ersetzt Guter Zustand: Alle Elemente haben ein Bild - Alle fehlenden bekommen ein neues (oder notfalls altes) Bild Bisheriger Zustand: Einige Bilder fehlen. Um Doppelarbeit zu vermeiden vielleicht hier auf der Liste eine kurze Notiz, wenn jemand an einem Bild arbeitet. Was wird gebraucht: PNG's mit 32x32 Pixeln und transparentem Hintergrund (sollte auf typischen Bildschirmeinstellungen gut aussehen - also i.d.R. grauer Hintergrund) P.S. Das malen von so kleinen und erkennbaren Bildern ist übrigens nicht gerade leicht. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Framework für die Kartendarstellung - Existent ???
meinst du sowas? http://j-po.de/datei/osm/?zoom=14lat=53.58012lon=9.70206layers=B0T ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] netzwerkspezifische Farben bei ÖPNV
Am 31.01.2009 21:31, Josias: Ich schlage vor diese Farbe in die routen Relationen mit aufzunehmen: zb könnte man es so taggen: network:color=* ich habe da an die css Farbdarstellung gedacht, da sie leicht verarbeitbar und eindeutig ist: die Hamburger S1 hat zb ungefähr die Farbe #33b540 dh: network:color=#33b540 über Gegenvorschläge und Anmerkungen freue ich mich Den identischen Vorschlag habe ich bereits letzte Woche als optionales Attribut der Routen-Relation [1] aufgenommen, nachdem wir darüber bereits hier auf der Mailingliste darüber diskutiert [2] haben. Allerdings sieht mein Vorschlag vor, der Route einer Bus- oder Tram-, Metro-, Fähr-, oder Was-auch-immer-Linie direkt die Farbe zuzuweisen. Das jetzt auch du auf die Idee kommst spricht für diesen Vorschlag. Gruß, Claudius [1] http://wiki.openstreetmap.org/wiki/Relation:route [2] http://lists.openstreetmap.org/pipermail/talk-de/2009-January/035086.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relationproblem: Route 'springt'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Habe folgendes Problem: Die Route des Busses 26 lässt sich nicht korrekt darstellen im RelationAnalyser: http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=70597useCache=false Mache ich irgendwas falsch oder ist das Analyzer da einfach noch zusehr 'beta'? Danke für etwaige Tips! Gruß - Fips - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJhNbNnHVyAFIfTkERAkQOAJ4qCgjs79p3d73N3QmL/Jcq8zjl+wCgj8Pc 2tFXI8VIYGTFKgIggYqwRME= =Odob -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zwei Fragen hab ich dann: - - Habe ich richtig verstanden, dass die Bahnsteige/platforms NICHT in die Relation sollen? Finde die gehören auch eigentlich dazu, bei Bussen wie bei Bahnen. Insbesondere sollten die U-Bahn-Zugänge auch zur Relation dazu. - - Soll wirklich highway=platform verwendet werden? Bisher heissen alle Bahnsteige railway=platform, denke nicht, dass wir das ändern sollten zudem es außerhalb DE durchaus platforms gibt, die nur mit Fahrkarte zu erreichen sind, war dann wieder Eisenbahntechnischer ist, etc. Ansonsten finde ich das ganze eine super Vorgehensweise! - - Fips - -- Gerrit Lammert schrieb: Hallo zusammen. Ich hatte ja die letzten Wochen bereits ab und zu etwas dazu geschrieben. Inzwischen habe ich eine ganze Anzahl von Bus-/Tram und Bahn-Strecken eingetragen und dabei (wenn ich damit nicht zuviel bestehendes kaputt mache) ein neues Schema zum Eintragen von Haltestellen verwendet. Die Erfahrungen damit waren eigentlich durchweg gut. Daher habe ich das ganze nochmal etwas formaler aufgeschrieben und stelle es hiermit zur Diskussion. Ich möchte alle, die sich für das Thema ÖPNV, Bahn etc. interessieren, bitten, sich das anzugucken und vielleicht einige interessantere Haltestellen in ihrem Gebiet entsprechend zu taggen (oder das zumindest im Kopf durchzuspielen). :) Gerrit Proposal zum einheitlichen Taggen von allen Haltestellen des öffentlichen Verkehrs Probleme der aktuellen Schemata zum Eintragen von Haltestellen: -- - Es wird Uneinheitlich getaggt. Innerhalb des Busnetzes wird meist (aber nicht immer) die Position des Haltestellenschildes/Wartehäuschens eingetragen. Bei Schienengebundenen Systemen wird in der Regel auf der Schiene getaggt. - Wenn nur ein Punkt als Haltestelle markiert wird, geht Detailinformation verloren. Wenn jeder Halt eingezeichnet wird, wird es unübersichtlich auf der Karte. - Es können nicht alle Zusammenhänge ausreichend genau abgebildet werden. - Routing und andere Anwendungen profitieren von einem einheitlichen Modell Diese Probleme (und andere) soll der unten vorgestellte Vorschlag lösen. Dabei wurde besonderer Wert auf Abwärtskompatibilität zu bestehenden Schemata gelegt. Viele Detailangaben können (erstmal) weggelassen werden, damit ist ein umtaggen bestehender Stationen recht einfach (siehe unten). Bitte beteiligt Euch alle mit konstruktiver Kritik und Vorschlägen um eventuelle Unrundheiten rechtzeitig ausmerzen zu können. Begriffsdefinition: [Haltepunkt] := Der Ort auf der Schiene/Straße (evtl. separate Busspur) wo das Gefährt anhält um Zustieg zu ermöglichen [Plattform]: Ort an dem Fahrgäste auf das Eintreffen des Fahrzeuges warten. Etwa der Bahnsteig beim Zug oder der Abschnitt des Bürgersteigs wo H-Schild, Bänke, Häuschen stehen. [Haltestelle] := Alle Elemente die relevant sind für den ÖPNV und die den selben Namen tragen zusammengenommen. Die [Haltestelle] Braunschweig Hauptbahnhof besteht etwa aus 8 [Haltepunkten] (Gleise auf denen Züge halten können) und 4 [Plattformen] (Bahnsteige). Eine einfache Bushaltestelle besteht etwa aus zwei [Haltepunkten] und zwei [Plattformen] (jeweils für eine Fahrtrichtung). Grundelemente -- 1. (relation) type=site; site=stop_area Die Relation bildet das logische Gebilde [Haltestelle] ab. Ihre Mitglieder sind also alle [Plattformen] und [Haltepunkte], die zusammengehören. 2. (node) highway=bus_stop, railway=tram_stop | halt Dieser Knoten bezeichnet einen [Haltepunkt] des entsprechenden Verkehrsträgers und liegt auf dem Way (Straße/Schiene). 3. (way | node) highway=platform An einem Way bedeutet dieser Schlüssel, dass es sich bei dem Stück um eine [Plattform] handelt. Am Knoten bezeichnet er die Position des Haltestellenschildes (mit Fahrplan etc). Weitere Details/Optionales - 1a. [Haltestelle] (also die Relation) bekommt alle Attribute, die für alle ihre Mitglieder gelten, also etwa Name, Operator, Öffnungs-/Betriebszeiten (bei Bahnhöfen), ... 1b. Zur [Haltestelle] können auch andere passende Elemente hinzugefügt werden, wie Fahrkartenautomaten, Kundeninformation, etc. 1c. Wenn die [Haltestelle] nur aus dem [Haltepunkt] besteht, kann auf die Relation verzichtet und die Attribute an diesen Punkt gesetzt werden (Relation wird erst dann erstellt, wenn weitere Elemente dazu genommen werden sollen.) 2a. [Haltepunkte] werden in die entsprechenden Routen-Relationen aufgenommen ([Plattformen] nicht!). 2b. Es können zur Vereinfachung mehrere tatsächliche Haltepunkte in einen oder wenige [Haltepunkte] zusammengefasst werden, wenn diese nicht zu weit auseinander liegen (Bsp: Eine Dorfstraße hat zwei gegenüberliegende [Plattformen] und nur einen
Re: [Talk-de] Relationproblem: Route 'springt'
Am 31.01.2009 23:55, Fips Schneider: Habe folgendes Problem: Die Route des Busses 26 lässt sich nicht korrekt darstellen im RelationAnalyser: http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=70597useCache=false Mache ich irgendwas falsch oder ist das Analyzer da einfach noch zusehr 'beta'? Möglicherweise arbeitet der Analyzer auch nur auf einem einmal wöchentlich abgeglichenen Datenbestand und enthält einfach noch nicht die von dir aufgetrennten Straßen. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Achja: Was spricht dagegen, die Relation als type=station zu taggen? - - Fips - -- Gerrit Lammert schrieb: Hallo zusammen. Ich hatte ja die letzten Wochen bereits ab und zu etwas dazu geschrieben. Inzwischen habe ich eine ganze Anzahl von Bus-/Tram und Bahn-Strecken eingetragen und dabei (wenn ich damit nicht zuviel bestehendes kaputt mache) ein neues Schema zum Eintragen von Haltestellen verwendet. Die Erfahrungen damit waren eigentlich durchweg gut. Daher habe ich das ganze nochmal etwas formaler aufgeschrieben und stelle es hiermit zur Diskussion. Ich möchte alle, die sich für das Thema ÖPNV, Bahn etc. interessieren, bitten, sich das anzugucken und vielleicht einige interessantere Haltestellen in ihrem Gebiet entsprechend zu taggen (oder das zumindest im Kopf durchzuspielen). :) Gerrit Proposal zum einheitlichen Taggen von allen Haltestellen des öffentlichen Verkehrs Probleme der aktuellen Schemata zum Eintragen von Haltestellen: -- - Es wird Uneinheitlich getaggt. Innerhalb des Busnetzes wird meist (aber nicht immer) die Position des Haltestellenschildes/Wartehäuschens eingetragen. Bei Schienengebundenen Systemen wird in der Regel auf der Schiene getaggt. - Wenn nur ein Punkt als Haltestelle markiert wird, geht Detailinformation verloren. Wenn jeder Halt eingezeichnet wird, wird es unübersichtlich auf der Karte. - Es können nicht alle Zusammenhänge ausreichend genau abgebildet werden. - Routing und andere Anwendungen profitieren von einem einheitlichen Modell Diese Probleme (und andere) soll der unten vorgestellte Vorschlag lösen. Dabei wurde besonderer Wert auf Abwärtskompatibilität zu bestehenden Schemata gelegt. Viele Detailangaben können (erstmal) weggelassen werden, damit ist ein umtaggen bestehender Stationen recht einfach (siehe unten). Bitte beteiligt Euch alle mit konstruktiver Kritik und Vorschlägen um eventuelle Unrundheiten rechtzeitig ausmerzen zu können. Begriffsdefinition: [Haltepunkt] := Der Ort auf der Schiene/Straße (evtl. separate Busspur) wo das Gefährt anhält um Zustieg zu ermöglichen [Plattform]: Ort an dem Fahrgäste auf das Eintreffen des Fahrzeuges warten. Etwa der Bahnsteig beim Zug oder der Abschnitt des Bürgersteigs wo H-Schild, Bänke, Häuschen stehen. [Haltestelle] := Alle Elemente die relevant sind für den ÖPNV und die den selben Namen tragen zusammengenommen. Die [Haltestelle] Braunschweig Hauptbahnhof besteht etwa aus 8 [Haltepunkten] (Gleise auf denen Züge halten können) und 4 [Plattformen] (Bahnsteige). Eine einfache Bushaltestelle besteht etwa aus zwei [Haltepunkten] und zwei [Plattformen] (jeweils für eine Fahrtrichtung). Grundelemente -- 1. (relation) type=site; site=stop_area Die Relation bildet das logische Gebilde [Haltestelle] ab. Ihre Mitglieder sind also alle [Plattformen] und [Haltepunkte], die zusammengehören. 2. (node) highway=bus_stop, railway=tram_stop | halt Dieser Knoten bezeichnet einen [Haltepunkt] des entsprechenden Verkehrsträgers und liegt auf dem Way (Straße/Schiene). 3. (way | node) highway=platform An einem Way bedeutet dieser Schlüssel, dass es sich bei dem Stück um eine [Plattform] handelt. Am Knoten bezeichnet er die Position des Haltestellenschildes (mit Fahrplan etc). Weitere Details/Optionales - 1a. [Haltestelle] (also die Relation) bekommt alle Attribute, die für alle ihre Mitglieder gelten, also etwa Name, Operator, Öffnungs-/Betriebszeiten (bei Bahnhöfen), ... 1b. Zur [Haltestelle] können auch andere passende Elemente hinzugefügt werden, wie Fahrkartenautomaten, Kundeninformation, etc. 1c. Wenn die [Haltestelle] nur aus dem [Haltepunkt] besteht, kann auf die Relation verzichtet und die Attribute an diesen Punkt gesetzt werden (Relation wird erst dann erstellt, wenn weitere Elemente dazu genommen werden sollen.) 2a. [Haltepunkte] werden in die entsprechenden Routen-Relationen aufgenommen ([Plattformen] nicht!). 2b. Es können zur Vereinfachung mehrere tatsächliche Haltepunkte in einen oder wenige [Haltepunkte] zusammengefasst werden, wenn diese nicht zu weit auseinander liegen (Bsp: Eine Dorfstraße hat zwei gegenüberliegende [Plattformen] und nur einen [Haltepunkt] für beide Richtungen; Wichtig ist das für jede Route-Relation ein korrekter [Haltepunkt] existiert. Bei Bahnhöfen werden daher immer alle tatsächlichen Haltepunkte eingetragen) 2c. Übergangsweise kann ein möglichst zentral liegender [Haltepunkt] mit zusätzlichem Name-Tag versehen werden um in der Karte schon jetzt gerendert zu werden. 3a. Bei der [Plattform] wird bei Nicht-Eindeutigkeit (etwa: Bus- und Tramverkehr führt vorbei) mittels bus=yes;tram=yes oder train=no;light_rail=yes
Re: [Talk-de] netzwerkspezifische Farben bei ÖPNV
ok... da hab ich dann schon nicht mehr mitgelesen... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
Am 01.02.2009 00:22, Fips Schneider: Zwei Fragen hab ich dann: - - Habe ich richtig verstanden, dass die Bahnsteige/platforms NICHT in die Relation sollen? Finde die gehören auch eigentlich dazu, bei Bussen wie bei Bahnen. Insbesondere sollten die U-Bahn-Zugänge auch zur Relation dazu. Ich wollte erst schreiben: Eben nicht und das ist ja das schicke daran: An die Info kommst du ja über die Site-Relation der gesamten Haltestelle. Die für das Verkehrsmittel-Routing relevanten Daten liegen so alle in der Routing-Relation, die Detailinfos für das Fußgängerrouting zur richtigen Anlauf-Beschreibung liegt dann in der Site-Relation ...dabei hab ich dann gemerkt, dass mit diesem Modell ja gar nicht abgebildet werden kann, welche platform zu welchem bus_stop gehört (Was wichtig ist, wenn ich den Fußgänger auf die richtige Seite der Kreuzung zum Abfahrt in Richtung Hauptbahnhof lotsen will) ohne die Information zu verlieren, dass beide bus_stops ja dieselbe Haltestelle in verschiedenen Richtungen ausmachen. Spontan würde mir da nur eine Über-Relation für Haltestellen einfallen, die diese zu einer (auch möglichen Umsteige-)Haltestelle zusammenfassen. Auch unschön. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurze Brücken
Martin Koppenhoefer schrieb: Am 31. Januar 2009 02:50 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Stephan Wolff schrieb: immer wenn ich sehr kurze Brücken eingeben muss, ärgere ich mich über das umständliche Verfahren. Als kurze Brücken würde ist solche unter 5 Meter Länge verstehen. Das sind meist Brücken über Gräben, Bäche und kleine Flüsse oder Orte, ... ... und die Schnittpunkte auf etwa 3m zusammenschieben. ... und bei mehrelementigen Wegen (Straße + Radweg) steigt der Aufwand nochmals. Am Ende stellt Osmarender den Bach in gerundeten Schleifen dar und führt ihn komplett an der Minibrücke vorbei. ich ärgere mich auch nicht. Ich finde, Du übertreibst das Problem, weil Dir kleine Brücken nicht viel bedeuten. Die Brücken werden im Laufe des Threads immer kleiner, von 5 auf 3 m und dann sollen da plötzlich mehrspurige Straßen drübergehen, ich kann das nicht direkt nachvollziehen, aber m.E. ist es sehr sinnvoll, Brücken mit ihrer Länge und nicht als Punkt abzubilden, und zwar unabhängig von der Brückenlänge. Übertreibung verdeutlicht ;-). Das Beispiel ist aber realistisch, da ich schon einen Wanderweg eingegeben habe, der eine Autobahn A215 unterquert. Technisch handelt es sich um eine Brücke von knapp 3m Länge und etwa 30m Breite. Südlich folgen noch mehrere Feldwege, die kaum breiter sind. Wenn jemand dort die Höchstgeschwindigkeiten (tageszeit- abhängig, fast jährlich geändert) pflegen will, muss er gut aufpassen alle Wegstücke zu erfassen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radwege auf Bahntrassen
Rotbarsch schrieb: Spontan hätte ich gesagt, ein railway=disused würde passen, da dieser Begriff in England für solche Bahntrassen genutzt wird (vgl. http://www.railwayramblers.org.uk/ oder http://www.sustrans.org.uk/default.asp?sID=1089735289781). In den Map-Features ist dieses Tag aber für Trassen empfohlen, wo noch Gleise liegen. Also railway=abandoned. Aber hier sind die Map-Features auch gegen mich : Unbenutzte ehemalige Strecke ohne Schienen. Nicht benutzen wenn es eine Alternative wie z.B. Radweg gibt. Stimmt ja auch, denn die Trassen sind weder verlassen noch herrenlos, wie der Begriff übersetzt werden könnte, trotzdem wird es laut Tagwatch schon 13 mal in Verbindung mit einem Radweg genutzt. Soll ich ein eigenes Tag erfinden? Vielleicht railway=converted? Im deutschen Bahnbereich kennt man die Begriffe stillgelegt und entwidmet. Stillgelegt heisst, es findet kein Zugverkehr statt. Ob die Strecke physikalisch noch befahrbar ist oder ob alle Gleise abgebaut sind lässt sich daraus nicht ableiten. Entwidmet: Die Bahntrasse wurde aufgegeben und kann anderen Verwensungszwecke zugeführt werden. Eine Wiederinbetriebnahme erfordert den kompletten Planungs-und baurechtlichen Aufwand eines Streckenneubaus so als hätte es diese Trasse nie gegeben. Ich denke man sollte die Begriffe auch entsprechen mit disused und abandoned einsetzen. Die Interessen an nicht mehr befahrenen Strecken sind vielseitig und für umgewandelte Radwege ist es ein Qualitätsmerkmal. So wird z.B. im Südschwarzwald für die ehmalige Bahnstrecke Neustadt-Bonndorf geworben dass sie als umgewandelter Radweg nur 70m Höhenunterschied auf 20km Länge in einer recht bergigen Gegend auf fast 1000m Höhe hat. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationproblem: Route 'springt'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danke für Deine Antwort - der Analyzer ist aber Echtzeit genau, wenn man die Routen# weiss, das hab ich ausprobiert, daran kann es also nicht liegen... - - Fips - -- Claudius Henrichs schrieb: Am 31.01.2009 23:55, Fips Schneider: Habe folgendes Problem: Die Route des Busses 26 lässt sich nicht korrekt darstellen im RelationAnalyser: http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=70597useCache=false Mache ich irgendwas falsch oder ist das Analyzer da einfach noch zusehr 'beta'? Möglicherweise arbeitet der Analyzer auch nur auf einem einmal wöchentlich abgeglichenen Datenbestand und enthält einfach noch nicht die von dir aufgetrennten Straßen. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJhO1UnHVyAFIfTkERAqjqAJ0SVtp1fKVhwLeVBtqvucGvnGJ/jgCgvSEZ 0GHCNa/ULco4G8r9V9Ksr4Q= =5YG2 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten für NaviPowm 0.2.0
Hallo, gibt es Karten für NaviPOWM für die Kanraren? Bei http://wince.dentro.info/koord/osm/TileMap.htm kann ich sie nicht finden. MfG Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Framework für die Kartendarstellung - Ex istent ???
2009/1/31 Jan Tappenbeck o...@tappenbeck.net: Hi ! gibt es eigentlich eine Art Framework (ich bezeichne es einmal so) bei dem nicht nur die Anzeige von Tracks und Points, wie schon aus manchen Beispielen ersichtlich, über zugehörige Navi-Schalter an der Seite erstellt werden können. Ich meine hierbei nicht die mit + aufklappbaren Leisten wie wir diese von OSM kennen - das ist für den Themen-Fremden Anwender etwas zu speziell. Gruß Jan :-) ja. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Linien richtig taggen?
Dimitri Junker wrote: Diese beinhaltet die beiden Busshäuschen neben der Straße als highway=platform und die Nodes auf der Straße als highway=bus_stop. Das bringt aber nichts für asymetrische Bushaltestellen. Die Haltestelle wurde bisher ja nur neben die Straße gesetzt um aanzuzeigen, daß sie nur einseitig benutzt wird, dies erreicht man aber auch durch das forward_stop/... Würde man jetzt zu der von Dir genannten Relation übergehen müßte man ja auch wieder einen Node auf die Straße seztzen, dann ist aber der Node neben der Straße unnötig, es sei denn jemand will wirklich anzeigen wo das Wartehäuschen steht, aber darum ging es ja nicht. Ich stimme Dir zu. Der Node auf der Straße ist wichtig für die Linien-Relation. Die Nodes neben der Straße sind jedoch auch wichtig, da solche Punkte wertvoll sind für Nutzer von ÖPNV und ebenfalls als Landmarken für andere OSM-Nutzer. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationproblem: Route 'springt'
Hi Fips. Ich vermute nur. Der Link geht gerade nicht und der Gin-Tonic von eben hilft auch nicht, aber: Der Relation-Verify-Dings kann noch nicht mit getrennten Strecken in verschiedene Richtungen umgehen. Hatte das Problem auch gerade, das er bei Bus-Routen jede Stelle als nicht zusammengehörig bemängelt, wo sich Hin- und Rückweg unterscheiden. Hatte dem Entwickler das bereits mitgeteilt, der hat aber keine Versprechungen gemacht. Schleifen (etwa am Ende der Route) machen auch Probleme. Falls Du was anderes meinst, vielleicht Morgen... Gerrit Fips Schneider wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Habe folgendes Problem: Die Route des Busses 26 lässt sich nicht korrekt darstellen im RelationAnalyser: http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=70597useCache=false Mache ich irgendwas falsch oder ist das Analyzer da einfach noch zusehr 'beta'? Danke für etwaige Tips! Gruß - Fips - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJhNbNnHVyAFIfTkERAkQOAJ4qCgjs79p3d73N3QmL/Jcq8zjl+wCgj8Pc 2tFXI8VIYGTFKgIggYqwRME= =Odob -END PGP SIGNATURE- ___ 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
[Talk-de] Farben zur highway-identifizierung
naja, ist ein bisschen OT: http://chaosradio.ccc.de/media/video/magic-highway-usa.m4v Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JAMBA verwendet OSM
Hallo Du kennst http://openstreetbugs.appspot.com/ ? Ja, und das ist ein Superbeispiel, wie einfach soetwas sein kann - und muss um Akzeptanz zu bekommen. Grüße, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
