Re: [Talk-de] Umstellung auf lanes AA Wittlich-West
Hi! Am 15. Januar 2013 23:21 schrieb Bernhard Weiskopf bweisk...@gmx.de: Hallo Jörg! Ich würde die schrägen motorway_link-Fahrbahnen wenige Meter früher abzweigen lassen, etwa beim Beginn der durchgezogenen Linie oder ein wenig später, eben dort, wo man am Lenkrad drehen muss. Du hast sie genau an der baulichen Trennung angebunden, das ist aber auch korrekt und unkritisch... Dann müsste Jetzt rechts abbiegen bei einer normalen Kreuzung auch immer zu spät kommen. Oder? Was verstehst du unter normaler Kreuzung? Wann der Abbiege-Hinweis kommt, wird durch interne Programmparameter festgelegt und ist bei den Geräten etwas unterschiedlich. Nach meiner Erfahrung mit einigen Geräten kommt der Hinweis im Mittel etwa 20 Meter zuzüglich 3 Sekunden vor dem Abzweig. Fährt man sehr langsam, z. B. im Stau, ist der geschwindigkeitsabhängige Teil (3 Sekunden) vernachlässigbar und der Hinweis kommt 20 Meter vor dem Abzweig. Ist der Abzweigknoten mehr als 20 Meter nach dem Beginn der durchgezogenen Linie eingezeichnet, darf man dann schon nicht mehr die Spur wechseln. Wenn man eine Kreuzung mit großen Fahrbahninseln ohne die Ausgleitbahnen vor den Inseln zeichnet, kann es durchaus passieren, dass der Abbiege-Hinweis etwas zu spät kommt. Zeichnet man dagegen die ganze Abbiegespur als separate Fahrbahn, kommt am Abbiegepunkt gar kein Hinweis mehr. Glücklicherweise kündigen fast alle Navis schon einige hundert Meter vorher an, dass man bald abbiegen muss. Unser Navi von Navigon sagt jetzt rechts abbiegen schon so früh, dass es bei dicht hintereinander folgenden Ausfahrten eine zu früh rausschickt. Das ist keine gute Lösung. Danke für die sehr gute Zusammenfassung eines der größten Navi-Probleme, welches wir derzeit mit OSM-Daten haben. Vielen Mappern ist nicht bewusst, dass Navis nicht direkt an dem Punkt wo sich die Wege trennen die Anweisungen geben sondern (tw. lange) davor. Daher muss die Trennung der OSM-Wege auch dort erfolgen wo sich die Fahrbahnen tatsächlich auftrennen. Nur dann haben Navis eine Chance korrekte Anweisungen zugeben. Ein (alp-)traumhaftes Beispiel dafür ist hier: http://osrm.at/1VR Drei Ausfahrten in kurzen Abständen. Mein Navi (Skobbler) sagt mir praktisch immer eine Ausfahrt zu früh an, dass ich abfahren soll. Meiner Meinung nach müssen wir in der nächsten Zeit nicht nur an Tagging-Schemas für's Spurmapping arbeiten sondern auch an Aufklärung und Dokumentation. Wir müssen den Mappern erklären, warum man z.B. eben nicht am Anfang des Verzögerungsstreifens schon die OSM-Wege auftrennt sondern eben erst dort wo die tatsächliche Trennung ist. Bei normalen Kreuzungen, d.h. Kreuzungen ohne Fahrbahntrennung würde auch kein Mapper auf die Idee kommen, die Wege nicht dort zu verbinden wo die tatsächliche Kreuzung ist. Ich habe in der Vergangenheit schon ein paar Beispiele für Autobahnen erstellt ([1]-[3], aktuell noch ohne placement-Key, welcher praktisch jedes dieser Beispiele in aktuellen Renderern hübscher aussehen lassen würde und trotzdem präzise Informationen zum Spurlayout liefert) und werde zumindest [1] jetzt noch um deine Erklärung zum Navi-Verhalten ergänzen. Abschließend noch eine Frage: hat sich schon jemand Gedanken gemacht, wie man taggen könnte, welche Spuren eines OSM-Weges mit welchen Spuren des nachfolgenden Weges verbunden sind? Dieses Problem möchte ich relativ bald angehen, allerdings fehlt mir noch eine Idee, welche mir auch tatsächlich gefällt. vg, Martin [1] http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Motorway_Deceleration_Lane_at_Exit [2] http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Motorway_No_Lane_Changing [3] http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Motorway_Acceleration_Lane ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 15.01.2013 20:03, schrieb Peter Wendorff: Am 15.01.2013 19:38, schrieb Josef Latt: Am 15.01.2013 17:57, schrieb Peter Wendorff: Insofern betrachte ich diese Regel als überflüssig und überholt, und sich daran zu halten ist eigentlich taggen-für-den-veralteten-renderer bzw. taggen-für-den-veralteten-validator. Dann ist das Wiki in dem Punkt also überholt. ;) Layer dienen doch dazu, physikalisch übereinander liegende Objekte zu kennzeichnen/trennen. Gilt dann zwangsläufig auch für Brücken und Tunnels. Lese ich auch so im Wiki. Das ist richtig, aber eben im Normalfall redundant. Für die Zeichenreihenfolge hilft das layer-tag außerdem übrigens auch nicht immer. Bei Wegen IMHO überhaupt nicht. Und die Schichtung von Flächen per layer ist nicht mehr angesagt, obwohl es da noch den ein oder anderen Altvorderen gibt. Beispiel 1: Ein Bach wird mit layer=-1 getagged, weil er ja unter der Straße verläuft. Gleichzeitig wird die Wiese links und rechts von Straße und Bach aber nicht mit einem layer getagged (also default layer=0, wenn du so willst). Konsequent wäre also: erst den Bach zeichnen, dann die Wiese, dann die Straße/Brücke. Demnach würde aber vermutlich der Bach übermalt = Fehler. Vermutlich. Weshalb sehe ich dann in Karten die Flüsse mit layer=-1? Beispiel 2: Der Bach fließt durch ein Rohr unter der Straße, (tunnel=culvert, von mir aus auch tunnel=yes). Layer=-1 ist hier eigentlich nicht nötig, bzw. würde wieder dafür sorgen, dass der Tunnel verschwindet (s. oben), weil erst der Tunnel, dann die Wiese, dann die Strßae gezeichnet wird = Fehler. Siehe Anmerkung zu Beispielm1: Beispiel 3: Die Straße führt über eine Brücke. Ich tagge an die brücke ein layer=1. Das ist richtig und in ordnung, aber warum sollte es notwendig sein? Eine Brücke liegt üblicherweise über dem, was sie überquert. Der Bach hat dabei kein layer=1, was völlig in Ordnung ist, aber der Render-Stil muss jetzt auch dafür sorgen, dass der Bach über der Wiese gezeichnet wird, die eben für den bach nicht aufgetrennt ist. Wichtig ist der layer-Tag meiner Meinung deshalb nur (!) da, wo es aus den sonstigen Informationen nicht ersichtlich wird. Also: - wenn level angegeben ist (und damit das Stockwerk in gebäuden), dann ist layer nur innerhalb eines Stockwerks sinnvoll. [wenn nicht: ] - wenn sich zwei Elemente kreuzen, dann haben die a) einen gemeinsamen Node und kreuzen sich echt (z.B. Bahnübergang, Querungsstelle, Furt, ...); der Node kann dann entsprechend getagged werden. b) an einem element bridge oder tunnel, evtl. gibt's hier zusätzliche Varianten. c) unterschiedliche level-Elemente Wenn sich zwei Brücken, zwei Tunnel oder mehr kreuzen, dann - und weitgehend nur dann - ist layer notwendig, weil die vertikale Lage der zwei entsprechenden Elemente zueinander nicht klar ist. Falls es weitere Ausnahmen gibt, dann sollten die sich weitgehend auf Fälle beschränken lassen, in denen die obigen Annahmen eben nicht gelten, also wenn ein Tunnel über einer Brücke verläuft () oder sowas. Insgesamt ist mir das nicht einsichtig. Keine Regel, so es denn welche gibt, ohne Ausnahme. Regeln sollten aber so gestaltet sein, dass es möglichst wenig Ausnahmen gibt. Darstellung in einer Karte und Dokumentation in der Datenbank sind IMHO zwei Paar Stiefel. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 15.01.2013 20:09, schrieb Josef Latt: bicycle = yes foot = yes highway = track layer = -2 Ist wohl auch normal? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 16.01.2013 09:33, schrieb Josef Latt: Am 15.01.2013 20:03, schrieb Peter Wendorff: Am 15.01.2013 19:38, schrieb Josef Latt: Am 15.01.2013 17:57, schrieb Peter Wendorff: Insofern betrachte ich diese Regel als überflüssig und überholt, und sich daran zu halten ist eigentlich taggen-für-den-veralteten-renderer bzw. taggen-für-den-veralteten-validator. Dann ist das Wiki in dem Punkt also überholt. ;) Layer dienen doch dazu, physikalisch übereinander liegende Objekte zu kennzeichnen/trennen. Gilt dann zwangsläufig auch für Brücken und Tunnels. Lese ich auch so im Wiki. Das ist richtig, aber eben im Normalfall redundant. Für die Zeichenreihenfolge hilft das layer-tag außerdem übrigens auch nicht immer. Bei Wegen IMHO überhaupt nicht. Und die Schichtung von Flächen per layer ist nicht mehr angesagt, obwohl es da noch den ein oder anderen Altvorderen gibt. Beispiel 1: Ein Bach wird mit layer=-1 getagged, weil er ja unter der Straße verläuft. Gleichzeitig wird die Wiese links und rechts von Straße und Bach aber nicht mit einem layer getagged (also default layer=0, wenn du so willst). Konsequent wäre also: erst den Bach zeichnen, dann die Wiese, dann die Straße/Brücke. Demnach würde aber vermutlich der Bach übermalt = Fehler. Vermutlich. Weshalb sehe ich dann in Karten die Flüsse mit layer=-1? Ich denke, weil die Macher von Renderregeln aufgrund von Tatsachen nicht konsequent sind und layer hier eben bewusst ignorieren. Aber meiner Meinung nach ist das kein Grund, weiter so zu mappen, sondern langsam aber sicher davon wegzukommen. [..] Beispiel 3: Die Straße führt über eine Brücke. Ich tagge an die brücke ein layer=1. Das ist richtig und in ordnung, aber warum sollte es notwendig sein? Eine Brücke liegt üblicherweise über dem, was sie überquert. Der Bach hat dabei kein layer=1, was völlig in Ordnung ist, aber der Render-Stil muss jetzt auch dafür sorgen, dass der Bach über der Wiese gezeichnet wird, die eben für den bach nicht aufgetrennt ist. Wichtig ist der layer-Tag meiner Meinung deshalb nur (!) da, wo es aus den sonstigen Informationen nicht ersichtlich wird. Also: - wenn level angegeben ist (und damit das Stockwerk in gebäuden), dann ist layer nur innerhalb eines Stockwerks sinnvoll. [wenn nicht: ] - wenn sich zwei Elemente kreuzen, dann haben die a) einen gemeinsamen Node und kreuzen sich echt (z.B. Bahnübergang, Querungsstelle, Furt, ...); der Node kann dann entsprechend getagged werden. b) an einem element bridge oder tunnel, evtl. gibt's hier zusätzliche Varianten. c) unterschiedliche level-Elemente Wenn sich zwei Brücken, zwei Tunnel oder mehr kreuzen, dann - und weitgehend nur dann - ist layer notwendig, weil die vertikale Lage der zwei entsprechenden Elemente zueinander nicht klar ist. Falls es weitere Ausnahmen gibt, dann sollten die sich weitgehend auf Fälle beschränken lassen, in denen die obigen Annahmen eben nicht gelten, also wenn ein Tunnel über einer Brücke verläuft () oder sowas. Insgesamt ist mir das nicht einsichtig. Keine Regel, so es denn welche gibt, ohne Ausnahme. Regeln sollten aber so gestaltet sein, dass es möglichst wenig Ausnahmen gibt. Die Alternative sind doch die: Entweder, die Regel ist, layer dranzupappen, damit die Datenbank vollzumüllen - und die Nutzer der Daten müssen trotzdem ohne klarkommen (ewiges Problem unvollständiger Daten in osm). dann wäre die Regel für Mapper weder für die Datenbank noch für die Datenkonsumenten nützlich, einige Mapper werden sich das aus Faulheit oder Unwissenheit trotzdem ersparen, und niemandem ist geholfen. Oder aber die Regel ist, keine Layer dranzupappen - das ist einfach für Mapper, erspart überflüssige Daten und Datenauswerter müssen auch nicht mehr unterstützen als bei der anderen Variante, und es gibt Ausnahmen genau da, wo die Reihenfolge dadurch nicht eindeutig ist; und wenn da der layer fehlt, kann man das mit technischen Mitteln erkennen (nicht lösen, aber erkennen und den Mapper darauf hinweisen). Das ist dann zugegeben nicht so einfach zu erkennen wie da ist 'ne Brücke, also fehlt ein layer, aber sooo viel schwerer dann auch nicht. Algorithmisch ist das ungefähr ein: bringe die kreuzenden Elemente in eine definierte Reihenfolge. Ist die nicht eindeutig, fehlt was. Reihenfolgeregeln: bridge.layer = bridge.layer nix.layer = nix.layer tunnel.layer = tunnel.layer Wo sich ein Widerspruch oder ein = zwischen zwei Elementen ergibt, fehlt eine layer-angabe oder aber ein gemeinsamer nodes der zwei ways. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 15.01.13 schrieb Ronnie Soak: Dein Argument war 'braucht Platz auf dem Server, wenn ich mich richtig erinnere, oder? Auf dem Server ist es sowieso zu spät, weil dort die gelöschten Daten stehenbleiben. Aber mehr Platz und mehr Zeit braucht auch jeder Datenkonsument. Daneben birgt es die Gefahr, dass Neulinge sich die Daten anschauen und das zusätzliche foot=yes in ihre Tagginggewohnheiten übernehmen, weil sie es in ihrer Heimat überall so sehen. Gruß, Fabian.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 16.01.2013 10:33, schrieb Fabian Schmidt: Daneben birgt es die Gefahr, dass Neulinge sich die Daten anschauen und das zusätzliche foot=yes in ihre Tagginggewohnheiten übernehmen, weil sie es in ihrer Heimat überall so sehen. +1 Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 16.01.2013 10:06, schrieb Peter Wendorff: Die Alternative sind doch die: Entweder, die Regel ist, layer dranzupappen, damit die Datenbank vollzumüllen - Da gibt es andere Kandidaten (teilweise Thema hier), die da erheblich effektiver sind. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Und wann ist nun das Resumee? foot=yes an highway=footway als Verifikation, welche real keine ist, oder Datenmüll. Dito für bicyle=no anhighway=footway Auch bicycle=yes an highway=cycleway fällt in diese Kategorie. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellung auf lanes AA Wittlich-West
Am Dienstag, den 15.01.2013, 01:30 +0100 schrieb Martin Koppenhoefer: Am 14. Januar 2013 22:34 schrieb Bernhard Weiskopf bweisk...@gmx.de: In Deutschland gilt außerorts (!) eine durchgezogene doppelte Linie als bauliche Trennung... Quelle: http://wiki.openstreetmap.org/wiki/Attributierung_von_Stra%C3%9Fen_in_Deutsc hland im Prinzip ist es für die Diskussion in OSM über Fahrbahnen, bauliche Trennungen und highway ways egal, ob bestimmte Markierungen rechtlich als bauliche Trennung gelten, solange sie sich nicht so anfühlen. Es bleibt halt immer ein Unterschied, ob man gegen eine Betonwand oder gegen eine weisse Linie fährt wenn man sich nicht an die Regeln hält. +1 Es handelt sich bei einer Mittellinie, egal aus wie vielen Strichen, nicht um eine bauliche Trennung. Diese Seite kannte ich noch nicht, sie ist die einzige, die das so beschreibt, siehe auch die Warnung am Kopf der Seite. Der Zusatz ist 2009 ohne größere Diskussion einfach eingetragen worden, wird aber von keiner anderen Seite so gesehen. Eine aufgemalte Linie ist nichts bauliches. Das sieht der Gesetzgeber übrigens genauso, denn in §3 Abs.3 Nr. 2c (darauf bezieht sich offensichtlich diese Einfügung) wird die doppelte Linie ausdrücklich als weitere Trennungsmöglichkeit zusätzlich zu baulichen Trennungen erwähnt. Anders als die Autorin das gelesen hat, steht dort die Formulierung ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung Die bauliche Trennung wird im Satz davor behandelt. Ich halte nichts davon, hier in Deutschland einen Sonderweg zu gehen, weil dadurch jede Darstellung in internationalen Karten auf der einen oder anderen Seite der Grenze nahezu zwangsläufig zu Fehlern führt, es sei denn der Kartenersteller erzeugt für jedes Land einen anderen Style. Die Darstellung der Fahrstreifen sollte dem Fahrspurmapping überlassen werden, das jetzt so langsam in Fahrt kommt. Insofern bin ich dafür, diesen Zusatz aus der Seite wieder zu entfernen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellung auf lanes AA Wittlich-West
Am Mittwoch, den 16.01.2013, 09:06 +0100 schrieb Martin Vonwald: Abschließend noch eine Frage: hat sich schon jemand Gedanken gemacht, wie man taggen könnte, welche Spuren eines OSM-Weges mit welchen Spuren des nachfolgenden Weges verbunden sind? Dieses Problem möchte ich relativ bald angehen, allerdings fehlt mir noch eine Idee, welche mir auch tatsächlich gefällt. Ja, ich würde eine Relation wählen, in der als eine von-nach-Beziehung steht. way a lane 3 - way b lane 1 - way c lane 3 So als Beispiel, wenn sich eine Spur verzweigt oder in diesem Beispiel auf verschiedene Wege verteilt. So ganz zuende gedacht habe ich das aber auch noch nicht. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellung auf lanes AA Wittlich-West
Hi, wieder was auf der Strecke geblieben... Am Mittwoch, den 16.01.2013, 23:08 +0100 schrieb Wolfgang Hinsch: Das sieht der Gesetzgeber übrigens genauso, denn in §3 Abs.3 Nr. 2c StVO (darauf bezieht sich offensichtlich diese Einfügung) wird Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue Möglichkeit für private Luftbilder
Hallo, eben entdeckt. http://www.slashcam.de/news/single/Drohne-mit-Autopilot-fuer-GoPro--Lehmann-Aviation-L-10384.html Wenn nur nicht Kosten so intensiv wären. :) vg Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am Mittwoch, den 16.01.2013, 16:53 +0100 schrieb Josef Latt: Und wann ist nun das Resumee? foot=yes an highway=footway als Verifikation, welche real keine ist, oder Datenmüll. Dito für bicyle=no anhighway=footway Auch bicycle=yes an highway=cycleway fällt in diese Kategorie. bicycle=yes wurde (wird?) z.B. im Lübecker Raum benutzt, um anzuzeigen, dass der Weg für Radfahrer erlaubt, aber nicht verpflichtend ist, als Gegensatz zu bicycle=designated. Wo das tag fehlte, war nicht klar, ob die verpflichtende Benutzung geklärt war oder nicht. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
bicycle=yes wurde (wird?) z.B. im Lübecker Raum benutzt, um anzuzeigen, dass der Weg für Radfahrer erlaubt, aber nicht verpflichtend ist, als Gegensatz zu bicycle=designated. Wo das tag fehlte, war nicht klar, ob die verpflichtende Benutzung geklärt war oder nicht. Gruß, Wolfgang So mache ich das auch (im Mannheimer Raum), manchmal auch bei Fußwegen (foot = yes - normaler Gehweg ohne Beschilderung, foot = designated - mit StVO-Zeichen 239, 240 oder 241) Die default-Werte wie oneway = no haben außerdem nur Vermutungscharakter, andernfalls dürfte man beispielsweise eine Straße ohne oneway-tag nur dann einzeichnen, wenn man genau weiß, dass sie in beiden Richtungen befahrbar ist. Bei Radwegen neben Straßen ist sogar wichtig, ob man sie in beiden Richtungen befahren darf, die sind in Deutschland ohne beidseitige Beschilderung Einrichtungs-Wege und ich setze immer onenway = no dazu, wenn der Radweg in beiden Richtungen genutzt werden darf bzw. oneway = yes wenn nicht. Fehlt das tag, dann ist diese Eigenschaft unbekannt. Ich würde alle vermeintlich redundanten Tags belassen. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 16.01.2013, 16:53 Uhr, schrieb Josef Latt josef.l...@gmx.net: Und wann ist nun das Resumee? foot=yes an highway=footway als Verifikation, welche real keine ist, oder Datenmüll. Dito für bicyle=no anhighway=footway Auch bicycle=yes an highway=cycleway fällt in diese Kategorie. Da es unterschiedliche Meinungen zu Defaultwerten gibt, halte ich die Löschung der Tags erstmal für fraglich. Hier [1] steht, dass footway, cycleway und bridleway *=designated als Standartwert haben. Die gelöschten *=yes würden in dem Fall das designated überschreiben... Besser währe es, den niedrigst möglichen, bzw. in jedem Fall geltenden Wert (oder gar nicht), als Standart festzulegen. Meine Meinung hierzu ist, dass es bei verschiedenen Arten von Wegen/Wegeigenschaften keinen Defaultwert geben sollte. Beispiel oneway=* Autobahnen 99% Einbahnstraße, Defaultwert: oneway=yes 95% aller (normalen) Straßen sind keine Einbahnstaßen, Defaultwert: oneway=no Bei Radwegen gibt es Zwei- und Einrichtungsradwege, kein Defaultwert Bei Radwegen gibt es Benutzungspflichtige, und welche die man befahren darf. Also eher kein Defaultwert. (Hingegen könnte man Argumentieren, dass bicycle=yes als Fallback-Defaultwert gilt. Da es aber viele unterschiedliche Radwege gibt, könnte es sich anbieten, alle zu taggen, so dass man unvollständig getaggte besser findet.) Übrigens kann ein bicycle=yes schon Sinn machen, zB wie hier [2] an einer Militärstraße durchs Militärgebiet. (Um sicher zu sein, dass man dort mit dem Rad langfahren kann/darf.) Dann gibt es noch Benutzungspflichtige Fußwege für Radfahrer frei: highway=* (zB. footway, path oder cycleway, je nach Gesamtbeschaffenheit) mit foot=designated + bicycle=yes (als Beschilderung/Berechtigung) [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany [2] http://www.openstreetmap.org/browse/way/74385474 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offenlegung von Stilen
Andreas Tille andr...@an3as.eu wrote: Allerdings entspricht Up to date = Daily weder meiner Beobachtung noch dem, was hier im Thread geschrieben wurde. (Wöchentlich könnte hinkommen, jedenfalls war meine Änderung vom Sonntag dann nach dem Donnerstag sichtbar.) Ich benutze diese Karte nicht. Wenn Du Dir sicher bist, dann ändere es. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013 00:11, schrieb Wolfgang Hinsch: Am Mittwoch, den 16.01.2013, 16:53 +0100 schrieb Josef Latt: Und wann ist nun das Resumee? foot=yes an highway=footway als Verifikation, welche real keine ist, oder Datenmüll. Dito für bicyle=no anhighway=footway Auch bicycle=yes an highway=cycleway fällt in diese Kategorie. bicycle=yes wurde (wird?) z.B. im Lübecker Raum benutzt, um anzuzeigen, dass der Weg für Radfahrer erlaubt, aber nicht verpflichtend ist, als Gegensatz zu bicycle=designated. Wo das tag fehlte, war nicht klar, ob die verpflichtende Benutzung geklärt war oder nicht. Und wenn es dran ist, ist es eben auch nicht klar. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offenlegung von Stilen
Hi, Am 17.01.2013 um 03:38 schrieb Tirkon tirko...@yahoo.de: Andreas Tille andr...@an3as.eu wrote: Allerdings entspricht Up to date = Daily weder meiner Beobachtung noch dem, was hier im Thread geschrieben wurde. (Wöchentlich könnte hinkommen, jedenfalls war meine Änderung vom Sonntag dann nach dem Donnerstag sichtbar.) Ich benutze diese Karte nicht. Wenn Du Dir sicher bist, dann ändere es. http://wiki.openstreetmap.org/wiki/OpenCycleMap Alle 48 Stunden werden frische Daten geholt, allerdings dauert das Neurendern nochmals ein paar Tage. Vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013 01:46, schrieb Masi Master: Am 16.01.2013, 16:53 Uhr, schrieb Josef Latt josef.l...@gmx.net: Und wann ist nun das Resumee? foot=yes an highway=footway als Verifikation, welche real keine ist, oder Datenmüll. Dito für bicyle=no anhighway=footway Auch bicycle=yes an highway=cycleway fällt in diese Kategorie. Da es unterschiedliche Meinungen zu Defaultwerten gibt, halte ich die Löschung der Tags erstmal für fraglich. foot=yes an highway=footway ist kein Defaultwert. Hier [1] steht, dass footway, cycleway und bridleway *=designated als Standartwert haben. Die gelöschten *=yes würden in dem Fall das designated überschreiben... Wie geht das denn? Besser währe es, den niedrigst möglichen, bzw. in jedem Fall geltenden Wert (oder gar nicht), als Standart festzulegen. Meine Meinung hierzu ist, dass es bei verschiedenen Arten von Wegen/Wegeigenschaften keinen Defaultwert geben sollte. Beispiel oneway=* Autobahnen 99% Einbahnstraße, Defaultwert: oneway=yes 95% aller (normalen) Straßen sind keine Einbahnstaßen, Defaultwert: oneway=no Bei Radwegen gibt es Zwei- und Einrichtungsradwege, kein Defaultwert Bei Radwegen gibt es Benutzungspflichtige, und welche die man befahren darf. Wie schön, dass man Radwege auch befahren darf. Also eher kein Defaultwert. (Hingegen könnte man Argumentieren, dass bicycle=yes als Fallback-Defaultwert gilt. Da es aber viele unterschiedliche Radwege gibt, könnte es sich anbieten, alle zu taggen, so dass man unvollständig getaggte besser findet.) Prinzipiell gibt es nur benutzungspflichtige (straßenbegleitende) Radwege, zumindest in DE. Die Querfeldeinwege mit dem blauen Schild sind ja an und für sich keine und können de facto auch nicht benutzungspflichtig sein. BTW, deren Beschilderung entspricht nicht der StVO. Hatte ich schon erwähnt. Übrigens kann ein bicycle=yes schon Sinn machen, zB wie hier [2] an einer Militärstraße durchs Militärgebiet. (Um sicher zu sein, dass man dort mit dem Rad langfahren kann/darf.) Dann gibt es noch Benutzungspflichtige Fußwege für Radfahrer frei: highway=* (zB. footway, path oder cycleway, je nach Gesamtbeschaffenheit) mit foot=designated + bicycle=yes (als Beschilderung/Berechtigung) Das ist doch ganz was anderes. footway + foot=yes ist gemeint und nicht andere Wege, wo das foot=yes die die per se nicht erlaubte Nutzung durch Fußgänger gestattet. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
