Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Am 12.05.2014, 11:46 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 11. Mai 2014 17:45 schrieb Masi Master masi-mas...@gmx.de: Wie das gemappt wird? Der Weg ist von der Fahrbahn separiert, also als eigener Weg. Besteht aus 3 Spuren, jeweils mit unterschiedlichen Eigenschaften nach dem :lanes-Schema: highway=path o.ä. (vielleicht highway:lanes=cycleway|cycleway|footway ?) lanes=3 bicycle:lanes=destiantion|destiantion| foot:lanes=||destination oneway:lanes=-1|yes|no surface:lanes=asphalt|asphalt|paving_stones smothness:lanes=excellent|excellent|good Kann man bei bicycle foot die Werte zwischen den | leer lassen? (im Normalfall werden die ja nicht getaggt) Oder muss da null oder empty rein? so ähnlich würde ich es (wenn sehr detailliert getaggt) auch sehen, abgesehen vom (Tipp)fehler destiantion, das sollte designated heissen, und nicht destination oder ähnlich (=Anlieger frei). Einfacher (aber ohne die konkreten Spurdetails, explizite Beschilderung angenommen): highway=path foot=designated bicycle=designated oneway=no segregated=yes Volle Zustimmung zu allem. Im Normalfall würde ich es auch ohne lanes taggen. Und danke für die Richtigstellung des Tippfehlers. :) -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition
Wie das gemappt wird? Der Weg ist von der Fahrbahn separiert, also als eigener Weg. Besteht aus 3 Spuren, jeweils mit unterschiedlichen Eigenschaften nach dem :lanes-Schema: highway=path o.ä. (vielleicht highway:lanes=cycleway|cycleway|footway ?) lanes=3 bicycle:lanes=destiantion|destiantion| foot:lanes=||destination oneway:lanes=-1|yes|no surface:lanes=asphalt|asphalt|paving_stones smothness:lanes=excellent|excellent|good Kann man bei bicycle foot die Werte zwischen den | leer lassen? (im Normalfall werden die ja nicht getaggt) Oder muss da null oder empty rein? Am 10.05.2014, 23:54 Uhr, schrieb Dirk Sohler s...@0x7be.de: Falk Zscheile schrieb: […] dass bei Straßen/Wegen die physische Beschaffenheit gemappt wird, also ein geteerter Weg, und nicht die rechtliche Beschaffenheit, eine Spur für Fahrräder und eine Spur für Fußgänger. Wie würde dann das hier gemappt werden? (Bild aus der Google-Suche.) http://img836.imageshack.us/img836/1209/wftj.jpg Links: Geteerter Zwei-Richtungs-Radweg Rechts: Fußweg mit Beton-Bodenplatten Sowohl rechtlich als auch von der Beschaffenheit her unterschiedlich. Und schließlich gibt es hier sogar drei Spuren (für Fahrrad-Router sicher nicht ganz irrelevant, dass der Radweg in beide Richtungen befahren werden darf). Nun ist so ein Luxusradweg natürlich nicht üblich, aber gerade hier in Hamburg gibt es häufig – unabhängig der Benutzungspflicht – die Situation, dass der Radweg geteert ist, und der Fußweg aus Beton-Bodenplatten besteht … Und das habe ich bisher noch nirgends derart erfasst gesehen. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting zu use_sidepath läuft
Die blauen Radweg-Schilder geben normale Beschränkungen wieder und gelten für Radweg UND Fahrbahn, also sollte auch beides getaggt werden. Hat erstmal nix mit dem Routing zu tun. bicycle=designated ist zu schwammig formuliert. In Deutschland, aber vor allem weltweit. Das Andere ist, dass das Bevorzugen von bicycle=designated-Radwegen nicht funktioniert. Der Radweg kann länger als die Fahrbahn sein und wird teils deswegen nicht bevorzugt. Oder es wird nur auf Radwegen geroutet. Außerdem funktioniert kürzeste Route (nach StVO) nicht, bei unterschiedlicher Gewichtung. Am 09.05.2014, 06:51 Uhr, schrieb Christoph (TheFive@OSM) thefive@gmail.com: Nach meiner Information ist in Deutschland ein ausgezeichneter Radweg benutztungspflichtig. Ist das nicht aber mappen für die Router ? Die Situation ist doch mit bicycle = designated ordentlich gemappt.. Christoph Am 08.05.2014 um 15:18 schrieb Dirk Sohler s...@0x7be.de: chris66 schrieb: Das Tag erlaubt es eine Straße zu markieren, die von einem benutzungspflichtigen Radweg begleitet wird. Ich sehe jetzt schon unzählige Falscheinträge mit diesem Tag, wo zwar ein straßenbegleitender Radweg vorhanden ist, dieser aber nicht Benutzungspflichtig ist … Die Gefahr besteht bei jedem Tag, bei use_sidepath gibt es kein erhöhtes Risiko. Dirk Sohler schrieb: Ich sehe jetzt schon unzählige Falscheinträge mit diesem Tag, wo zwar ein straßenbegleitender Radweg vorhanden ist, dieser aber nicht Benutzungspflichtig ist -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Straße: Revertieren eines Changesets o der nicht ?
Am 18.01.2014, 05:37 Uhr, schrieb malenki o...@malenki.ch: On 18.01.2014 00:52, li...@xanth.de wrote: Martin Koppenhoefer wrote wobei ein undelete zu bevorzugen ist, nicht einfach den Weg neu einzeichnen. In josm FILE(Datei) - undelete object und die id eintragen, vor die id ein n, w oder r, je nach Objekttyp. Hierzu ist allerdings das Plugin undelete notwendig... Dieses Plugin schreibt beim Wiederherstellen meist einen Wiederherstellungskommentar an die Ways und deren Nodes. Das Wiederherstellen eines Objekts kann man auch über das Revertieren eines Changesets machen. Nach dem Revert in JOSM einfach das gewünschte Objekt wählen und Auswahl hochladen. Objekte sind in diesem Fall dann der way (Straße) und die dazugehörigen node's (Knoten). Um die Knoten eines way's zu selektiert man, klickt man den Weg an und drückt dann die Taste e. Danach noch mit Shift oder Strg den Weg dazu auswählen und Datei-Auswahl hochladen. Allerdings braucht man für die Funktion Alle Knoten des Wegs selektieren das utils2-plugin. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz nur für PKW
Am 08.01.2014, 14:56 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 8. Januar 2014 01:48 schrieb Masi Master masi-mas...@gmx.de: Mein Favorit wäre das vererbungsfreie highway=path foot=yes bicycle=yes horse=no alles andere ergibt sich aus den default-restrictions. Sehe ich ganz und gar nicht so! (Wenn dann würde laut der access-Seite übrigens noch inline_skates, ice_skates ski=no fehlen...) gehts es hier noch um den Parkplatz des Threads? Ski parken? Inline skates parken? Jedenfalls sind die von Dir genannten AFAIK allesamt Fußgänger und daher in foot enthalten, zumindest in Deutschland. Wollte damit nur deutlich machen, dass das Tagging ein bischen hinkt. Ich schrieb ja auch laut access-Seite... ist dort also anders als gesetzlich geregelt. Es ging nur um ein anderes Beispiel, und da es langsam ins OT abdriftet stehts in Klammern. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz nur für PKW
Am 07.01.2014, 16:08 Uhr, schrieb Gertrud Simson simson.gert...@gmail.com: Am 7. Januar 2014 10:01 schrieb chris66 chris66...@gmx.de: Da viele Mapper die Vererbungsregeln der access-Hierarchie nicht verstehen,... Da müssten wiedersprüchliche Angaben im Wiki entfernt werden. Die Grafik oben links auf http://wiki.openstreetmap.org/wiki/DE:Key:access zeigt hgv fälchlicherweise als Unterkategorie von motorcar. Hat jemand Zeit die Grafik zu berichtigen? Ansonsten müsste sie wohl erstmal entfernt werden, was ich eigentlich bedauern würde, da ich die Grafik für einen schnellen Überblick immer ganz hilfreich fand. Das wiki war (in diesem Punkt) nicht widersprüchlich. Beispiel: Bei dem Zeichen 251 (Verbotsschild mit einem Auto drin): Verbot für Kraftwagen und sonstige mehrspurige Kraftfahrzeuge taggt man motorcar=no. Es gilt dann auch für LKW (hgv) Normalerweise war doch motorcar das tag für 2-spurige Motorfahrzeuge... Ansonsten müssten man ja Zeichen 251 so taggen: motor_vehicle=no + motorcycle=yes. Oder wir brauche ein Tag für 2-spurige Motorfahrzeuge. Zum Thema: access=no + motorcar=yes funktioniert nicht, da nicht der Zugang, sondern das Parken limitiert wird. Über den Parkplatz gehen/mit dem Fahrrad fahren darf man ja wohl noch. motorcar=designated gefällt mir ganz gut. Oder sowas wie access:parking=motorcar (+access:parking=no) -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz nur für PKW
Am 08.01.2014, 00:18 Uhr, schrieb chris66 chris66...@gmx.de: Am 07.01.2014 23:18, schrieb Andreas Schmidt: Im Beispielsfalle eines schmalen Weges mit einem Schild /nur Fahrräder und Fußgänger/ ohne Benutzungspflicht /[.../] Um aber nicht alle Verkehrsteilnehmer, für die der Weg verboten ist, einzeln aufführen zu müssen, verbietet man den Zugang zunächst für alle und erlaubt ihn dann für die Ausnahmen wie folgt: * /highway=path/ * /access=no/ * /foot=yes/ * /bicycle=yes/ Quelle: http://wiki.openstreetmap.org/wiki/DE:Key:access Also das access=no halte ich für suboptimal. Nicht nur weil der Weg auf der Standard-Mapnikkarte rot schraffiert wird. Mein Favorit wäre das vererbungsfreie highway=path foot=yes bicycle=yes horse=no alles andere ergibt sich aus den default-restrictions. Sehe ich ganz und gar nicht so! (Wenn dann würde laut der access-Seite übrigens noch inline_skates, ice_skates ski=no fehlen...) Besser ist es den Weg separat von den access-tags zu kennzeichnen. In diesem Fall bei nur Fahrräder und Fußgänger ist access=no + foot=yes + bicycle=yes schon richtig und kann nicht missinterpretiert werden. Was wäre, wenn es sich um einen breiteren Weg handelt, und der nächste Mapper das zu highway=track verbessert? Dann haben wir noch mehr Kuddelmuddel... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Land- UND Forstwirtschaflticher Verkehr
Am 14.12.2013, 10:30 Uhr, schrieb chris66 chris66...@gmx.de: Am 14.12.2013 00:43, schrieb Michael Kugelmann: Am 13.12.2013 21:59, schrieb Volker Schmidt: Wie wird ein Verbot fuer Kraftfahrzeuge mit dem Zusatz Land- und forstwirtschaflticher Verkehr frei getaggt? motor_vehicle=agriculture; forestry Forstwirtschaft ist IMHO ein Unterkapitel der Landwirtschaft = motor_vehicle=agriculture. agricultural ist die korrekte Schreibweise. Den Doppelbegriff findet man aber auch häufig in den Daten (mv=agricultural;forestry 2200 mal). Da das ; bei den wenigsten Anwendungen ausgewertet wird sollte man aber nicht unbedingt erwarten dass es im Router beachtet wird. ;-) Man sollte aber unbedingt den Doppelwert agricultural;forestry eintragen. Sonst kann man den Unterschied zu den anderen 2 Fällen nicht mehr unterscheiden. Dass das ; von einigen nicht ausgewertet wird, ist kein Grund es nicht zu verwenden! Die die es auswerten hätten sonst falsche Daten. Gruß Masi -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lane oder SharedLane?
Am 05.12.2013, 09:34 Uhr, schrieb pmsg pmsg2...@yahoo.com: Hallo, 2013/12/5 Masi Master masi-mas...@gmx.de: [...] Der Schutzsteifen ist allerdings eine Radspur (nicht verpflichtend und auch nicht ganz exklusiv), die nur im Bedarfsfall von KFZ befahren/benutzt werden darf, und auch nur wenn kein Radfahrer behindert wird. behindert - gefährdet [1] Bei Bedarf dürfen Kraftfahrzeuge auf dem Schutzstreifen anscheinend auch behindern und müssen auch nicht die Geschwindigkeit reduzieren. Das ist eine wesentlich schwächere Beschränkung als gilt für Radfahrer auf Gehwegen mit Radfahrer-frei Schild (dort müssen Radfahrer Schritttempo fahren und dürfen nicht Fussgänger behindern [2]). Von daher kann man schon von shared_lane in Zusammenhang mit Schutzstreifen sprechen. Danke für die Richtigstellung! Hatte das nur aus dem Kopf wiedergegeben. Etwas schwerer wiegt die Tatsache, dass Fahrzeuge die Linie des Schutzstreifens nur bei Bedarf überfahren dürfen. In dem Zusammenhang von gemeinsam Nutzung zu sprechen finde ich ein wenig fraglich. Ohne jetzt in der StVO nach feinen Details zu suchen (die in anderen Ländern eh unterschiedlich sind), finde ich es viel wichtiger die Schutzstreifen von wirklichen gemeinsam benutzten Spuren zu unterscheiden, den Sharrows (gibts auch ohne die Pfeile). Radfahrstreifen und Schutzstreifen finde ich auf den ersten Blick ähnlicher als eine komplette Spur die von verschiedenen Verkehren verwendet wird. Wirkt sonst irgendwie wie eine komplette Fahrspur. [1] http://dejure.org/gesetze/StVO/Anlage_3.html, Anlage 3 (zu § 42 Absatz 2) Richtzeichen, lfd nr 22 [2] http://dejure.org/gesetze/StVO/Anlage_2.html, Anlage 2 (zu § 41 Absatz 1) Richtzeichen, lfd nr 18 -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lane oder SharedLane?
Am 03.12.2013, 11:26 Uhr, schrieb Andreas Neumann andr-neum...@gmx.net: Moin, ich bin grad etwas verwirrt auf Grund der wiki-Seite zum cycleway: http://wiki.openstreetmap.org/wiki/DE:Key:cycleway Wir haben mehrere Straßen mit Fahrradschutzstreifen (sprich mit Strichellinie abgesetzte Spur auf Straße, meist mit Piktogramm). Bisher sind die alle mit cycleway=lane getaggt. Nun steht der Schutzstreifen aber explizit bei shared_lane. Was genau ist der Unterschied? Kann man diesen evtl. etwas besser auf der Seite hervorheben? Öhm, sehe ich nicht so wie das wiki. shared_lane würde ich mal mit Fahrspur, die von verschiedenen Verkehrsarten genutzt wird übersetzen. Der Schutzsteifen ist allerdings eine Radspur (nicht verpflichtend und auch nicht ganz exklusiv), die nur im Bedarfsfall von KFZ befahren/benutzt werden darf, und auch nur wenn kein Radfahrer behindert wird. Aus meiner Sicht sind das eher Fahrradspuren (cycleway=lane), die mit den passenden access-tags versehen werden sollten (zur Abgrenzung zum Radfahrstreifen), also mit motor_vehicle=xxx. xxx:irgenwas schwächeres als yes, vielleicht permitted? Oder bin ich da etwas zu kleinlich? Praktisch genauso wie hier die Fußwege mit Fahrrad-frei Schild. Radfahrer sind nur Gast und haben absolute Rücksicht auf Fußgänger zu nehmen. Sie dürfen die Fußwege aber generell nutzen, nicht nur im Bedarfsfall. Deswegen bei Schutzstreifen etwas schwächeres als yes. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tracer2Server funktioniert auf einigen Systemen nicht
Feedback zum Tracer2Server Hallo zusammen, euer Plugin hört sich ja ziemlich praktisch an, nur leider läuft es auf meinem System nicht. Der Tracer2Server schließt sich sofort nach dem Starten. Es kommt die Fehlermeldung: Tracer2Server hat ein Problem festgestellt und muss beendet werden. Systemdaten: WinXP, 32bit, 1-Kern-Prozessor, Installation klappte fehlerfrei. .NET Frameworks 1.1, 2.0, 3.0, 3.5 und 4.0 sind installiert. Bei Linux und OS X soll es auch nicht laufen. Im Forum gibts eine Anleitung für eine Lösung: http://forum.openstreetmap.org/viewtopic.php?id=23319p=1 Habe das selber unter WindowsXP nicht getestet, da ich mir nicht sicher bin, ob es dann läuft. Den Aufwand und die Nerven wollte ich mir sparen. Vielleicht habt ihr ja den möglichen Fehler schon lokalisiert... Danke beste Grüße Masi -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fernbuslinien
Hi, hilfreich sind ggf. 2 JOSM plugins: 1. download_along 2. reltoolbox Mittels Overpass API kann man seit ein paar Monaten die Daten eines Ausschnittes herunterladen, der nicht rechteckig sein muss. Falls das 1. Plugin dies unterstützen würde (wovon ich ganz stark nicht ausgehe), kann mit einem Mal ein Korridor entlang des GPS-tracks heruntergeladen werden. Glaub momentan wird der Korridor in viele Rechtecke gesplittet, also viele viele download-anschnitte. Das 2. Plugin erleichtert etwas das Einfügen in Routenrelationen. Ist nicht ganz intuitiv, aber wenn man den dreh raus hat, gehts damit schneller. Beste Grüße Masi Am 27.11.2013, 12:54 Uhr, schrieb Falk Zscheile falk.zsche...@gmail.com: Moin, ich habe mich soeben einmal an der Eintragung einer Fernbuslinie versucht und habe mir dabei fast eine Sehenscheidenentzündung geklickt. Dank Brücken, Geschwindigkeitsbeschränkungen und Ab- bzw- Auffahrten sind unsere Autobahnen in sehr übersichtliche Elemente zerfallen. Gibt es für die Eintragung einen besseren Arbeitsablauf als den folgenden? 1 JOSM öffnen. 2. GPS-Track laden 3. Am Startpunkt Kartenausschnitt laden. 4. Neue (Fernbus-) Relation anlegen. 5. Ersten Streckenabschnitt zur Relation hinzufügen. 6. Streckenabschnitt bis außerhalb des geladenen Kartenausschnitts verfolgen, dort einen kleinen Kartenausschnitt laden. 7. Die neu geladene Teilstrecke (Wegabschjitt) zur Relation hinzufügen. 8. Schritte 6. und 7. solange wiederholen, bis man am Ziel ist. Zwischenzeitliche Uploads nicht vergessen. Die komplette Strecke entlang des GPS-Tracks zu laden kommt bei 400 km nicht als Alternative in Betracht. Gibt es ein Werkzeug, dass einem anhand des GPS-Tracks empfehlen kann, welche Wege man zur Relation hinzufügen sollte, so dass man nur noch eine Schlüssigkeitskontrolle machen muss? Über eure Tipps und Tricks in diesem Zusammenhang würde ich mich freuen. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 06.11.2013, 07:57 Uhr, schrieb bkmap burkhard.kirch...@web.de: Bei nicht-residental kommt halt innerorts ein maxspeed mit source:maxspeed=de:urban dran. Für residental außer Orts fällt mir jetzt kein Beispiel ein, aber wenn das auftreten sollte, bekommt der Weg z.B. maxspeed=100 source:maxspeed=DE:rural. Das source:maxspeed-Tag ist nicht so praktisch zur Kennzeichnung. Denn wo liegt eine Straße, die mit source:maxspeed=sign + maxspeed=30 oder 70 getaggt ist? Die Schilder traffic_sign=city_limit funktionieren auch nicht, denn wenn man aus dem Wald, von der Anlegestelle oder von einem eigenständigen Radweg kommt sieht man keine Schilder. Außerdem gibt es bisher (leider!) noch keine Lösung für die Richtung eines (Schild-)Knoten an einem Weg. Schilder neben dem Weg abzufragen scheint mir für die Auswertung/Routing viel zu umständlich. Die ganzen getaggten Schilder oder eine Häufung von residentials kann höchstens zur Qualitätskontrolle eingesetzt werden. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 06.11.2013, 14:48 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 6. November 2013 13:54 schrieb Masi Master masi-mas...@gmx.de: Das source:maxspeed-Tag ist nicht so praktisch zur Kennzeichnung. Denn wo liegt eine Straße, die mit source:maxspeed=sign + maxspeed=30 oder 70 getaggt ist? wie relevant ist das? Im Prinzip hast Du Recht, beides zusammen (Ortsschilder und source:maxspeed) sollten normalerweise ausreichen aber es mag Ausnahmen geben. Wenn man es gern noch gründlicher machen will (weil man z.B. auch in OSM die Info drin haben will, ob man rechts überholen darf und das Rechtsfahrgebot aufgehoben ist, oder ob Parkleuchten beim Parken ausreichen) kann man ja auch noch einen weiteren tag einführen (innerort=yes) und promoten in der Hoffnung, dass das auch viele andere Mapper für wichtig erachten. Relevant u.a. für Mofafahrer. Sowas wie innerort=yes ist ja ganz praktisch, allerdings denke ich nach wie vor, das es nur mit einem großen Polygon funktionieren kann. (Bei Umweltzonen ist es ja genauso.) Die Schilder traffic_sign=city_limit funktionieren auch nicht, denn wenn man aus dem Wald, von der Anlegestelle oder von einem eigenständigen Radweg kommt sieht man keine Schilder. das kommt wohl auf die Gegend an. In der Gegend in D., die ich ganz gut kenne, sind die Ortseingangsschilder an jedem Weg, der befahrbar ist (auch Feldwege etc.). Bei Radwegen bin ich mir nicht sicher, für Radfahrer spielt es ja auch keine Rolle, ggf. würde ich Radwege bei einer automatischen Innerorts-Analyse nicht berücksichtigen. Die Frage kam doch aus der Richtung außerorts ist Mofa fahren auf Radwegen erlaubt. An Radwegen gibt es normalerweise kein maxspeed- oder Ortseingangsschild, bzw. wird es dort nicht getaggt. Mofa-FahrerInnen sind zwar nur ne kleine Gruppe... Überflüssig könnte es nur sein, weil es ein darf ist, und die Fahrbahn ohnehin sicherer ist. Außerdem gibt es bisher (leider!) noch keine Lösung für die Richtung eines (Schild-)Knoten an einem Weg. Schilder neben dem Weg abzufragen scheint mir für die Auswertung/Routing viel zu umständlich. Ist glaube ich viel weniger umständlich oder kompliziert als die Innerorts-Inseln automatisch zu ermitteln. Die Frage ist doch, wie wichtig uns diese innerorts-Thematik überhaupt ist (offenbar nicht besonders, sonst wäre es schon längst gelöst), wenn man den Hauptaspekt (implizite Geschwindigkeitsbegrenzung) schon an die ways gemappt hat. Letzteres allerdings empfehle ich auch, weil es doch erheblichen Einfluss auf die Routingergebnisse hat, vor allem in Gegenden ohne weitere explizite Limits (in D. ist ja meistens sowieso 30 in Wohngebieten). Ja, hab mir extra ein JOSM-Preset gebastelt, das die source:maxspeed immer mit drangängt, weil ich vorher immer ein schlechtes Gewissen hatte, das zu unterschlagen. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 04.11.2013, 01:18 Uhr, schrieb Bernhard Weiskopf bweisk...@gmx.de: bicyle=no ist ganz falsch, denn man darf die Fahrbahn benutzen, unter verschiedenen Bedingungen. Ich dachte da eher an eine Kombination aus einem Tag am Radweg (bicycle=designated) und einem auf der Fahrbahn (bicycle=use_cycleway). Zu bicycle=use_cycleway wird es in den nächsten Tagen einen Vorschlag geben, ist schon so gut wie fertig. bicycle = no ist ganz richtig, das steht im Gesetz. (Verbot die Fahrbahn zu benutzen) Wir können nicht alle Ausnahmen taggen. Was ist tragisch, wenn z. B. der Weg mal unbenutzbar ist und man als Umleitung die Straße benutzt? Verirrt man sich, weil man 5 Meter neben dem Weg mit der Linie im Navi fährt? Nein, im Gesetz steht erstmal: Fahrzeuge müssen die Fahrbahn benutzen. Ein Verbot die Fahrbahn zu benutzen steht so nicht explizit im Gesetz, nur die Pflicht benutzungspf. Radwege zu benutzen: Eine Pflicht, Radwege in der jeweiligen Fahrtrichtung zu benutzen, besteht nur, wenn dies durch Zeichen 237, 240 oder 241 angeordnet ist. Andere Fahrräder (...) wie mehrspurige Lastenfahrräder und Fahrräder mit Anhänger werden davon nicht erfaßt. Die Führer anderer Fahrräder sollen in der Regel dann, wenn die Benutzung des Radweges nach den Umständen des Einzelfalles unzumutbar ist, nicht beanstandet werden, wenn sie den Radweg nicht benutzen Das ist was ganz anderes als ein richtiges Fahrbahnverbot. Ich hoffe nicht, dass wir zwei verschiedene Situationen mit dem gleichen Tag behandeln! Wenn die Bordsteine nicht genügend abgesenkt sind, sehe ich das mit dem Rennrad als unzumutbar an und fahre auf der Fahrbahn. Es besteht weiterhin die Wahl zwischen indirektem und direktem Linksabbiegen. Beim direkten, also einfädeln auf die normale Linksabbiegerspur, darf also der Radweg verlassen werden (denn die Fahrbahn ist nicht verboten). Man darf auch nicht dicht an parkenden Autos entlang fahren. Ein ausreichender Abstand ist 1,5m, etwa die maximale Öffnungsweite von Autotüren. Wenn dort aber der Radweg entlangführt (was zumindest in Köln fast überall so ist) darf dort nicht gefahren werden. Sondern auf der Fahrbahn, denn ein Fahrbahnverbot existiert nicht. Bei nicht benutzungspflichtigen Radwegen darf dann nicht mehr bicycle=designated verwendet werden. Und da es dummerweise der Defaultwert von highway=cycleway ist, darf es keine Defalutwert mehr geben, oder bzw. zusätzlich bicycle=yes gesetzt werden, damit man den Unterschied feststellen kann. Eine andere Lösung fällt mir momentan nicht ein. bicycle = designated ist ein für Radfahrer bestimmter und gekennzeichneter Weg. Das ist unabhängig, ob man die Fahrbahn benutzen darf oder nicht. Wenn bicycle=designated für das blaue Schild für Sonderwege für Radfahrer gilt (bzw. bei zusätzlich foot=designated gemeinsame/getrennte Fuß- und Radwege), dann ist damit gleichzeitig eine Benutzungspflicht ausgesprochen, denn in DE kennzeichnen die Zeichen 237, 240 und 241 die Benutzungspflicht. Soweit sogut. Doch was ist mit anderen Ländern? In Frankreich, den Niederlanden und sogar in Deutschland gibt es Zeichen die Radwege ohne Benutzungspflicht anzeigen. Wie willst du diese Wege taggen? Auch mit bicycle=designated, dann bräuchten wir nämlich ein extra-Tag für Radwege mit Benutzungspflicht. Es ist nicht sinnvoll für Verschiedene Zeichen/Situationen das gleiche Tag zu verwenden. - Wir haben alles was wir brauchen, neue Werte halte ich für unnötig. Wenn wir die Radwegbenutzungspflicht auch auch der Fahrbahn taggen wollen, kommen wir um ein weiteres Tag nicht herum. bicycle=no ist keine Lösung. Gruß Masi -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 04.11.2013, 20:54 Uhr, schrieb Garry garr...@gmx.de: Am 04.11.2013 10:09, schrieb Martin Koppenhoefer: Am 03/nov/2013 um 23:14 schrieb Garry garr...@gmx.de: Dafür gibt es zu viele Sonderfälle(so häufig, dass man sie schon gar nicht mehr Sonderfall nennen kann) als dass man dafür sinnvoll Inseln bilden könnte. Dass residentials meist innerorts liegen ist ehr selbstredend Ortsschilder sind nicht hilfreich, aber residentials schon? Eine Ansammlung von residentials (ein tag!) lässt darauf schließen dass diese Innerorts sind. Es gibt auch highway=residential's außerhalb geschlossener Ortschaften, zB in Weilern (Gehennzeichnet durch die grünen Ortsschilder mit gelber Schrift.) oder sicher auch ganz in der Pampa. Wahrscheinlich wird es auf eine Fläche hinauslaufen, die in etwa dem Haupt-residential entspricht, muss ja nicht so genau sein, sollte nur die (alle) Highways dort schneiden wo das Ortsschild steht, bzw. wo die (Neben-)Straßen in Tracks übergehen. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 02.11.2013, 15:51 Uhr, schrieb fly lowfligh...@googlemail.com: On 31.10.2013 19:54, Masi Master wrote: Am 31.10.2013, 19:20 Uhr, schrieb Dirk Sohler s...@0x7be.de: Stephan Wolff schrieb: Auch für gutes Fahrradrouting muss man straßenbegleitende von eigenständigen Radwegen unterscheiden können. Und benutzungspflichtige, von nicht benutzungspflichten Radwegen. Gibt es da eine Möglichkeit? Entweder: benutzungspflichtig: bicycle=designated nicht benutzungspflichtig: bicycle=yes Oder: benutzungspflichtig: bicycle=official nicht benutzungspflichtig: bicycle=yes/designated Die Frage ist was designated sein soll? Ein Beschilderter Radweg? Das könnte aber auch eine Radroute oder ein Fahrrad frei Schild sein... Deswegen wurde official erfunden. Man müsste sich da nur mal einigen, am besten weltweit! Official hat sich ja wohl nicht durchgesetzt und ich dachte wir hätten uns geeinigt das designated mit official gleich zu setzten ist. Die Sache mit dem bicycle=yes ist auch nicht so klar. Viele setzten das einfach bei allen Wegen, die mit dem Rad befahren werden KÖNNEN. Wahrscheinlich die Potlatch-User mit den eingebauten presets. Sinn macht es nur bei Schildern die das erlauben, der Rest wird ohnehin durch die Landesspezifischen access-Regelungen geregelt. Alternative für dort darf man radeln könnte sowas sein: cycling=yes +1, aber ist das nötig ? Nein, ist es nicht! Das größte Problem sind die Web-Editoren mit ihren Vorschlägen/Auswahlfelder, so dass man als Benutzer geneigt ist alle ausführlich auszufüllen. :( -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing-Hinweise taggen
Am 02.11.2013, 17:34 Uhr, schrieb Bernhard Weiskopf bweisk...@gmx.de: Was kann man tun, dass Fahrradrouter die empfohlene Beschilderung kennen? Ich benutze in solchen Fällen gerne ein bicycle=avoid. Aber es spricht nichts dagegen, die Umgehung als lcn=yes zu taggen. lcn ist mir nur in Verbindung mit Relationen bzw. ausgeschilderten Routen (mit Namen) bekannt. Hier ist das nur eine kurze (namenlose) Umgehung, ich finde es trotzdem okay. lcn gibt auch an der tertiary (Straße) weiter nördlich. bicycle = avoid habe ich noch nie gesehen geschweige denn verwendet. Aber das ist ziemlich genau das, was die Stadt mit dem Aufstellen der Schilder gemeint hat. Ein genereller Vermeidungshinweis ist nicht optimal. Dann doch besser was aus dem Tag class:bicycle=* http://wiki.openstreetmap.org/wiki/Class:bicycle z.B. class:bicycle:non_experienced=1/-1 für die Umleitung bzw. die Hauptstraße. Ich habe mir die Straße zwar nur im Satellitenbild angeschaut, würde aber wahrscheinlich nicht den Umweg inkaufnehmen, da es auf der Hauptstraße vermutlich deutlich schneller und sicherer voran geht. Deswegen ginge mir ein bicycle=avoid etwas zu weit. Die Straße ist ohne Zweifel schneller, aber für Radfahrer sehr unsicher. Sie ist schmal, da passt auf ein paar hundert Meter kein Radweg daneben und die Autos überholen sehr dicht. An zwei Bushaltestellen wurden kleine Inseln eingerichtet, dass Fußgänger beim Überqueren in der Straßenmitte stehenbleiben können. Hier sind die Fahrbahnen genau 3 Meter breit und PKW überholen trotzdem die Radfahrer. Wenn man mittig auf der Spur fährt, können müssen die Autos zum Überholen nur auf die Gegenfahrbahn ausweichen, wenn das nicht möglich ist kann man halt nicht überholt werden. Diese Fahrweise macht besonders viel Sinn bei Gegenverkehr und ein Stück vor den Verkehrsinseln um sich nicht in Gefahr zu bringen. Es ist auch keine Behinderung des Autoverkehrs, da dieser bei zuwenig Platz nicht überholen darf. Routing von schnellster Strecke und kürzester Strecke soll durchaus über diese gefährliche Strecke führen, aber Router, die mehr können, sollen die Ausweichstrecke erkennen und nutzen. Der Radweg ist mit horse=no motor_vehicle=no getaggt. Es ist besser, nur die Bedeutung der Schilder zu taggen, die auch dort stehen. foot/bicycle=designated zeigt ja schon an, dass es sich um einen Sonderweg für Radfahrer Fußgänger handelt und für die anderen Verkehrsteilnehmer nicht erlaubt ist. Gemäß den Empfehlungen ist der kombinierte Rad- und Fußweg als path getagged. Hier muss horse = no dazu, denn implizit gilt bei path horse = yes. foot/bicycle=designated hat keinen Einfluss auf horse. motor_vehicle=no ist nicht notwendig, da stimme ich zu. Üblicherweise lasse ich Redundanzen stehen, sie schaden nicht. Und wie taggst du einen Weg mit den expliziten Beschränkungen für Pferd und Motorfahrzeug? Genauso? Es macht mMn viel mehr Sinn die Aussage der Schilder zu Taggen, und das foot/bicycle=designated steht für den benutzungspflichtigen Sonderweg, und somit automatisch ein Verbot für alle anderen. Bei dem Taggen Schildern die nicht da sind, vergisst mal leicht einzelne Nutzergruppen, was ist mit den nichtmotorisierten Fahrzeugen, die dürfen nämlich dort auch nicht fahren. Also wenn dann vehicle=no, oder noch besser access=no. (Dies bitte nicht ernst nehmen, wollte nur aufzeigen wo es dann hinführt.) Stattdessen wäre es praktisch anzugeben, ob es ein gemeinsamer- oder getrennter Fuß- und Radweg ist, mit segregated=yes/no :-) Warum stattdessen? segregated=yes/no muss jemand nachprüfen. Als ich zuletzt dort war, war im nördlichen Teil segregated = yes und im südlichen segregated = no. Das wurde aber mehrmals geändert und den jetzt aktuellen Stand kenne ich nicht. Da zwischen Radweg und Straße teilweise ein Grünstreifen verläuft, sind darauf oft die Hunde und ich bin froh, wenn Herrchen dann auf dem Radweg steht, dann komme ich mit dem Rad über den Fußweg gut vorbei. Andernfalls gibt's Konflikt mit der Leine quer über den Radweg. Ok, natürlich kann man das nur taggen wenn man es weiß! Gruß Masi -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 03.11.2013, 15:48 Uhr, schrieb Bernhard Weiskopf bweisk...@gmx.de: Denn: Außerorts ist das befahren mit dem Mofa erlaubt. (Bei gleicher Beschilderung) Das ist ein Punkt, den ich vermisse: Inner- und außerorts gelten in Deutschland andere Verkehrsregeln, nicht nur für die Benutzung von Radwegen, sondern auch fürs Parken, fürs Gehen an Straßen, für Höchstgeschwindigkeiten, fürs Rechtsfahrgebot usw. Gibt es ein Tag, mit dem man inner- oder außerhalb geschlossener Ortschaft kennzeichnen kann? +1 Einzelne Straßen/Wege so zu taggen mach keinen Sinn, das jeder diesen Tag übernehmen müsste wenn ein neuer Weg eingezeichnet wird. Also gehts eher in die Richtung Fläche/Umriss. Habe ein altes Proposal gefunden: http://wiki.openstreetmap.org/wiki/Proposed_features/trafficzone Ggf. geht es mit einem Zusatztag an landuse=residential, weil meist desckungsgleich. Bzw. an dem jeweiligen outer-Ring, denn die per Relation ausgeschnittenen innerstädtischen landuse bleiben natürlich innerorts. Oder sonst mit mit einer boundary oder einer anderen Fläche die nochmal drübergelegt wird. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 03.11.2013, 15:04 Uhr, schrieb Dirk Sohler s...@0x7be.de: Masi Master schrieb: OT: Sonder eher ob der Radweg innerorts oder außerorts ist. Also ob er sich innerhalb der Ortsfläche befindet, oder außerhalb? Ja genau. Genauer gesagt, mit Ortsfläche meine ich nicht die Ortsfläche landuse=residential/comercial/retail o.ä., sondern das was innerhalb der gelben Ortsschilder liegt. Bernhard Weiskopf hat dazu eine neue Überschrift erstellt: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege und auch noch mehrere gute Aspekte/Begründungen dazu geschrieben! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 03.11.2013, 15:26 Uhr, schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 03.11.2013 14:41, schrieb Masi Master: Am 02.11.2013, 16:14 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 2. November 2013 16:10 schrieb Bernhard Weiskopf bweisk...@gmx.de: Aus meiner Sicht: oneway = yes - Fahrzeuge dürfen nur in eine Richtung fahren (Beschilderung wurde geprüft) oneway = no - Fahrzeuge dürfen in beiden Richtung fahren (Beschilderung wurde geprüft) keine oneway-Angabe - Richtung unbekannt bzw. ungeprüft. Router nehmen an, dass beide Richtungen erlaubt sind. Vorläufig oder nicht - Keine Zeitunterscheidung, d. h. bleibend Straßenbegleitend oder nicht - Keine Fallunterscheidung notwendig zu allem Zustimmung außer Router nehmen an, dass beide Richtungen erlaubt sind. keine oneway-Angabe bei Radwegen: Router nehmen an, dass Radfahrer nur in eine Richtung fahren dürfen (wie beim oneway=no) Begründung: Die VwV der StVO sagt: II. Freigabe linker Radwege (Radverkehr in Gegenrichtung) 1. Die Benutzung von in Fahrtrichtung links angelegten Radwegen in Gegenrichtung ist insbesondere innerhalb geschlossener Ortschaften mit besonderen Gefahren verbunden und soll deshalb grundsätzlich nicht angeordnet werden. [...] Also zumindest gilt das für deutsche Radwege. Du bist hier aber nahe dran, dir selbst zu widersprechen: Einerseits meinst du, wir bräuchten keine Unterscheidung zwischen straßenbegleitend und nicht-straßenbegleitend, andererseits aber forderst du von Routern, für straßenbegleitende Radwege oneway anzunehmen. Nun müssten Router dafür aber diese Unterscheidung treffen, und zwar - da deiner Meinung nach das ja nicht über die Tags auszudrücken ist - allein aufgrund der Geometrie und der relativen Lage zu Straßen. Allein auf einer Karte würde ich dabei nicht unterscheiden wollen, ob ein Radweg im Sinne der StVO Straßenbegleitend ist oder nicht: - Auf dem Bürgersteig, also nur durch eine Stufe getrennt: sicher straßenbegleitend. - Durch 1m-breiten Grünstreifen getrennt: Meistens straßenbegleitend - Durch 5m breiten Grünstreifen getrennt: puh... - schon schwieriger, das kann auch ein Radweg sein, der grob entlang der Straße führt. Insofern braucht man entweder das oneway-Tag immer, oder aber die Information, dass und zu welcher Straße (!) ein Radweg straßenbegleitend ist. Sorry, vielleicht habe ich mich nicht ganz klar ausgedrückt: Ich bin ganz klar für ein oneway-tag an JEDEM Radweg. Ich bin gegen (irgend)eine oneway-Annahme von Routern (á la der Defaultwert für Straßen ist oneway=no, also ist er das auch für Radwege.) Bei Autobahnen ist der Defaultwert oneway=yes. Bei Radwegen gibt es keine hauptsächliche Regelung, also auch kein Defaultwert (der weggelassen oder gar gelöscht werden kann). Das Zitat aus der StVO sollte nur ein (halb ernstzunehmendes) Gegenbeispiel zum entkräften sein. So ist es ja nur in DE, und passt nicht unbedingt für das weltweite OSM. Wenn das durchgängige oneway an Radwegen der Fall ist, sehe ich grade nicht, zu welchem Zweck es ein Tag für straßenbegleitend oder nicht geben braucht. Fürs Routing ist es egal, Hauptsache man kommt an. Höchstens die Benutzungspflicht kann/sollte in irgendeiner Weise ablesbar sein, möglichst im Unterschied zu Radwegen ohne Benutzungspflicht. Aber die kann man auch durch die Bedeutung der aufgestellten Schilder taggen. +1, leider meinen manche Mapper, dass man scheinbar redundante tags am besten wieder entfernt, also z.B. so was wie oneway=no. +1 Ich denke nicht, dass wir eine Unterscheidung in straßenbegleitend oder nicht brauchen. OT: Sonder eher ob der Radweg innerorts oder außerorts ist. Denn: Außerorts ist das befahren mit dem Mofa erlaubt. (Bei gleicher Beschilderung) -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 03.11.2013, 21:35 Uhr, schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 03.11.2013 17:14, schrieb Masi Master: Am 03.11.2013, 15:26 Uhr, schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 03.11.2013 14:41, schrieb Masi Master: Am 02.11.2013, 16:14 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 2. November 2013 16:10 schrieb Bernhard Weiskopf bweisk...@gmx.de: Aus meiner Sicht: oneway = yes - Fahrzeuge dürfen nur in eine Richtung fahren (Beschilderung wurde geprüft) oneway = no - Fahrzeuge dürfen in beiden Richtung fahren (Beschilderung wurde geprüft) keine oneway-Angabe - Richtung unbekannt bzw. ungeprüft. Router nehmen an, dass beide Richtungen erlaubt sind. Vorläufig oder nicht - Keine Zeitunterscheidung, d. h. bleibend Straßenbegleitend oder nicht - Keine Fallunterscheidung notwendig zu allem Zustimmung außer Router nehmen an, dass beide Richtungen erlaubt sind. keine oneway-Angabe bei Radwegen: Router nehmen an, dass Radfahrer nur in eine Richtung fahren dürfen (wie beim oneway=no) Begründung: Die VwV der StVO sagt: II. Freigabe linker Radwege (Radverkehr in Gegenrichtung) 1. Die Benutzung von in Fahrtrichtung links angelegten Radwegen in Gegenrichtung ist insbesondere innerhalb geschlossener Ortschaften mit besonderen Gefahren verbunden und soll deshalb grundsätzlich nicht angeordnet werden. [...] Also zumindest gilt das für deutsche Radwege. Du bist hier aber nahe dran, dir selbst zu widersprechen: Einerseits meinst du, wir bräuchten keine Unterscheidung zwischen straßenbegleitend und nicht-straßenbegleitend, andererseits aber forderst du von Routern, für straßenbegleitende Radwege oneway anzunehmen. Nun müssten Router dafür aber diese Unterscheidung treffen, und zwar - da deiner Meinung nach das ja nicht über die Tags auszudrücken ist - allein aufgrund der Geometrie und der relativen Lage zu Straßen. Allein auf einer Karte würde ich dabei nicht unterscheiden wollen, ob ein Radweg im Sinne der StVO Straßenbegleitend ist oder nicht: - Auf dem Bürgersteig, also nur durch eine Stufe getrennt: sicher straßenbegleitend. - Durch 1m-breiten Grünstreifen getrennt: Meistens straßenbegleitend - Durch 5m breiten Grünstreifen getrennt: puh... - schon schwieriger, das kann auch ein Radweg sein, der grob entlang der Straße führt. Insofern braucht man entweder das oneway-Tag immer, oder aber die Information, dass und zu welcher Straße (!) ein Radweg straßenbegleitend ist. Sorry, vielleicht habe ich mich nicht ganz klar ausgedrückt: Ich bin ganz klar für ein oneway-tag an JEDEM Radweg. okay, das hatte ich tatsächlich anders verstanden. Ich bin gegen (irgend)eine oneway-Annahme von Routern (á la der Defaultwert für Straßen ist oneway=no, also ist er das auch für Radwege.) Bei Autobahnen ist der Defaultwert oneway=yes. Bei Radwegen gibt es keine hauptsächliche Regelung, also auch kein Defaultwert (der weggelassen oder gar gelöscht werden kann). Nun ja... - aber was soll dann ein Router deiner Meinung nach tun, wenn oneway nicht am Weg getagged ist? Es geht ja nicht darum, dass Mapper das Tag weglassen sollten weil Router immer oneway=x annehmen (was auch immer x ist); aber wenn ein weg kein oneway-Tag hat, dann MUSS ein Router einen Wert für oneway annehmen - und damit ein default intern nutzen. Die einzige Alternative wäre, den Weg komplett zu ignorieren. Entweder erlaubt der Router das Routing in beide Richtungen oder nicht (wenn es nicht explizit als Tag definiert ist), aber weder noch bzw. sowohl als auch geht nicht. Dass der Router natürlich nicht erkennen kann, was nun die richtige Richtung ist (der Weg kann ja auch andersrum gezeichnet sein), hatte ich nicht dran gedacht. Ein Grund mehr für ein oneway-tag. Halbernst: Aus Sicherheitsgründen (falschrumfahren ist extrem gefährlich) müsste der Router den Weg dann nicht beachten. (Aber ich bin mir ganz sicher, dass es keine Mehrheit dafür geben wird. Außerdem sucht sich der Router aus was er annimmt.) Das Zitat aus der StVO sollte nur ein (halb ernstzunehmendes) Gegenbeispiel zum entkräften sein. So ist es ja nur in DE, und passt nicht unbedingt für das weltweite OSM. Wenn das durchgängige oneway an Radwegen der Fall ist, sehe ich grade nicht, zu welchem Zweck es ein Tag für straßenbegleitend oder nicht geben braucht. Fürs Routing ist es egal, Hauptsache man kommt an. Höchstens die Benutzungspflicht kann/sollte in irgendeiner Weise ablesbar sein, möglichst im Unterschied zu Radwegen ohne Benutzungspflicht. Aber die kann man auch durch die Bedeutung der aufgestellten Schilder taggen. Kann man das? Spontane Fälle, bei denen ich mir da nicht sicher bin, wie das zu tun wäre: Fall 1) Benutzungspflichtiger Radweg: Taggst du dann bicycle=no an der dazugehörigen Straße? Im Grunde genommen schon, denn da darf man dann eben nicht Radfahren (solange der Zustand des Radwegs zumutbar ist). Fall 2) Benutzungspflichtiger Radweg ohne explizite Erlaubnis in Gegenrichtung, aber nur auf einer
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 02.11.2013, 09:35 Uhr, schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Am Freitag, den 01.11.2013, 20:06 +0100 schrieb Bernhard Weiskopf: Dann zeige doch mal einen Radweg, der mit oneway=yes getaggt ist, weil er straßenbegleitend ist. Zum Beispiel hier: http://www.openstreetmap.org/?mlat=49.50360mlon=8.49903#map=19/49.50360/8. 49903 In Mannheim sind etwa die Hälfte der straßenbegleitenden Radwege in beiden Richtungen freigegeben, die andere Hälfte nicht. So auch im o. a. Fall: der südliche Weg darf nur Richtung Osten benutzt werden, der nördliche in beiden Richtungen. Stimmt, kommt häufig vor. Aber ebenso häufig auch nicht. Vielleicht sollte jeder straßenbegleitende Radweg mindestens vorläufig ein oneway=yes/no bekommen, damit ersichtich wird, wo das gemappt wurde und wo nicht. +1 für oneway=yes/no an Radwegen! (-1 für vorläufig) Radwege sind nicht einheitlich in 2 Richtungen (bzw. eine Richtung) freigegeben, so dass ein Standardwert (wie bei motorway oder normalen Straßen) überhaupt keinen Sinn macht. Aber warum nur an straßenbegleitenden? -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing-Hinweise taggen
Am 01.11.2013, 21:11 Uhr, schrieb chris66 chris66...@gmx.de: Am 01.11.2013 21:01, schrieb Bernhard Weiskopf: Am Ende des Radwegs stehen (unverbindliche) Hinweisschilder, die Radfahrer Richtung Süden über die parallel verlaufende Hohensalzaer Straße leiten. Die Hohensalzaer Straße ist eine ruhige Wohnstraße, auf der man gut Radfahren kann, während die Sonderburger Straße eine verkehrsreiche Hauptstraße ist, mit LKW-Verkehr, Bushaltestellen und Engstellen. Hier ist Radfahren zwar nicht verboten, aber auch wirklich nicht zu empfehlen. Was kann man tun, dass Fahrradrouter die empfohlene Beschilderung kennen? Ich benutze in solchen Fällen gerne ein bicycle=avoid. Aber es spricht nichts dagegen, die Umgehung als lcn=yes zu taggen. Ich habe mir die Straße zwar nur im Satellitenbild angeschaut, würde aber wahrscheinlich nicht den Umweg inkaufnehmen, da es auf der Hauptstraße vermutlich deutlich schneller und sicherer voran geht. Deswegen ginge mir ein bicycle=avoid etwas zu weit. Gruß Masi PS: Der Radweg ist mit horse=no motor_vehicle=no getaggt. Es ist besser, nur die Bedeutung der Schilder zu taggen, die auch dort stehen. foot/bicycle=designated zeigt ja schon an, dass es sich um einen Sonderweg für Radfahrer Fußgänger handelt und für die anderen Verkehrsteilnehmer nicht erlaubt ist. Stattdessen wäre es praktisch anzugeben, ob es ein gemeinsamer- oder getrennter Fuß- und Radweg ist, mit segregated=yes/no :-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 31.10.2013, 18:20 Uhr, schrieb Stephan Wolff s.wo...@web.de: Moin, für eine brauchbare Fahrradkarte genügt es offensichtlich nicht, wenn Straße und Radweg einzeln erfasst sind (siehe Mapnikkarte mit je nach Zoomlevel sichtbaren, halb überdeckten oder gar nicht sichtbaren straßenbegleitenden Radwegen). Auch für gutes Fahrradrouting muss man straßenbegleitende von eigenständigen Radwegen unterscheiden können. Mein Garmin-GPS hat mich teils vom Radweg auf die Straße und zurück auf den Radweg geschickt, um wenige Meter in der Kurve abzukürzen. Das hat nichts mit straßenbegleitend oder nicht nicht zu tun, sondern eher ob der Radweg benutzungspflichtig ist oder nicht, und ob dein Garmin das unterscheiden kann, oder ob du es darin gar einstellen kannst, wo du lieber radeln möchtest. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Am 31.10.2013, 19:20 Uhr, schrieb Dirk Sohler s...@0x7be.de: Stephan Wolff schrieb: Auch für gutes Fahrradrouting muss man straßenbegleitende von eigenständigen Radwegen unterscheiden können. Und benutzungspflichtige, von nicht benutzungspflichten Radwegen. Gibt es da eine Möglichkeit? Entweder: benutzungspflichtig: bicycle=designated nicht benutzungspflichtig: bicycle=yes Oder: benutzungspflichtig: bicycle=official nicht benutzungspflichtig: bicycle=yes/designated Die Frage ist was designated sein soll? Ein Beschilderter Radweg? Das könnte aber auch eine Radroute oder ein Fahrrad frei Schild sein... Deswegen wurde official erfunden. Man müsste sich da nur mal einigen, am besten weltweit! Die Sache mit dem bicycle=yes ist auch nicht so klar. Viele setzten das einfach bei allen Wegen, die mit dem Rad befahren werden KÖNNEN. Wahrscheinlich die Potlatch-User mit den eingebauten presets. Sinn macht es nur bei Schildern die das erlauben, der Rest wird ohnehin durch die Landesspezifischen access-Regelungen geregelt. Alternative für dort darf man radeln könnte sowas sein: cycling=yes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Wenn ich das richtig sehe geht es hier nur um Relation oder keine Relation!? Ohne Relation müsste man name des Radnetzes, network, ref, type, website, operator und andere Tags alle an den jeweiligen Weg hängen. Das kann nie einheitlich klappen! Also muss eine Relation her. Noch ein paar Gedanken: - Auf den Schildern (Wegweiser) ist jeweils immer ein Nahziel und Fernziel angegeben. Beide sind aber nicht weiter als 20 km weit entfernt. Dann müsste es doch eher network=lcn sein (lokal)? Ob das Netz nur ein kleines Bundesland/wenige Landkreise umspannt, oder Europaweit existiert ist mMn nebensächlich für den network-Tag. - Es gibt die Netze als Waben-, Knotenpunkt-, Kanten- und ohne Struktur. Hier bei Köln wird ab nun das Netz ohne Struktur in eins mit Knotenpunkten umgebaut. Der einzige Unterschied wird sein, dass die Wegweiser (mit 3 oder mehr Richtungen) eine Nummer bekommen. Die Waben gibt es im Raum Münster. Jede Wabe hat eine eigene Relation. (Die Waben-Kanten sind also in genau 2 Relationen enthalten, außer am Rand des Netzes) Bei Knotenpunktsystemen sind meines Wissens die Verbindung zwischen 2 Knoten je in einer Relation. Da Knotensysteme und die ohne Struktur praktisch gleich sind, kann man auch dort sie Abschnitte zwischen 2 Wegweisern in eine eigene Relation packen. (name könnte dann das Nah- oder Fernziel auf den Wegweisern sein, statt sonst der Wegweisernummer.) Vorteil ist, dass nicht alles in einer Superrelation reingeklatscht wird und riesig und unübersichtlich wird. Und man kann, wenn roundtrip=no/yes gesetzt wird, sofort per Algorithmus erkennen kann, ob die Relation defekt ist oder nicht. Mit name in den Relationsabschnitten kann die Navigation auch ausgeben, zu welchem Wegweiser es weitergeht. Die Einteilung des NRW-Radnetzes wurde vermutlich in die Landkreise aufgeteilt, weil es sonst zu groß würde. Am 19.10.2013, 22:17 Uhr, schrieb Henning Scholland o...@aighes.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 19.10.2013 17:24, schrieb fly: Ansonsten würde eine Flächenberechnung mit Hilfe der Wegweiser genügen, bzw ist so was auch häufig über administrative Grenzen bestimmbar. Kommt drauf an. Wenn deine Annahme stimmt, muss man vorher schon wissen, dass es in Gemeinde X nur das Netz von Landkreis Y gibt. Wenn das Netz nun aber von der Kurverwaltung kommt, dann muss es sich ja nicht unbedingt an die administrativen Grenzen halten. Wenn man nach administrativen Grenzen geht, weiß man auch noch nicht, wer nun der operator ist und welche Grenze man nun nehmen muss. Evtl. haben sich auch mehrere Landkreise zusammengeschlossen... Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSYujlAAoJEPFgsWC7jOeTtTIH/RQZIsiMGWZH0pIBcgGj8w/Q TDNqzQXYJ+mmxuguvTM+mBbJCiqdome3P5GExwHGLg7L1UNZSZ4sSLPATfgAq1tt VaGRGoovlRTUBrbRNhqD4wi+M2jdRZZpDJiPE/E46jdsrwxKHf6xJV5BDPb/4v+f eURVtwOdL42GH7u/uLnNxi4zfGJtmOVt7yQJB9Du02nCXzSKFNCfPxQeAUuy1bbU nnzwlwNaFOaVgDDKbnBsUKEBgDzt+T7vllMM1ZZyPnA6O/qTR7aY1JqQ8S6aPcMf lWg4rhvLNA11PIMbGU15R96SV1QHIuZuq6xzqfGzDboWMmhS2+Z90Gu0Pm8d85U= =1XVH -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abkürzungen (bei Sportvereinen) im Namen
Am 14.10.2013, 17:41 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 14. Oktober 2013 17:33 schrieb Manuel Reimer manuel.s...@nurfuerspam.de : Auch name:de mit Abkürzung halte ich für falsch. Im Sprachgebrauch verwendet ja schließlich keiner die Abkürzung sondern den ganzen Namen. name:de sollte die deutsche Variante des name-tags sein, d.h. in Deutschland (bzw. bei deutschem Inhalt des name-tags) sollte name:de genau dasselbe sein wie name. Für Varianten gibt es alt_name nat_name, loc_name etc. Wie macht Ihr das ? Wenn ich das hier so betrachte: http://wiki.openstreetmap.org/**wiki/DE:Key:namehttp://wiki.openstreetmap.org/wiki/DE:Key:name Dann scheint mir short_name ganz gut zu treffen... Ich würde es ehrlich gesagt lieber anders rum machen (also Abkürzung wenn die gebräuchlichere Form in der gesprochenen Sprache in den name-tag und die ausgeschriebene Variante in den tag official_name). Im Sprachgebrauch verwendet man eher die Abkürzung bei Sportvereinen (zumindest kenne ich das aus meiner Heimat im Südwesten so bei den dort ansässigen Sportvereinen). Man sagt te-es-ge XStadt und nicht Turn- und Sportgemeinde XStadt oder te-es-fau XStadt anstatt Turn- und Sportverein XStadt. Ganz genauso würde ich es auch machen: Das was man Ausspricht ins name-Tag, und (meinetwegen) den ausgeschriebenen/offiziellen in official_name. Bei SpVgg Unterhaching wäre das dann mit der Kurzschreibweise andersrum, weil keiner SpVgg spricht: name=Spielvereinigung Unterhaching short_name=SpVgg Unterhaching Bei dem anfangs genannten St. wäre das dann genau wie str. nicht gekürzt im name-Tag. Gruß Masi -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] fehlende Mofa-Tags ausserhalb geschlossener Ortschaften in D auf Fahrradwegen?
Hmm, danke für die Anregung! Fahre zwar kein Mofa sondern Rad, aber das mofa=yes Tag ist außerorts sicherlich richtig. Wird wahrscheinlich auch deswegen vergessen zu taggen, weil sowas kein (extra) Schild anzeigt. (Und natürlich weil die Mofa-Lobby hier nicht so groß ist.) Wenn die es hier endlich die neuen Bing-Bilder gibt, versuch ich beim aktualisieren der Radwege mal drauf zu achten. Als grobe Näherung (z.B. für ein Qualitätssicherungs-Tool) bieten sich sie residential-Flächen an, falls diese an den Straßen nicht ausgestanzt sind. Gruß Masi Am 11.10.2013, 12:35 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Anscheinend fehlen sehr viele mofa=yes tags auf Fahrradwegen ausserhalb geschlossener Ortschaften in Deutschland (wo diese AFAIK auch ohne gesonderte Beschilderung erlaubt sind). Wollte ich mal so erwähnen, auch wenn Mofas ja nicht mehr sonderlich beliebt oder verbreitet zu sein scheinen heutzutage. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autokennzeichen
Am 09.08.2013, 10:19 Uhr, schrieb Sarah Hoffmann lon...@denofr.de: On Fri, Aug 09, 2013 at 09:33:20AM +0200, Roland Olbricht wrote: für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die Suche nach deutschen Autokennzeichen unterstützen möge. Finde ich jetzt keine schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die Kreise dienen. Berlin macht das bereits so, mit dem Erfolg, dass jetzt solche Suchergebnisse herauskommen: http://nominatim.osm.org/search.php?q=berlinaccept-language=xx Sämtliche Bundesländer (und auch die in Italien) tragen solche Abkürzungen. Genauer: Beim Sichten der Einträge in Admin-Level 4 und 6 hat sich herausgestellt, dass da bis auf je eine Relation immer Abkürzungen drinstehen. Das liegt daran, dass der Nutzer MasiMaster die vor einer Woche dort alle angefügt hat: http://www.openstreetmap.org/browse/changeset/17204949 Die ersten Beschwerden gab es eine Stunde später. ;) Ups, Beschwerden wollte ich keine auslösen! Mein Vorgehen was so: Ich suchte einen kleinen Ort bei mir in der Nähe (der x-mal in DE vorkommt), wusste aber nicht in welchem Landkreis der war. Und die Suche mit: Ortsname, NRW lieferte kein Ergebnis zurück. Da ich mir (und anderen) den langen Namen Nordrhein-Westfalen ersparen wollte, hab ich die Abkürzung gesetzt. Denn irgendwann habe ich mitbekommen dass Nominatim auch short_name auswertet. Hat aber leider nicht funktioniert. Praktisch wäre es auch, nicht immer Rheinisch-Bergischer-Kreis aus schreiben zu müssen, sondern wie das Kennzeichen GL (wegen Bergisch Gladbach). Wie und wo das Kürzel nun untergebracht werden soll, ist mir erstmal nicht ganz so wichtig, Hauptsache es vereinfacht die Eingabe bei der Suche :) Bei den Kürzeln für die Bundesländer gibt es auch verschiedene Schreibweisen, einmal die (inoffiziellen?) 1-3-stelligen NRW, BY, B, und die 2-stelligen ISO-soundso NW, BY, BE beste Grüße Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsfehler im Rendering. Wie Fehler melden?
Am 07.08.2013, 15:18 Uhr, schrieb Sven Geggus li...@fuchsschwanzdomain.de: rainerU ra...@sfr.fr wrote: Es könnte mit der Umstellung auf CartoCss[1] zusammenhängen, die am Wochenende erfolgt ist. Nein, das kann es nicht! Das Problem liegt wie bereits mehrfach geschrieben an der Kachelgrenze und tritt im deutschen Kartenstil, der nicht CartoCss basiert ist ebenfalls auf. Vielleicht ist genau dort die Grenze der Meta-Kachel!? Dann könnte es ggf. helfen, wenn die Meta-Kacheln größer, überlappend gerechnet werden und der Rand verworfen wird!? Wird momentan nich nur ein Pseudo-Rand erzeugt, der sofort von mapnik verworfen wird. Oder der momentane Rad reicht nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Am 23.07.2013, 11:21 Uhr, schrieb Stefan Keller sfkel...@gmail.com: Hallo Masi Finde deine Überlegungen interessant, v.a. der Teil Am 23. Juli 2013 00:13 schrieb Masi Master masi-mas...@gmx.de: ... Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von Routern nicht mehr berücksichtigt werden und aufgrund des Datums können alle überfälligen Baustellen aus der Datenbank gelöscht werden. Ok. Aber warum zwingend mit Relationen? Nicht zwingend. Aber Relationen bieten gewisse Vorteile, z.T. vorher schon erwähnt: Man hat alles in einer Relation, beim Rückändern bei Fertigstellung der Baustelle muss nur ein Objekt gelöscht werden, anstatt mehrere Tags bei vielen Wegen, welche man erst mühsam raussuchen muss. Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, versteht sich) Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Stimmt. Die langen Tags sind problematisch. Aber immer noch das kleinere Übel als Tags, die voneinander abhängig sind. Zu diesem Schema gibt es bereits seit längerer Zeit ein Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/temporary Könnte man z.B. eine temporäre Sperrrung nicht so erfassen - gemäss Eckharts Hinweis auf das bereits existierende [1]? motor_vehicle:conditional=no @ (2014-07-27..2014-07-28) [1] http://wiki.openstreetmap.org/wiki/Conditional_restrictions Das wird nicht funktionieren, da es nicht die anderen tags alle überschreibt. Naja, das conditional-Schema ist eh schon recht kryptisch... Leider konnte man sich dabei nicht auf das einfachere Schema mit den Relationen einigen... Dann hätte man auch nicht die ganzen Strings aufzuschneiden und die Logik dort herauszufiltern müssen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Am 22.07.2013, 20:25 Uhr, schrieb Frank fr...@fotodrachen.de: Am 22.07.2013 08:07, schrieb Eckhart Wörner: Hallo Alexander, Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen • zusätzliche amenities: opening_hours? Eckhart Ich denke, es ging Alexander eher um die Frage, ob man die temporären Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen sollte. Es wäre zwar nett, wenn die Karte auch während des Ausnahmezustandes Stadtfest aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich. Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend eingerichtet wurden. Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann wochenlang mit diesen Sonder-Anpassungen herum. Auch andere Auszüge werden nicht täglich aktualisiert. Ich denke, die OSM-Datenbank sollte nur den Normalzustand wiedergeben und nicht den temporären Ausnahmezustand. Dies kann evtl. auf einer Webseite oder in Flyern durch Overlays dargestellt werden. Das Problem ist doch, dass das zeitliche Sperren nicht funktioniert und zu lange in der Datenbank bestehen bleibt (oft wird die Sperrung vergessen aus OSM herauszunehmen) Angenommen eine Straße hat das Tagging motorcycle=no + mofa=yes. Nun kommt einer und will die Straße mit access=no sperren. Funktioniert natürlich nicht für Mofas und alle anderen (vorher überflüssigen) *=yes Tags werden zum Verhängnis. date_on date_off geht genausowenig, da nicht klar ist, auf welche Tags es sich bezieht. Eine mögliche Lösung ist eine Baustellen- oder Sperrungs-Relation, die alle access tags der Wege nicht beachtet und mit access=no überschreibt. Gleichzeitig kann die Relation weitere access tags aufnehmen, zB Freigabe für Fußgänger und Radfahrer, oder Freigabe für Anwohner. Bei der Relation MUSS aber mit angegeben werden, von wann - und noch wichtiger - BIS wann gesperrt ist. Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von Routern nicht mehr berücksichtigt werden und aufgrund des Datums können alle überfälligen Baustellen aus der Datenbank gelöscht werden. Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, versteht sich) Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Falls das Enddatum unbekannt ist, sollte/muss eine Schätzung angegeben werden, damit die Mapper nach der Frist die Baustelle nochmal überprüfen/aktualisieren können. So, das war meine bisherige Überlegung. Aber vielleicht hat jemand noch einen besseren Vorschlag? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 02.07.2013, 19:28 Uhr, schrieb Tirkon tirko...@yahoo.de: Wolfgang Hinsch osm-lis...@ivkasogis.de wrote: Zudem werden insbesondere langstreckige Relationen leicht bei Gebrauch des Anfängereditors ID beschädigt, da man sie im Gegensatz zu JOSM nicht sieht und auch nicht gewarnt wird, wenn man ein Member hiervon löscht - letzteres auch bei Potlatch. Das gleiche Problem besteht, wenn jemand beispielsweise den Lauf der Straße auftrennt, um eine Brücke einzufügen. Er nimmt die Relation dank des Editors nicht wahr und trägt sie folglich bei der Brücke nicht ein bzw. hat im Editor nicht die Möglichkeit, sie eintragen. Mögliche Folge beim Navi: Wenn möglich, bitte wenden. Im Normalfall wird die Straße nur mit P aufgetrennt, um eine Brücke einzufügen. Aber anscheinend schaffen viele Benutzer das nicht, und zeichnen die Linie neu. Dann fehlen auch die Relationen. Vielleicht muss man in den Editoren besonders auf die allerwichtigsten Befehle/Tasten hinweisen! Alles in Allem hat das Einbahnstraßen-Modell wesentlich mehr Vorteile und ist zudem eindeutiger. Denn ob die Fahrbahnen faktisch zwischen zwei richtungsgetrennten Auf-/Abfahrten durchgehend richtungsgetrennt sind, kann eindeutig bestimmt werden. Dagegen ist die Definition eines Mittelstreifens umstritten. Willst du überall dort, wo eine einfache Mittellinie besteht aus der Straße zwei Einbahnstraßen machen??? ... die aber gerade für eine bauliche Trennung ausschlaggebend sind. Auf eine eindeutige bauliche Trennung hin zu mappen, ist ebenfalls verkehrsunsicherer. Denn bei einem Grünstreifen mit Leitplanke wechselt man nicht so schnell auf die Gegenfahrbahn, wie bei einer Trennung mit Doppelstreifen. Damit ist eine suggestivere Kennzeichnung im letzteren Fall noch angebrachter und damit verkehrssicherer. Die StVO hat zwar eine andere Definition von Baulicher Trennung als wir bei OSM. Das System nur bei einer echten baulichen Trennung die highways aufzutrennen, finde ich nach wie vor sehr gut! Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder zusammenfügen
Am 26.06.2013, 23:24 Uhr, schrieb Thorsten Alge m...@thorsten-alge.de: Hallo Liste, ich komme ggf. ein ältere Karten heran die ich gerne für verschiedene Zwecke einscannen würde. Da diese aber deutlich über die größe meines Scanners herausragen muss ich diese in Abschnitten einscannen und danach zusammen fügen. Hat damit schon Jemand Erfahrung und kann mir eine brauchbare Software empfehlen? Ich habe es bereits mit Hugin versucht komme damit aber gar nicht zurecht. Mit Hugin ists vielleicht ein wenig zu aufwändig, nur rechteckige Bilder aneinander zu fügen. Jedoch kann man damit relativ gut die Erdkrümmung aus den Karten herausrechnen, also die Längen- und Breitengrad parallel zueinander machen, damit man sie als Hintergrund legen kann. Ansonsten kann ich dir leider nicht weiterhelfen, bzw. kein Programm empfehlen. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht
Am 15.06.2013, 19:19 Uhr, schrieb gmbo g...@kilometerfresser.eu: Am 15.06.2013 17:32, schrieb Eckhart Wörner: Hallo Ruben, Am Samstag, 15. Juni 2013, 16:47:28 schrieb Ruben Kelevra: Das heißt ein Mapper würde oben DE auswählen, dann auf den Verbotsschildtyp, würde den LKW auswählen und dann ein Zusatzschild mit 7,5 Tonnen. Davon ableiten würden wir dann, das die Straße in DE ist und das Deutsche Recht gilt, was bedeutet hgv:no wenn über 7,5 Tonnen. Das funktioniert vielleicht bei ein paar Standardschildern, aber schon bei den Zusatzschildern wird es schwierig, weil es da variable Texte gibt. Es ist wahrscheinlich deutlich sinnvoller, eine gute Doku (mit guten Beispielen) zu schreiben, und Neulinge nicht ständig davon abzuhalten, da auch mal reinzuschauen. Eckhart Ich halte beide Lösungen für gut. Erst einmal natürlich die Doku verbessern, erstmal auf Landesebene die dortigen Besonderheiten berücksichtigen, denn manchmal habe ich das Gefühl der Versuch eine allgemeingültige Beschreibung zu finden, führt dazu, dass gar nicht dokumentiert wird. Andererseits wäre die Auswahlmöglichkeit eine tolle Sache. Gibt es da etwas Beispielhaftes, was einen solchen Ansatz hat? Ich finde den Vorschlag von Ruben sehr gut (hatte sowas ähnliche vor kurzem mal im wiki vorgeschlagen). Es bräuchte dazu nur das Verkehrszeichen-Tool als JOSM plugin (und natürlich auch in den anderen Editoren): http://osmtools.de/traffic_signs/ Bei den Zusatzschildern wird es denke ich nicht schwierig, da es eine durch die StVO begrenzte Zahl gibt. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht
Am 13.06.2013, 19:39 Uhr, schrieb Eckhart Wörner ewoer...@kde.org: Hi Burkhard, Am Donnerstag, 13. Juni 2013, 19:18:02 schrieb bkmap: sorry, das hgv passt vermutlich schon, wenn es auch im Wiki nicht weiter beschrieben wird, Problem ist das weight. Habe dazu zwar im Wiki nichts explizit gefunden, würde aber davon ausgehen, dass das wie height funktioniert, also das tatsächliche Gewicht beschreibt. Dann sollte ja hgv:conditional=no @ (weight7.5) passen. nein, das passt nicht. Zwischen dem zulässigen Gesamtgewicht und dem tatsächlichen Gewicht ist ein großer Unterschied. Bezieht sich das Zusatzschild nicht IMMER auf das zulässige Gesamtgewicht, und das Zeichen 250 mit dem Gewicht drinnen immer auf das tatsächliche Gewicht? (Oder so ähnlich...) Dann müsste der Auswerter den Unterschied kennen und nur schauen, in welcher Kombination das Schild getaggt ist (sofern es hier richtig eingetragen ist). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturtrails in OpenStreetBugs
Am 13.05.2013, 10:28 Uhr, schrieb chris66 chris66...@gmx.de: Am 05.05.2013 21:12, schrieb NopMap: Chris66 wrote highway=cycleway ist gleichbedeutend mit: highway=path + bicycle=designated + foot=no + horse=no Und wird dementsprechend in Mapnik jeweils identisch gezeichnet. Das ist leider nicht so eindeutig. Im Moment bin ich mir gar nicht mehr sicher, ob Reiter Fußwege (Zeichen 239 / 241) benutzen dürfen. Gelten sie nicht rechtlich als Fußgänger ? Auf meiner letzten Radtour sah ich jedenfalls jede Menge von dieser Beschilderung: http://osmtools.de/traffic_signs/?signs=241,258 StVO § 28 Tiere: Wer reitet, Pferde oder Vieh führt oder Vieh treibt, unterliegt sinngemäß den für den gesamten Fahrverkehr einheitlich bestehenden Verkehrsregeln und Anordnungen. Mit deiner angegebenen Beschilderung ist das horse=no natürlich richtig, auch wenn das Schild überflüssig ist. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bus-Spur gegen die Einbahnstraße
Am 13.05.2013, 15:52 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 13. Mai 2013 14:03 schrieb Tobias Knerr o...@tobias-knerr.de: Am 13.05.2013 06:23, schrieb Wolfgang Hinsch: Am Samstag, den 11.05.2013, 18:02 +0200 schrieb Ruben Kelevra: ich suche nach dem üblichen Weg eine Busspur zu taggen. Soweit gefunden gibt es derzeit drei Möglichkeiten oneway=yes lanes=2 lanes:forward=1 lanes:backward=1 [...] Möglichkeit 3 bus:lanes:backward=yes http://www.openstreetmap.org/?lat=53.565739lon=10.019727zoom=18layers=M Das Problem mit Wolfgangs Vorschlag ist, dass psv oder bus im Sinne der Dokumentation kein gültiger Wert für access-Tags ist - das ist nur als Schlüssel definiert. Allgemeiner ist die Schwierigkeit hier, dass es kein nur Verkehrsmittel X für access-Tags gibt. Daher ist es zwar möglich, mit spurgenauen access-Werten zu arbeiten, benötigt nach momentanem Stand aber zwei Tags: bus=designated (oder official)? das ist zwar nicht notwendigerweise exklusiv, weil es noch mehr Verkehrsmittel geben könnte, die auch designated sind, aber solange nur eins designated ist, bedeutet das normalerweise dass der Rest verboten ist. (Busspuren dürfen oft/meist auch von Taxis benutzt werden, dass besser psv verwenden), bus=designated als exklusiver Sonderweg für Busse finde ich auch passender als bus=yes + access=no. Das ist dann einfach zu merken, da bei Reit-, Rad- und Fußwegen bei den blauen, runden Schildern auch *=designated steht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturtrails in OpenStreetBugs
Am 06.05.2013, 23:15 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: On 06/mag/2013, at 17:19, Masi Master masi-mas...@gmx.de wrote: Der Weg sollte im footway-Fall auch für Rollstuhlfahrer, Roulator u.ä. geeignet ist. davon kannst Du nicht grundsätzlich ausgehen, schon gar nicht weltweit. Ok, davon könnte man aber zB im Großteil der westlichen Welt ausgehen (zumindest sollte es dort so sein). Ich finde das muss man mit der generellen Infrastruktur im jeweiligen Land/Region ins Verhältnis setzten. In Länder in denen die meisten Straßen nicht asphaltiert sind, würde ich auch nicht davon ausgehen, mit einem Rennrad auf den dortigen Radwegen fahren zu können (sofern es diese dort gibt). Oder mit einem tiefergelegten Sportwagen auf der Straße. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturtrails in OpenStreetBugs
Am 06.05.2013, 12:57 Uhr, schrieb Henning Scholland o...@aighes.de: Nur Radfahrer: foot=no bicycle=designated Nur Fußgänger: foot=designated bicycle=no Am 04.05.2013, 21:08 Uhr, schrieb chris66 chris66...@gmx.de: highway=footway ist gleichbedeutend mit: highway=path + foot=designated + bicycle=no + horse=no highway=cycleway ist gleichbedeutend mit: highway=path + bicycle=designated + foot=no + horse=no Warum setzt ihr bicycle=no oder horse=no? Das wird doch nur bei einem expliziten Verbot getaggt!? Das foot/bicycle=designated steht doch für einen Sonderweg mit klar geregelten Beschränkungen (also einem implizierten access=no für alle anderen, wenn man so will). Außerdem finde ich nicht unbedingt, dass ein highway=path + foot=designated somit zum highway=footway wird. Das eine ist eine Beschränkung (foot=*), das andere eine Wegeigenschaft (footway). Der Weg sollte im footway-Fall auch für Rollstuhlfahrer, Roulator u.ä. geeignet ist. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturtrails in OpenStreetBugs
Am 06.05.2013, 17:56 Uhr, schrieb Ronnie Soak chaoschaos0...@googlemail.com: Außerdem finde ich nicht unbedingt, dass ein highway=path + foot=designated somit zum highway=footway wird. Das eine ist eine Beschränkung (foot=*), das andere eine Wegeigenschaft (footway). Der Weg sollte im footway-Fall auch für Rollstuhlfahrer, Roulator u.ä. geeignet ist. Das eben nicht. Zumindest schien hier Konsens zu herrschen, das highway=footway eben doch nichts anderes als eine Kurzschreibweise für die access-tags ist. Das hat also mit Eignung nichts zu tun, sondern nur mit offizieller Nutzungserlaubnis. Also: foot=designated NUR bei blauem Schild. Wenn blaues Schild, dann KANN auch highway=footway. Es folgt: wo foot=designated da kann auch highway=footway. Weder wheelchair noch Rolatoren (für die ich gar kein tag kenne) sind access tags. Das steht auch so auf der access=* wiki-Seite. Wheelchair=* beschreibt eben eine Eignung, kein rechtliches Gebot. Ok, laut Wiki ist es eine Kurzschreibweise. Nur logisch ist es nicht! Die anderen highway Typen stehen ja für den Weg an sich, Verkehrsbedeutung und ggf. Ausbauzustand, und weniger für access-Regeln. Warum muss das bei foot-, cycle- und bridleway anders sein? Ich würde nicht versuchen, überall access-Tags zu implizieren. Während es bei highway=motorway vielleicht Sinn macht, ein minspeed=* oder ein foot=no zu implizieren, da es bei ALLEN Autobahnen so ist, macht es zB bei Radwegen keinen Sinn, denn es gibt Radwegen in den verschiedensten Arten und Ausbaustufen, auch bei Fußwegen. (Aus diesem Grund würde ich etwa auch bei allen Radwegen ein oneway=* setzen, da beides etwa gleich häufig vorkommt, und man von keinem Standard ausgehen kann, wie bei Straßen.) Ich fänd' es besser, wenn path die Grundform des schmalen Weges (kein 2-spuriger Verkehr möglich) ist, der dann bei Bedarf als foot- oder cycleway die Wegart genauer spezifizieren kann. Gruß Masi P.S.: Meine Sichtweise der Radwegarten ist sicher von den abenteuerlichen Radwegführungen in DE sowie Fußgänger, Autos, Bordsteinen, Mülltonnen usw. auf Radwegen beeinflusst :-\ In anderen Ländern ist das vielleicht anders, so dass dort ein Weg + bicycle=designated auch wirklich ein Radweg ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rechtschreibung und Zeichensetzung in den Karten
Am 22.04.2013, 19:42 Uhr, schrieb Martin Trautmann tr...@gmx.de: On 13-04-22 18:02, Andreas Schmidt wrote: Am 22.04.2013 15:31, schrieb Wolfgang Hinsch: Aber - da ich ja wohl der Urheber der ganzen Diskussion war - ich finde inzwischen, dass ich einen Kindergarten namens Kita „Villa Kunterbunt“ als Kita Villa Kunterbunt eintragen sollte. Nö, als name=Villa Kunterbunt amenity=kindergarten Hmm ja, hätte ich auch so gemacht. Allerdings bei Restaurants usw. (siehe unten) bin ich eher der Meinung, die Beschreibung mit in den Namen zu übernehmen, bin mir aber nicht ganz sicher... Also weglassen oder erhalten, da sie eigentlich zum Namen gehört: zB bei Café Soundso, oder bei Landgasthof, Gasthaus, Gaststätte, Restaurant... Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits - Revert?
Am 21.03.2013, 00:41 Uhr, schrieb Frederik Ramm frede...@remote.org: Hallo, On 21.03.2013 00:10, Masi Master wrote: Aufgrund der unterschiedlichen Sichtweise/Verwendung (beim Taggen von Radwegen) plädiere ich für einen Revert des riesigen Massenedit-Changesets: 14614172 +1 Der User hat sich ja auch ein paar Tage nach diesem Changeset loeschen lassen. Fragen: Revert ja/nein/egal? Wer ist dafür zuständig? Oder muss/soll ich das selber in die Hand nehmen? Kannst Du schon selber machen, wenn hier auf der Liste einigermassen Einigkeit herrscht. Mal abwarten, was die anderen sagen. Ok, die geringe Resonanz deute ich mal als Neutral bis Zustimmung. Habe nun versucht den Datensatz zurückzusetzen, doch gibt es dabei mehr als 900 Konflikt (wie ich auch schon im Forum schrieb [1]). Gibt es eine Möglichkeit dies sinnvoll zu lösen? Es würde ja schon ausreichen, nur die Tags zurückzusetzen bzw. zurück zu ändern. Gruß Masi [1] http://forum.openstreetmap.org/viewtopic.php?pid=323202#p323202 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] unangekuendigte Massenedits - Revert?
Hi, als Fortsetztung von dem Thread unangekuendigte Massenedits aus Januar 2013: http://lists.openstreetmap.org/pipermail/talk-de/2013-January/100538.html In den letzten 19 Beiträge, ab etwa hier [1], gibt es kontroverse Meinungen zum Thema bicycle=yes bei highway=cycleway. Und auch relativ am Anfang [2] schrieb jemand, dass in Lübeck bicycle=yes für Radwege ohne Benutzungspflicht verwendet wird. Aufgrund der unterschiedlichen Sichtweise/Verwendung (beim Taggen von Radwegen) plädiere ich für einen Revert des riesigen Massenedit-Changesets: 14614172 Ggf. würde es schon ausreichen, die gelöschten Tags wiederherzustellen. Fragen: Revert ja/nein/egal? Wer ist dafür zuständig? Oder muss/soll ich das selber in die Hand nehmen? Gruß Masi [1] http://lists.openstreetmap.org/pipermail/talk-de/2013-January/100607.html [2] http://lists.openstreetmap.org/pipermail/talk-de/2013-January/100637.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013, 09:16 Uhr, schrieb bkmap burkhard.kirch...@web.de: 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. ärt war oder nicht. Wie wär's denn hier mit highway=path oder highway=track? highway=cycleway impliziert immer bicycle=designated wenn das anders ist, sollte man path oder track verwenden. Da sind Fahhräder implizit erlaubt. Warum soll man path oder track zweckentfremden? Ein Radweg ist ein auf Radfahrer angepasster Weg. Dazu zählen u.a. abgesenkte Bordsteine, Sicherheitsraum zu Parkplätzen Fußweg, sehr ebenener Untergrund, gradlinige Führung, gute Sicht/wenig Gefahrenstellen, ... Warum soll man einen Radweg nicht als solchen taggen? Ein path kann alles sein, und ein track ist wieder was anderes. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013, 08:15 Uhr, schrieb Josef Latt josef.l...@gmx.net: 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. Dann frage ich mich, warum denn Löschen, wenns kein Default ist? 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? Ganz einfach: Bei highway=tertiary + access=no + motor_vehicle=yes + hgv=no: Das explizit gesetzte access=* hat eine höhere Bedeutung als der Defaultwert(?) access=yes für tertiary-Straßen. Desweiteren überschreibt das motor_vehicle=* das access=* (natürlich nur für Motorfahrzeuge), weil es spezifischer ist. Genauso hat hgv=* eine höhere Bedeutung als motor_vehicle=*. 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.) 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. Eben nicht! Es gibt straßenbegleitende Radwege MIT blauem Schild (benutzungspflichtige), und auch welche OHNE Schild (genannt: andere Radwege). Als drittes gibt es noch eigenständige Radwege, diese werden üblicherweise auch mit dem blauen Schild gekennzeichnet, einerseits um anzuzeigen welche Verkehrsteilnehmer erlaubt sind, und andererseits welche NICHT erlaubt sind. Und dies ist laut StVO nicht verboten. Bin mir grad nicht sicher, ob es in den VwV einen Hinweis dazu gibt. (Die Benutzungspflicht entfällt natürlich, da es keine parallele Straße gibt.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013, 10:52 Uhr, schrieb Josef Latt josef.l...@gmx.net: Am 17.01.2013 01:32, schrieb Bernhard Weiskopf: 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. Ein notwendiges oneway=yes bedeutet nicht, dass alles andere per oneway=no getaggt werden muss. Ist doch hirnrissig. Wenn dies in Richtung einer fragwürdigen Verifikation gehen soll, wie hier n anderem Zusammmenhang schon erwähnt, sollte man sich was anderes einfallen lassen. Bei Radwegen gibt Ein- und Zweirichtung Wege, wirklich! Und da beide etwa gleichhäufig sind, sollte man auch oneway=* taggen. Es ist bei weitem nicht so, dass Einbahn-Radwege die Ausnahme sind, wie etwa bei normalen Straßen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013, 19:50 Uhr, schrieb Falk Zscheile falk.zsche...@gmail.com: Du lieferst gerade ein schönes Beispiel dafür, indem du Radwege ausschließlich als für Radfahrer angepasste Wege definierst und die rechtliche Komponente damit völlig außen vor lässt. Andere gehen genau umgekehrt an die Klassifizierung heran :-) Die rechtliche Komponente, also die Beschilderung kommt als bicycle=* daher. :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013, 20:19 Uhr, schrieb Josef Latt josef.l...@gmx.net: Am 17.01.2013 17:30, schrieb Masi Master: Am 17.01.2013, 08:15 Uhr, schrieb Josef Latt josef.l...@gmx.net: 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. Dann frage ich mich, warum denn Löschen, wenns kein Default ist? Weil bei highway=footway foot=designated impliziert (default) ist. Falls das nicht zutrifft - highway=path. OMG 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? Ganz einfach: Bei highway=tertiary + access=no + motor_vehicle=yes + hgv=no: Das explizit gesetzte access=* hat eine höhere Bedeutung als der Defaultwert(?) access=yes für tertiary-Straßen. Desweiteren überschreibt das motor_vehicle=* das access=* (natürlich nur für Motorfahrzeuge), weil es spezifischer ist. Genauso hat hgv=* eine höhere Bedeutung als motor_vehicle=*. Nee, ein highway=cycleway usw. mit oder ohne designated setzt balue Schilder voraus. Schon deshalb kann es da kein *.yes geben. Bicycle=yes ermöglich die Nutzung einer anderen Wegeart, die normalerweise für Radfahrer verboten sind (z.B. ein für Radfahrer freigegebener Fußweg). ...ich glaubs nicht... 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.) 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. Eben nicht! Es gibt straßenbegleitende Radwege MIT blauem Schild (benutzungspflichtige), und auch welche OHNE Schild (genannt: andere Radwege). Als drittes gibt es noch eigenständige Radwege, diese werden üblicherweise auch mit dem blauen Schild gekennzeichnet, einerseits um anzuzeigen welche Verkehrsteilnehmer erlaubt sind, und andererseits welche NICHT erlaubt sind. Und dies ist laut StVO nicht verboten. Bin mir grad nicht sicher, ob es in den VwV einen Hinweis dazu gibt. (Die Benutzungspflicht entfällt natürlich, da es keine parallele Straße gibt.) Das ist ein Widerspruch in sich, den auch die Schilderaufsteller zum größten Teil nicht begriffen haben. Es sind Gebotsschilder und dürfen laut StVO nur für benutzungspflichtige Radwege benutzt werden. Die jetzige StVO wurde AFAIK in dieser Hinsicht aufgehoben. Mit der neuen StVO wird sich dies ändern. Du solltest mal den Text der StVO zu den blauen Schildern genau durchlesen. Ich habe keine Lust nochmals alles zu wiederhoeln, was ich hier dazu schon geschrieben habe. Habe ich schon mal gemacht... Ich fand sinngemäß: Benutzungspflichtige Radwege sind mit Zeichen 237 gekennzeichnet. (Quelle: VwV Zu § 2 Nr. 8/Zu Absatz 4 Satz 2) Ich fand NICHT: (Alle) Wege mit dem blauen Schild sind benutzungspflichtig. Bei Radwegen gibt Ein- und Zweirichtung Wege, wirklich! Und da beide etwa gleichhäufig sind, sollte man auch oneway=* taggen. Es ist bei weitem nicht so, dass Einbahn-Radwege die Ausnahme sind, wie etwa bei normalen Straßen. Es muß für manche schwer sein, ein nicht vorhandenes oneway=no entsprechend zu werten. Wenn dann hier gesagt wird, wenn dies getaggt ist, hat das jemand geprüft und ist richtig. Mag sein, mag nicht sein. Also letztendlich unklar. Weshalb dann unnützerweise taggen, da eh default. Bei Radwegen gibts kein Default für oneway=* (zumindest hab ich nix dazu gefunden, und Sinn macht dort ein Default auch nicht.) Außerdem halte ich den Defaultwert bicycle=designated bei Radwegen für falsch/kontraproduktiv, auch wenns so im Wiki steht. So sind zB Schutzstreifen auch Radwege, allerdings ohne Benutzungspflicht, also hier bicycle=yes. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013, 19:53 Uhr, schrieb Josef Latt josef.l...@gmx.net: Es geht um diese Aussage: 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. In dem Fall ist highway=cycleway per Definition falsch. Deshalb der Hinweis auf path bzw. track, IMHO absolut richtig. Komisch, wenn etwas anderes ist als der Defaultwert, muss man ein anderes highway-tag nehmen? wo kommen wir denn da hin? Am 17.01.2013, 19:57 Uhr, schrieb Josef Latt josef.l...@gmx.net: Am 17.01.2013 17:46, schrieb Gerhard Hermanns: Es gibt auch straßenbegleitende Radwege, die nicht benutzungspflichtig sind. Dort hat der Radfahrer die Wahl, ob er auf der Fahrbahn oder auf dem Radweg fährt. Ja ntürlich gibt es diese. Es geht um sraßenbegleitende Wege mit blauem Schild. Nicht nur, diese nicht benutzungspflichtigen Radwege taggt man üblicherweise mit bicycle=yes. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013, 20:23 Uhr, schrieb bkmap burkhard.kirch...@web.de: Wenn der Radweg entlang einer Straße verläuft, darf ich nicht auf dieser Straße fahren. Das attributiere ich AUF DIESER STRASSE mit bicycle=no. Dann weiß das auch jeder Router. Das ist falsch und nichts anderes als taggen für den Router. Üblicherweise taggt man nur bei Zeichen 254 die Straße mit bicycle=no. ___ 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] Landwirtschaftliche Fahrzeuge mit Sondergenehmigung auf 2x2 autobahnähnlicher Straße
Am 13.01.2013, 18:07 Uhr, schrieb Martin Koppenhöfer dieterdre...@gmail.com: Am 13.01.2013 um 15:17 schrieb Tirkon tirko...@yahoo.de: auf der Bundesstraße 210 wurde im Landkreis Friesland beim Wilhelmshavener Kreuz ein autobahnähnlicher Lückenschluss vor wenigen Wochen vollzogen und freigegeben. Trotz 2x2 Fahrstreifen mit baulicher Richtungsfahrbahntrennung sind hier landwirtschaftliche Fahrzeuge zugelassen, wenn sie mindestens 40 km/h schnell sind - allerdings nur mit Sondergenehmigung. Es handelt sich offensichtlich um einen Modellversuch. Demzufolge gibt es die Regelung sonst nirgendwo (im Landkreis? / in Deutschland?). Ich habe daher * agriculture=yes m.E. müsste das private sein und nicht yes, da es nur mit Sondergenehmigung möglich ist ja, private scheint mir auch plausiebel. (also mit Erlaubnis des Eigentümers.) und * minspeed:agriculture=40 getaggt minspeed, also eine Mindestgeschwindigkeit auf einem Straßenabschnitt ist nicht ganz dasselbe wie eine bauartbedingte Mindestgeschwindigkeit eines Fahrzeugs. Ich würde das weglassen, da die Voraussetzungen erfüllt sind, wenn man mit private Zugang hat. das würd ich auch weglassen. Zumal bedeutet das Treckersymbol: Kraftfahrzeuge und Züge, die nicht schneller als 25 km/h fahren können oder dürfen..., was nichts mit landwirtschaftlichem Verkehr zu tun hat. (Also das Schild und auch das tagging agricultural=* werden in den falschen Zusammenhang gebracht.) Damit sollte dem nicht-landwirtschaftlichem Benutzer der Straße diese Eigenschaft deutlich werden. wobei agricultural m.W. in Deutschland nicht landwirtschaftliche Fahrzeuge bezeichnet sondern Fahrzeuge, die sich in landwirtschaftlichem Einsatz befinden (also auf die Nutzung bezogen ist und nicht auf den Fahrzeugtyp). ja, [access]=agricultural entspricht landwirtschaftlicher Nutzung, ABER hingegen agricultural=yes entspricht dem Trecker-Symbol, was wiederum bedeutet: Kraftfahrzeuge/Züge bis 25km/h Ist der Fall so einzigartig und zudem theoretisch, dass man ihn im Tagging vernachlässigen kann? Falls nein, wie würde man die notwendige Sondergenehmigung taggen? grob schonmal mit private, m.E. Im Prinzip würd ich auch agricultural=private nehmen. Passt zwar nicht perfekt, aber besser gehts mit dem Taggingschema momentan nicht. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multipolygone im Wiki
Am 11.01.2013, 01:45 Uhr, schrieb Frederik Ramm frede...@remote.org: On 10.01.2013 16:52, Peter Wendorff wrote: Also ich hab Multipolygone immer so verstanden wie es dann wohl momentan im Wiki steht. Gibt es den irgendeine Software, die das auch so versteht? Mir ist dieser Gedanke, wie gesagt, komplett neu. Dass Taggs vom Outer-Ring der Relation zugeortnet werden, ist meines Wissens nur eine Altlast. Im Normalfall wird der Tag der Relation genommen, klar. Wenn dieser Tag allerdings fehlt, wird von einer alten (also überholten) Relation ausgegangen, und es wird ersatzweise das Tag des äußeren-Rings herangenommen. Im Wiki steht meines Wissens nichts darüber, dass beide Tags gleichwertig oder gegeneinander austauschbar sind. Und von der Logik scheint es mir klar, dass Tags der Relation zu dieser, und Tags des Outer-Rings (also einen ganz normalen geschlossenem Polygon) zu diesem gehören. Evtl. ist es besser, alle Relationen zum neuen Standard hin zu konvertieren... Gruß Masi P.S.: Mit der Rücksichtname auf alte Schemata (anstatt Anpassung dieser) fördert man doch nur verschiedene Schreibweisen für ein und dasselbe und am Ende blickt keiner mehr durch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapnik high res rendering
Am 03.01.2013, 09:26 Uhr, schrieb Peter Körner osm-li...@mazdermind.de: Am 02.01.2013 16:42, schrieb Masi Master: Damit überschreibt generate_tiles.py den Wert aus dem XML. In tirex habe ich das vor einiger Zeit gepatcht [1] und nun auch in generate_tiles.py [2]. [2] https://trac.openstreetmap.org/changeset/29155/subversion Danke, auch für den Hinweis. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapnik high res rendering
Hallo, habe auch mal versucht, den Parameter buffer-size (in der *.xml) zu erhöhen, leider ohne Erfolg: Habe ihn bis auf 1 erhöht, es ergab sich keine Änderung, noch nichtmal eine längere Renderdauer. Hingegen half es, in der generate_tiles.py den Wert self.m.buffer_size = 128 auf einen höheren Wert einzustellen. Damit dauerte das Rendern jetzt auch länger und die Schilder werden auch vollständig angezeigt. Gruß Masi Am 30.12.2012, 19:29 Uhr, schrieb Tobias Hobmeier tob...@antifuse.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/28/12 01:22, Peter Körner wrote: Hi Tobias, Masi, Am 27.12.2012 16:45, schrieb Masi Master: also bei mir funktioniert es... Ahh, du meinst wahrscheinlich den Fehler an den Kachelgrenzen? Da wird manchmal abgeschnitten. Mit welcher Einstellung oder Befehl man das unterbindet, weiß ich leider nicht. Der entsprechende Parameter im Mapnik-XML lautet buffer-size. Sinnvolle Werte wären beispielsweise 64 oder 128. Beispiel: Map background-color=#b5d0d0 srs=srs900913; minimum-version=2.0.0 buffer-size=64 Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hi Peter, ich hab jetzt die buffer-size auf 128 gestellt. Die größe eines meiner Tiles liegt bei 256px. In meinem beispiel hab ich die Wanderwege der Region mit schönen großen keksen versehen 18x18px und rendere sie mit ShieldSymbolizer size=14 fill=#fff placement=line file=symbols;/hike.png spacing=800 minimum-distance=40 fontset-name=bold-fonts[ref]/ShieldSymbolizer in meine Karte. Die Darstellung auf den Tiles ist leider nicht optimal ( http://mac.piffpaffpuff.net/osm/darstellung.png ) oft treten halbe oder 3/4te kekse auf. Hat jemand eine Idee woher das kommt und wie ich das am einfachsten beheben kann? An einer anderen stelle habe ich das problem dass der keks von Wanderweg 1 (relation ref=1) vom Weg des Wanderweges 0 (relation ref=0) überdeckt wird... :-( Gruß Tobias -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ4IgOAAoJEEbEq/z9yHouKC0P/jlEmVZcf5HJKi74gpUTBUeb yF4ff/PZcvNAyj0/WZs4ajtqhi1ZRjUsMIs3OIGtT7KGqoc4s9Osok37Uxt5Z3jr Mgwmvgl6JN7PxkCyQ6NwpD3GfGmr6OpsEPaenQmwjW2UUJhSHQEAKZqH2l2IigxJ BUD/k78nHPzPWy0wuKdzzDE6r7t6epJhPAlNmNcNmN0/Ii+/aPzZTXiDrjB+Goq7 TvyJpPVFiqs7Ux+n5BXgKihwVEkRVHw+YJuP2rTHfmP65IrcB2/N1BCH0wqC3+GD QHOjY4jeCQCwuWkdH8wckSkHEqHLUtd4JcF5yd7MWC8tlgtfanjPBg0K/t2q2Tm0 ZLhIx/93g4hS3mySbz2x6CrNwKi4tB2lPPD6d6Vj2znP6oXBlr+nxHO8yGkfmvbZ 5u/rW0GZIUW/Wvx1Tq/RvI1t68YUtzTsyTmvn79Q0GUltk0A7uSuahlPYJgr5KKU hmiWO1pwyOMH0zRPXd64kIhRHcVLQi6XEDGmQ+Bue1kJ7jmQK2LAHYqdGotUjhJK xhX3rfS2SwzeVwh4WnKczXrKEEpz85Pc64P+p8G58GhsWDoIbrjFMGt3eMxvT4R9 Xldw+/Ngb8pBnTMdQwN1LWone6nC3Y7ziVm0kpNrb8+9fSEC8aGA2RUJ0TxtfcMb r0BYbES1NYhbqFO1EU6P =eWQ3 -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
Re: [Talk-de] mapnik high res rendering
Hi, also bei mir funktioniert es... Ahh, du meinst wahrscheinlich den Fehler an den Kachelgrenzen? Da wird manchmal abgeschnitten. Mit welcher Einstellung oder Befehl man das unterbindet, weiß ich leider nicht. Aber bei den professionellen Mapnikkarten wird die Kachel einfach mit einem breiten Rand gerendert, der dann wieder Abgeschnitten wird. So dass der Mittelpunkt des Schilds auch auf der angrenzenden Kachel (zwar im Verschnittbereich) liegt, aber so dass das Schild auch dort gerendert wird, und somit das Stückchen Rand dort zu sehen ist. Prinzip soweit verstanden? Gruß Masi Am 27.12.2012, 10:22 Uhr, schrieb Tobias Hobmeier tob...@antifuse.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Masi, ja die Bilder groesser gemacht habe ich schon. Mein problem ist dass es offensichtlich eine art clipping gibt das die bilder abschneidet. Siehe Bild: http://mac.piffpaffpuff.net/osm/example.png Gruß Tobi On 12/27/12 02:30, Masi Master wrote: Nabend Tobias, ich hab zwar an den Schildern noch nicht rumgespielt, aber gehe davon aus, dass du neben der (Schrift-)Größe [size=10] auch die Bilddatei vergrößern (seperat in einem Bildbearbeitungsprogamm) musst. Gruß Masi Am 26.12.2012, 09:08 Uhr, schrieb Tobias Hobmeier tob...@antifuse.de: hier ist die verlohrene grafik http://mac.piffpaffpuff.net/osm/example.png On 12/26/12 08:57, Tobias Hobmeier wrote: Schöne Feiertage zusammen, ich bin gerade dabei mich ein wenig mit Mapnik zu spielen :-) das rendern haut auch schon ganz gut hin. Nachdem die Straßen beschriftungen zu klein waren habe ich diese in meiner XML angepasst. Dann waren natürlich auch die pri_shield's die ich gefunden habe viel zu klein eine vergrößerung war leider nicht sehr erfolgreich (siehe anhang). Wie vermeide ich es denn dass der Keks abgeschnitten wird? Gruß Tobias ___ 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 mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ3BNrAAoJEGkKxZ+TJ35M1QQH/2ByRgtVCTiyHSpHIDabVJ3Z tAbRJYSkJhcmJ2MuxqWnyRPlaJwaYEl4+8oWNCncqZ1AE3Kx4JtHMjq3Rvu6rlno 8mdhtNDaj8jjYzu/iBa2x+yLIBme5dgkornIrRBrzfamNB3BBQOS1itChkFVq+O4 N3sIyp/cLovxby2UQxNmwAC+EyoF+PnYG0mNDZtfyckygGfAlxd5xLwhQy6dDuqF CVuBH+Q4Gm3mIT+cC8o/6saDFtmBn52Syj+8yHyBbGRqwS3StrAFh3/nKSbF/gys ApyRKGWsogbpku3dxtwl5VcGuTLM4E3Tx8QTIZvINsylbCPHGYI/5jre8rBZnhE= =fHhn -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
Re: [Talk-de] mapnik high res rendering
Nabend Tobias, ich hab zwar an den Schildern noch nicht rumgespielt, aber gehe davon aus, dass du neben der (Schrift-)Größe [size=10] auch die Bilddatei vergrößern (seperat in einem Bildbearbeitungsprogamm) musst. Gruß Masi Am 26.12.2012, 09:08 Uhr, schrieb Tobias Hobmeier tob...@antifuse.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hier ist die verlohrene grafik http://mac.piffpaffpuff.net/osm/example.png On 12/26/12 08:57, Tobias Hobmeier wrote: Schöne Feiertage zusammen, ich bin gerade dabei mich ein wenig mit Mapnik zu spielen :-) das rendern haut auch schon ganz gut hin. Nachdem die Straßen beschriftungen zu klein waren habe ich diese in meiner XML angepasst. Dann waren natürlich auch die pri_shield's die ich gefunden habe viel zu klein eine vergrößerung war leider nicht sehr erfolgreich (siehe anhang). Wie vermeide ich es denn dass der Keks abgeschnitten wird? Gruß Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ2rBzAAoJEEbEq/z9yHouhWUP/397Q3sFKXeMuztsEE3IVXZx bHpSQZ5++u4Gr6lC1hAa17+mboqVXlQDiicSJ68mwV+SOwcHHlO4noBsoFjz++bD uooACebT6IHrYzBgiD3dCe6V34fxgPSqtsgbmZZ2wN3LEKKND7+0B4gHEcaFPeUL /6VdDyMoYgBuT1F8FulBX2usLFJeFMqQJzg3J1BuT2JIlDkm7P7oQnk335BxJVyX cp54Gg/vo4wwL5FQZB4Hcmj32+8aR7qZnKvJTHaK4+lLAhtEnZq2//SVfsN2Wt1+ quxHRwTKaQ6ZfYMUK0YwyBY8ylOUuvAP374GXlLG5PK7BKdTIvMdyGqK822+k/dC GtCmcyt7VeJ/ZJW0ZQSFG76fn6Qoq+6ZotUuNMaMTzcSJ5IYorvvTPU6cTpwnRl5 jxX9iFQ/LDvxXagiMtb8D0H8MW4EAwN+vrVZXi8H7BEvIqaW+GgCrL3VCX4kf1jg 0Ka+D/f6H2y9pkdbMZ/oO43G/4lfhQbY+MBjYY5/wSXYi2mFMR8DF3Z7EL4shYGn ojfFXQMuVuCMaeKwFUU7Vo8xDANGN2WHhNjjmzUxyjbnRH44t7zo+uMgMGK3UVUM rTq8q9EalQEMKeGn5ZShRE/p2wB1WGgmxugbM3B8gF3qfxk8mT49Vlny3hXBPA3d IiT87Rq8LoKQmBl5wGdO =osOk -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
Re: [Talk-de] Wieder einmal Fläche die nicht gerendert wird
Am 24.10.2012, 16:54 Uhr, schrieb Jan Tappenbeck o...@tappenbeck.net: Am 24.10.2012 16:37, schrieb Willi: Am 24.10.2012 10:18, schrieb Jan Tappenbeck: es geht um die Fläche http://www.openstreetmap.org/browse/way/182701143 Kann mir einer sagen warum die nach Wochen nicht gerendert wird in Mapnik ?? Laut JOSM müßte die Fläche ordnungsgem. geschlossen sein. Könnte auch ein Fehler beim Import sein wie hier vermutet http://forum.openstreetmap.org/viewtopic.php?id=18795. Die Radfahrerkarte zeigt es doch richtig an? http://www.openstreetmap.org/?lat=54.15337lon=9.35646zoom=16layers=C Willi Hallo Willi, weißt Du wie man das beheben lassen kann - mir ist noch eine andere Stelle in Lübeck bekannt (Gespräch eines anderen Mappers) bei welchem sich Mapnik verschluckt haben soll. Gruß Jan :-) Hi, ich bin zwar nicht Willi, aber kann dir helfen :) Dass die Fläche gerendert wird, muss man das Polygon nur ändern, landuse auf was anderes setzten, zB. residential und nach 3 Minunten wieder zurück. Oder es könnte auch helfen, einen der Knoten um 1 mm zu verschieben. Dies habe ich allerdings noch nicht getestet. Der Ursprung liegt höchstwahrscheinlich in einem Fehler in osm2pgsql (siehe Mail von Kai), oder in osmosis (welches die Diffs erstellt). Genaueres habe ich dazu nicht herausfinden können. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bitte um Kritik zu Dreifach-Kulturweg
Hi, die Super-Relations-Struktur sieht gut aus. (hätte ich auch so gelöst) Von den ganzen anderen Tags hab ich nicht viel Ahnung, sieht aber auf den ersten Blick auch ok aus. Hoffe das hilft dir schomal etwas. :) Ob an der Superrelation network=lwn, route=hiking und osmc:symbol=blue:blue::ECP:yellow Oder an den Kind-Relationen website=* stehen muss/darf, weiß ich nicht. Denn wenn ich den Bodensee [1] taggen würde (bestehend aus Obersee, Seerhein und Untersee, welche wiederrum aus Teilseen bestehen), würde ich der Superrealtion, oder in dem Fall besser collection(?) nicht umbedingt natural=water geben, währ ja sonst doppelt-gemoppelt. Aber das ist ein anderes Thema. Antworten hierzu gerne mit einem anderen Betreff. [1] http://de.wikipedia.org/wiki/Bodensee Gruß Masi Am 22.10.2012, 19:56 Uhr, schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Hallo, mir geht es um diesen Kulturweg: http://www.spessartprojekt.de/kulturwege/weisser_leimen/ Um die einzelnen Routen trennen zu können und auch die Tafeln den richtigen Routen zuweisen zu können, habe ich das so gelöst: http://www.openstreetmap.org/browse/relation/2260920 Eigentlich mag ich ja Super-Relationen nicht, aber hier erscheint mir diese als einzige gangbare Lösung. Ist das so korrekt getaggt, oder sollte noch irgendwo korrigiert werden? Danke im Voraus Gruß Manuel ___ 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
Re: [Talk-de] Taggen von falschen Verkehrsregeln
Am 21.10.2012, 01:31 Uhr, schrieb Stephan Wolff s.wo...@web.de: Privatwege mit Schild Befahren verboten interpretiere ich eher als access=private oder access=destination statt als access=no. Wohl eher als vehicle=* (z.B. privat) mMn wird access=* viel zu häufig eingesetzt, wo es stattdessen bessere keys gibt. Am 21.10.2012, 11:45 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 21. Oktober 2012 11:33 schrieb Bernhard Weiskopf bweisk...@gmx.de: Vor kurzem wurde bei einer Einfahrt im Zuge von Baumaßnahmen ein neues Schild angebracht: Zeichen 260 (Verbot für Kraftfahrzeuge) mit zwei Zusatzschildern: 1. Landwirtschaftlicher Verkehr frei und 2. Anlieger bis Heddesheimer Landstraße 9-11 frei. Da man in OSM motor_vehicle = agricultural und motor_vehicle = destination nicht gleichzeitig angeben kann, werde ich hier letzteres eintragen. ja, weil motor_vehicle=agricultural;destination ist es auch nicht, da das bedeuten würde (m.E.) agricultural UND destination, was Du aber bräuchtest wäre agricultural ODER destination. Vielleicht kann man für so was eine Lösung finden? Kommt ja öfter mal vor. sehe ich etwas anders: Bei land- und forstwirtschaftlicher Verkehr wird auch *=agricultural;forestry gettagt. Es sind beide erlaubt, also man kann also auch *=agricultural;destination verwenden. (mit vehicle oder motor_vehicle) Andernfalls bliebe noch: (motor_)vehicle=no + agricultural=yes + destination=yes Würd aber die abgekürzte Schreibweise bevorzugen. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von falschen Verkehrsregeln
Am 21.10.2012, 14:45 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Es sind beide erlaubt, also man kann also auch *=agricultural;destination verwenden. (mit vehicle oder motor_vehicle) m.E. kann man nur destination setzen, weil land- bzw. forstwirtschaftlicher Verkehr ist man ja auch nur dann, wenn man dort ein Anlieger ist, und nicht, weil man z.B. mit einem Traktor unterwegs ist. Auf den ersten Blick sehe ich das auch so... Jedoch mag ich mich darum nicht streiten :) Ich würd einfach beides setzten, wenn beides angegeben wurde. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Multipolygonen
Ahh, da hätte auch gleich drauf kommen können, dass du der Ersteller dieser Relation bist :) Aber du musst nicht gleich ausfallend werden, wenn man auf eine überflüssige/falsche Relation hinweist, ist ja nicht das erste mal! Wenn ich es richtig verstehe, sind Multipolygone nicht dazu da, um Renderen zu helfen wie sie etwas Darstellen sollen (genausowenig wie das layers-Tag), sondern um Flächen zu beschreiben. Erstellen wir nicht primär eine Geo-Datenbank und nicht eine Karte? Also weshalb Terminal und Flugfeld aus dem Flughafen ausschneiden? Oder soll es eine site-Relation werden? Ich weiß zwar nicht was du mit dem Vergleich aussagen willst, aber ich komme fast immer ohne Multipolygone aus. Konsens? Hier bei OSM würde ich schon bei 80% davon reden. Anders gehts wohl kaum in einer so großen Community, wenn man etwas vorranbringen will. Desweiteren verbiete ich mir die Verschandlung meines Nicknamens! Sowas ist einfach nur kindisch! Gruß Masi Am 19.10.2012, 23:14 Uhr, schrieb Willi wil...@gmx.de: Ehe ich so forsch in die Tasten hauen und und Andere eines Fehlers bezichtige würde ich mich erst mal über Multipolygone und deren unterschiedliche Verwendungsmöglichkeiten schlau machen. Zum Beispiel die Wiki Seiten zum Thema Multipolygon lesen und hoffentlich auch verstehen http://wiki.openstreetmap.org/wiki/Relation:multipolygon http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon http://wiki.openstreetmap.org/wiki/Multipolygon_Examples http://wiki.openstreetmap.org/wiki/DE:Multipolygon_Examples Oder schauen wer wieviel zum Thema Multipolygon im Wiki beigetragen hat http://wiki.openstreetmap.org/w/index.php?title=Relation:multipolygonaction =history http://wiki.openstreetmap.org/w/index.php?title=DE:Relation:multipolygonact ion=history http://wiki.openstreetmap.org/w/index.php?title=Multipolygon_Examplesaction =history http://wiki.openstreetmap.org/w/index.php?title=DE:Multipolygon_Examplesact ion=history Oder wer wieviele Multipolygone schon selber kartiert hat (created) http://hdyc.neis-one.org/?MasiMaster http://hdyc.neis-one.org/?Willi2006 Oder die schon erwähnten, immer wiederkehrenden, nie zu einem Konsens kommenden Diskussionen im Forum lesen und versuchen, die dort beschriebenen unterschiedlichen Ansichten zu verstehen und zu akzeptieren. Sonst macht man sich schnell lächerlich. Aber vielleicht sollte man diesen ach so vielfältigen Benutzernamen nicht nur mit schoolmaster (Oberlehrer) sondern auch mit Maso-Master (da schweigt des Sängers Höflichkeit) assoziieren ;) Um einem möglichen Missverständnis vorzubeugen: Ich bin nicht nachtragend. Nur ich vergesse selten etwas. Willi ___ 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
Re: [Talk-de] Verwendung von Multipolygonen
Am 18.10.2012, 23:13 Uhr, schrieb Stephan Knauss o...@stephans-server.de: Ich hätte als Flugplatz das ganze Gelände gesehen. Und Vorfeld und Gebäude sind eben Bestandteil vom Flugplatz. Ist das jetzt einfach eine ungünstige Verwendung oder kommt so was häufiger vor (und sollte dann auch mal im Wiki beschrieben werden)? Ja, es kommt leider viel zu oft vor. Wie du schon sagt, ist die Relation überflüssig bzw. sogar falsch. (Vor dem Löschen aber bitte die Relations-Tags an die große Fläche übernehmen.) Ich fänds nicht schlecht, wenn das jemand ins Wiki schreibt... Meistens sieht man das fehlerhafte Ausschneiden bei Parks, wo dann Seen und kleine Wälder ausgeschnitten werden. Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] geplante und historische Objekte
Am 14.09.2012, 01:54 Uhr, schrieb Garry garr...@gmx.de: Am 12.09.2012 11:26, schrieb Martin Koppenhoefer Korrekter Name und eine Zusatzinformation dahinter in Klammer sollte ein gangbarer Kompromiss sein um einerseits nicht die Anwendungen zu stören, andererseits dem Nutzer wichtige Zusatzinformationen zu geben auf die er sonst keinen Zugriff hat. Aber nicht im name-tag sondern auf Anwendungsseite. In den Name-Tag gehört der reine Name und kein Kompromiss. Idealistisch gesehen hast Du recht. Realistisch gesehen ist es verwirrend wenn die Realität nicht mit dem übereinstimmt was die Karte hergibt und es keinen Hinweis gibt dass sich die Realität gerade verändert hat. OSM bietet zwar die Möglickeit aktuelle zu sein, aber es ist nur eine Möglichkeit! DIE Karte zeigt den Status eines Objektes nicht an, weil die Ersteller DER Karte es nicht implementiert haben. Und die Ersteller haben es nicht implementiert, weil es kein eindeutig dokumentiertes Taggingverfahren gibt. Ich bin auch gegen mehrere Schemata für ein und dasselbe. So wie es jetzt ist, weiß man nicht was man taggen soll, damit es die Auswerter begreifen und ggf. anzeigen können. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete?
Hi, Es existiert bereits eine Auswertung von Flussläufen. Auf [1] kann man unter Tools auf eine Seite [2] kommen, die sich mit Auswertungen von Flussläufen auseinander setzt. [1] http://wiki.openstreetmap.org/wiki/Relation:waterway [2] http://www.h-renrew.de/h/osm/osmchecks/07_watershed/index.html Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead End Karte an Grenze zu Luxemburg und Frankreich
Am 09.08.2012, 21:58 Uhr, schrieb ThomasB toba0...@yahoo.de: hehe, ihr seid gut! Für die polnische Karte hatte ich genau die beiden Kritikpunkte behoben, sprich route=ferry und highway=construction als eligible Fortsetzungen von major roads anerkannt. Bisher dachte ich mangels Feedback, dass die Karte niemand nutzt. Ich baue das mal ein und mache dann bis spätestens Sonntag früh ein Update. Und in den nächsten Tagen kann ich auch mal alle 3-4 Tage in Update machen. Ich hatte Frederik angeschrieben, ob er das nicht in den OSMI einbauen möchte. Aber er mag mich scheinbar nicht ;) Hi, danke, das Update war klasse! So hatte man einen tollen Überblick ohne false positive. Hatte?? Ja! Zur Zeit wird man auf http://suncobalt.dyndns.org:82/maxspeed.php umgelenkt (wenn man .../deadend.php eingibt). Ich weise mal darauf hin, weil es wohl nicht beabsichtigt ist. ;) Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead End Karte an Grenze zu Luxemburg und Frankreich
Am 08.08.2012, 16:11 Uhr, schrieb ThomasB toba0...@yahoo.de: Huch, ich wusste gar nicht, dass da noch jemand drauf schaut. [...] Viele Grüße Thomas Jep, die Karte ist super! Findet sogar Kreisverkehre, die nicht als junction=roundabout kartiert wurden. Minimaler Kritikpunkt währe, dass Enden an highway=construction als false-positive erkannt werden. Und vielleicht, dass man nicht die Fehler direkt in JOSM reinladen kann (wie beim OSMI), aber der Aufwand ist für das Übergangstool(?) nicht nötig. :) Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 08.08.2012, 11:27 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 07.08.2012 um 14:30 schrieb Masi Master masi-mas...@gmx.de: Relation: type=restriction restriction=hgv hgv:toll=yes minweight=12 Das halte ich so für keine besonders gute Syntax. hgv ist eine Fahrzeugklasse und keine turnrestriction. Auch wenn man type=restriction für andere Einschränkungen als Abbiegevorschriften verwenden wollte, sollte man m.E. eher so was wie restriction:for=hgv restriction=maxweight verwenden M.E. macht es aber eigentlich keinen Sinn, die Nutzung dieses Relationentyps um weitere, im Prinzip grundverschiedene (s. z.B. members) Verkehrsvorschriften zu erweitern, da die Logik eine ganz andere ist. Gruß Martin Hi Martin, meinte, dass es so ähnlich aussehen könnte (und von TURNrestriction war keine rede :) ). Ob es später type=restriction oder type=XYZ heißt, ist erstmal egal. Der Grundaufbau der Ralation kann aber so sein: type=beschränkung beschränkung=was_beschänkt_werden_soll nebenbedingungen Vorteil ist, dass man es auch für zeitabhängige Geschwindigkeitsverbote o.ä. hernehmen kann. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 06.08.2012, 18:52 Uhr, schrieb Eckhart Wörner ewoer...@kde.org: Hallo Chris, Am Montag, 6. August 2012, 18:38:54 schrieb Chris66: Ihr benötigt unbedingt die Unterscheidung von leichten und schweren LKWs ? Die Frage ist schon einmal in dem Thread beantwortet worden: wenn nicht unterschieden wird, funktioniert das Routing in jedem Fall für mind. 20% der LKW nicht. Die bestehenden Tags für hgv (damit werden in der Regel LKW Verbotsschilder Z.251 getaggt), maxweight und maxheight reichen für Eure Zwecke nicht aus ? maxweight und hgv reichen nicht aus, um - LKW über 7,5t verboten - LKW über 12t mautpflichtig zu taggen. Eckhart Hi, denke dass es doch reicht: [hgv=no minweight=7.5] [hgv:toll=yes minweight=12] Und da man mit einzelnen Tags keine Verbindung zwischen den beiden herstellen kann, nimmt man Relationen. (Denn genau dafür sind die da.) Etwa so: Relation: type=restriction restriction=hgv hgv=no minweight=7.5 Relation: type=restriction restriction=hgv hgv:toll=yes minweight=12 Vorteil ist auch, dass nicht jeder Kartierer wissen muss, was N2/N3 heißt. Erweiterbar ist das ganze natürlich auch, z.B. mit time=Mo-Fr 8:00-19:00 Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen in Relationen
Am 10.06.2012, 13:48 Uhr, schrieb hike39 ho...@hike.de: Hi, nachdem ich nun angefangen habe unsere letzte Streckenwanderung auf dem Weg der Deutschen Einheit (WDE) auszuwerten und in OSM als Wanderroute einzupflegen, habe ich die Idee gehabt die einzelnen Wegabschnitte als eigenständige Relationen zu erfassen und diese dann mittels einer übergeordneten Relation zusammen zu fassen. Die gesamte Strecke dieser Route wird am Ende über 1.000km gehen und in einer Relation wohl nur schwer händelbar sein. Hierzu wollte ich mich aber ersteinmal schlau machen, wie man dies über Kinds- und Elternrelationen machen kann. Aber wie so oft habe ich zu dieser Fragestellung in Wiki und auch in den Foren keine Hilfestellung gefunden. Daher meine Frage an Euch: Geht so etwas, sollte man so etwas machen, wird so etwas von den diversen Tools (JOSM, Potlach, RA usw) und Applikationen (Lonvias Weltwanderkarte oder der Reit- und Wanderkarte u.ä.) unterstützt? Gruß hike39 Auf Lonvias Karten steht ein Hinweis, dass es unterstützt wird: http://cycling.lonvia.de/de/help/rendering/hierarchies Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Fahrradweg mit abgebauten Schildern taggen ?
Am 02.06.2012, 15:16 Uhr, schrieb fly lowfligh...@googlemail.com: Hi Aufgrund des Leipziger Urteil vom Herbst 2010 werden hier immer mehr blaue Schilder abmontiert. Wie tagge ich solche Wege ohne jegliche Schilder ? highway=path foot=yes oder foot=designated und als noch etwas aufwendigeres Bsp.: Wad machen wenn es vorher ein geteilter Fuß- und Radweg war und die Markierungen noch vorhanden sind, ich als Radfahrer diese Wege somit noch benutzen darf, aber nicht muß ? highway=path bicycle=yes foot=yes oder bicycle=yes foot=designated bicycle=designated foot=designated Für blaue Schilder verwende ich eigentlich *=official (wird leider von Mapnik nicht gerendert), da selbst auf talk@ nicht geklärt werden konnte ob official ≙ designated gilt. Insbesonders das Verbot für alle anderen Fortbewegungsmittel scheint hier ein Problem zu sein. Ich tendiere ja zu *=yes was ich für Bürgersteige als zu schwach empfinde. Wenn ich jetzt auch noch highway=footway ins Spiel bringe stehe ich vor dem Dilemma diese Wege alle auf highway=path foot=yes umzutaggen, da footway ja foot=designated impliziert (bzw official ≠ designated). Wie seht Ihr das ? Grüße fly Bei Wegen ohne jede Beschilderung und Zeichen ist der (straßenbegleitende) Weg ein Bürgersteig (mit Bordstein oder Grünstreifen abgetrennt), welcher nur durch Fußgänger zugelassen ist. - highway=footway, hinzufügen würde ich noch foot=yes, um zu verdeutlichen, dass kein Sild steht. (Bezüglich des implizierten designated: foot=yes würde das überschreiben. 2. ist mMn u.a. das ein Grund, Implizierungen bei Fuß-, Rad- und Reitwegen auf maximal *=yes zurückzuschrauben!) 'Radwege ohne Benutzungspflicht' sind mit rotem/andersfarbigem Pflaster/Farbe versehen, oder mit einem Fahrradpiktogramm. (Ausschließlich dem Radverkehr vorbehalten.) - highway=cycleway + bicycle=yes (gleiche Begründung wie oben) Wie das bei rotem Pflaster + [Zeichen 239 Fußweg] (ohne [1022-10 Fahrrad frei]) aussieht? Eher wie nur-Fußweg!? Im konkreten Fall ist die zulässige Höchstgeschwindigkeit von 50 auf 30 km/h runtergesetzt wurden - keine Radwege. Der Weg verläuft parallel zur Straße ist aber durch senkrechte Parkplätze von der Straße getrennt. - highway=footway + foot=yes + bicycle=yes (falls teils roter Weg oder Fahrradpiktogramm) Grüße Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Definition von highway=bridleway
Am 14.05.2012, 09:07 Uhr, schrieb André Riedel riedel.an...@gmail.com: Ich unterstütze die Varianten abseits von bridleway/cycleway/footway mit track und path. Dazu dann die passende Benutzungsbeschränkung oder Ausschilderung. foot/bicycle/horse = no/yes/designated/official Ciao André Ich sehe das ähnlich. Denn nach dem höchsten OSM-Gesetzt: Wir taggen was wir sehen ist einen Weg mit dem blauen Reiterschild horse=designated. Bei einem zusätzlichen blaues Fußgängerschild kommt noch foot=designated dazu. (Als highway=* kann man sich natürlich zwischen bridleway, path oder sonstwas streiten.) Mit einer Access-Restrictions-Tabelle kann man dann super die Länderspezifischen besonderheiten rausheben (Beispielsweise bicycle=yes. Ein guter Router stellt denn zur Auswahl, ob man über einen solchen Weg geroutet werden will). Wenn man nicht jeden tiefhängenden Ast (nervig für Reiter), oder jede 'zu hohe' Bortsteinabseinkung taggen will, eignet sich anstatt path der speziellere Wegtag: bridleway/cycleway/footway. Wenn man Vorort ist, sieht man ja ganz genau was es für ein Weg ist. Stichworte: Benutzbarkeit, suitable. (Was ist das für ein Weg? highway=* taggen; Welche Schilder hängen dran: *=designated taggen.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway = steps auch für eine Fläche?
Hi, schau mal hier: http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling (ist sogar auf der steps-Seite verkinkt) Es ist zwar noch nichts konkretes, aber es lohnt sich bestimmt es zu taggen, auch wenn es (noch) nicht gerendert wird. Am 15.05.2012, 12:31 Uhr, schrieb Michael Kugelmann michaelk_...@gmx.de: Hallo, nachdem ich große Lücken auf dem Olympiagelände in Barcelona gab, habe ich am Wochenende mal mithilfe der Bing-Luftbilder etwas gemappt/überarbeitet/ergänzt: http://www.openstreetmap.org/?lat=41.36477lon=2.151114zoom=18layers=M Zum Glück hatte ich von meinem Besuch nach der SOTM 2010 noch relativ gute Erinnerungen (bzw. auch Fotos/Tracks). Was aber noch offen ist: es gibt dort sehr breite Treppen auf der Fläche. Diese sind geschätzt bis zu 100m lang. Wie tagge ich diese? Ich bin eigentlich kein Freund von Flächenmalerei, aber in dem Fall frage ich mich, ob ich eine Fläche malen soll und diese mittels area = yes und highway = steps kennzeichnen soll (entsprechend den highway = pedestrian). Kommentare erbeten. Grüße, Michael. PS: das it ein touristisch sehr gut besuchter Ort wo es gute Luftbilder gibt und wo noch jede Menge Details gemappt werden können (viel Fußwege fehlen noch) = wenn es also jemand langweilig ist und er nicht weiss wo er etwas machen soll, dort ist ein (m.E.) dankbarer Ort... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Multipolygone zusammenfassen
Am 13.05.2012, 05:33 Uhr, schrieb Tirkon tirko...@yahoo.de: Moin, ich möchte diese Multipolygon-Relation http://www.openstreetmap.org/browse/relation/963669 als Kindrelation zu dieser http://www.openstreetmap.org/browse/relation/2136138 addieren. Mir ist klar, dass ich dies bewerkstelligen kann, indem ich alle Inseln der ersten Relation wieder einzeln aufnehme. Aber wenn wir schon Kinderrelationen unterstützen, sollte das doch auch gehen, oder? Grüße Tirkon Hi Tirkon, ja, du kannst die erste Fläche (das MP) als outer in das das 2. MP einfügen. Logisch ist das korrekt, nur kann es sein, dass wenige/viele Anwendungen mit solchen Ineinanderschachtelungen nicht klar kommen. Ob und wieweit das so ist, können andere hier sicher besser sagen. Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] online tool: track selector für tracks ohne tracktype
Am 07.05.2012, 22:10 Uhr, schrieb Johannes Hüsing johan...@huesing.name: Am Montag, den 07.05.2012, 11:53 +0200 schrieb aighes: Am 07.05.2012 11:31, schrieb Adrian Stabiszewski: Die Idee ist, die Erfassung der tracktypes zu vervollständigen, da wir bei geschätzten 90% liegen. Außerdem sehe ich den tracktype aus der Radfahrerperspektive und hier brauche ich einfach nur die Info: Rennrad-tauglich (grade1), Trekkingrad-tauglich(grade1-3) und MTB (grade1-5). Hallo, gerade für das Radfahren ist meiner Meinung nach doch surface nötig. grade1 steht für befestigten oder hochverdichteten Untergrund. Das schließt nur so als Beispiel auch Kopfsteinpflaster, üble Betonplattenwege, uvm. mit ein. Solche Wege meide ich schon mit dem Treckingrad, mit dem Rennrad möchte ich von einem Router/oder einer Karte nicht diese Wege als supertoll angepriesen bekommen. Bei mir ist tracktype=grade(6 - Geschwindigkeit, die bequem zu fahren ist (wäre der Weg in der Ebene)*h/5km). Mir wäre lieb, wenn die Router das etwa so einpreisen würden. Bin mal auf einem Betonplattenweg aus DDR-Nachlass gefahren, den ich heute mit grade4 eingestuft hätte (und dem ich damals beim Abfahren für die Radkarte den niedrigstmöglichen Rang zuteilte). Meine Handgelenke zittern unwillkürlich, wenn ich daran zurückdenke. Was da in JOSM steht (4 = mäßig bewachsen), halte ich für unmaßgeblich. tracktype hat absolut rein gar nichts mit fahrbarer Geschwindigkeit oder gutem Fortkommen zu tun! Es ist lediglich eine Unterteilung in Kategorien, welche untereinander keine Rangfolge haben (auch wenn die grade-Zahl das symbolisieren will). Es gibt zB einen befestigten Weg (grade1), der aus groben Kopfsteinpflaster oder aus einer uralten Asphaltstraße besteht (smoothness=bad). Im Gegensatz kann ein Weg aus feinem Schotter (grade2) sogar von Rennrädern befahren werden (smoothness=good/intermediate). Es gibt sicherlich auch grade4/5 Wege, welche gut mit einem Citybike befahrbar sind (smoothness=intermediate). Somit ist für mich als Radfahrer nur surface und smoothness interessant (was leider nicht so oft getaggt wird, weil es wiederum nicht gerendert wird). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 22.04.2012, 10:31 Uhr, schrieb Jimmy_K jimm...@gmx.at: Am 21.04.2012 17:01, schrieb Masi Master: Mindestbreite für einen Radweg bzw. Fussweg ist 2,50 m, also prinzipiell breit genug für 2-spuriges Fahrzeug. (=kollidiert mit highway=path) . Gruß Masi Bei neuen Radwegen, aber bei existenten, gibt es da viel schmälere Ausführungen. Speziell in Österreich gibt es teils sehr extreme Weg (kombinierter Geh-/Radweg mit unter einem Meter!) LG Jimmy PS: Für mich sind die 2,5m ja eine reine Verhinderungstaktik. Hier in Deutschland gibt es auch viele solcher Radwege, die nicht dem Stand der Technik entsprechen. Laut Gesetz sind aber die verantwortlichen Gemeinden dazu verpflichtet, alle Wege zu überprüfen und die Beschilderung (oder den Zustand) anzupassen. Wird leider in allen Fällen nicht gemacht. Ob diese falsche Kennzeichnung hier in OSM übernommen werden soll, bin ich mir nicht sicher... Verhinderungstaktik für path? Na, wenn ich mit dem Auto über eine Autobahn fahre, geh ich davon aus, dass dort keine Ampeln/Kreuzungen sind. Es sollte doch auch ein tag geben, um die Benutzbarkeit (und Sicherheit) von Radwegen anzuzeigen, ohne nur aufs MTB mit Schrittgeschwindigkeit angewiesen zu sein. Für mich ist momentan cycleway das tag der Wahl. Path ist mir da zu unspezifisch (das kann alles sein, von 20cm zugewuchertem Pfad in der Pampa bis Autobahnähnlich, und mit bicycle=designated wird daraus dann nen Radweg??). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 22.04.2012, 19:51 Uhr, schrieb Falk Zscheile falk.zsche...@googlemail.com: Am 22. April 2012 19:04 schrieb Masi Master masi-mas...@gmx.de: Für mich ist momentan cycleway das tag der Wahl. Path ist mir da zu unspezifisch (das kann alles sein, von 20cm zugewuchertem Pfad in der Pampa bis Autobahnähnlich, und mit bicycle=designated wird daraus dann nen Radweg??). Genau. Ein kleines Tag, ein wesentlicher Unterschied. Und so einfach. Wie viele highway=path, bicycle=designated mit 20 cm Bewuchs kennst du? Du unterstellst anderen Mappern gerade, das die nicht richtig zwischen Pfad (highway=path) und einem Radweg (highway=path, bicycle=designated) unterscheiden könnten. Für mich klingt Deine Aussage eher nach einem Scheinargument. Nein, ich unterstelle, dass andere Mapper alle kombinierte Fuß/Radwege mit path +designated taggt, wenn dort ein blaues Schild hängt, und zwar unabhängig davon, ob der Weg die Anforderungen für den Radverkehr erfüllt. Leider kann man wenig gegen die immens häufige falsch-Ausschilderung machen. Ich erkenne den Vorteil von path nicht... nur weil man sich nicht zwischen 2 tags entscheiden will? P.S.: Von ausgeschilderten (=designated?) MTB-Routen/Wege (=path) hab ich gar nicht gesprochen und auch nicht gemeint. Mir ging es eher darum, dass einige Mapper zB kombinierte Wege, mit erstklassigen Radeigenschaften, sogar mit Radweg im Namen, in einen etwas undefinierteren path verwandeln. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 21.04.2012, 13:35 Uhr, schrieb Falk Zscheile falk.zsche...@googlemail.com: Am 21. April 2012 13:12 schrieb Wolfgang wolfg...@ivkasogis.de: Am Samstag, 21. April 2012 08:02:53 schrieb Falk Zscheile: Am 21. April 2012 00:15 schrieb Wolfgang wolfg...@ivkasogis.de: Übrigens ist für mich path die schlechteste aller Alternativen. Die Unterscheidung zu wirklichen Pfaden, z.B. Alpen, Moore, ... wird verwischt. Nein, da man an den sub-Tags sehr gut erkennen kann, was es ist -- auch in den Alpen. Das alles sowohl für Maschinen als auch für Menschen. Wenn diese sub-tags denn benutzt werden. Das ist häufig, gerade bei neuen Mappern, nicht der Fall. Aber doch für Dich als erfahrenen Mapper kein Argument es wie ein Anfänger falsch zu machen :-) Intuitiv ist ein Pfad für einen 4 m breiten Weg nicht gerade. Nö, aber 1. ist es für Radwege nicht gerade die Regelbreite, damit eine Argumentation am Einzelfall und damit für den hier zu klärenden Normalfall, nicht gerade hilfreich. 2. gibt es width=value. Mindestbreite für einen Radweg bzw. Fussweg ist 2,50 m, also prinzipiell breit genug für 2-spuriges Fahrzeug. (=kollidiert mit highway=path) Lieber Hauptnutzung cycleway/footway und die andere Nutzung mit yes dazu. Es gibt ja auch nichts schöneres als die Diskussion darüber, wo jetzt der Schwerpunkt der der Nutzung ist. Das Argument Hauptnutzung suggeriert ein objektives Kriterium, nur um dem Mapper dann doch die Möglichkeit zu geben, bei seinem Lieblingstag zu bleiben. Niemand stellt sich hin und zählt aus, ob da nun mehr Fahrräder sind oder Fußgänger. Der so objektive Eindruch des Mappers ist also nicht mehr als ein subjektives Gefühl. Das siehst du viel zu eng ;-) Es ist mir und dem Router völlilg egal, ob der Mapper den Hauptnutzer im Fußgänger oder Radfahrer sieht, solange sich beide denselben Weg teilen und der jeweils anderer mit 'yes' dranhängt. Aber es macht fürs Routing einen signifikanten Unterschied ob es ein Radweg nach StVO ist oder nicht. Das muss erkennbar sein. Um mehr geht es mit nicht. wenn nicht gerade die Behörde an den beiden Enden des Weges verschiedene Schilder aufgestellt hat. ;-) Wenn ein Schild dran steht. Sonst s.o. Verstehe ich dich vielleicht falsch? Wann setzt du foot/bicycle=yes. Nur wenn die offizielle Ausschilderung nach StVO fehlt oder widersprüchlich ist? Dann habe ich kein Problem damit. Wie erfasst Du kombinierte Fuß/Radwege nach StVO? Ich wurde zwar nicht gefragt, wähle aber bei kombinierten Fuß-/Radwegen entweder foot- oder cycleway aus (genau so wie man es bei amenity=restaurant/bar, oder highway=secondary/tertiary macht). Der Inforationsgewinn ist, dass relevante Dinge wie abgesenkte Bordsteine, zügiges Vorrankommen möglich und gefährliche Ausfahrten Parkplätze normalerweise nicht gemappt werden. Dazu gibt es die passenden access tags: bicycle/foot=(official/)designated/yes/... Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 19.04.2012, 22:01 Uhr, schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag, 19. April 2012 19:34:39 schrieb Joerg Fischer: Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. Gruß, Wolfgang bicycle=official ist das (neuere) tag der Wahl für benutzungspflichtige (Rad)Wege. Bei Wegen die nicht neben der Straße verlaufen, oder anders als mit dem blauen Schild gekennzeichnet sind, gibt es bicycle=designated :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 17.04.2012, 22:49 Uhr, schrieb Chris66 chris66...@gmx.de: Am 17.04.2012 22:22, schrieb Bernhard Weiskopf: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Naja, das gilt aber nicht für alle Radfahrer. Ein Anhänger z.B. entbindet von der Benutzungspflicht des Radweges. bicyle=no setze ich deshalb nur bei bei explizitem Verbot durch Zeichen 254 o.Ä. Chris Auch wenn der Radweg unzumutbar ist, darf auf der Straße gefahren werden. Somit ist bicycle=no falsch (außer bei Verbotsschildern). Es gibt aber auch Straßen mit abgesetzt parallel verlaufendem asphaltiertem Wirtschaftsweg oder Fußweg mit Fahrradfreigabe hier ergänzt man bicycle=yes (oder Tempo-30-Zonen, in denen keine nutzungspflichtigen Radwege erlaubt sind). Der abgesetzte Weg ist dann nicht als Radweg markiert, es besteht keine Nutzungspflicht und die für Radfahrer gefährlichere Straße darf benutzt werden (wird sie auch, z. B. von Rennradfahrern). Die Straße ist übrigens erheblich sicherer als die allermeisten Radwege. Man darf nur nicht äußerst rechts fahren, um die Autofahrer nicht zum Überholen ohne Abstand zu animieren. Aber das ist ein anderes Thema. Der abgesetzte Weg ist meistens geringfügig länger und die Router leiten dann Radfahrer über die Autostraße. Gibt es eine Möglichkeit, den Routern quasi eine Empfehlung (per tag o. ä.) für den meistens besser geeigneten, abgesetzten Weg mitzuteilen, oder müssen die Router damit alleine zurechtkommen? Das sollte eigentlich Sache der Router sind. Ich würde mir eine Software wünschen, bei der mal bei allen Wegtypen (auch in Kombination von surface/smoothness usw.) die Priorisierung festlegen kann. Bernhard Gruß Masi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreatives Mapping von Wald_Flurstücken
Auch wenn die Teile nicht nebeneinander liegen, besteht kein Grund die Teile aus dem Wald (mit dem Namen Y) (per Muptipolygon) herauszuschneiden. Gehört doch immernoch zum Wald. Gruß Masi Am 07.03.2012, 13:17 Uhr, schrieb Andre Joost andre+jo...@nurfuerspam.de: Am 07.03.12 12:26, schrieb Falk Zscheile: Apropos -- wenn die einzelnen Flurnamen gemeinsam einen anderen Namen haben als die einzelnen Stücke: Der Wald besteht aus den Flurnstücken mit den Flurnamen X1, X2 und X3. Der Wald selbst heißt Y. In diesem Fall wäre für die Zusammenfassung eine Multipolygonrelation das Mittel der Wahl -- oder gibt es da etwas besseres? Eine Site-Relation? wenn die Teile nebeneinander liegen, besteht kein Grund, eine Multipolygonverarbeitung anzustoßen. Da reicht also collection oder site. Gruß, André Joost ___ 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
Re: [Talk-de] Abkürzungen?
Am 19.12.2011, 16:35 Uhr, schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Hallo, nachdem ich heute beim Versuch, eine Route zu planen, daran gescheitert bin, einen Ort zu finden, bin ich dem nachgegangen. Ergebnis: Ursache war eine Abkürzung. Statt am Main wurde nur a. Main geschrieben. Ich habe das korrigiert, weiß aber nicht wie lange es nun dauert, bis das jemand für optisch nicht ansprechend hält und zurückändert. Meine Meinung zum Thema: Wer eine Datenbank erstellt, der sollte dort keine Kurzformen hinterlegen. Ich schreibe ja auch nicht Hauptstr. wenn die Straße Hauptstraße heißt. Korrekt oder liege ich da falsch? Gruß Manuel Hi, du liegst nicht falsch. Habe irgendwo (weiß nicht mehr wo) im wiki gelesen, dass man alles ausschreiben soll, also KEINE Abkürzungen benutzen soll. Gruß Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breite Treppe
Am 19.12.2011, 19:51 Uhr, schrieb Markus liste12a4...@gmx.de: Wie beschreibt man eine sehr breite Treppe mit geschwungenen wenigen Stufen, wie sie manchmal an Ufern oder Plätzen zu finden sind? Beispielsweise 50m breit, davon linker und rechter Teil je 20m gerade, mittlerer Teil halbkreisförmig gebogen zu einem Denkmal hin, insgesamt 5 Stufen... Hier steht nichts: http://wiki.openstreetmap.org/wiki/DE:Tag:highway=steps Gruss Markus Apropos Denkmal: wie heisst der passende Schlüssel? Hi, schau mal ob du dort was passendes findest: http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling Das sind ein paar gute Vorschläge, wie ich meine. Implementiert in der Karte ist es zwar noch nicht, aber es schon mal so zu taggen schadet nicht. :) Gruß Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance+steps
Hallo, wie sieht es eigentlich mit Stufen im Eingangsbereich aus? Muss man dort einen kleinen Treppenstummel vor den Eingang setzen, oder kann man in dein Eingangsknoten steps=yes + step_count=NumberOfSteps schreiben? Ich frage vor dem Hintergrund des Routings von einer Fläche (Fussgängerzone) in einen Eingang, ob die Treppe/Stufen vom Routing überhaupt mitgenommen werden kann. Gruß Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
