Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell
Am Freitag, 25. Januar 2019, 19:30:54 CET schrieb Hubert87: > Hallo Georg, > > Am 25.01.2019 um 17:58 schrieb Georg Feddern: > > Moin, > > > > nun ja - jeder benutzungspflichtige Radweg muss ja "designated"(*) > > sein - sonst wär er ja nicht benutzungspflichtig. > > Richtig. > > > Andererseits sind ja nicht alle "designated" auch tatsächlich > > benutzungspflichtig - siehe Querfeldein-Wege. > > (Hier war die frühere StVO eigentlich besser formuliert m.M.n.) > > Richtig > > > Die Benutzungspflicht ergibt sich ja erst aus der Nähe/Begleitung > > einer Straße - und kann im Wesentlichen durch "use_sidepath=yes" an > > der Straße abgebildet. > > Hierdurch soll ja genau das Wesentliche - nämlich die Vermeidung der > > Straßenbenutzung beim Routing - erreicht werden. > > Richtig. Der Radweg muss dann aber als eigene Linie eingezeichnet sein. Wobei sich daraus dann in manchen Innenstadtlagen das Problem ergibt, zu welchem Straßenabschnitt jetzt welcher Radwegeabschnitt gehört. Gerade in engen Innenstadtlagen würde ich daher eher von einem separat gemappten Radweg absehen und ihn durch tags darstellen, solange er dem Verlauf der Fahrbahn folgt. Der Unterschied ist beim Routing maßstabsbedingt praktisch bedeutungslos, außerdem entfällt das Problem der Abbildung von Abbiegemöglichkeiten auf der linken Seite. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konfigurationsfehler Apache www.openstreetmap.de (WAS: Deutsche Homepage - Fehlermeldung)
Hallo, Am Samstag, 27. August 2016, 11:06:45 schrieb lars lingner: > Hallo, > > viele Dank für das Feedback. Die SSL-Config wurde habe ich eben > überarbeitet und jetzt wird die Seite mit A bei sslabs [1] bewertet. > > Falls noch weitere Einschränkungen auffallen, bitte melden. der Ausfall der Suchfunktion ist bekannt? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland
Am Sonntag, 13. März 2016, 14:02:58 schrieb Martin Koppenhoefer: > +1, wenn Kommunen ihre Routen in OSM haben wollen dann ist das keine Frage, > die uns beschäftigten muss, vielmehr sollten sich dann ggf. die Kommunen > mit dieser Frage beschäftigen, besonders schwierig ist sie aber auch nicht > zu beantworten: entweder machen sie es selbst oder sie beauftragen jemanden > damit oder sie warten, dass es Freiwillige evtl. kostenlos machen. Wenn diese Routen nachvollziehbar von den Kommunen definiert und unter kompatibler Lizenz öffentlich dokumentiert werden, +1 Dann kann der Mapper vor Ort die Eintragungen prüfen. Nicht jede prüfbare Eintragung beruht auf einem Schild vor Ort oder der direkten Zugängikeit durch den Mapper. (Busrouten, Eisenbahnrouten, PLZ, Grenzen aller Art, TMC, Gebäudeumrisse, Bach- und Flussläufe auf Privatgelände, ...) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Karte / Darstellung historischer Bahnstrecke
Am Samstag, 17. Oktober 2015, 13:02:34 schrieb Rolf Eike Beer: > Am Samstag, 17. Oktober 2015, 11:25:39 schrieb goegeo: > > Hallo zusammen, > > > > mir ist aufgefallen, dass in der ÖPNV-Karte eine historische Bahnlinie > > (blau) angezeigt wird. Es handelt sich um die ehemalige Straßenbahn > > Flensburg, welche nur bis 1973 bestand. Mag jemand bei der Entfernung > > behilflich sein. Bin im Tagging vom ÖPNV noch recht neu unterwegs. Denke > > aber, dass historische Bahnstrecken nicht in der ÖPNV-Karte dargestellt > > werden sollten. > > Moin, > > geh doch mal bitte etwas ins Detail, z.B. Koordinaten oder oder die id eines > Weges, dann können wir uns das mal ansehen. > > Gruß > > Eike <http://öpnvkarte.de/?zoom=14=54.79101=9.43546=TBTT T> Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
, die Du im Fußgängerrouting gern vermeiden willst, muss der Renderer dann aber machen, will er seien Job gut machen - hat dieser Fussweg hier zufällig den gleichen Namen wie eine benachbarte Straße, für geeignete Werte von 'benachbart', dann schreibe den Namen nicht extra rein. Das ist das gleiche Problem bei getrennten Fahrbahnen und bei Radwegen. Einerseits die Raterei, zu welcher Straße die Wege gehören, andererseits die Namen auf mehreren Ways. Ein weiteres Problem für den Renderer besteht darin, dass die Rad- und Fußwege mit Verkleinerung des Maßstabes unter oder über die Signatur der Fahrbahn geschoben werden. Entsprechend sehen die Karten dann auch aus, die Radwege liegen wie eine Straßenbahn in der Fahrbahnmitte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht
Am Sonntag, 5. April 2015, 16:51:16 schrieb fly: Hast Du nicht den Datensatz runtergeladen ? War da eine Lizenz dabei ? Falls nicht, hast Du den Satz als CC0 runtergeladen und der bleibt auch CC0, selbst wenn die Lizenz jetzt geändert ist. Du meinst wahrscheinlich, ob eine von der auf der Seite zu dem Zeitpunkt angegebenen CC0-Lizenz abweichende Angabe im Datensatz war. (Ganz ohne Lizenz CC0) Grundsätzlich ist das erst mal richtig, aber: Es handelt sich sehr wahrscheinlich um einen Irrtum. Dies ist von uns bemerkt worden. Ob wir die Beute trotzdem einfach behalten und verwerten dürfen, ist fraglich. Bei der sehr zurückhaltenden OSM-Politik in diesen Bereichen zumindest im Projekt eher nein. Außerdem halte ich es im Sinne eines Miteinanders mit der Verwaltung, bei der sich jetzt endlich etwas ändert, für kontraproduktiv, jeden Brocken, der mal versehentlich etwas daneben geworfen wurde, sofort mit Zähnen und Klauen zu schnappen und festzuhalten. Es gibt mit Sicherheit innerhalb der Verwaltung unterschiedliche Positionen und wir würden nur die Fraktion stärken, die sowieso der Meinung ist, die Piraten von OSM klauen sofort alles, was nicht niet- und nagelfest ist. Im übrigen ist uns die Verwaltung schon sehr weit entgegen gekommen. Der in der Lizenz geforderte Quellenverweis muss nur angegeben werden, wenn er vom Datenanbieter bereitgestellt wird, und der schreibt ausdrücklich Namensnennung nicht erforderlich. Siehe auch Mail vom 2.4.15 Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht
Am Donnerstag, 2. April 2015, 14:22:04 schrieb Johannes Kröger: Für die Datenlizenz Deutschland Namensnennung 2.0 finde ich bei uns keine belastbare Aussage, ob das Ding nun kompatibel ist oder nicht. Dito. :( Die Namensnennung im Changeset und der Homepage wird kaum gerecht sein, sie infiziert ja die Daten und muss erhalten bleiben. Sonst wären da wirklich tolle Daten verfügbar, Teile von ALKIS, Adressen, Gebäudegrundrisse etc. Die wären toll zum vorsichtigen Abgleichen. Möglicherweise ist zwar die Deutschland-Lizenz 2 prinzipiell nicht kompatibel, aber in diesem Sonderfall schon. Laut Lizenz müssen die Pflichtangaben vom Anbieter der Daten bereitgestellt werden, wenn er sie verlangen will. Dieser Anbieter schreibt aber nur Namensnennung nicht erforderlich, ansonsten sehe ich da keine weiteren Forderungen. Ich gehe davon aus, dass hier bewusst verzichtet wird. Darauf deutet auch die zunächst genutzte CC0. Dies ist jetzt gewissermaßen die amtliche CC0. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht
Hallo, Am Dienstag, 31. März 2015, 20:27:40 schrieb Johannes Kröger: Ich habe zwar noch keine Antwort von irgendwem offiziellen bekommen, aber der Datensatz (und die anderen CC0er) ist jetzt wie alles andere unter der Deutschlandlizenz. Da hätte ich wohl abwarten sollen, bevor ich es geschrieben habe, sorry! http://suche.transparenz.hamburg.de/dataset/hamburger-strasseninformationsba nk-hh-sib Für die Datenlizenz Deutschland Namensnennung 2.0 finde ich bei uns keine belastbare Aussage, ob das Ding nun kompatibel ist oder nicht. Ich vermute mal, dass schon einige Leute munter am Abpinseln sind. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht
Am Montag, 30. März 2015, 13:07:00 schrieb Martin Koppenhoefer: Am 30. März 2015 um 12:47 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Ich frage aber doch mal nach: Reicht die Lizenz für uns aus? wieso, da steht doch cczero, mit link: http://creativecommons.org/publicdomain/zero/1.0/deed.de das heisst, es gelten überhaupt keine Auflagen, Du kannst damit machen, was Du willst (wie Public Domain). Namensnennung ist nicht erforderlich. Hups, da hast du recht :) Ich bin durch das crossposting da etwas von der Schiene gekommen. Es ging in einem anderen Thread auf talk-HH darum, ob die noch interessanteren Kreuzungsskizzen[1] ausgewertet werden dürfen, die stehen unter der Datenlizenz Deutschland – Namensnennung – Version 2.0 [2], bei der ich mir nicht so sicher bin. Gruß, Wolfgang [1] http://suche.transparenz.hamburg.de/dataset/kreuzungsskizzen-hamburg [2] https://www.govdata.de/dl-de/by-2-0 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht
Am Freitag, 27. März 2015, 13:36:25 schrieb Martin Koppenhoefer: Am 26.03.2015 um 19:03 schrieb Johannes Kröger johannes.kroe...@hcu-hamburg.de: Besonders bei solchen manuell eingestellten Daten. Sind doch alles auch nur Menschen. Es sind nur drei Datensätze mit CC0 im Transparenzportal, während alles andere unter der Deutschlandlizenz steht. Da sollte man erstmal sichergehen, dass sie wirklich so gedacht sind. wenn sie sie mit dieser Lizenz veröffentlichen dann sollte die wohl auch gelten, der Sinn einer Lizenz ist ja gerade, dass man nicht mehr nachfragen muss. Ich frage aber doch mal nach: Reicht die Lizenz für uns aus? Was ist mit dem Quellenverweis für Abwandlungen, also das, was wir daraus machen? Wir können das im Kommentar zum Changeset unterbringen, aber derjenige, der die Daten von uns runterlädt, hat den Verweis nur, wenn bei jedem Objekt im Sourcetag der Quellenverweis auftaucht, was wohl praktisch kaum zu leisten ist. Vor allem aber: Was ist mit Abwandlungen von Abwandlungen (Weiterverarbeitung unserer Daten)? Reicht ein Quelleneintrag auf der Quellenseite unseres Wiki? Muss der Downloader in seinen Anwendungen wiederum den Quellenverweis mitführen? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am Freitag, 20. Februar 2015, 00:32:24 schrieb Patrick Niklaus: Ich würde OSRM von der Auswahl entfernen, bis sie z. B. auch Abbiegerelationen und Anliegerstraßen beachtet, die gehören meiner Meinung nach zu den Grundfunktionen. Falls du Abbiegerelationen findest die nicht funktionieren, dann poste das bitte hier [1]. Momentan nicht unterstützt werden lediglich Abbiegerelationen bei den via ein Way ist. Was schade ist, denn an dieser Stelle http://www.openstreetmap.org/directions?engine=osrm_carroute=53.60779%2C10.03524%3B53.60774%2C10.03872#map=18/53.60797/10.03697 gibt es dazu keine Alternative. Am Ende der Verkehrsinsel beginnt nahtlos eine Busspur, die nicht gequert werden darf. Rechtsabbieger müssen also rechts an der Verkehrsinsel vorbei fahren, alle anderen links. Google behilft sich mit falscher Straßendarstellung, die können es also auch nicht. Hätte OSM also die Nase vorn haben können... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
Hallo zusammen, leider komme ich nur selten dazu diese Liste hier zu lesen, habe aber diese Diskussion gesehen und mal gelesen. Und da ich beruflich mit Radwegweisung zu tun habe, könnte ich dazu was beitragen. Diese hier immer wieder erwähnte Wegweisung (WW) ist nicht x-beliebig. Sie ist seit 1998 die durch die FGSV festgelegte Norm http://www.fgsv-verlag.de/catalog/product_info.php?products_id=433 Für ihren Einsatz braucht es eine Netzplanung nach ERA http://www.fgsv-verlag.de/catalog/product_info.php?products_id=2869 Bundesweit ist sie meist grün auf weiß, in Teilen von Niedersachsen auch rot auf weiß wie in ganz NRW. Dort ist sie sogar Teil der StVO-Wegweisung. Diese WW hat mehrere Komponenten: ZwischenWW http://www.stempelcity.de/l8mimages/zwischenwegweiser.jpg die stehen grob dort, wo es nur in eine Richtung weiter geht. HauptWW http://www.gruene-koengen.de/bilder/radweg/piktogramme.anordnung.png die solche PfeilWW sein können, aber auch entsprechende TabellenWW http://www.wfg-rd-eck.de/uploads/Tourismus/Bsp.%20Tabellenwegweiser_1.jpg Beide stehen dort, wo es in mehrere Richtungen geht. Nur auf den HauptWW stehen Zielorte (oben Fernziel, unten Nahziel) mit km Angabe. Zudem können vor dem Ziel noch Zusatzangaben zum Ziel (z.B. (S-)Bhf, Schwimmbad, ...) stehen, die sich dann bei Bedarf in der Nähe des Ziels aufsplitten. Zwischen Zielort und km können noch Zusatzangaben zum Weg sein (viel Autoverkehr, Steigung oder Baum für nicht alltagstauglich). Routen werden als Signet unten im HauptWW eingehangen. Sie sind in der Regel touristisch. Da es sich bei der WW um eine offizielle ;-) handelt, wollen auch alle Offiziellen mitreden, d.h. sie muss abgestimmt werden und viele Bedenkenträger können alle möglichen Einwände einbringen, weshalb auf einer für den Radverkehr gut geeigneten Strecke keine WW erscheinen darf. Daher sind derartige Netze immer suboptimal, aber offiziell. Und es muss noch erwähnt werden, dass das hier beschriebene idealtypisch ist. Die Realität sieht nicht selten anders aus. Schlecht und/oder regelwidrig geplant, nicht gewartet und daher lückenhaft, oder durch Bauarbeiten unterbrochen und nicht wieder hergestellt. Aber das gibt es auch (zwar geringer) bei PKW-WW. Nur dort fallen Fehler eher auf, da die Planer mehr Auto als Rad fahren ;-) Aber eigentlich ;-) müssten die Kommunen, Kreise oder Länder, die diese Netze geplant haben, davon auch Unterlagen über den Sollzustand ohne Fehler im Gelände haben, die abrufbar sein sollten. Damit wären die Netze auch leichter zu taggen. Dabei will ich es gerade belassen, weil ich ins Bett muss. Für Fragen stehe ich gerne zur Verfügung. Falls ich hier in der Liste nicht antworte, schreibt mir gerne ne PM. tschau und gute N8 Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abkürzungen für die Radwege in OCM
Hallo Michael, Das stimmt nicht ganz. In kleinen Teilabschnitten existiert er schon, teils aber nicht im geplanten Ausbauzustand. Den genauen geplanten Verlauf findet man in der Machbarkeitsstudie: http://www.rs1.ruhr/fileadmin/user_upload/RS1/pdf/RS1_Machbarkeitsstudie_web.pdf (20MB) Bitte beachten: 1. We map what's on the ground. Das heißt Ways werden nur dann in die Routenrelation aufgenommen, wenn sie fertig sind (ansonsten ist es ein propsed- bzw. construction-Route). Die Machbarkeitsstudie ist ein Planung. IMHO sollte man geplante Sachen frühestens mappen, wenn das Planfeststellungsverfahren läuft. 2. Urheberrecht. Haben wir eine Nutzungerlaubnis für die Machbarkeitsstudie? Die Information, wo der RS1 lang gehen wird, unterliegt nicht dem Urheberrecht. Wenn überhaupt, dann nur das Schriftstück, nicht sein Inhalt. Und wie gesagt: es gibt schon Teilstücke z.B. in Essen, teils in noch nicht fertigem Ausbauzustand. D.h. z.B. kein Asphalt und/oder nicht so breit wie geplant. Wenn OSM aber wirklich nur mit Wegweisung ausgeschilderte Strecken abbilden will, dann ist es meist noch nicht soweit. Gibt es eine derartige Festlegung? fragt Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abkürzungen für die Radwege in OCM
Hallo zusammen, Den gibt's doch noch garnicht: http://www.schmidts-katze.info/2014/radschnellweg-ruhr-110-mio-e-fuer-100-km-radweg/ Das stimmt nicht ganz. In kleinen Teilabschnitten existiert er schon, teils aber nicht im geplanten Ausbauzustand. Den genauen geplanten Verlauf findet man in der Machbarkeitsstudie: http://www.rs1.ruhr/fileadmin/user_upload/RS1/pdf/RS1_Machbarkeitsstudie_web.pdf (20MB) Ansonsten wuerdest du ihn auf http://cycling.waymarkedtrails.org/ finden Da ist er noch nicht verzeichnet Gruß Wolfgang Schuch 2015-01-29 14:16 GMT+01:00 Bernd Sommer gabes...@me.com: Hallo zusammen Kann ich irgendwo nachlesen, welche Abkürzungen die einzelnen Radwege auf den „Open Cycle Map`s“ haben? Wie finde ich den RS1-Radweg von Duisburg nach Dortmund? LG B.Sommer ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am Montag, 22. Dezember 2014, 13:28:16 schrieb huey212: Hallo, folgende Gedanken: ich mappe sehr viel Radverkehrspezifisches. Da stellt sich mir die Frage, was haben Radwege und (Auto-)Fahrbahnen gemeinsam? -ggf. einen Bordstein, -grob den gleichen Verlauf, -den gleichen Straßennamen, -die gleiche Beleuchtung Was ist unterschiedlich? -Der Verlauf im Detail -Fahrbahnbelag, -Nutzungsvorgaben (access) -Einbahnstraßenregelungen (Fast alle straßenbegleitenden innerstädtischen Radwege in Deutschland sind Einbahnstraßen! Fußwege hingegen nicht.) -Spuraufteilung -Abbiegebeschränkungen Ich halte das Anbringen von Fuß- und Radweginformation an der Hauptfahrbahn nur bei relativ grobem Mapping für sinnvoll. Sobald es in die Details geht sollte die Wege als einzelne Linienzüge erfasst werden. Alles andere wird unübersichtlich und ist nicht mehr editierbar (weil zu kompliziert). Von einer sinnvollen Auswertung reden wir mal noch gar nicht. Die sinnvolle Auswertung besteht meistens aus einer Karte oder einem Router. Die Karte hat, wenn gedruckt oder sonstwie als Übersicht genutzt, einen Maßstab, in dem die Symbole von Fahrbahn und Radweg sich gegenseitig verdecken. Man kann zwar im Web weiter hineinzoomen, einen Nutzen hätte das aber nur für eine Art Straßenkataster, das wir ohnehin nicht leisten können. Der Router braucht verbundene Wege, um alle Abbiegemöglichkeiten nutzen zu können. Das wird häufig ausgelassen, wenn nur auf der Gegenseite ein Weg abzweigt. Die Zuordnung des Radweges zu einer bestimmten Straße ergibt sich im innerstätischen Bereich aus der reinen Lage nicht immer. Daher meine ich, dass der Radweg, wenn er keine erheblich andere Streckenführung als die Straße selbst hat, an sie getaggt werden sollte. Das eigenständige Einzeichnen hat in hohen Zoomstufen einen optisch schönen Effekt, besonders im Zusammenwirken mit dem Luftbild, ist aber für die meisten Auswertungen eher hinderlich. Als Ausweg bliebe noch, den straßenbegleitenden Radweg, wenn man es denn unbedingt möchte (und solange es überhaupt noch so etwas gibt), sowohl als tag als auch als eigenständigen Weg einzuzeichnen und dem Auswerter über eine Relation (street) oder über ein Tag (?) mitzuteilen, dass er sich hier die für ihn günstigere Variante aussuchen kann. Übrigens gilt für den straßenbegleitenden Fußweg sinngemäß das Gleiche. Wenn der Radweg unbedingt ein eigenständiger Weg sein soll, müsste der Fußweg analog ebenfalls eigenständig eingezeichnet werden. Die Argumente sind letztlich die Gleichen, mit allen Vor- und Nachteilen. Ob aber 5 Linienzüge im Verlauf einer Straße übersichtlicher als ein einzelner sind, muss wohl jeder Mapper für sich selbst entscheiden. Einen guten Editor (mit gutem css-Stil) vorausgesetzt, dürfte das Modell mit den Tags übersichtlicher darstellbar sein als das Modell mit den separaten Wegen. Dann erscheinen die Rad- und Fußwege optisch am Außenrand der Straße. Was bleibt, sind die längeren tags, dafür aber alle an einem Way zusammengefasst und nicht an 5 Ways verteilt. Auch hier kann ein guter Editor viel Übersicht schaffen. Wenn wirklich die Straße genau abgemalt werden soll, halte ich eine zusätzliche Flächenerfassung für sinnvoller. Letztlich ist das die einzige Möglichkeit, in hohen Zoomstufen (und nur dort) die Straße mit allen Einzelheiten abzubilden. Auch dann bleibt aber die Frage, wer das eigentlich braucht, außer als schöne Ansicht. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am Samstag, 13. Dezember 2014, 00:41:23 schrieb Hubert: Der Renderer, welcher den Bürgersteig an der Straße darstellen möchte, unterdrückt halt alle highway=footway + footway=sidewalk und stellt die highway=residential + footway:both=sidewalk entsprechend dar. Z.B. als roten Rand. Derjenige, der den Bürgersteig als eigenen Weg darstellen will, malt die highway=residential + footway:both=sidewalk als normale Straßen, ohne roten Rand, und stellt darfür die highway=footway + footway=sidewalk dar. So oder so ähnlich. Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße gehören und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, sollten es eine street-Relation geben, in der alle Linien, die zur gleichen Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von Straßennamen etc. zu separaten Wegen. Auf dem gleichen Weg kann auch die Diskussion um die separaten oder nicht separaten Radwege gelöst werden. Der Datenkonsument kann sich dann frei aussuchen, welche Lösung er für sich für geeigneter hält. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Erstellung kml-Dateien mit Markern
Hallo, gibt es eine OSM-Seite mit einem Straßenkarte, auf der man - ähnlich wie mit GoogleEarth über einem Luftbild - Marker eintragen kann, diese mit Namen und Beschreibung erweitern kann und letztendlich alles in einer kml-Datei speichern kann? -- mit freundlichen Grüssen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Hallo,
Am Mittwoch, 12. November 2014, 09:49:45 schrieb Joachim Kast:
... denn von dem Network-Vorschlag halte ich persönlich für nicht optimal
(Änderung eines Verwendungszweckes eines Tag's, müsste auch erst
ausführlich diskutiert werden).
Es mag sein, dass network=* nicht so optimal ist, aber mir fällt
momentan auch nichts besseres ein. Bei der Analyse der
network-Werteverteilung [1] findet man jedoch so ein wohlgeordnetes
kreatives Chaos, dass es auf ein network=eBusinesslotse eigentlich auch
nicht mehr ankommt.
Ziel dieser wie auch immer aussehenden Kennzeichnung soll sein, die
dezentral eingegebenen Daten für eine App einzusammeln. Das könnte man
prinzipiell auch über die Auswertung des Anfangs des Name-Tags bei einer
einheitlichen Namensgebung machen, aber ich finde eine eigene key/value
Kombination dennoch besser.
Sollte jemand eine optimalere Lösung anstatt network=eBusinesslotse
haben, dann möge er seinen Vorschlag hier bitte präsentieren.
Letztlich läuft es immer wieder auf das gleiche Problem hinaus, über das seit
mehreren Jahren diskutiert und für das immer wieder eine Lösung abgelehnt
wurde: Eindeutige Verweise auf OSM-Daten aus anderen Datenbeständen heraus.
Alles schreit nach externen Datenbanken (Nicht alles in OSM kippen), aber
eine Lösung gibt es bis heute nicht, so dass letztlich Insellösungen gebastelt
werden, die individuell Tags festlegen, mit denen dann die Daten
referenzierbar sein sollen. Wenn das so weiter geht, haben wir bald ein
schönes Sammelsorium von verschiedensten Tags, für jede Anwendung ein paar.
Ich schlage daher vor, über _ein_ objektbezogenes Referenz-Tag nachzudenken,
dass in eindeutiger Form, wo notwendig, vergeben wird und das dann jeder
Nutzer für seine Anwendung benutzen kann.
Ich werfe mal ein Tag in den Ring:
externel_reference_id=[nwr]{derzeitige-id-Nummer}
also ein Tag, das bei Bedarf jederzeit mit den Editoren erzeugt werden kann
und dessen Wert einfach der derzeitigen Objekt-ID entnommen wird,
also z.B. für Ways
externel_reference_id=w1234567890
ERID im Folgenden
Für Relationen und Nodes eben mit n bzw. r
Ich könnte mir vorstellen, dass es ohne besonderen Aufwand möglich wäre, die
Editoren entsprechend zu erweitern. Das Tag sollte nur vergeben werden, wenn
tatsächllich Bedarf für eine externe Refernenz besteht, dann aber einheitlich
von allen Interessenten nutzbar sein.
Vorteil gegenüber dem heutigen Gebastel: Ein Tag für alle und gut.
Vorteil gegenüber der ID direkt: Wird das Objekt geteilt oder verschmolzen,
bleibt das Tag im Gegensatz zur ID erhalten, es überlebt auch eine Änderung
des Datentyps, z.B. von Node auf Way.
Natürlich bleiben noch Fragen. Was passiert, wenn zwei Referenzobjekte
verschmolzen werden.
Man könnte die ERIDs dann mit Trennern aufzählen, aber das führt
möglicherweise zu Datensalat.
Besser wäre es, wenn das neue Objekt eine eigene ERID bekommt oder eine der
ERIDs fortführt. Die Kontinuität ist gegeben,wenn in der letzten Version der
untergehenden ERID ein Tag mit einem Hinweis auf die Folge-ERID gesetzt wird.
Eine Abfrage nach einer Referenz muss also immer nach der ERID mit der
maximalen Versionsnummer suchen. Steht dort ein Verweis auf die neue ERID,
wird im Datenbestand des Nutzers der Verweis entsprechend aktualisiert und er
sucht nach dem Datensatz mit der neuen ERID.
Letzlich also: Extern verlinkte Objekte haben 2 zusätzliche Tags (ERID und
ERID-Version), und damit gut für alle.
Nur für den Fall, dass der Verweis in ein anders Objekt überführt wurde
(Verschmelzung etc.), gibt es in der letzten Version des alten Objekts ein
extra-Tag mit einem Hinweis auf die neue ERID.
Der Vorschlag ist nicht perfekt und nicht zu Ende gedacht. Ich habe das jetzt
nur mal so aus dem Ärmel geschüttelt, aber wenn echtes Interesse an einer
endgültigen Lösung besteht, könnte man ein Proposal im Wiki anlegen und die
Sache von allen Seiten beleuchten.
Gruß, Wolfgang
(der das Problem auch schon hatte)
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bing-Layer mit OSM-API V3
Hallo,
ich habe obiges versucht, die Anzeige des Luftbildes klappt auch mit:
varmap = new ol.Map({
target: 'map',
layers: [ new ol.layer.Tile({ source: new ol.source.BingMaps({
key: mein Key,
imagerySet: 'AerialWithLabels' })
})
],
view: new ol.View({ center:
ol.proj.transform([6.10428,50.76079], 'EPSG:4326', 'EPSG:3857'),
zoom: 11 }),
});
Ich bekomme aber keine controls und keine attribution hin, was ich auch
eingebe.
--
mit freundlichen Grüssen
Wolfgang Wienke
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte auf openstreetmap.de defekt
Hallo Am Donnerstag, 23. Oktober 2014, 19:27:07 schrieb Pascal Neis: Hi, Wolfgang Hinsch schrieb: Von mir aus kann es auskommentiert bleiben. Wer brauchts? die Idee dahinter kennst du? Wir (Frederik ich) hatten eigentlich vor zwei Jahren [1] etwas ähnliches geplant was vor kurzen von jemand anderem unter dem Titel Predicting data curation in OpenStreetMap[2] gezeigt wurde. Also auf Basis der Information WO sich jemand die online Karte ansieht und den Infos z.B. von der Bevölkerungsdichte Statistiken zu generieren wo evtl. eine gute oder schlechte Vollständigkeit vorliegt. [1] http://www.remote.org/frederik/tmp/ilike.pdf [2] https://www.mapbox.com/blog/osm-tracing-candidates/ Diese Idee hätte allgemein ersichtlicher kommuniziert werden sollen. Mein persönlicher Eindruck war, dass dieser Spielkram den Gesamteindruck der Präsentation der Karte ruiniert hat. Vielleicht wäre eine geschicktere Gestaltung mit mehr Abstand zu Gesichtsbüchern eine Abhilfe gewesen. Nebenbei: An der Darstellung von Mapbox überrascht mich nichts, außer vielleicht, dass die Ex-Position von Lummerland ein Hotspot ist :-) Die meisten Informationen hätte ich mir auch so vorstellen können. Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten ist ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte ansieht. Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus meiner Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit aufgelöst die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und Akribie aufgenommen wie der Times Square in New York. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte auf openstreetmap.de defekt
Am Freitag, 24. Oktober 2014, 15:18:06 schrieb Falk Zscheile: Am 24. Oktober 2014 15:02 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten ist ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte ansieht. Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus meiner Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit aufgelöst die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und Akribie aufgenommen wie der Times Square in New York. Aber auch wir haben es mit knappen Ressourcen zu tun (z.B. Rechenkapazität). Man könnte also z.B. Regionen identifizieren, wo man einen höhere Auflösungen rendert ... Wobei wir wieder beim Anbieter von Karten sind, nicht bei OSM. Wir schaffen eine Geodatenbank. Das Rendern ist nicht Sache von OSM, sondern eine von vielen möglichen Anwendungen. Unsere Karte auf der Hauptseite, en wie de, ist vor allem eine Motivationsstütze für die Mapper und nur ganz, ganz nebenbei und unter engen Voraussetzungen ein Angebot für die Öffentlichkeit. Insofern ist es auch logisch und folgerichtig, dass ein Unternehmen wie Mapbox als Datennutzer sich fragt, wo am meisten Nachfrage besteht. Überraschenderweise da, wo die meisten Leute in einer einigermaßen durchtechnisierten Umgebung leben. Das hätte man auch mit dem Finger im Wind erraten können, aber jetzt ist es eben amtlich. So ähnlich wird Geld mit Verkehrszählungen verbraten. Jeder weiß, dass auf der A8 mehr los ist als auf der Dorfstraße von Hinterpfaffenburgstedtwinkelstättenhofen. Aber gezählt ist es doch viel ordentlicher und amtlicher ;-) Gegenden, in denen möglicherweise höher aufgelöst gerendert werden _könnte_, ergeben sich so durch die Datendichte. Allerdings stellt sich die Frage, ob es sinnvoll ist, Gebiete, die schon überproportional erfasst sind, durch weiter aufgelöstes Rendern noch weiter zu pushen, so dass dort irgendwann jeder Krümel erfasst ist, wogegen in anderen Regionen noch die Straßennamen fehlen (Schleswig-Holstein z.B., von Afrika gar nicht zu reden). Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte auf openstreetmap.de defekt
Hi, Am Mittwoch, 22. Oktober 2014, 13:48:17 schrieb Sven Geggus: Sven Geggus li...@fuchsschwanzdomain.de wrote: Ich vermute, dass das mit der kaputten Platte auf dem devserver zusammenhängt auf dem dieses komische iLike OSM läuft. Das wars ich hab das fürs Erste mal im Quellcode auskommentiert. Von mir aus kann es auskommentiert bleiben. Wer brauchts? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Adressenkonvertierung
Hallo, kennt jemand eine Internetseite, die Adressen in GPS-Koordinaten konvertiert? Es geht aber nicht nur um einzelne Adressen, sondern um einige Hundert. -- mit freundlichen Grüssen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einladung und Call for Papers für die Kieler Open Source und Linux Tage
Hallo, nochmal zur Erinnerung: Wir möchten das OSM-Projekt einladen, bei den Kieler Open Source und Linux Tagen, einem mittelgroßen Linux-Event in Kiel, mitzumachen. Hier die Details: Datum: 19. September 2014, ca. 8 - 18 Uhr 20. September 2014, ca. 10 - 18 Uhr (20.9. ist SFD) Ort: Kieler Innovations- und Technologiezentrum (KiTZ), neben der Christian-Albrechts-Universität Am Donnerstag, 15. Mai 2014, 16:42:14 schrieb Wolfgang Hinsch: Hallo, ich habe einen OSM-Stand eingetragen. Wiki-Seite: https://wiki.openstreetmap.org/wiki/KielerLinuxTage Mitstreiter willkommen! Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am Dienstag, den 03.06.2014, 13:39 +0200 schrieb Martin Koppenhoefer: Am 3. Juni 2014 11:30 schrieb Falk Zscheile falk.zsche...@gmail.com: Ich denke, jetzt hat jeder Interessierte genug Argumente, um sich zwischen permessive und yes zu entscheiden, also zwischen quasi öffentlichem Raum und privatrechtlich gewährtem Zugang zu wählen. kurz möchte ich hier doch noch zu bedenken geben, dass yes nicht quasi öffentlich bedeutet, sondern dass es bedeutet, dass der Zugang öffentlich rechtlich gesichert ist. Permissive bedeutet ja, dass man Zugang bekommt, nur eben nicht, dass man auch ein sicheres Anrecht darauf hat. Bei den Aussagen und Folgerungen aus dem BVerfG-Urteil werden wir uns wohl nicht einig werden Jein, ich finde das Urteil persönlich ja durchaus begrüßenswert, nur deckt sich das nicht mit meiner persönlichen Erfahrung der gelebten Realität. Was soll man denn tun, wenn man trotz des Urteils rausgeworfen wird, ggf. von der Polizei, die gerufen wurde, weil man der Aufforderung zu gehen nicht nachkam, bzw. wenn man gar nicht erst eingelassen wird, und physisch vom Wachpersonal am Zugang gehindert wird? Ein Hinweis auf das BVerf.G. Urteil wird da doch nur mit Unverständnis quittiert werden. Selbst wenn man auf Zugang klagen würde und sogar Recht bekäme, dann wäre dieses Recht für den konkreten Fall doch nichts mehr wert, weil seitdem Monate und Jahre vergangen sind. Wie immer ein Problem zwischen Recht haben und Recht bekommen, zusätzlich möglicherweise noch ein Beweisproblem, wenn die Wachleute irgendetwas behaupten. Das sollte man aber nicht mit der Rechtslage vermengen, sonst mappen wir gute, mittlere und böse Einkaufszentren, eventuell noch nach den Dienstplänen der jeweils Verantwortlichen ;-) access versucht, die gesetzlichen Zugangsbestimmungen für Wege abzubilden (Zitat dt. Wiki) Möglicherweise fehlt noch ein tag zwischen - permissive (jemand erlaubt den Zutritt in der Regel, ggf. während der Öffnungszeiten, könnte ihn aber verweigern) und - yes (jeder hat das Recht, dort zu sein, was aber letztlich auch Grenzen hat, siehe Sondernutzung) - obligatory_tolerance (Duldungspflicht, es besteht ein Recht, sich dort aufzuhalten, ggf. innerhalb von Öffnungszeiten, es ist aber nicht so umfassend wie im Fall von yes) ? Damit bekäme man auch Wege in den Griff, die sich zwar im Privateigentum befinden, dennoch aber für den öffentlichen Verkehr freigegeben sein müssen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Hallo, Am Montag, den 02.06.2014, 10:15 +0200 schrieb Bernd Wurst: Hallo. Am 02.06.2014 08:41, schrieb Falk Zscheile: Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die eines oeffentlichen Raumes / Strasse. Mit solch einer Aussage wäre ich in Deutschland vorsichtig. Seit dem Fraport Urteil des Bundesverfassungsgerichts[1] reicht es nicht mehr, dass ein Einkaufszenrum o. ä. in privater Hand ist um nach Belieben Dritte vom Zugang auszuschließen. Jedenfalls wenn diese Dritte ihre Grundrechte auf Meinungsäußerungs- und Versammlungsfreiheit dort ausüben wollen. Wie es in Italien ist, das weiß ich nicht. Jedenfalls sind mit dieser Entscheidung deutlich in Richtung öffentlichen Raum gerückt worden. Ich weiß, dass man access=Grundrechtsausübung nicht mappen kann, aber den Vergleich Bauernhof--Einkaufszentrum wollte ich dann doch hier nicht so stehen lassen. Das Urteil stützt sich maßgeblich auf den Fakt, dass die Fraport AG zu über der Hälfte in Besitz der öffentlichen Hand ist: Von der öffentlichen Hand beherrschte gemischtwirtschaftliche Unternehmen unterliegen ebenso wie im Alleineigentum des Staates stehende öffentliche Unternehmen, die in den Formen des Privatrechts organisiert sind, einer unmittelbaren Grundrechtsbindung. (46) Ja, aber erweitert auf z.B. Einkaufszentren in Randnummer 68 ff. und noch stärker 98 ff. In der abweichenden Meinung eines Verfassungsrichters (111 ff) findet sich ja grade die Einschätzung, dass bei Betrachtung der Einzelanteile jeder öffentliche Anteilseigner nur Minderheitsbeteiligter ist und daher das Urteil hätte anders lauten müssen. Typische Einkaufzentren befinden sich nicht (überwiegend) in Besitz öffentlicher Anteilseigner sondern sind wirklich private Betriebe. Daher lässt sich dieses BVerfG-Urteil hier sicherlich nicht übertragen. Es ist ausdrücklich nicht dafür entschieden, aber u.a. in den Randnummern s.o. gibt die ganz erhebliche Mehrheit (7:1) der Richter hier einen deutlichen Hinweis, dass sie diese Bereiche dem freien Himmel gleichstellt. Die Ausgangslage ist also anders und IMHO doch eher mit einem Hof zu vergleichen. -1 Dass Einkaufszentren ihren Teil zur öffentlichen Infrastruktur (Grundversorgung) beitragen und daher nicht nach Belieben Leute vom Einkauf in den Geschäften ausschließen können halte ich zwar für richtig, aber die Zeiten zu denen geöffnet ist kann der Inhaber durchaus verändern. Er kann ja auch von heut auf morgen einfach zumachen wenn der Hauptmieter pleite ist. +1 Ich gehe zumindest davon aus, dass mit nach Gutdünken verweigert werden kann nicht unbedingt die individuelle Gesichtskontrolle gemeint ist sondern die Tore nach Belieben auch mal geschlossen bleiben können wenn der Eigentümer das so will. Oder sich die Öffnungszeiten verschieben können. Das Recht, diese Fläche zu nutzen, insbesondere als Durchgangsweg, ist nicht öffentlich vorgegeben sondern ist abhängig von dem Willen des Eigentümers, dass da jetzt grade jemand laufen können soll. Er könnte das auch baulich so umgestalten dass ein direktes Durchgehen unattraktiv wird. Bezüglich der Öffnungszeiten +1 Der Betreiber hat sicherlich das Recht, zu entscheiden, wann er seine Flächen allgemein zugänglich machen will. Er wird aber sicher nicht sagen können, Oh nein, da kommt schon wieder X, wir schließen jetzt mal spontan. Selbst dann, wenn X nicht einkaufen, sondern Flugblätter mit seiner Meinung verteilen will. Insofern ein sehr interessantes Urteil. :-) Allerdings wird es jetzt ziemlich OT. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Am Sonntag, den 01.06.2014, 22:27 +0200 schrieb Christian H. Bruhn: am Donnerstag, 29. Mai 2014 um 13:59 schrieb Bernhard Weiskopf: Die zeitliche Zutrittsbeschränkung möchte ich in OSM erfassen, damit Navigationsgeräte nur zu den Öffnungszeiten hier durchleiten. Du kannst es gerne eintragen, aber bitte gehe nicht davon aus, das es auch nur ein Routingprogramm gibt, welches diese Angabe nutzt. Das sollte beim Mappen auch nicht das Kriterium sein. Wenn man kein Ei mappt, kann es auch keine Henne geben - oder so ähnlich ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung
Hallo Am Freitag, den 30.05.2014, 01:59 +0200 schrieb Martin Koppenhoefer: Am 29/mag/2014 um 22:55 schrieb Bernhard Weiskopf bweisk...@gmx.de: Da bei geschlossener Tür niemand und bei offener Tür theoretisch auch andere reinkommen, verwende ich für access die allgemeine Form, hier also: access = no access:conditional = yes @ (Mo-Sa 07:00-20:30; PH off) barrier = gate foot = yes bei einem Einkaufszentrum würde ich statt yes lieber permissive verwenden, weil der Zugang auf Privatgelände normalerweise nicht rechtlich gesichert ist sondern nach Gutdünken verweigert werden kann. Ich bin mir da nicht so ganz sicher. Das Verweigern nach Gutdünken könnte diskriminierend sein. Bei einem Einkaufszentrum gelten andere Regeln als in Wohnzimmer ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rettet die Kleingarten-Wegenamen
Am Montag, den 19.05.2014, 05:50 +0200 schrieb Bernd Wurst: Hallo. Am 19.05.2014 02:14, schrieb Wolfgang Hinsch: Der Auswerter für die Navigation kann nur alle Wege im Kleingarten rausschmeißen oder mit mit einem Auswahlmenü für 20 Wege kommen, weil die Blumennamen so gerne vergeben werden. Deinen offiziellen Wegnamen im Kleingarten findet in beiden Fällen kaum einer. Wenn du es algorithmisch schaffst, die Wege im Kleingarten zu identifizieren und gezielt aus dem Suchindex rauszuschmeißen, dann sollte es auch gehen die Straßennamen um die Angabe der Kleingartenanlage zu erweitern (Rosenstraße, Kleingartenanlage XY). Und schon hast du den Nachteil zu einem echten Vorteil gewandelt. Grade die Kleingartensiedlungen die groß genug für Straßennamen sind, haben durchaus auch mal mehrere Eingänge und damit macht es Sinn, gleich das richtige Ziel anzusteuern. Darin sehe ich nicht das Problem. Das Problem besteht darin, dass 1. private Wegebezeichnungen auch außerhalb von Kleingärten auftreten können und 2. aus den Daten nicht erkennbar/berechenbar/herleitbar ist, ob der Weg, der sich in dem Park oder der Kleingartenanlage oder wasauchimmer befindet, nun einen offiziellen Namen hat oder nicht. Denn auch in Kleingartenanlagen gibt es stellenweise offizielle Wegebezeichnungen. Praktische Folge: Der (z.B.) Taxifahrer bekommt entweder eine Hasskappe, weil er den Namen in seinem OSM-Navi nicht findet, oder weil er den Namen 10x findet. Im Falle des offiziellen Namens im Kleingartengebiet mit Zusatz Kglv xx, nicht unterscheidbar von den wirklich lokalen Kleingartennamen. In beiden Fällen wird er OSM entsorgen. Ich bin schon konkret darauf angesprochen worden, dass die Daten für eine professionelle Adresssuche unbrauchbar sind. Das ist offensichtlich von der Mehrheit bei OSM so gewollt. Die Straßenlistenauswertung ist übrigens auch recht spaßig, wenn die Verwaltung 132 Straßennamen kennt, die bei OSM fehlen und in OSM 621 Namen sind, die der Verwaltung fehlen. Ca. 90% dürften Kleingartennamen sein, der Rest falsche Schreibweisen, ein Bruchteil Fehler der Verwaltung oder von OSM. Vielleicht könnte man wenigstens aus der Straßenlistenauswertung alle Namen in Kleingartengebieten rausschmeißen, dann kann man wieder vernünftig manuell vergleichen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten
Am Montag, den 19.05.2014, 09:37 +0200 schrieb Falk Zscheile: Als Lösung schlagen einige hier vor das vorhandene Tagginschema so zu nutzen, dass Irrtümer weitgehend ausgeschlossen werden, insbesondere auf der Auswertungsseite zu schauen, ob man dort nicht etwas verbessern kann, bevor man daran geht zu sagen name bedeutet etwas anderes als name Wie gesagt, den offiziellen Namen im Kleingartengelände kann keine Auswertung vom Phantasienamen unterscheiden. Und es gibt auch in anderen Zusammenhängen privat benannte Wege. Wenn es wirklich keine Lösung auf der Auswertungsseite gibt, dann könnte ich mir auch vorstellen, dass man für nicht amtlich registrierte Wege ein name=value und ein official_name=nonexistent vergibt, obwohl das auch gegen die OSM-Konvention ist und bei den Kartenrenderern vielleicht zu Problemen führt. Es handelt sich bei nonexistent ja schließlich nicht um einen echten Namen, sondern um eine technische Interpretationsregel. Jedenfalls würde ich mich über mehr Beiträge freuen, die über Lösungen nachdenken, die nicht die Inhaltsdefinition von name=value berühren. Oder anders ausgedrückt, mit Zusatztags beschreiben, was name=value definiert, damit die Mapnik-Karte nicht berührt wird. Obwohl man auch loc_name rendern könnte, wenn name fehlt. ;-) Ich vermute mal, dass das für die meisten der Hauptgrund ist. official_name ist vergeben und sollte nicht umdefiniert werden. loc_name statt name passt IMO, soll aber nicht benutzt werden. source:name=inofficial? name_operator=local? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten
Am Montag, den 19.05.2014, 15:30 +0200 schrieb Martin Koppenhoefer: Es gibt auch privat benannte Wege, wo dieser Name amtlich und offiziell ist, bsp. Inge-Beisheim-Platz in Berlin (super zentral gelegen): http://www.openstreetmap.org/?mlat=52.51067mlon=13.37574#map=19/52.51067/13.37574 http://de.wikipedia.org/wiki/Otto_Beisheim Hintergrund: http://www.berlin.de/ba-mitte/bezirk/gedenken/inge_beisheim.html Da kann sich jeder selbst eine Meinung bilden, nur weil die Kleingärtner weniger Geld haben, und deren Namen daher nicht offiziell werden würde ich die nicht gleich abwerten ;-) Stop! Ich will keine Kleingärtner oder ihre Straßennamen abwerten, ich möchte nur unterscheiden können zwischen ist amtlich oder ist nicht amtlich. U.a. weil ist amtlich meistens, wenn auch nicht immer ist eindeutig in der Administration, in (fast) jedem Fall aber ist in der Liste der Administration. Wer es für wichtig hält, kann ja taggen, ob der Name privat vergeben und amtlich anerkannt oder amtlich vergeben und privat anerkannt wurde ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wegenamen in Kleingärten
Hallo, in vielen Kleingartenanlagen vergeben die Kleingärtner Wegenamen nach eigenem Ermessen. Das führt dann dazu, dass z.B. der Dahlienweg in HH 10x oder öfter existiert, davon aber nur 1x offiziell von der Stadt benannt und in öffentlichen Verzeichnissen vorhanden. Wenn das Tag name für diese Wege benutzt wird, macht das die Navigation nach OSM-Daten unbrauchbar, für jeden Navi-Benutzer wie für Rettungsdienste, Taxi etc. Ich würde vorschlagen, in Fällen, in denen der Name nicht offiziell ist (es gibt auch offizielle Namen), das Tag loc_name zu benutzen, da der Namen nur lokal im Bereich der jeweiligen Gartenanlage gilt. Name sollte dann nicht vergeben werden. Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber nicht in der Karte. Das ist einerseits Mapping für den Renderer versus Mapping für den Router, andererseits On The Ground steht der Name dran, aber er ist On The Ground ebenfalls nur gültig im lokalen Bereich, nicht etwa gemeindeweit. Vielleicht könnte man durch ein Ticket erreichen, dass bei fehlendem Name-Tag an Verkehrswegen auf ein loc_name-Tag geprüft und dieses in Z17-19 angezeigt wird. Meinungen? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rettet die Kleingarten-Wegenamen
Am Sonntag, den 18.05.2014, 21:45 +0200 schrieb Jan Tappenbeck: Hallo Wolfgang, ich weiß einfach nicht, warum Du immer wieder gegen die Namen in den Kleingärten bist. Wenn es Dich für Deine Karten stört, dann rechne diese doch mit einer Datenbankfunktion raus Blödsinn. Du solltest eigentlich wissen, dass ich das auch ohne deinen Rat machen würde, wenn es mir darum ginge. Ich bin nicht gegen Namen in Kleingärten, sondern will nur die Phantasienamen örtlicher Kleingärtner (und Vergüngungsparks etc.) eindeutiger von den offiziellen Namen unterscheiden können. Im Moment sieht es so aus, dass in Aufbereitungen für das Routing alle Namen innerhalb Kleingärten entweder rausgeschmissen werden müssen, egal ob sie offiziell sind oder nicht, oder es kommt zu umfangreichen Auswahllisten. Wenn die Kleingärten die gleiche PLZ haben, hilft auch eine Auswahlliste nicht weiter, kennt man die PLZ nicht, ist man aufgeschmissen. Ein Taxifahrer schmeißt nach so einer Erfahrung OSM-Karten sofort über Bord. Das halte ich für unbefriedigend. Solange nicht anderer Missbrauch des Namen-Tags bereinigt ist sollten man sich an den Laubenpiebern nicht vergreifen. ?? Möchte nur die Benennung der Bushaltestellen am Hamburger ZOB anführen. Die ersten 10-20 Straßen in alphabetischer Reihenfolge für HH sind die Haltestellen dort. Wenn es dich stört (und falsch ist), ändere es. Nicht meine Baustelle. Und OT. Die Frage nach der Benennung der offiziellen Straßennamen ist wer diese durchführt. Bei städtischen Straßen ist das zwangsläufig die öffentliche Verwaltung. Wie ich schon in dem Posting im Forum geschrieben habe (http://forum.openstreetmap.org/viewtopic.php?id=22750 - hier ging es mal wieder um die KLG-Parzellennummern die einige stört und nun gnadenlos auf die schnelle und ohne offizielle Abstimmung umgestellt wurden. Wo sind die Wächter über die Tags und Massenedits??) gibt es in der offiziellen Liste der Hansestadt Lübeck Wege in den Kleingärten (Beispiel Parade 1-7 u.a.http://www.openstreetmap.org/?way=35050005) die ich nur durch Zufall in einem Kleingartengelände gefunden habe. Genau. Der Auswerter für die Navigation kann nur alle Wege im Kleingarten rausschmeißen oder mit mit einem Auswahlmenü für 20 Wege kommen, weil die Blumennamen so gerne vergeben werden. Deinen offiziellen Wegnamen im Kleingarten findet in beiden Fällen kaum einer. Was ist mit den Wegen im Forst und im Feld - denen kann ich nicht ansehen, ob diese offiziell sind und dennoch schreibe ich diese in OSM rein. Genauso verhält es sich mit den Klg-Namen. Auf den ersten Blick kannst du es nicht sehen, richtig. Schreib ihn ruhig rein. Wenn weitere Erhebungen ergeben, dass er nicht offiziell ist, kann er immer noch auf ein passenderes *_name-tag verschoben werden. Ich könnte übrigens auf meinem Grundstück meine Wege mit Mönckebergstraße, Heidenkampsweg oder ähnlichem benennen, einen Pfahl reinrammen und mit einem Holzschild beschriften. Anschließend On The Ground mappen. Viel Spaß. Was machen wir eigentlich, wenn tatsächlich irgendwelche Spaßvögel auf so eine Idee kommen? Das klingt jetzt vielleicht unwahrscheinlich, aber dem einen oder anderen Oberförster würde ich so was schon zutrauen. Wenn es einem um die Mehrfachnennung von Namen geht, dann gibt es sicherlich auch Orte, entstanden aus Zusammenlegungen, wo die Dorfstraße mehrfach vorkommt. Ich weiß, dass in Meck-Pomm wegen einer Zusammenlegung von Gemeinden ganz genau die Dorfstraße umbenannt wurde, um doppelte Straßennamen zu vermeiden. In einigen Ländern ist das sogar im Gesetz so vorgesehen, lt. entspr. Postings hier. Ob das im Meck-Pomm gesetzlich erzwungen wird, entzieht sich meiner Kenntnis. Vernünftig ist es auf jeden Fall. Auf der anderen Seite ist OSM doch ein Projekt das für die breite Masse und will sich von den anderen abheben. Genau. Im Moment hebt es sich dadurch von anderen ab, dass ich mit meinem Nüvi mit der Garmin-Karte eine Rosenstraße in Hamburg finde. Mit der OSM-Karte finde ich mit demselben Gerät 9 verschiedene Rosenstraßen. Ein echtes Alleinstellungsmerkmal. Jetzt frage mal, warum kein Autohersteller OSM-Karten in sein Navi einbaut. Jeder hat andere Interessen - den einen interessieren die Wege und den anderen die anderen. Bei einem Besuch bei den Kleingärtnern war man begeistert das mal einer die Wege alle erfaßt hat. Wieder nicht zuende gedacht. Mapnik könnte bei fehlendem name-Tag auf das nächstliegende ausweichen. Ich finde es schon sch... genug das durch den o.g. Massenedit plötzlich all die mühsam erfaßten Parzellennummern rausradiert wurden. Das steht noch auf einem anderen Blatt und wird bei uns Thema auf dem nächsten Stammtisch sein.. eben, anderes Blatt. Also Rettet die Kleingarten-Wegenamen Unsinn, die will niemand rausschmeißen. Oder sollte sich das nur auf Mapnik beziehen (für den Renderer... ?) Die Mehrheit bei OSM geht im Moment den Weg, das Name-Tag zu verwenden. Die
Re: [Talk-de] Wegenamen in Kleingärten
Am Sonntag, den 18.05.2014, 22:03 +0200 schrieb Mark Obrembalski: On 18.05.2014 21:17, Johannes wrote: Sehe ich genauso. Wenn etwas keinen amtlichen Namen hat gehört es in loc_name rein und name entfernt. Quatsch! Kein Laden, keine Kneipe hat einen amtlichen Namen. Dann mach mal einen Laden ode eine Kneipe auf. Du wirst dich wundern, in wie viele Verzeichnisse, Anmeldungen, Lizenzen, Genehmigungen ... du den Namen eintragen musst. Und zwar immer denselben. Aussuchen darfst du ihn dir selbst, ja. Aber anschließend ist er deine Firma. Kannst du jederzeit ändern. Aber du wirst dich wundern, in wie viele Verzeichnisse ... ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rettet die Kleingarten-Wegenamen
Hi, ps: Am Sonntag, den 18.05.2014, 21:45 +0200 schrieb Jan Tappenbeck: Ich finde es schon sch... genug das durch den o.g. Massenedit plötzlich all die mühsam erfaßten Parzellennummern rausradiert wurden. Das steht noch auf einem anderen Blatt und wird bei uns Thema auf dem nächsten Stammtisch sein.. :1,$ s/rausradiert/auf das ref-Tag verschoben/g Rausradiert wurden sie aus der Mapnik-Karte, nicht aus den Daten. In Hamburg hat jemand in Alsternähe sämtliche landuse=residential rausradiert. Aus den Daten rausvandaliert, nicht verschoben. Weil sie eine Zeit lang in der Mapnik-Darstellung Vorrang vor seinem leisure=garden hatten. War ihm nicht grün genug. Das Argument ist im Grunde das Gleiche. Manchmal würde ich die Mapnik-Karte am liebsten ganz abschalten... ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einladung und Call for Papers für die Kieler Open Source und Linux Tage
Hallo, Am Dienstag, den 13.05.2014, 15:54 +0200 schrieb Michael Reichert: Hallo, das kam gerade bei uns vom Wochennotizteam. Wer möchte sicv drum kümmern. ich habe einen OSM-Stand eingetragen. Wiki-Seite: https://wiki.openstreetmap.org/wiki/KielerLinuxTage Mitstreiter willkommen! Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxheight=none
Am Montag, den 31.03.2014, 09:58 +0200 schrieb Martin Koppenhoefer: Am 31. März 2014 09:50 schrieb Florian Lohoff f...@zz.de: Auf Straßen an denen keine Brücke drüber ist gehört IMHO nix dran. es sind nicht nur Brücken, die ggf. das zur Verfügung stehende Lichtraumprofil einschränken, z.B. Allee-Bäume, Straßenbahnoberleitungen und Beleuchtungskörper / Ampeln und Schilderbrücken können Hindernisse darstellen. Es sollte eine Obergrenze geben für maxheight, z.B. 4,50. Sondertransporte fahren sowieso nicht nach OSM, auch nicht nach irgendwelchen anderen Quellen, sondern erkunden die Strecke zeitnah selbst. Es gibt sonst zu viele Überraschungen durch provisorische Brücken, Leitungsüberführungen etc. pp., wo der Transport hängen bleiben könnte. Übrigens sind Sondertransporte oft nicht nur extrem hoch, sondern auch extrem breit oder lang. Für die Breite könnte man notfalls noch mappen, aber wie wollen wir ermitteln, mit welcher Länge man da noch rumkommen könnte bzw. welchen Balkon man abbauen müsste? ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Noch eine Wappenkarte
Hallo Tim, Am Samstag, den 29.03.2014, 15:05 +0100 schrieb Kolossos: Hallo, das Berliner Hackweekend hatte ich mal genutzt die Idee der Wappenkarte auf Wikidata-Basis aufzugreifen und in meine Koordinatenextraktion der Wikipedia zu integrieren: http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=deuselang=dezoom=6lat=50.08584lon=6.63143coats=yes Das sind jetzt 42.000 Wappen bei 3.5 Mio Artikeln, viel Spaß beim stöbern. ich würde vorschlagen, dass ihr euch mal überlegt, wie man möglichst einfach melden kann, dass man Fehler gefunden hat. Ich finde ca. alle 20 Sekunden einen falsch verlinkten Artikel. Es müsste da eine einfache Möglichkeit geben anzuzeigen, dass das Objekt hier nicht ist. Häufig kennt man das Objekt gar nicht und weiß nur, dass es jedenfalls nicht an der eingetragenen Stelle sein kann. Also eine Meldungsmöglichkeit ohne eine Master-Arbeit in Wiki-Web-Bearbeitung und Registrierung hier/Registrierung da etc pp. Etwa so wie die Notes auf OSM. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postalische Bezeichnung (addr:place -)
Hallo Andreas, Am Freitag, den 28.03.2014, 07:00 +0100 schrieb Andreas Neumann: Fehler beim Überprüfen der Signatur Fehler bei der Syntaxanalyse --ms010607030705050801080908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fehler beim Überprüfen der Signatur Hash: SHA1 gpg: ASCII-Hülle: Version: GnuPG v1.4.14 (GNU/Linux) gpg: ASCII-Hülle: Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ gpg: ASCII-Hülle: gpg: Ursprünglicher Dateiname='' gpg: Falsch aufgebaute Prüfsumme gpg: Keine Signatur gefunden gpg: quoted printable Zeichen in der ASCII-Hülle gefunden - möglicherweise war ein fehlerhafter Email-Transporter(MTA) die Ursache gpg: Die Signatur konnte nicht überprüft werden. Denken Sie daran, daß die Datei mit der Signatur (.sig oder .asc) als erste in der Kommandozeile stehen sollte. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Einerseits w=E4re addr:place wohl das sinnvollere. Andererseits werten viele Programme nur addr:street aus und wie du es ausschreibst w=E4re es einer Stra=DFe gleichzusetzen. Jetzt ist die Frage, ob du es syntaktisch korrekt taggen willst oder f=FCr die Auswerter. MfG Andreas so kommt deine Mail bei mir an. (Evolution 3.2.3) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hervorheben von POIs auf eignen Karten
Am 27.03.2014 09:26, schrieb Manuel Reimer: Wolfgang Wienke wo_wienke at gmx.net writes: Du kannst dir via Overpass API die Koordinaten für die Pins aus dem OSM-Datenbestand abholen. So kann man wunderbar einzelne POIs und auch ganze Wege mit OpenLayers-Mitteln hervorheben. Das heißt aber dann doch, dass ich die POIs wieder selbst über Pins setzen muss!?? Wie sonst? Du holst dir die Koordinaten ab (bei einem meiner Projekte mache ich das automatisch einmal am Tag in der Nacht via Cron-Job). Dann bleibt es dir überlassen wie du die erhaltenen Daten nachbearbeitest. Du könntest z.B. sowas damit füttern: http://openlayers.org/dev/examples/dynamic-text-layer.html Oder nach der Anleitung vorgehen: http://wiki.openstreetmap.org/wiki/Openlayers_POI_layer_example Grundlegende Programmierkenntnisse sind natürlich nötig um aus den OSM-Daten das für OpenLayers nötige Eingabeformat automatisiert zu erzeugen. Ok, danke, damit sehe ich, welcher Weg möglich wäre. -- mit freundlichen Grüssen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hervorheben von POIs auf eignen Karten
Am 25.03.2014 10:09, schrieb Manuel Reimer: Wolfgang Wienke wo_wienke at gmx.net writes: gibt es eine Möglichkeit auf eingebundenen OSM-Karten (z.B. gemäß Beisp openlayers.org) eine bestimmte Art von POIs z.B. durch einen pushpin automatisch hervorzuheben, OHNE jeweils solche pushpins mit Koordinaten separat an der Position einzublenden? Du kannst dir via Overpass API die Koordinaten für die Pins aus dem OSM-Datenbestand abholen. So kann man wunderbar einzelne POIs und auch ganze Wege mit OpenLayers-Mitteln hervorheben. Das heißt aber dann doch, dass ich die POIs wieder selbst über Pins setzen muss!?? -- mit freundlichen Grüssen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hervorheben von POIs auf eignen Karten
Hallo, gibt es eine Möglichkeit auf eingebundenen OSM-Karten (z.B. gemäß Beisp openlayers.org) eine bestimmte Art von POIs z.B. durch einen pushpin automatisch hervorzuheben, OHNE jeweils solche pushpins mit Koordinaten separat an der Position einzublenden? -- mit freundlichen Grüssen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Linienobjekt aus OSM Datenbank als GPX-Datei exportieren
Hallo, wo finde ich die Möglichkeit oder die Doku obiges möglichst ohne Script (kompliziert -:( ) auszuführen? Die ID der Relation kenne ich! -- mit freundlichen Grüssen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Visualisierung von (notwendigen) Postdienstleistungen
Hallo, http://www.flosm.de/html/POI-Karte.html zeigt auch Briefkästen und Postfilialen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?
Am Dienstag, den 04.03.2014, 14:33 +0100 schrieb Martin Koppenhoefer: Am 4. März 2014 14:26 schrieb chris66 chris66...@gmx.de: Im Prinzip ja, leider sind die Multipolygon-Relationen vollkommen unberechenbar und interpretieren teilweise aus eigener Kraft, dass ein tag nicht sein soll wo es ist (z.B. wenn man ein Loch hat, welches die tags des Multipolygons hat, dann wird das als Loch gerendert und die tags des Objekts werden offenbar weggeworfen, Beispiel: http://www.openstreetmap.org/way/263521637 auch ein Hinzufügen von building:part=yes hat leider nichts geändert, es bleibt ein Loch im Rendering). Das ist nie und nimmer ein valides MP. :-) Wozu soll es überhaupt dienen, wenn das Gebäude keine Löcher hat? es sind mehrere Gebäude, die zu einem zusammenkleben bzw. wo eines von einem anderen umschlossen ist, unterschiedliche Stockwerkshöhen und ggf. Typologie etc., macht also durchaus Sinn, wenn man das aufteilt. Abgesehen von diesem Beispiel dürfte es auch noch andere Fäll geben, wo etwas um etwas gleiches (im Sinne von bestimmten OSM-tags) herum liegt, also ein Teil eingeschlossen ist, aber trotzdem nicht als Loch gerendert werden soll. Also wenn ich das MP richtig verstanden habe, dann gibt es 2 Möglichkeiten: entweder mehrere Outer liegen nebeneinander, ohne sich zu berühren, oder im Outer liegt ein Inner, dass dann ein Loch bildet. Erst innerhalb des Lochs kann es wieder ein Outer geben, dass ein Loch im Loch darstellt und damit wieder zur Fläche gehört. Ein Outer direkt im Outer ist AFAIK ein Fehler, sowohl nach OSM-Definition als auch nach postgis. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]
Hallo Markus, Am Freitag, den 28.02.2014, 11:59 +0100 schrieb Markus: Manuelle Ergänzung Am Freitag, den 28.02.2014, 08:50 schrieb Michael Kugelmann: Am Freitag, den 28.02.2014, 00:08 schrieb Bernhard Weiskopf: /Manuelle Ergänzung Hallo Bernd, Ich will für die Benutzer taggen :-) Das ist m.E. eine gute Einstellung. Bei allem was wir tun ist die Frage wichtig: - wozu? - wem nützt es? - wie kann ich es am besten umsetzen? soweit +1 Hallo Michael, wer sind die user Das ist eine wesentliche Frage. Nur so kann ich von ihnen erfahren, was sie gerne hätten, und mir dann überlegen, wie man das gut umsetzen könnte. Die richtige Denkweise wäre richtig gibt es immer nur in Bezug auf etwas. Für OSM ist der Bezug m.E. immer die Benutzer :-) OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben. OSM ist eine *Weltkarte*. /Dafür/ werden Geo-Daten erhoben und in einer DB abgelegt. *Karte und Daten* ist eine systemische Einheit. Das erfordert eine gezielte Zusammenarbeit zwischen denen die Daten sammeln und denen die sie anzeigen, bzw denen die die Karte nutzen :-) Nein, genau das ist nicht so. Die osm.org (Mapnik-Karten) - Darstellung ist /eine/ mögliche Interpretation der Daten, die noch dazu eben /nicht/ ein Aushängeschild oder eine Marke darstellen soll. Primärzweck ist, die Mapper, insbesondere Anfänger, zu motivieren und eine großen Anteil von viel benutzen Tags anzuzeigen. Es gibt noch einen ganzen Haufen anderer Karten. Letztens ist jede Karte nur eine Auswahl der Daten, und jede Karte hat ihr eigenes Thema. Deshalb sollten die Tags so genau und sinnvoll wie sachlich möglich gesetzt werden - im Prinzip ohne Rücksicht auf die Mapnik-Karte. Das heißt aber nicht, dass damit jetzt jeder seine Tags möglichst individuell gestalten sollte. Sinnvoll ist natürlich, nach dem Wiki vorzugehen, soweit die Tags für die Objekte sinnvoll und richtig sind. Damit wird der größte Teil der Tags auch in der Mapnik-Karte dargestellt werden. Sollte das aber nicht so sein, sollte - soweit sinnvoll - der Stil der Karte und nicht das Mappen verändert werden. eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik Mapnik ist /die Karte/ :-) Eben nicht. Selbstverständlich /kann/ man aus den Daten auch noch viele und tolle Spezialanwendungen machen: Spezialkarten, Routing, Statistik, ... Und selbstverständlich brauchen Anwendungen sinnvolle Datenschemen als Grundlage. Deshalb sind Daten(-Struktur) immer als Einheit mit der geplanten Anwendung zu betrachten und zu verstehen - und zu entwickeln und zu verbessern. Stil Ein einheitliches Erscheinungsbild hilft OSM als Marke zu etablieren. Dabei sind Ziele zu erfüllen wie schnelles Orientieren und Erkennen, schnelles präzises Finden, sinnvolle Verknüpfung von Information, etc. Iterativ und gemeinsam ist das Optimum zu finden. Dabei kann man gute Fremd-Beispiele nutzen und die besten Ideen daraus übernehmen. Es macht aber m.E. wenig Sinn, diese nur deshalb nachzuahmen, weil man sie gewohnt ist. Bei den iterativen Suchprozessen macht es auch Sinn, immer mal wieder etwas ganz anderes auszuprobieren - um die gefundenen Essenzen dann synergetisch in das Produkt zu integrieren. Es macht aber m.E. wenig Sinn, viele Skins zu haben. Ich glaube, du denkst jetzt zu sehr an den Namen OpenStreetMap. Damit hat es zwar angefangen, aber der Name trifft heute nicht mehr zu. Eigentlich müsste das ganze Ding jetzt OpenGeoBase heißen, nur ist der Name nachträglich kaum noch zu ändern. Will sagen: Wir machen überhaupt keine Karten. Wir machen /nur/ eine Datenbank. Unsere Karten sind lediglich Beispiele und Motivationselemente, sonst nichts. Interpretieren kann das jeder, wie er will und in welchem Stil er Lust hat. Insofern sind unterschiedliche Skins selbstverständlich. Sinnvolles Taggen im Stile des Wiki, wenn es passt, ja. Uminterpretieren, verbiegen, absichtliche Unschärfen, nicht so ganz passende Tags nehmen, damit etwas dargestellt wird = Taggen für einen bestimmten Stil eines einzelnen Renderers = Wertlosigkeit der Daten für andere Anwendungen und keinerlei Weiterentwicklung = nein. Aus Prinzip andere Tags benutzen, obwohl es geeignete gibt = taggen gegen den Renderer = auch nein. - - - - Zur Frage nach dem Rendering von Gewann-Namen: Namen von Gegenden helfen bei der Orientierung. Solche Namen auf der Karte zu haben ist ein sinnvolles Anliegen. Richtig, aber Aufgabe der Renderer = Stil anpassen. Solange wir dafür kein brauchbares Konzept haben, werden Benutzer immer wieder versuchen, die Namen irgendwie so in die DB zu schreiben /damit/ sie gerendert werden. Dann werden die entweder korrigiert oder gelöscht. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?
Am Freitag, den 28.02.2014, 14:27 +0100 schrieb Martin Koppenhoefer: s.o., die Schneisen sind auch Teil des Käfertaler Walds (obwohl nicht landuse=forest). Das ist wieder so eine Sache der Definition. Ich würde dazu tendieren, die Schneise als funktionales Sicherheits-Element des Waldes zu sehen und damit im landuse=forest einzuschließen. Der Notausgang im Supermarkt würde auch als Element des Supermarktes bezeichnet werden, obwohl man auf dem Weg nichts einkaufen kann. Als Verkaufsfläche dagegen fiele er raus. Wenn man zusätzlich landcover=forest mappt, bin ich aber bei dir, die Schneise nicht im landcover zu lassen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am Freitag, den 28.02.2014, 15:46 +0100 schrieb bkmap: Die Auswerter sehen aber keinen Unterschied, es sei denn, der Tag ist an eine Fläche gebunden. Dann könnte man Rückschlüsse aus der Größe ziehen. +1 Insofern kann es sinnvoll sein, Gebiete mit einheitlichem Namen als Polygone oder bei großen Gebieten wie dem Schwarzwald als Multipolygone zur Namenskennzeichnung zu mappen. Das MP kann ja aus bereits vorhandenen Polygonen zusammengesetzt werden. Dann kann der Renderer erkennen, in welches Gebiet der Namen gehört und entscheiden, wie prominent und auseinander gezogen er dargestellt werden soll. Das ist nicht nur für den Renderer, sondern für jede Auswertung sinnvoll, die sich mit irgendwelchen Regionalbegriffen, die nicht mit Verwaltungseinheiten identisch sind, auseinander setzt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?
Am Freitag, den 28.02.2014, 16:34 +0100 schrieb Martin Koppenhoefer: Am 28/feb/2014 um 16:00 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Das ist wieder so eine Sache der Definition. Ich würde dazu tendieren, die Schneise als funktionales Sicherheits-Element des Waldes zu sehen und damit im landuse=forest einzuschließen. Der Notausgang im Supermarkt würde auch als Element des Supermarktes bezeichnet werden, obwohl man auf dem Weg nichts einkaufen kann. Als Verkaufsfläche dagegen fiele er raus. Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt aber im Schwarzwald. Ich würde daher eher einen neuen Key für Gebiete vorschlagen, sowas wie georegion=forest name=* Bei Elementen, die nichts mit dem Wald zu tun haben, sind wir uns einig. oder evtl. auch location anstatt georegion od. toponym od. natural oder... Multipolygonrelation ist bei so großen Gebieten allerdings problematisch aus div. Gründen, zB Auffinden, dann fehleranfälligkeit (nur ein Loch macht sie schon ungültig) und die schiere Anzahl an members (OK, könnte man verschachteln), etc Gelegentlich kam hier schon ein neuer Relationstyp ins Spiel, ein Gebiet zu definieren über einen Haufen von quasi zufälligen Objekten, die noch drin liegen (oder evtl auch role für nicht mehr drin), woraus man dann später ein ungefähres Gebiet errechnen kann. Man könnte vielleicht so eine Art Tangentenpolygon erfinden. Eine Figur, die aus Polygonen, einfachen Ways und Punkten besteht. Sie wird dadurch definiert, dass man eine Linie berechnet, die als Tangente um alle Elemente außen herumläuft. Außen wird definiert als die andere Seite der Elemente gegenüber dem geografischen Mittelpunkt. Bei Polygonen und Wegen wird die Figur berechnet, indem zwischen 2 Elementen immer eine Linie genutzt wird, die die kürzeste Strecke beschreibt, die 2 Punkte der beiden Elemente verbindet, die aber keine Linie der Elemente schneidet (außen anliegt). Bei Punkten geht die Figur genau durch den Punkt. Die Reihenfolge ist von Bedeutung. Das hat den Vorteil, dass ein Gebiet wie z.B. die Alpen beschrieben werden kann, ohne einen Riesenhaufen von verschachtelten Multipolygonen zu erzeugen. Es werden nur ein paar signifikante Elemente benutzt, die am Rand liegen. Für die Alpen könnte das z.B. ein Tangentenpolygon aus Nizza - Turin - Como - Verona - Belluno - Llubljana - Wien - Salzburg - Bregenz - Luzern - Genf - Genoble - Nizza sein (Vorsicht, nur als Beispiel und GANZ grob). Wobei ich festgestellt habe, dass es sinnvoll sein könnte, mit outer und inner zu arbeiten, wobei die Tangente außen am inner vorbeiläuft, es also dazugehört, und innen am outer, es also ausschließt. Damit sollten große Gebiete ohne all zu viel zusätzliche Daten erfassbar sein. So 100% trennscharf ist so eine Linie ohnehin nicht. Nur so eine Idee... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am Freitag, den 28.02.2014, 17:35 +0100 schrieb Bernhard Weiskopf: Namen für Gebiete an eine Fläche binden halte ich für absolut notwendig. Schließlich soll der Goetheplatz nur in den großen Zoomstufen angezeigt werden, der Schwarzwald dagegen nur in mittleren, aber nicht mehr in großen. Je nach Flächeninhalt muss man minimale und maximale Zoomstufe für das Anzeigen festlegen. (Wenn wir eines Tages bis Zoom = 25 kommen, soll Goetheplatz auch nicht mehr angezeigt werden.) Das müsste so ähnlich auch bereits mit anderen Objekten, wie Ländernamen, Städtenamen usw. umgesetzt sein. Jetzt vermischst du wieder die Teilnehmer. Der Mapper legt nur fest, was zum Schwarzwald und was zum Götheplatz gehört. In welcher Zoomstufe welcher Renderer was anzeigt, muss er - und nur er - selbst entscheiden. Wenn ich eine Karte von X-Dorf mache und das mitten im Schwarzwald liegt, würde ich Schwarzwald nicht mehr rendern, sondern auf den Kartentitel schreiben: X-Dorf im Schwarzwald. Wenn das Dorf aber am Rande des Schwarzwaldes liegt, und der Schwarzwald die linke Kartenhälfte ausmacht, würde der Begriff gerendert, unabhängig vom Maßstab oder Zoomlevel. Versuche doch einmal, eine Karte selbst zu machen. Beschäftige dich z.B. mit Maperitive. Dann kannst du auch selbst festlegen, welche Bezeichnung wo zu stehen hat. Kann ja erst mal der Ortsplan von X-Dorf sein ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planetarium
Am Sonntag, den 23.02.2014, 21:47 +0100 schrieb Johannes: Bisher klingt es so als ob alle mit amenity=planetarium zufrieden wären. Bisher gibt es also keinen richtigen Konsens für einen solchen Tag. Sollte man dafür ein Proposal schreiben? Hat das schon mal jemand gemacht, bzw. möchte das jemand freiwillig machen? Wie richtig willst du denn den Konsens? Eine kurze Frage noch auf tagging, und dann ab damit ins Wiki, falls keine Proteste kommen. Für ein einzelnes Tag, für das eine Lösung gefunden wurde, mit der alle leben können, sollte man den Aufwand nicht übertreiben. Die 5-10 Stimmen, die da noch kommen könnten, fallen bei 1,5 Mio registrierten Usern nicht wirklich ins Gewicht. Falls das Tag später sich doch noch ändern sollte, kann man die paar Planetarien notfalls umtaggen. Wenn über jedes einzelne Tag monatelang diskutiert und abgestimmt wird, hat Tante G den letzten Wanderpfad Jahrzehnte vor uns erfasst. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planetarium
Am Montag, den 24.02.2014, 13:10 +0100 schrieb Johannes: Wenn das bei einem einzelnem Tag nicht üblich ist und man anderssprachige nicht fragen braucht, ist's ja in Ordnung. Die anderssprachigen erreichst du auf Tagging. Englisch zu fragen, reicht. Wir können ja nicht alle Sprachen abklappern ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planetarium
Am Sonntag, den 23.02.2014, 12:27 +0100 schrieb Martin Koppenhoefer: Am 23/feb/2014 um 12:14 schrieb Johannes jotpe@gmail.com: Wenn man sich nicht einig werden kann, ob ein Planetarium ein Theater oder ein Museum ist, dann scheint amenity=planetarium oder man_made=planetarium eine der besseren Ideen zu sein. +1, Kino hat ja auch einen eigenen Tag und wird nicht als Theater getaggt, Museum ist es sicher nicht. Und ich sehe es immer noch als technisches Museum ;-) +1 für amenity=planetarium auch von mir. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planetarium
Am Samstag, den 22.02.2014, 21:07 +0100 schrieb Martin Koppenhoefer: Am 22. Februar 2014 20:42 schrieb Johannes jotpe@gmail.com: Ein Vorschlag von mir: tourism=museum und museum=planetarium museum als key gibt es ca 160 mal. planetarium ist unter den values noch nicht zu finden, dafür aber genauere Infos über das Museum, wie railway oder art. Passt also vom Schema gut rein. ich finde nicht, dass Planetarium ins Museums-schema passt. Typologisch ist das noch eher ein Kino oder gar ein Theater, als ein Museum, ich würde aber für einen dedizierten tag plädieren. -1 tourism=museum museum=planetarium passt voll ins Museum. Theater dagegen überhaupt nicht. Planetarium ist ein technisches Museum, in dem ganz überwiegend der Stand des Wissens von kosmischen Zusammenhängen visualisiert wird. Ich sehe da Parallelen z.B. zum Deutschen Museum in München. Sonst müssten alle Museen mit Technik und/oder Multimedia eine andere Kategorie bekommen. Ein Museum muss nicht zwangsläufig eine Staubsammlung sein ;-) Ein Theater oder Kino dagegen zeigt Unterhaltung, die ganz überwiegend auf Phantasie beruht. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] D-A-CH
Hallo, Am Donnerstag, den 20.02.2014, 19:55 +0100 schrieb Caronna: Am 20.02.2014 17:04, schrieb Frederik Ramm: Hi, für den rein hypothetischen Fall ;) dass ich auf download.geofabrik.de auch ein File D-A-CH anbieten würde, statt nur entweder die Länder einzeln oder ganz Europa - würde man dann auch noch Südtirol mit dazu nehmen, oder eher nicht? D-A-CH... wieso nur diese Kombination (halt mich schon immer bei Navis geärgert) Ich brauchte D + BeNeLux, andere hätten wohl gerne Dänemark dabei, Polen oder die Tschechen. +1 Wie das so ist, wenn man etwas anbietet... ;-) Schön wäre es, wenn man die runtergeladenen Dateien mit einem Script zusammenlesen könnte. Dann lädt man einfach benachbarte Files zusammen und kann seine Kombination selbst bestimmen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hack-weekend in Berlin nach der Fossgis
Hi Kolossos, manche Dinge sind so wichtig, die kann man gar nicht oft genug sagen ;-) Gruß, Wolfgang Am Donnerstag, den 13.02.2014, 19:08 +0100 schrieb Kolossos: Am 22.-23. März wird es im Anschluss an die Fossgis-Konferenz ein Hack-weekend geben: http://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_März_2014 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vertikale/horizontale Linienbündel
Am Dienstag, den 11.02.2014, 21:47 +0100 schrieb r...@gmx.de: Liebe Tagger(innen) und Mapper(außen?), ich beginne mit dem Fall eines vertikalen Linienbündels, d.h. mit mehrstöckigen Wegen: Unten (layer=-1) verläuft vielleicht ein Kanal, darüber (layer=0) eine Straße und eine Bahnlinie (layer=1). Ansatzweise gibt es so etwas bei der Minderener Str. in Bielefeld http://www.openstreetmap.org/way/48403389 - aber sicher gibt es bessere Beispiele in Japan. Wenn die Wege wirklich für längere Zeit exakt übereinander verlaufen, wie ist das sinnvoll zu mappen? Macht es Sinn, dafür eine Relation vbundle zu ersinnen? Damit könnte man zwar (zusätzlich zum layer) eine Lagebeziehung (über/unter) zwischen den einzelnen Strängen herstellen, müsste aber jeweils einen eigenen Streckenzug (way) erstellen. Bei Verfeinerungen ist so etwas anfällig. Das Rendern ist ohnehin problematisch. Ich würde den Bündel/Relationsansatz ganz schnell wieder vergessen. Für jede Etage/Höhenlage einen Layer vergeben und den Filter von JOSM benutzen. Damit kann man jederzeit einstellen, dass man nur die Objekte von Layer xx sehen will (Filter hinzufügen Layer=3 Filter invertieren) Ob das Ganze überhaupt sinnvoll ist, wie man es auswertet und was Renderer anzeigen sollen, ist eine andere Frage. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbild-Versatz - Schachtdeckel
Moin, Am Montag, den 10.02.2014, 19:28 +0100 schrieb Markus: N'Abend Dirk, User A ist sich sicher Was genau bedeutet sicher? Vermutlich „Der User Stand mit perfektem GPX-Fix auf seinem Gerät direkt drauf“ :) *lach* - und was bedeutetperfekt? ;-) Mal zur Info: In Lübeck sind wir im Besitz der Koordinaten nahezu sämtlicher Schachtdeckel der Stadt. Die hat ein User genau zu dem Zweck der Georeferenzierung für alle hochgeladen. Das war vielleicht nicht so super geschickt, weil es eine 5-stellige Anzahl war, aber die Absicht war genau dieselbe wie eure. Derjenige ist an den Marterpfahl gebunden und gesteinigt und geteert und gefedert worden. Der macht das bestimmt nicht wieder. Die Punkte wurden gelöscht. Ganz böser Fall von unerlaubtem Import. Jetzt kann eine handverlesene Anzahl von Mappern in Lübeck Luftbilder georeferenzieren... Und nein, ich war es nicht ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
Am Mittwoch, den 05.02.2014, 12:20 +0100 schrieb Tobias Knerr: Am 05.02.2014 11:10, schrieb Falk Zscheile: Aus Sicht von jemanden der on the ground mappt gibt es die schon. Darum dreht sich ja der Thread mittlerweile. Ich finde, die on the ground-Regel wird in dieser Diskussion arg überstrapaziert. Nach meinem Verständnis sagt diese Konvention, dass die Situation on the ground als Quelle dienen soll. Darauf wendet man dann die Taggingregeln an: Beispielsweise, dass Anlieger frei mit dem Wert destination gemappt wird, obwohl das nicht wortwörtlich auf dem Schild steht. Und eben, dass Abkürzungen ausgeschrieben werden, obwohl das nicht wortwörtlich auf dem Schild steht. Daher sehe ich keinen Widerspruch zwischen der on the ground-Regel und der Ausschreiben-Regel. Der entsteht nur dann, wenn man vergisst, dass es zwischen der Quelle (d.h. bevorzugt der Realität) und den Tags immer einen Übersetzungsschritt gibt. +1 Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbild-Versatz
Am Montag, den 03.02.2014, 08:05 +0100 schrieb Ronnie Soak: Meine Aussage sollte sein: Die Flugplätze bekommt man damit vielleicht sehr genau, alles andere ist zu weit weg als dass die Flugplatzkoordinaten was verbessern könnten... Irgend jemand hatte von einer Stadt doch mal die exakten Koordinaten der Gullideckel. DAS wäre eine Referenznetz, das dicht genug für eine Luftbildkorrektur wäre. Gibt's wahrscheinlich nur nicht überall. Und beim Hochladen wird auf denjenigen eingeprügelt... Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbild-Versatz
Am Montag, den 27.01.2014, 20:20 +0100 schrieb Andre Hinrichs: Einem einzelnen GPS-Track kann man nicht vertrauen, ob nun aus Gründerzeiten oder neuerdings. Daher versuche ich stets Straßen zum Ausrichten zu verwenden, wo bereits mehrere Tracks aufgenommen wurden. Das Problem mit den Häuserschluchten besteht ja im Wesentlichen in den großen Städten. Dort findet man jedoch auch häufig vielbefahrene Hauptstraßen, an denen man das dann ausrichten kann. Der Versatz der 200 Meter entfernt liegenden Nebenstraße, die in einer Häuserschlucht verläuft, sollte davon nicht wesentlich abweichen. Man kann also die dortigen ungenauen Tracks ignorieren. Das ist aber sehr von den Bing-Bildern abhängig. In HH musst du jede Kreuzung einzeln positionieren. Da geht es munter 5m nach links, 4m nach vorn... . Die Bing-Bilder werden nur noch benutzt, weil die Auflösung besser ist als bei den Bildern des Vermessungsamtes. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vortrag von Jochen Topf zum OSM-Datenmodell in Hamburg
Am Freitag, den 17.01.2014, 10:42 +0100 schrieb Jochen Topf: Das tut mir leid. Die HafenCity ist da nur in provisorischen Räumlichkeiten und deshalb ist da nichts richtig ausgeschildert. Ich habs auch nicht gleich gefunden... Ja, provisorisch wirkt das wirklich. Die Räumlichkeiten hat die jetzige HCU allerdings seit mindestens Mitte der 70er Jahre, als sie noch Fachhochschule für Vermessung, Bauing-Wesen und Architektur hieß. Da wäre genug Zeit für eine Ausschilderung gewesen... War trotz der innovativen Beleuchtungseffekte ;) ein interessanter Vortrag und ein netter Abend. Vielleicht kannst du, falls der Ton nicht klappen sollte, die Folien irgendwo hochladen? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
Am Sonntag, den 12.01.2014, 18:56 +0100 schrieb Werner Hoch: Am Sonntag, den 12.01.2014, 12:31 +0100 schrieb Florian Lohoff: ich sehe hier seit 3 Tagen das irgendjemand einfach ohne irgendwas zu machen OSB Bugs schliesst. Die Bugs gehen ohne Username und Ohne Kommentar einfach zu. Mittlerweile sind 30 Bugs von mir im Umkreis Guetersloh/Rheda-Wiedenbrück geschlossen worde. [...] 1. Es geht nicht drum die OSB Bugs so schnell es geht einfach zuzumachen, das geht schneller - einfach ein drop all tables in der Datenbank. 2. Wenn man Bugs schliesst bitte mit Kommentar was geaendert worden ist und vor allem mit Namen. So kann ich denjenigen nichtmal per Nachricht wüst beschimpfen was das soll. Ich habe eine Empfehlung ergänzt, wie bugs geschlossen werden sollen: https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#General_hints Ich würde ja neue Bugs aufmachen in dem Gebiet und denjenigen Wüst beschimpfen aber das geht ja bei OSB nicht mehr weil ja voreilig das neu eröffnen abgeschaltet worden ist. [...] Du nennst es voreilig. Konstruktive Vorschläge für die schrittweise Abschaltung sind willkommen. Welcher Zeitraum wäre für dich sinnvoll gewesen, in welchen Schritten? Worin bestand eigentlich das Problem, die bisherigen OSB-Einträge in die Notes zu übernehmen und dann OSB abzuschalten? Der Aufwand, die OSBs manuell zu überprüfen und ggf. zu übertragen dürfte in jedem Fall wesentlich größer sein. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auto versus PKW im deutschen StVR - war: Parkplatz nur für PKW
Hallo Am Donnerstag, den 09.01.2014, 10:06 +0100 schrieb Ronnie Soak: Natürlich sinf die boat=no and motor_boat=no an jede Strasse taggende darüber unglücklich. Macht keine Witze. Ich hatte schon motor_vehicle=no, snowmobile= no an innerstädtischen (mitteldeutschen) Servicewegen aufzuräumen. Keine Ahnung welches intuitive Template dabei geholfen hat. Man könnte das tagging vereinfachen und die Auswerung trotzdem komfortabel halten, wenn man ein paar einfache Regeln aufstellt: 1. Ohne Access-Tag ist ein Weg für alles zulässig, was da drauf kann und generell auf einen solchen Weg darf. 2. Ist ein Weg nur für eine oder wenige Gruppen zulässig, werden die Gruppen erwähnt. Damit sind alle nicht erwähnten ausgeschlossen. Beispiel Busspur: psv=yes, das impliziert dann ein Verbot für alle anderen. 3. Ist ein Weg nur für eine oder wenige Gruppen verboten, werden die Gruppen genauso erwähnt, aber mit no. Das erlaubt alle davon nicht betroffenen Gruppen. Beispiel für Gefahrgüterverbot: hazmat=no Zu überlegen wäre, ob nicht grundsätzlich immer ein access: vorgesetzt werden soll. Das erleichtert die Erkennung. access:psv=yes bzw. access:hazmat=no Ansonsten kann das access-Schema genauso benutzt werden. Nur das vorherige access=no entfällt (es sei denn, es ist wirklich für alle verboten). Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz nur für PKW
Man kann auch in Frage stellen, ob denn das hierarchische Modell hinter den Zugangstags nicht vielleicht einfach zu kompliziert ist... Vom Gefühl gilt für mich auch eher: motor_vehicle=no = motorcar=no v motorcycle=no v hgv=no v bus=no v ... (äquivalentes entsprechend bei yes oder designated). Ich sehe das eher als Werkzeug-Problem. Sobald die Editoren dafür eine Funktion anbieten, läuft es. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am Freitag, den 03.01.2014, 12:29 +0100 schrieb Peter Wendorff: Hallo Stefan, leider beschränkt sich das ja nicht nur auf Kreuzungen: Mittelinseln an Fußgängerüberwegen, Bushaltestellen mit deutlichen Buchten, Taxistände, Parkhausein-/ausfahrten oder auch nur die Frage, wonach Straßen in Fahrbahn-Ways aufgetrennt werden (bauliche Trennung, juristisch bauliche Trennung und damit auch durchgezogene Doppellinie, Das Ding ist nicht tot zu kriegen :-( Wir haben das vor ca einem 3/4 Jahr hier schon mal durchgekaut. Juristisch ist eine durchgezogene Doppellinie zwei gemalte Linien zwei Striche auf der Straße eine Fahrstreifentrennung für den Gegenverkehr und keine, gar keine, überhaupt keine, in keinster Weise eine bauliche Maßnahme, Trennung oder sonst was und auch nie nicht niemals sowas gewesen! Das einzige was für Mapper schwer verständlich zu sein scheint, ist der Gesetzestext. - Diese Geschwindigkeitsbeschränkung gilt nicht auf Autobahnen (Zeichen 330.1) sowie auf anderen Straßen mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind. - Sie gilt ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben. (§ 3 Abs. 3 c StVO) Ferner dazu der Satz mit der Doppellinie aus der Anlage zu § 41 Abs. 1 Vorschriftszeichen, Laufende Nummer 68, Erläuterung Nr. 1 StVO - Die Fahrstreifenbegrenzung kann zur Abtrennung des Gegenverkehrs aus einer Doppellinie bestehen. Erläuterung 2 sagt, dass _seitlich_ die Fahrbahn durch eine Seitenbegrenzungslinie gegen Seitenstreifen oder Sonderwege abgegrenzt werden kann, das aber nicht als Doppellinie. Will heißen: Baulich getrennt im ersten Satz (Diese...), wenn _baulich_ getrennt. Baulich nicht getrennt im zweiten Satz (Sie gilt ferner...), wenn _baulich_ nicht getrennt, sondern gemalt. Die zwei bezieht sich auf die Anzahl der Fahrstreifen (Spuren) pro Richtung und nicht auf die Anzahl der Striche. Man achte auf die Bezeichnung Fahrstreifen, nicht Fahrbahnen. Außerdem jede Richtung. Gemeint ist eine Straße allgemein genannt mindestens 4-spurig. Dort, und nur dort, darf man außerorts schneller als 100 km/h fahren, wenn nichts dran steht. Egal, ob in der Mitte ein Strich, 2 Striche, 20 Striche, eine Rasenfläche, eine Weide mit Kuh, ein Mittelstreifen oder sonstwas ist, wobei für die Striche der 2. Satz, für Mittelstreifen mit/ohne Weide und Kuh der erste Satz gilt. Merke: Hast du in der Mitte 2 Striche, aber für mindestens eine Fahrtrichtung nur eine Fahrspur, solltest du im Interesse deines Lappens nicht wesentlich schneller als mit 100 km/h unterwegs sein. Wenn nichts dransteht. seufz Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Hallo Peter Am Freitag, den 03.01.2014, 16:59 +0100 schrieb Peter Wendorff: Hallo Wolfgang, ich wollte das gar nicht wieder aufkochen, sondern nur anmerken, dass die Ansichten, wann in OSM der Weg jetzt geteilt wird und wann nicht, deutlich auseinandergehen. Die Frage ist/wäre nämlich unabhängig von den daraus gezogenen Implikationen, denn zwei oneway-ways in OSM lassen noch absolut nicht auf irgendeine Höchstgeschwindigkeit schließen, wenn diese nicht explizit angegeben ist. Ich wollte hier nur neue Missverständnisse vermeiden. Übrigens hatten wir eine Einigung: Nur die bauliche Trennung zählt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Hallo, Am Freitag, den 03.01.2014, 18:08 +0100 schrieb chris66: Am 03.01.2014 17:29, schrieb Florian Lohoff: Was AFAIK fehlt ist ein tag um anzudeuten das zwischen den lanes:forward und lanes:backward eine durchgezogene line bzw bauliche trennung gibt d.h. ein kreuzen oder wenden nicht moeglich ist. Flo Da hilft evntl. change:lanes:forward=not_left|yes (Beispiel) weiter. http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension http://wiki.openstreetmap.org/wiki/Key:change:lanes Tipp: lanes immer mit forward/backward taggen. Zur Anzeige von gemappten Fahrspuren gibt es mehrere JOSM-Stile. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OT] Etrex 30: Sekundengenaue Uhrzeit abfotografieren?
Hallo, Am Dienstag, den 31.12.2013, 14:39 +0100 schrieb Andreas Tille: Hmmm, bei mir (also in Werkseinstellungen) ist da die Zeit bis Sonnenuntergang. Eine nette Information, die aber eigentlich kein Mensch so richtig braucht. Was bei Dir steht, klingt viel interessanter - leider habe ich noch nicht raus, wie ich das ändern kann. Ab Sonnenuntergang muss auf Sportbooten (und nicht nur diesen) die Positionsbeleuchtung eingeschaltet sein, egal wie hell es zu dem Zeitpunkt noch sein sollte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am Dienstag, den 24.12.2013, 10:50 +0100 schrieb Peter Wendorff: Am 23.12.2013 07:12, schrieb Wolfgang Hinsch: Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf mehrere Äste verteilt werden, weil ein way nur einmal in der Relation vorhanden sein darf. Wer hat dir den den Blödsinn erzählt? Natürlich kann ein Weg mehrfach vorhanden sein, insbesondere, aber rein technisch gesehen nicht darauf beschränkt, wenn unterschiedliche Rollen (z.B. forward/backward) genutzt werden. Hab ich mehrfach so gesehen und auch mehrfach selbst so gempapped; beschwert hat sich bisher niemand. Glückwunsch! JOSM reagiert mit einer Fehlermeldung. Ob das Ganze dann heil in der DB ankommt, möchte ich nicht ausprobieren. Der Vorteil der neuen Relationen ist ja gerade, dass es eine Relation für eine Strecke gibt. Daduch kann man die Relation mit der Sort-Funktion sortieren und ggf. auf die Lücken springen, um sie zu reparieren. Wenn da jetzt wieder Verzweigungen und mehrfache Wege reinkommen, ist der Vorteil dahin. Dann hätten wir die alten Relationen lassen können. Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet werden. Auch deshalb darf es innerhalb derselben Route-Relation keine Verzweigungen geben. Wenn das so wäre, wär das neue Schema unbrauchbar, denn dass Busse, Bahnen, Straßenbahnen etc. Teilstrecken mehrfach befahren ist durchaus die Regel. Die werden als eigene Relationen innerhalb der Route-Master-Relation eingetragen. Das finde ich auch sinnvoll, denn man muss nicht mehr diese Spaghetti-Relationen verfolgen. Probleme entstehen, wenn da jetzt wieder Verzweigungen auftauchen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am Sonntag, den 22.12.2013, 12:58 +0100 schrieb Florian Lohoff: On Sat, Dec 21, 2013 at 12:24:04PM -0800, mmd wrote: Ich hatte damals an eine reine Web-Anwendung gedacht, mit der man neben neuen Relationen auch existierende Relationen einfach durch Drag-und-Drop anpassen kann. Also genau so, wie man heute auf osrm.at eine Route mit Start/Ziel und Zwischenpunkten zusammenbaut. Passt das Ergebnis, sollte automatisch die Relation in der OSM-DB aktualisiert werden können. Alle Split-Operationen (die Du wie geschrieben in JOSM händisch machen würdest) würden dann automatisch im Hintergrund erfolgen. Ich warne davor das Automatisch zu machen. Das wird diskussionen geben ohne ende ob denn das sein muss und jeder kleine fehler würde aufgebauscht werden so wie bei allen automatischen aenderungen oder den imports. +1 Die Idee klingt zunächst bestechend. Das Problem ist einmal der berechnete Weg, der Ungenauigkeiten enthalten kann. Das größere Problem sehe ich in der mangelnden Aktualität. Die Editoren arbeiten immer mit topaktuellen Daten, die Router hängen ein paar Tage hinterher. Wenn ich eine Kreuzung umbaue und anschließend die Routen in Ordnung bringen will, nützt mir das wenig. Andererseits halte ich es für unsinnig, das Routing im Editor einbauen zu wollen, denn dann müsste eine viel zu große Datenmenge herunter geladen werden. Für den besseren Weg halte ich eine Weiterentwicklung der Routeneditoren. Im Josm läuft das bei Busrouten schon recht gut. Dazu würde ich vorschlagen, immer für den ersten Wegeabschnitt jeder Busroute eine Role start zu vergeben. Dann kann Josm in den neuen Busrouten die Route entsprechend sortieren. 80% des Aufwands, den ich im Moment in der Reparatur von Busrouten habe, besteht darin, den Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander gewürfelt haben. Josm sollte für die neuen Busrouten in der Lage sein, die Route fortlaufend zu sortieren wie jetzt, aber mit Berücksichtigung der start-Role, automatisch forward/backward zu entfernen und die Haltestellen entsprechend der Wege zu sortieren. Da nach dem neuen Schema immer eine stop_position auf dem Weg liegt, sollte es anhand der übereinstimmenden Haltestellennamen und der Entfernung möglich sein, auch die Haltestellen automatisch in die richtige Reihenfolge zu bringen. Wenn Josm auf eine Lücke stößt, wird danach weiter sortiert wie jetzt auch. Der Sprung auf die Lücke ist bereits vorhanden, hier sollte der herunterzuladende Bereich deutlich verkleinert werden. Es reicht, die nächsten 20m im Umkreis zu laden. Wenn der Editor positioniert ist, kann der Mapper eine größere Umgebung manuell herunter laden. Im Moment ist es so, dass man je nach Ausstattung des Rechners nach 5 - 10 Sprüngen erst einmal den Datenpuffer wegschmeißen muss. Das ist überflüssige Zeit und Traffic. Die alten Relationen mögen vordergründig einfacher sein, weil man nach einem Straßenumbau einfach die Wege irgendwo reinschmeißen kann. Übersichtlich sind die Relationen auf keinen Fall. Der Wartungsaufwand ist bei den neuen Relationen sehr viel kleiner, und wenn an Josm noch ein bisschen geschraubt wird, sollte es auch für Anfänger recht einfach sein. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
Am Sonntag, den 22.12.2013, 16:51 +0100 schrieb Roland Olbricht: 80% des Aufwands, den ich im Moment in der Reparatur von Busrouten habe, besteht darin, den Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander gewürfelt haben. Das Public-Transport-Plugin kann Routen automatisch sortieren und umdrehen, wenn sie genau falsch herum sortiert sind. Die forward/backward-Rollen sind allerdings für eine eindeutige Sortierung notwendig, vor allem, wenn eine Buslinie z.B. in einem Busbahnhof einen kreisförmigen Weg befährt. Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf mehrere Äste verteilt werden, weil ein way nur einmal in der Relation vorhanden sein darf. Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet werden. Auch deshalb darf es innerhalb derselben Route-Relation keine Verzweigungen geben. Wenn die Relation lückenlos ist, kann sie automatisch sortiert werden, ggf. anhand des From-tags. Da die Relationen aber in der Praxis nach einiger Zeit Lücken aufweisen, wäre es gut, wenn JOSM den Anfangsway automatisch erkennen und dann schon einmal sortieren könnte, soweit es geht. Manuell kann man dann auf die Lücken springen und damit auch größere Routen innerhalb weniger Minuten klären. Wenn nur die Suche nach dem Anfang nicht wäre... Ich vergebe inzwischen für den ersten way der Relation die Role start. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?
Hallo, Am Freitag, den 20.12.2013, 15:08 +0100 schrieb Bernhard Weiskopf: Von: Tirkon [mailto:tirko...@yahoo.de] Gesendet: Dienstag, 17. Dezember 2013 01:37 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Zeitreise ins 4. Jahrhundert oder was? ... Ein wichtiger Fall, der IMHO gegen eine Aufnahme von Daten sprechen könnte, wäre eine Unübersichtlichkeit durch den Gebrauch komplizierter Konstrukte, welche die breite Masse der Mapper, von denen wir immer noch zu wenig haben, vom Anfassen und Maintainen abhalten könnte. Das ist doch längst passiert. In meiner Umgebung sind ein paar breite Hauptstraßen an Kreuzungen aufgeteilt in zwei Richtungsfahrbahnen und in der Mitte sind Inseln für Fußgänger und Radfahrer. Diese Aufteilung und damit das genauere Eintragen von Fuß- und Radwegen würde ich gerne auch in OSM abbilden, wo die Straßen zurzeit als jeweils eine durchgehende Linie eingetragen sind. Da über diese Straßen aber Bus-Relationen führen und nach deren neuen Schema die Straßensegmente in der Relationsliste in der richtigen Reihenfolge eingetragen werden müssen und das Ganze auch noch für jede Fahrtrichtung einzeln, lasse ich das Editieren sein. Das ist mir inzwischen zu aufwändig zu pflegen. Wenn das die alten Relationen sind, einfach die neuen Straßen mit reinkippen. Wenn es die neuen Relationen sind, die 2 oder 3 Wege aus der einen Richtung entfernen und die neuen Wege dafür reinsetzen. Josm kann das sogar automatisch sortieren. Das ist eigentlich recht trivial. Komplizierter sind die tmc-Gebilde. Die versteht inzwischen wahrscheinlich niemand mehr. Es werden immer mehr, sie sind unverständlich, umständlich und kaum handhabbar. Es gab da mal einen Ansatz, das ganze zu vereinfachen in einem einzelnen Tag. Mit dem Einzeichnen von separaten Parallelwegen verkomplizierst du übrigens die Daten auch. Ein tag am way für den Radweg sagt klar, für welche Straße er begleitend ist, wie der Straßennamen zuzuordnen ist etc. Die Darstellung ist in allen Zoomleveln außerhalb 17+ besser. Aus der Klemme kann man rauskommen, wenn die cycleway-tags an der Straße bleiben und eine Street-Relation den separaten cycleway an die Straßen koppelt. Dann kann der Auswerter je nach Maßstab entscheiden, ob er den Radweg einzeln zeichnet oder nur das tag auswertet. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?
Hallo Bernhard Am Freitag, den 20.12.2013, 17:17 +0100 schrieb Bernhard Weiskopf: Hallo Wolfgang, ich arbeite mit Potlach 2. JOSM hatte ich auf dem alten PC installiert, hab's aber kaum benutzt, weil mir die Schrift zu klein war. Eben habe ich versucht JOSM zu installieren, ich komme damit aber nicht klar: Bei der Schrift muss ich im Moment passen. Es startet mit einem Fenster Veraltete JAVA-Version. Sie verwenden die JAVA-Version 1.6.0_06 ... JOSM wird mit dieser Version bald nicht mehr funktionieren... JAVA darf ich nicht updaten, sonst läuft ein Programm, das ich geschäftlich brauche nicht mehr. Beim Versuch Hintergrundbilder zu laden stürzt JOSM ab JOSM is out of memory. Dafür gibt es den Parameter -Xmxnn. Irgendwo (TM) in deinem System hast du eine Startdatei, mit der JOSM gestartet wird. Die enthält einen Aufruf java -jar josm-tested.jar, eventuell noch ein paar Parameter mehr. Falls der -Xmx da schon drin ist, musst du die nachfolgende Zahl nn erhöhen, andernfalls den Parameter dazusetzen. nn beschreibt dabei die maximal zulässige Speichermenge für JOSM in Bytes, bei angehängtem K oder M in Kilo- oder Megabyte. Der Wert muss natürlich zum vorhandenen Speicher passen und ein bisschen hätte das System selbst meistens auch noch gerne. (Bisschen ist weit untertrieben!) Also: java -Xmx 1000M -jar josm-tested.jar startet mit 1GB Memory für JOSM. Das ist im Wiki auch noch mal erklärt. Ist JOSM der einzige Editor, mit dem die OSM-Daten noch editiert werden können? Nein, es gibt auch ID und Potlach. Josm hat aber viel mehr Möglichkeiten. OSM hat den Vorteil, dass auch Fußgängerrouting relativ detailliert funktioniert. Und die Radwege sind in der Realität teilweise nur in einer Richtung erlaubt und etwa 25 m auseinander. In OSM kann man das zurzeit nicht erkennen. Wenn ich mit einer Gruppe fahre interessiert mich auch, ob zwischen zwei Fahrbahnen, die wir überqueren wollen, eine Insel zum Sammeln ist, die ist jetzt gar nicht eingetragen. Dafür gibt es die Möglichkeit, die Fahrbahnen zu trennen, hier ist ja eine bauliche Trennung vorhanden, oder das Tag für die Mittelinsel beim crossing dazuzusetzen. highway=crossing crossing=island Zurzeit ist Google an vielen Kreuzungen detaillierter inkl. Abbiegebeschränkungen und separaten Abbiege-Fahrbahnen. OSM-Router melden oft Jetzt rechts abbiegen wenn man nicht mehr auf die separate Fahrbahn wechseln kann. Das liegt an der Qualität des Routing-Programms. Ich fahre mit Garmin-Navis und OSM-Daten seit mindestens 2009 Auto und habe diese Probleme nicht. Neben der grafischen Anzeige bekomme abhängig vom Straßentyp und der gefahrenen Geschwindigkeit die Hinweise 250 - 2500m vorher. Das Fahrspurmapping ist ebenfalls schon in Gange, es gibt dazu einiges im Wiki. In Josm gibt es Stile, mit denen getaggte Fahrspuren angezeigt werden. Da sind dann auch die Verzweigungen mit drin. Das ist aber alles noch in den Kinderschuhen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?
Hallo, Am Samstag, den 21.12.2013, 00:47 +0100 schrieb Martin Koppenhoefer: Am 20/dic/2013 um 19:18 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: highway=crossing crossing=island wie passt denn das zu uncontrolled oder traffic_lights? http://taginfo.openstreetmap.org/keys/crossing#values Das sind doch klar unterschiedliche Kategorien, Im Prinzip ja, aber die Josm-Standardvorlage macht es genau so. Vielleicht ist da noch etwas Optimierungsbedarf. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?
Hallo, Am Samstag, den 21.12.2013, 02:03 +0100 schrieb Bernhard Weiskopf: Am Freitag, den 20.12.2013, 17:17 +0100 schrieb Bernhard Weiskopf: Mit Potlach und ID kann man alle Straßen mit neuen Busrelationen aber nicht mehr vernünftig editieren. Selbst mit JOSM wird man sich extra um die Reihenfolge kümmern müssen. Es reicht, den ersten Way nach ganz vorn zu nehmen und auf Sortieren zu drücken. Allerdings sollten die Ways keine Role haben, zumindest der Erste, sonst hat Josm Schwierigkeiten. Wenn es nicht richtig sortiert wird, liegt irgendwo ein Fehler vor. Auf die Lücke springen und darauf zoomen, dann klärt sich das. Bei mir jedenfalls bisher. Das liegt an der Qualität des Routing-Programms. Ich fahre mit Garmin- Navis und OSM-Daten seit mindestens 2009 Auto und habe diese Probleme nicht. Neben der grafischen Anzeige bekomme abhängig vom Straßentyp und der gefahrenen Geschwindigkeit die Hinweise 250 - 2500m vorher. Die kommen bei OsmAnd und Navigator auch. Da in Großstädten dann aber oft einige Kreuzungen dicht hintereinander folgen, kommt kurz vor dem tatsächlichen Abzweig zusätzlich die Ansage Jetzt rechts abbiegen. Und wenn die separate Abbiegefahrbahn in OSM fehlt, kommt diese Ansage oft zu spät. Garmin sagt vorher schon mal rechts halten, demnächst rechts abbiegen. Außerdem läuft immer eine große Zahl als Countdown in Metern bis zur Abbiegung. Die einzige Stadt, in der man sich trotzdem verfährt, ist Salzburg ;-) Im übrigen ist es gerade in der Großstadt relativ egal. Wenn man die eine Abzweigung nicht erwischt hat, soll sich das Navi einen anderen Weg suchen. An manchen Kreuzungen in den Großstädten muss man als Fahrradfahrer die Seite wechseln und dazu alle Fahrbahnen an einem markierten Übergang kreuzen, meistens auch mit traffic_signals. Wenn die Radwege als tags an den Straßen hängen kann man das nicht darstellen. Na ja, wenn da ein Baucontainer oder der Müllwagen auf dem Radweg steht, kann man das auch nicht darstellen. Ich sehe das Navi nur als Hilfsmittel, nicht als Fernsteuerung. Im übrigen haben wir die crossing-Tags. Das Navi kann so schon berechnen, wo die Straßenseite gewechselt werden sollte. In vielen Straßenschluchten kann das Navi ohnehin nicht erkennen, auf welcher Straßenseite du gerade bist. Oft liegt ein schmaler Grünstreifen zwischen Radweg und Fahrbahn oder mindestens ein hoher Bordstein. Vom Radweg aus ist an vielen Stellen kein Linksabbiegen möglich und der Router muss das entsprechend erkennen und rechtzeitig auf die Fahrbahn routen oder ähnlich. Das geht am übersichtlichsten und fehlerärmsten, wenn die Radwege getrennt gezeichnet werden, so wie sie auch in der Natur geführt werden. Das Thema dürfte sowieso in ein paar Jahren durch sein, dann haben alle Straßen Radspuren. Die Radwege werden vermutlich aussterben. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitreise ins 4. Jahrhundert oder was?
Am Dienstag, den 17.12.2013, 00:55 +0100 schrieb Martin Koppenhoefer: Am 16. Dezember 2013 19:54 schrieb Eckhart Wörner ewoer...@kde.org: Hallo Chris, Am Montag, 16. Dezember 2013, 15:33:36 schrieb chris66: Bei Wikipedia gibt's das ja schon, es wird immer schwieriger für Anfänger was neues (in entsprechender Relevanzhöhe) einzutragen. Mit dem Ergebnis, dass es immer weniger Wikipedia-Autoren gibt. Ja und? Seit wann definieren sich OpenStreetMap und Wikipedia über die Menge der Daten? Wikipedia hat schon längst erkannt, dass Qualität viel wichtiger ist als Quantität, es wird Zeit, dass OSM auch zur Einsicht kommt. Wikipedia hat im Gegenteil entdeckt, dass der Autorenschwund so dramatisch ist, dass dringend gegengesteuert wird. Deshalb werden u.a. einfachere Editoren entwickelt. http://www.handelsblatt.com/technologie/it-tk/it-internet/neue-technologie-wikipedia-kaempft-gegen-autorenschwund/8555600.html Uns würde das noch viel härter treffen. Ein Autor in der Engelbrechtschen Wildnis oder Lüneburger Heide ist locker durch einen Autor aus München zu ersetzen. Bei Mappern funktioniert genau das nicht, und unsere Daten veralten viel schneller. ich würde es nicht begrüßen wenn wir in OSM auch anfangen, die Mapper mit Relevanzregeln zu vergraulen. +1 Dann lieber die Importe komplett verbieten, die haben nämlich große Mitschuld am quantitativen Datenwachstum (auch durch zusätzliche tags wie source, Quelldatenset-ids und -klassen, etc.) Nicht komplett, sondern nur dort, wo die Datendichte den Import nicht sinnvoll erscheinen lässt. (Persönlich bin ich z.B. nicht bereit, für OSM zu spenden, solange das Geld den Bordsteinkantenmappern zugute kommt.) Für Bordsteinkanten gibt es gute Chancen, dass die selbst nach Einführung von Relevanzkriterien gemappt werden dürften. Sachen, die nicht direkt mit Verkehr zusammenhängen, fielen da vermutlich früher raus. Bordsteinkanten (insb. die Lage der abgesenkten) sind wichtig für viele Fortbewegungsmittel, Fahrräder, Rollstühle, Kinderwägen, Rollatoren, ... daneben sind die Bordsteine die Grenze zwischen Fahrbahn und Gehweg, definieren also die Verkehrsflächen. +1 Mangelnde Toleranz scheint irgendwie eine deutsche Eigenschaft zu sein. Immer muss etwas geregelt, vorgeschrieben oder verboten werden. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege
Hallo, Am Dienstag, den 05.11.2013, 16:26 +0100 schrieb Martin Koppenhoefer: Am 4. November 2013 20:19 schrieb Bernhard Weiskopf bweisk...@gmx.de: Den Wortlaut Der Radverkehr darf nicht die Fahrbahn, sondern muss den Radweg benutzen finde ich klar formuliert. das wäre so sicher klar formuliert, steht aber in der StVO überhaupt nicht so drin, oder hast Du mal die passende Stelle? http://www.gesetze-im-internet.de/stvo_2013/__2.html ich zitiere mich mal: Na, dann zähl' ich noch mal ein paar Erbsen dazu: STVO, Anlage 2 (zu § 41 Absatz 1), Abschnitt 5 Sonderwege, Zeichen 237 Radweg ;-) / Zitate aus Gesetzen sollten immer die genaue Fundstelle enthalten. Ich habe auch suchen müssen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] path am Strand fuer den Router ...
Hallo, Am Montag, den 04.11.2013, 23:27 +0100 schrieb Florian Lohoff: Hi, On Mon, Nov 04, 2013 at 08:52:05PM +0100, Martin Raifer wrote: Der Weg existiert ja defakto nicht. Doch. Ich sehe keinen großen Unterschied zu (teilweise) weglosen Wanderrouten im Gebirge. Einfach ein entsprechendes trail_visibility-Tag [1] dranhängen und jeder versteht was gemeint ist (hier könnte z.B. good passen, falls die Route ansonsten gut durch Wegweiser markiert ist). Die permanente Existenz einer Wegspur sollte keine notwendige Voraussetzung für einen Weg i.S.v. OSM sein. Ansonsten dürfte es so etwas wie [2] nicht geben, man müsste Wanderwege an Furten zwischen den beiden Ufern auftrennen, und und und. Es darf auch nicht existieren - Hier muesste der router ueber den Strand routen koennen. Der Weg existiert nicht sondern in Dänemark ist das befahren des gesamten Strandes mit dem Auto erlaubt. Wir taggen nicht fuer den Renderer und wir taggen auch nicht fuer den Router. Doch, genau das wird gemacht. Oder hast du schon einmal eine Fährlinie im Wasser gesehen? Oder im Fluss? Von Grenzen und PLZ-Gebieten will ich jetzt gar nichts weiter schreiben... Ich würde vorschlagen, an den Weg, der ja letztlich da ist, aber nur als ideale Linie existiert, ein highway=virtual bus=yes hgv=no foot=... oder highway=* waytype=virtual oder so zu setzen. Dann wissen alle Renderer, dass es sich um einen Way auf einer Fläche handelt und können in Abhängigkeit von der Fläche und den tags entscheiden, ob gerendert werden soll oder nicht. Wenn der way an die flaeche mit landuse=beach angeschlossen ist, ist es technisch moeglich eine route zu finden. Man sollte nicht vergessen, dass Straßen in einigen Gebieten wie z.B. Wüsten auch nicht überall einem Weg entsprechen, sondern sich da jeder seine Spur sucht, auch je nach Befahrbarkeit. Das kann man bei OSM auch nicht einfach ignorieren und die Wege auf beiden Seiten an die Sahara anschließen lassen. Gruß, Wolfgang ___ 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 Sonntag, den 03.11.2013, 21:35 +0100 schrieb Peter Wendorff: 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 Seite: Welche Tags kommen dann an die Straße? Noch schöner: Benutzungspflichtiger Radweg links, zusätzlicher Radweg rechts, beide für beide Richtungen zugelassen, aber nur der linke ist -s.o.- benutzungspflichtig. Eigentlich müsste man dann das Rad tragen :-) Gruß, Wolfgang ___ 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 Sonntag, den 03.11.2013, 22:37 +0100 schrieb Bernhard Weiskopf: 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). In Deutschland: Ja. StVO: Der Radverkehr darf nicht die Fahrbahn, sondern muss den Radweg benutzen. (- Fahrbahbenutzungsverbot) Nee, das war mal. §2 Abs. 4 Satz 2ff: Eine Pflicht, Radwege in der jeweiligen Fahrtrichtung zu benutzen, besteht nur, wenn dies durch Zeichen 237, 240 oder 241 angeordnet ist. Rechte Radwege ohne die Zeichen 237, 240 oder 241 dürfen benutzt werden. Linke Radwege ohne die Zeichen 237, 240 oder 241 dürfen nur benutzt werden, wenn dies durch das allein stehende Zusatzzeichen „Radverkehr frei“ angezeigt ist. Gruß, Wolfgang ___ 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 Sonntag, den 03.11.2013, 23:59 +0100 schrieb Bernhard Weiskopf: Von: Wolfgang Hinsch [mailto:osm-lis...@ivkasogis.de] Am Sonntag, den 03.11.2013, 22:37 +0100 schrieb Bernhard Weiskopf: StVO: Der Radverkehr darf nicht die Fahrbahn, sondern muss den Radweg benutzen. (- Fahrbahbenutzungsverbot) Nee, das war mal. §2 Abs. 4 Satz 2ff: Eine Pflicht, Radwege in der jeweiligen Fahrtrichtung zu benutzen, besteht nur, wenn dies durch Zeichen 237, 240 oder 241 angeordnet ist. Rechte Radwege ohne die Zeichen 237, 240 oder 241 dürfen benutzt werden. Linke Radwege ohne die Zeichen 237, 240 oder 241 dürfen nur benutzt werden, wenn dies durch das allein stehende Zusatzzeichen „Radverkehr frei“ angezeigt ist. Nee, das ist immer noch so: Benutzungspflichtige Radwege müssen benutzt werden. Du hast nur zitiert, was benutzungspflichtig bedeutet, das war hier gar nicht strittig. Es ging ausschließlich um benutzungspflichtige Radwege. Na, dann zähl' ich noch mal ein paar Erbsen dazu: STVO, Anlage 2 (zu § 41 Absatz 1), Abschnitt 5 Sonderwege, Zeichen 237 Radweg ;-) Gruß, Wolfgang ___ 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 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. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege taggen, Lübecker Methode
Am Samstag, den 02.11.2013, 07:45 +0100 schrieb Dirk Sohler: Leo Koppelkamm schrieb: Hier die Antwort von Martin vom ADFC: Als solche behandele ich deine Mail mal :) […] leider kann man ja auf de Mailingliste nicht antworten, ohne sich anzumelden. Dann tu das doch … Erst einmal möchte ich die anmaßende und unzutreffende Kritik zurückweisen. Scheinbar sind einige Mitglieder der Liste der Meinung, sie seien die Chefs von Openstreetmap und können über alles bestimmen, rufen sogar dazu auf, mühsam erarbeitete Daten zu löschen. Und andere meinen, sie können die mangelnde eigene Infrastruktur für ihre Spezialanwendungen durch die OSM-Infrastruktur ersetzen, und Tags nach ihrem Gusto inkompatibel und unnötig redundant verändern. [Änderungen] brauchen keine Genehmigung durch die Mailingliste. Nicht von der Mailingliste an sich, aber solch massive Änderungen sollten vorab zumindest mal mittels Proposal oder anderweitig vorgestellt werden, und nicht einfach wild ohne Rücksicht auf Verluste vorgenommen werden. Jedenfalls solltet Ihr Euch mal überlegen, ob man Lust hätte, seine Überlegungen das nächste Mal bei Euch zur Diskussion zu stellen. Vielleicht „sollte man“ mal überlegen, solche Änderungen nicht nur auf einem Stammtisch zu diskutieren, sondern öffentlich online „an Prominenter Stelle“ zur Diskussion zu stellen, anstatt einfach – ich wiederhole mich da – Tags inkompatibel und redundant für die eigenen Anwendungen in ihrer Bedeutung und Verwendung zu verändern. Die ist aber notwendig, damit der Renderer […] Wir mappen nicht für den Renderer. Def. Mappen für den Renderer: Inhalte bewusst sachlich verkehrt darstellen, damit ein bestimmter Renderer etwas im Sinne des Verwenders darstellt. Das einzige tag, das _heute_ sich gefestigt hat und anders benutzt wird, ist cycleway. Aber auch das nicht für den Renderer, sondern weil es logisch erschien. Das haben wir aber schon durchgekaut. Irgendwann reicht es. Im übrigen wird weder für noch geegen den Renderer gemappt. Ansonsten wäre es schön, wenn weniger Polemik und mehr konstruktive Vorschläge kämen. Gruß, Wolfgang ps.: Prominentes Beispiel für Mappen für den Renderer: Missbrauch des name-tag, damit Mapnik Texte darstellt. ___ 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 Samstag, den 02.11.2013, 14:18 +0100 schrieb Masi Master: Am 02.11.2013, 09:35 Uhr, schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: 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? Weil die nicht straßenbegleitenden in aller Regel wie andere Straßen auch onewway=no sind. Ich habe keine Probleme damit, wenn die auch ein oneway bekommen, aber bei den straßenbegleitenden finde ich es wichtiger. Gruß, Wolfgang ___ 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 Freitag, den 01.11.2013, 13:45 +0100 schrieb Peter Wendorff: Eine Fahrtrichtungsbeschränkung wird über oneway getagged - warum sollten wir das jetzt auf einmal weglassen, nur weil man es rein theoretisch über die Lage zu einer Straße erraten könnte? Dann zeige doch mal einen Radweg, der mit oneway=yes getaggt ist, weil er straßenbegleitend ist. Gruß, Wolfgang ___ 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 Donnerstag, den 31.10.2013, 20:18 +0100 schrieb Michael Reichert: Hallo, Am 31.10.2013 20:11, schrieb cracklinrain: * Oft muss man einen Radweg früher verlassen und auf die Straße fahren, damit man in eine andere Straße abbiegen kann. So etwas kann durch Taggen an Straßen nicht gelöst werden. Deshalb gibt es ja die allgemeine Regel: Ein Weg für alles, wenn es keine bauliche Trennung gibt, zwei oder noch mehr Wege, wenn es eine bauliche Trennung gibt. Bauliche Trennungen: Leitplanke: ja weißer Strich: nein doppelter weißer Strich: allgemeine Uneinigkeit, siehe talk-de-Archiv Die letzte Diskussion auf talk-de (7/13) hatte ergeben, dass wir hier ein nein annehmen. Selten, aber wahr ;-) Grünstreifen: eher ja Bordstein: für Autos würde ich ja sagen, für Fußgänger nein, bei Radlern kommt es auf die Höhe an. Ein Fußgänger kann an einem Bordstein überall die Straße überqueren. alle anderen +1 Gruß, Wolfgang ___ 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 Donnerstag, den 31.10.2013, 18:20 +0100 schrieb Stephan Wolff: 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. +1 Das Lübecker-Modell mit dem Tag cycleway:*=sidepath, den Relation für eigenständige Radwege an Straßen und den sidepath:refname=* mit willkürlich gewählten Pseudonamen finde ich seltsam. Ich teile die von Rainer genannten Kritikpunkte. Wir sollten uns endlich eine bessere Lösung überlegen. Sofort einverstanden. Offenbar braucht man die Information, ob ein Radweg straßenbegleitend oder eigenständig ist, und umgekehrt, ob zu einer Straße ein Radweg als eigener way existiert. Dafür wäre je ein einfaches Tag ausreichend. Brauchen wir eine Relation, die alle Wegsegmente (Straße und Radweg) zusammenfasst? Das ist sinnvoll, um die zusammengehörenden Elemente zu finden, z.B. ist der Radweg sonst nicht mit dem Straßennamen verbunden. Außerdem unterscheidet man dann eindeutig den zufällig in der Nähe verlaufenden Radweg von dem, der zur Straße gehört, und bei räumlicher Nähe mehrerer Straßen wird klar, welche Straße gemeint ist. Das ist auch für die Annahme einer Fahrtrichtungsbeschränkung von Bedeutung. Brauchen wir eine explizite segmentweise Zuordnung straßenbegleitender Radwege zur Straße? Das hängt von der Detailmenge ab. Wenn der Radweg segmentweise detailliert erfasst wurde mit Oberflächenmaterial und ~zustand, sollte es eine Möglichkeit geben, die Lage der Segmente an der Fahrbahn abzubilden. Wie oben schon richtig angeführt muss der Radweg in kleineren Maßstäben zeichnerisch nach außen gerückt werden. Das beste Mittel dazu ist das Aufnehmen in die Signatur der Straße. Theoretisch könnte man die Segmente auch aus der geometrischen Lage an die Fahrbahn rechnen. Probleme entstehen bei Sonderfällen, wenn die Fahrbahn und die Radwege nicht gerade verlaufen, z.B. sich um irgendwelche Hindernisse schlängeln und dabei nicht parallel zu einander sind und die Segmente relativ kurz sind. Wir brauchen also eine Methode, die immer funktioniert. Für straßenbegleitende Fußwege sollte das Modell natürlich auch anwendbar sein. +1 Fußwege werden leider viel zu wenig in die Überlegungen einbezogen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege taggen, Lübecker Methode
Am Dienstag, den 29.10.2013, 11:04 +0100 schrieb rainerU: Hallo, Am 29.10.2013 00:19, schrieb Wolfgang Hinsch: cycleway=track ist unbrauchbar, da in ~50% der Fälle der Radweg nicht auf beiden Seiten gleich ist. Das ist aus meiner Sicht nicht das Thema dieses Threads. Mit dem eingeführten und im Wiki [1] dokumentierten Tagging-Schema können die Wege auf beiden Seiten einer Straße durchaus differenziert getaggt werden. Was an diesem Lübecker Schema aufstößt ist - Das cycleway-Attribut wird umdefiniert. Standardmäßig wird dort der Typ des Radwegs angegeben, in Lübeck wird dort angegeben, auf welcher Seite der Straße ein Radweg oder -streifen verläuft. Das ist nicht ganz richtig. Cycleway wurde zum damaligen Zeitpunkt (Vor 2,5 Jahren, seit dem ist das in Lübeck so üblich) mal mit track/lane und mal mit left/right genutzt. Der Stammtisdh hat sich dann gemeinsam mit dem ADFC dafür entschieden, die sinnvollere Variante left/right zu nehmen, da track/lane sehr häufig seitenrelevant ist. - Das Schema macht Redundanz zum Prinzip. Wenn cycleway:right und cycleway:left vorhanden sind, braucht es nicht noch cycleway=both. Redundanz schadet nichts, aber man sollte sie nicht obligatorisch machen. Das riecht förmlich nach Taggen für eine Anwendung. Das wurde so auch nicht benutzt. cycleway:both ersetzt cycleway:left + cycleway:right, ist also das Gegenteil von Redundanz. Wenn die Wege auf beiden Seiten gleich sind, wird both benutzt. Das entspricht damit dem cycleway=*. - cycleway=no und oneway=no sind zwar überflüssig, werden aber wohl zur Fortschritts-/Vollständigkeitskontrolle beim Mappen genutzt. Dafür gibt es durchaus plausible Argumente wie die immer mal wiederkehrenden Diskussionen zu oneway=no zeigen. oneway=no ist eine Kennzeichnung für straßenbegleitende Radwege, die für beide Fahrtrichtungen zugelassen sind. Standardmäßig sind straßenbegleitende Radwege immer oneway, das wird üblicherweise aber nicht getaggt. Radfahrer dürfen nur den rechten Radweg benutzen, es sei denn, es ist anders ausgeschildert. - Ein neuer Wert cycleway=sidepath wird eingeführt. Vermutlich will man damit Radwege kennzeichnen, die zwar baulich mit der Strasse verbunden sind, aber als separater highway=cycleway|track erfasst sind. Das erscheint durchaus sinnvoll, hätte aber diskutiert werden müssen. Letztlich bleibt als klarer und gravierender Verstoß gegen die bisherige Praxis das Umdefinieren des Attributs cycleway. Der ganze Wust an redundanten Daten ist zwar ärgerlich aber anwendungstechnisch nicht schädlich. Dass ausgerechnet eine Radfahrorganisation mit Server- und Netzressourcen so verschwenderisch umgeht, verwundert mich allerdings. Wenn du dich damit näher beschäftigst, wirst du feststellen, dass Lübeck zu dem Zeitpunkt das besterfasste Radwegenetz bei OSM überhaupt hatte und heute - jedenfalls bis jetzt - immer noch einen Spitzenplatz einnimmt. Der ADFC Lübeck hat für OSM das gesamte Radwegenetz Lübecks komplett abgeradelt und mit Fragebögen detailliert erfasst. Das gibt zwangsläufig eine Datenmenge, die andernorts mangels detaillierter Erfassung fehlt. Man sollte nicht vergessen, dass der ADFC Bundesverband nach wie vor mit G* arbeitet. Lübeck hat hier Pionierarbeit geleistet, auch durch die im Lübecker Raum sehr öffentlichkeitswirksam präsentierte Karte. Auf der Radmesse 2 Jahre vorher hatten wir mit 2 Leuten am OSM-Stand ~ 5 Gespräche am ganzen Nachmittag. Als die Karte erschien, waren wir am OSM-Stand mit 6 Leuten den ganzen Tag ausgelastet. Dass beim Hobeln dann mal Späne fallen, ist nicht immer vermeidbar. Neue tags erst mal 2 Jahre zu diskutieren und dann mit 12 Leuten abzustimmen, ist nicht immer praktikabel, und die Abstimmungen sind nicht gerade überzeugend. Üblicherweise kann man tags ausprobieren, einführen und dokumentieren. Das ist auch geschehen. Beim tag cycleway ist über das Ziel hinausgeschossen worden bzw. die Entwicklung hat eine andere Richtung genommen, das tag könnte man wieder entfernen, es ist sowieso überflüssig, wenn der Weg entsprechend gemappt ist. Ich schlage vor, zu überlegen ob das tag cycleway=* nicht generell als deprecated zu bezeichnen ist. Es stammt aus der Zeit ~2007/8 als man froh war, dass aus den Daten hervor geht, dass da überhaupt irgendwo ein Radweg ist. Damals konnte keine Anwendung die Seite unterscheiden. Wenn ein Radweg auf beiden Seiten gleich ist, könnte man entweder cycleway:left und cycleway:right oder cycleway:both benutzen, das wäre wesentlich eindeutiger. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege taggen, Lübecker Methode
Am Mittwoch, den 30.10.2013, 14:25 +0100 schrieb Peter Wendorff: Am 30.10.2013 13:29, schrieb Wolfgang Hinsch: Am Dienstag, den 29.10.2013, 11:04 +0100 schrieb rainerU: [...] - cycleway=no und oneway=no sind zwar überflüssig, werden aber wohl zur Fortschritts-/Vollständigkeitskontrolle beim Mappen genutzt. Dafür gibt es durchaus plausible Argumente wie die immer mal wiederkehrenden Diskussionen zu oneway=no zeigen. oneway=no ist eine Kennzeichnung für straßenbegleitende Radwege, die für beide Fahrtrichtungen zugelassen sind. Standardmäßig sind straßenbegleitende Radwege immer oneway, das wird üblicherweise aber nicht getaggt. Radfahrer dürfen nur den rechten Radweg benutzen, es sei denn, es ist anders ausgeschildert. Oha... Entweder ist das hier jetzt verkürzt dargestellt (und es geht um cycleway:oneway=no oder sowas in der Art), oder es geht um explizit als eigene ways eingetragene Radwege (was so auch nicht deutlich wird aus den Mails), oder aber oneway=no wird hier mehrfach verwendet. oneway=yes|no bezieht sich erstmal auf die Straße, nicht auf den Radweg am Straßenrand oder auf dem Bürgersteig. Wenn das tatsächlich jemand anders nutzt, halte ich das für einen Fehler br. ;-) Es ging um straßenbegleitende, eigenständig gemappte Radwege, nicht um die Straße (Fahrbahn) selbst. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege taggen, Lübecker Methode
Am Montag, den 28.10.2013, 13:29 +0100 schrieb Leo Koppelkamm: Hallo Liste, verzeiht falls das schonmal diskutiert wurde, ich konnte nichts dazu finden. Zum Thema: Der ADFC Lübeck hat in Eigenarbeit eine neue Art Fahrradwege zu tagen erfunden, die leider komplett inkompatibel mit dem bisherigen Model ist. ( http://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren_L%C3%BCbecker_Methode) Statt cycleway=track benutzen sie jetzt cycleway=both; cycleway:right=track, cycleway:left=track. ??? wiki.openstreetmap.org/wiki/DE:Key:cycleway /Zusätzliche Fahrradwegtags für andere highway-Typen http://wiki.openstreetmap.org/wiki/Key:cycleway cycleway=track ist unbrauchbar, da in ~50% der Fälle der Radweg nicht auf beiden Seiten gleich ist. Habe ich dich jetzt falsch verstanden oder sind das die Auswirkungen des letzten Orkans ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo Henning, Hallo, du sagtest: *cn am Weg reicht aus und operator gehört nur an den Wegweiser. Nun frage ich mich, wie ich jetzt aus den Daten das Radwegenetz des Tourismusverbandes XYZ bekommen soll. Leider verstehe ich nicht was du meinst und kann es auch nicht nachvollziehen, da du weder geschrieben hast, auf wen oder auf welchen Text du dich beziehst. sorry sagt Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Guten Morgen Henning, Wären da auch gänzlich falsch. Denn für jeden Weg und jede Straße in Deutschland gibt es einen Baulastträger, der für den Unterhalt der Straße zuständig ist. Die Rad-Wegweisung an der Straße wird aber meist jemand ganz anderem gehören ! Hallo, das Radwegnetz hat einen operator. Dieser gehört dann auch zu dem Netz dazugetaggt. Wenn man das Netz nur an den Wegen erfasst, muss der operator auch an den Wegen erfasst werden. Und genau da sehe ich das Problem, denn dann kann es am Netz 2 (oder gar mehr) operatoren geben; für den Weg an sich und für die Wegweisung. Sinnvoller finde ich, wenn beim Weg der Baulastträger (für den Weg an sich) als operator eingetragen wird und in der relation der des Netzes (für die das Netz beschreibende Wegweisung). Dann können in verschiedenen relationen auch verschiedene operatoren eingetragen werden, obwohl sie das gleiche Stück Weg beinhalten. Schönen Tag wünscht Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Nabend Martin, Solche Netze werden üblicherweise spätestens nach 10 Jahren grundsätzlich überarbeitet, da sich das benutzbare Netz ändert. Kleine Änderungen gibt es ständig. Das im Gelände nach zuhalten bzw. zu überprüfen ist doch arg aufwändig. Einfacher ist es in der Relation die zuständige Stelle zu finden, sich den aktuellen Stand des Netzes geben zu lassen und das mit in der Relation zu vergleichen. Du kannst denselben Effekt über Filter in Josm bekommen oder mit Tools wie der Overpass-API. Nur weil alle 10 Jahre mal für einen bestimmten Edittyp eine Relation einen Tick einfacher ist, allen anderen Mappern in der Zwischenzeit diese Relation aufzudrängen (Edits an den betroffenen Straßen werden für alle komplexer) halte ich für unverhältnismäßig Ich sehe das genau anders herum. Nicht jeder Mapper kennt alle tags. Ich glaube, dass es mehr Leute wie mich gibt, die sich auf spezielle Gebiete spezialisieren. Wenn ich einen neuen Weg mappe, vergesse ich sicher das eine oder andere tag, wenn dort alles vollständig drin sein muss. Dagegen bin ich wer, der sich gerne auf die Radnetze stürzen würde und diese auch nach hält. Das sind dann Spezialdaten, die nicht andere Verwirren oder überfrachten und trotzdem vollständig vorliegen und genutzt werden können. *cn ist aber leider in gar Weise vergleichbar wieso, lcn=yes sagt doch genau das, was die Relation auch sagt: dieser way ist Teil des lokalen Radwegenetzes Im KFZ-System ist z.B. eine Straße entweder eine Bundes- oder eine Landesstraße. Dies ist eineindeutig. Im Radsystem kann eine Straße sowohl lcn als auch rcn und/oder ncn sein. Das wollte ich damit ausdrücken. Es grüßt Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo zusammen, Am 16.10.2013 18:24, schrieb Henning Scholland: Am 16.10.2013 14:09, schrieb Martin Koppenhoefer: ja, der operator beschriebe in dem Fall (m.E.) den Straßenunterhalt. Wenn man taggen will, wer die Schilder aufstellt und unterhält böte sich an, das als operator auf den Schildern zu taggen. Wo wir dann wieder an dem Punkt wären, dass man sich dann das Radnetz von XY nicht mehr separieren kann. ;) d.h. nach Martins Vorschlag wäre die Information, dass eine Weg fürs Rad vorgesehen ist (tag *cn am Weg) und wer dafür verantwortlich ist (tag am Wegweiser) getrennt. Das halte ich für keine gute Idee ;-) Gruß von Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo fly, Wenn wäre eher sinnvoll die Zielspinnen in einer Relation aufzunehmen. Dennoch ist für den Nutzenden die Information, dass er sich auf einem Netz befindet ziel führender, sprich ich plädiere auch dafür, die Netze in Relationen zusammen zu fassen. Da entstehen also mal wieder Sammel-Relationen. Wo ist da der Nutzen gegenüber einfaches taggen als Attribute an die Straßen ? - es kann sich der Verlauf von solchen Netzen ändern. Das ist mit einer Relation einfacher zu überblicken, als jede Straße nach den tags zu durchsuchen. - die Zuständigkeit kann sich ändern. So hat z.B. der Lahntalradweg vor einigen Jahren einen Wechsel an das Land erlebt. So was möchte ich nicht in jedem Teilstück ändern müssen ;-) - kann ein Wegstück zu mehreren Relationen/Netzen gehören. Das ist z.B. auch wieder beim Lahntalradweg (s.wikipedia) so. Wobei in dem Artikel noch nicht drin ist, das dieser Weg auch noch Teil von lokalen Netzen ist. D.h. es gäbe an den Wegen sich widersprechende Zuständigkeits-tags b.z.w. sowohl ein lcn als auch ein rcn. Das alles ist mit Relationen kein Problem. Es grüßt Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo Martin, Das könnte man auch an den einzelnen Wegen taggen, z.B. mit lcn:ref, wenn es dafür ein einheitliches Schema gäbe. Derzeit sehe ich aber nur die von dir vorgeschlagene Lösung ein note=Radstreckennetz der Stadt A anzubringen, und das ist ohne Relation doch zuviel der Redundanz. lcn_ref als Krücke gibt es zwar, wenn es allerdings ein ref gibt, würde ich pro ref eine Route als Relation modellieren. Die Info Radstreckennetz von Stadt A bringt m.E. gar nichts, aber vielleicht übersehe ich da ja was? Solche Netze werden üblicherweise spätestens nach 10 Jahren grundsätzlich überarbeitet, da sich das benutzbare Netz ändert. Kleine Änderungen gibt es ständig. Das im Gelände nach zuhalten bzw. zu überprüfen ist doch arg aufwändig. Einfacher ist es in der Relation die zuständige Stelle zu finden, sich den aktuellen Stand des Netzes geben zu lassen und das mit in der Relation zu vergleichen. In den tag note hätte ich eher eingetragen, von wo nach wo die Route führt, so dass man im Editor die richtige Route auswählen kann. Das hatte ich schon mal erläutert. Netze werden nicht aufgebaut als Summe von Strecken von A nach B. Es ist eine Summe von Zielspinnen, die sich auch noch überlagern. Es gibt keine festen Streckenabschnitte (sie können sogar verlegt werden), es ist eben ein Netz. Das machen wir beim Straßennetz ja genauso, nur weil es ein Netz gibt heisst das nicht, dass das in OSM in _einer_ Relation gesamtheitlich enthalten sein muss. Das Straßennetz ist eben ganz anders aufgebaut (hierarchisch und grob nach Reise-Geschwindigkeit). Ein Radnetz nutzt alle verfügbaren Wege, eine Unterscheidung nach Reisegeschwindigkeit ist bisher fast nicht vorhanden. (Das einzige, was es gibt, ist einen Baum als Streckenpiktogramm für teils nicht alltagstauglich) Gruß von Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo Manuel, Bei einer sauber gepflegten Karte kann ein mitegeführtes Navi den Job dieser grünen Radwegweiser übernehmen und oft auch übertreffen. OK, aber woher bekommt die Karte ihre Infos? Ich finde die mit Wegweisern ausgestatteten Netze von ihrer Qualität oft auch sehr ärgerlich und schäme mich für Kollegen, die solches verbrechen. Aber dennoch ist es erstens im Gelände und gehört somit in Karten und zweites sehe ich keine Möglichkeit ein anderes operationalisierbares Maß für ein Radnetz zu finden. Wenn schon eintragen, dann könnte ich noch am ehesten verstehen, wenn der Wegweiser an sich eingetragen wird. Eventuell so: http://wiki.openstreetmap.org/wiki/DE:Relation:destination_sign Und dann wäre da noch: http://wiki.openstreetmap.org/wiki/Key:destination:sign Und da kann die Relation mit ihren dort eingetragenen Ansprech-Institution helfen und Daten zur Verfügung stellen, die nicht mühsam und oft Fehlerbehaftet im Gelände erhoben werden müssen. Grüße von Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo fly, Für eine Relation spricht weiterhin, dass sich die Netze überlappen können. So kann ein Weg an einer Stelle nur eine Oberflächenbeschaffenheit haben, jedoch unbegrenzt viele Radwegnetze. Frage mich ja wieviele dieser Netze mit unterschiedlichen Betreiber Sinn machen. Darüber lässt sich genauso vortrefflich streiten wie über die Sinnhaftigkeit der Streckenauswahl eines Netzes. Das ist aber eine andere Baustelle, die ich als ADFCler angehe, als Planer versuche so gut wie möglich zu machen, und mich als OSMler nix angeht. Denn Karten sollen die Wirklichkeit abbilden. Sie können auch herangezogen werden um Arbeitsmaterial für die anderen beiden Bereiche zu sein. Aber man sollte tunlichst eine Vermischung unterlassen. Nein, für so ein Netzt reicht ein simpler Tag an den Wegen. Wenn Relation, dann noch bitte Routen mit Richtungen. Routen können Teil eines Netzes sein, aber ein Netz besteht eben nicht aus der Summe von Routen. Grürzi Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo Rainer, Was fuer die Fahrrad-Navigation jetzt noch sinnvoll waere, waere eine Abstufung der Wege, wie es aehnlich auch fuer die Strassen gibt (highway=motorway, trunk, primary, secondary, ...). Wobei es hier sinnvoller waere, ein Fahrradweg-Hierarchie-Attribut gesondert vom highway-Attribut zu fuehren. Man kann beide Einstufungen nicht von einander trennen. Sieht man von Straßen ab, die mit Radspur, Radweg o.ä. versehen sind, dann ist eine Straße je höher sie für den motorisierten Verkehr eingestuft ist um so ungeeigneter für den Radverkehr. So einfach ist es leider nicht. Bei einer Entwicklung von einem Radnetz gibt es immer ein Wunschliniennetz, das dann an die Realität angepasst werden muss. Dann kann auch eine Hauptstrecke für den Radverkehr an einer Bundestrasse verlaufen, weil es entweder keine Alternative gibt, sie ein zu großer Umweg wäre, die Qualität der Oberfläche schlecht ist, oder ... Nur ein kurzer Einwurf von Wolfgang RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
