Re: [Talk-de] Starrflügel-Drohne für Luftbilder
On Fri, Aug 14, 2020 at 06:35:44PM +0200, Florian Lohoff wrote: > Ich hab mich grob an dem hier Orientiert - Der hat eine komplette > Teileliste: > > https://blog.seidel-philipp.de/fpv-wing-aus-kopter-teilen-bauen-mit-inav/#Empfohlene_Teileliste > > Der hat da alles was du brauchst als Erklärung. Ach ja - Das ganze First Person View (FPV) zeugs hab ich natürlich weggelassen. Das hat mich nicht interessiert. Insgesamt ist der Styroporflieger leider ein ganz kleines bisschen zu klein für den Kameraeinbau. Man sägt doch ordentlich dran rum. Ich habe auch Steuerung und co alles nach vorne in die FPV Bay verlegt damit ich zentral platz für den Akku und die Kamera habe. Akku ist mit Abstand das schwerste und muss möglichst nah an den Schwerpung/Neutralpunkt. Also statt 80cm Spannweite hätte ich lieber 1m und ne größere Bay innen. Aber gut. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Starrflügel-Drohne für Luftbilder
Hi Frederik, On Fri, Aug 14, 2020 at 11:59:15AM +0200, Frederik Ramm wrote: > Hallo, > > kennt sich jemand aus beim Stand der Technik mit Starrflügel-Drohnen? > Ich hätte gern so eine, die man in die Luft schmeisst und die dann ein > paar Bahnen über dem Baugebiet dreht und ein schönes Luftbild macht. Und > möglichst keine 20.000 Euro kostet ;) > > Wenn ich die Rechtslage richtig verstehe, ist es ja nicht verboten, dass > die Drohne selber (nach einer vorporogrammierten Bahn) fliegt - ich muss > sie lediglich immer im Blick haben und die Steuerung übernehmen können, > falls was wäre, oder? Ja - ich habe das gebaut mit zeugs von Hobbyking und Co. Rechtslage mal aussen vor gelassen - Ja - Die fliegt autonom und man kann das einfach planen - Mit ein bisschen Übung kriegt man die in die Luft geworfen ohne das was zu Bruch geht. (Am Anfang macht man einfach mal ein paar Propeller kaputt weil man den Boden küsst) aber das ist quasi Verbrauchsmaterial. Am Ende hat die ne schöne Steuerung (Alles Open Source) die automatisch Startet wenn man sie in die Luft wirft (Also gerade leveled und leicht steigt mit Vollgas) bis man die Steuerung übernimmt - Dann kann man manuell fliegen oder eben über einen Switch die vorprogrammierte Flugbahn aktivieren. Dann steigt der auf die Sollhöhe und fliegt dann eben ein Muster ab. Hier war das eher so nen bisschen schwierig weil das dingen ECHT Strecke macht. D.h. einfach nur ein paar linien sind ggfs schwierig weil der natürlich am ende Wenden muss und das braucht raum d.h. auf 20m wendet der nicht. Bedarf auch ein bisschen Übung das zu planen. Man sieht dann hinterher im GPS Track schön wie sehr der auf der Planung geblieben ist. Das Dingen liegt schön ruhig in der Luft und die Bilder sind entsprechend gut. Man kann das dann zusammenstitchen mit dem OpenDroneMap zeugs und man bekommt Bilder. Ich habe den Akku noch nie leer genudelt und Airtime ist 60 Minuten und länger wobei ich nach 20 Minuten immer mit allem Fertig war. Die hat ein "Return to Home" was sehr schick ist. Wenn man sich nicht mehr sicher ist wie die Fluglage gerade ist - Switch umlegen und die kommt zurück und fängt über dir das kreisen an. Ich habe das mal in Neubaugebieten gemacht wo nur die Planstraßen bisher da waren so das ich die schonmal habe. Leider ist nach dem Zusammenstitchen mit dem OpenDroneMap zeugs die Lagegenauigkeit nicht zu vergleichen mit dem was z.b. bei den Deutschen ESRI Bildern man so kennt/erwartet. Vielleicht bin ich da auch einfach nicht so weit oder hab Dinge nicht verstanden. Teilweise hat man eben auch Warp. D.h. die Kanten sind gut aber in der Mitte ist es gestaucht und gestreckt. Aber gut - Um eine Straße und ggfs ein paar Bäume/Rohbauten reinzunageln damit man überhaupt was hat geht das gut. Kosten waren glaube ich <500€ und nen paar Tage basteln. Kamera hab ich mir die kleine Powershot meiner Tochter geklaut und dann die CHDK Firmware drauf gemacht damit die einfach jede Sekunde ein Bild macht. Ich hab mich grob an dem hier Orientiert - Der hat eine komplette Teileliste: https://blog.seidel-philipp.de/fpv-wing-aus-kopter-teilen-bauen-mit-inav/#Empfohlene_Teileliste Der hat da alles was du brauchst als Erklärung. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging historischer, aber nicht amtlicher Straßennamen?
On Sun, Jul 12, 2020 at 07:29:23PM +, Elstermann, Mike wrote: > Hallo zusammen, > > wie kennzeichnet man eine Straße richtig, die es früher gab, die heute noch > als Bauwerk vorhanden, aber nicht im aktuellen amtlichen Straßenverzeichnis > geführt wird? > > https://www.openstreetmap.org/way/11609716#map=18/51.49553/11.97901=D Es gäbe ja sowas wie old_name. https://wiki.openstreetmap.org/wiki/Key:old_name Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?
Hi Volker, On Thu, Jun 25, 2020 at 01:05:55PM +0200, Volker Schmidt wrote: > Ohne Kenntnis vor Ort (Manuel, kannst du eine Beispiel verlinken, am besten > mit Foto) würde ich sagen: > Driveways, zumindest solche die für Anlieferverkehr benutzt werden, sollten > als routable highway in den Daten stehen. > Für das Rendering ist im beschriebenen Fall eine Fläche nützlich, daher > würde ich area:highway=* für geeignete halten. > > @Florian: Ich verstehe das "nur" in deiner Bemerkung "Jegliches > Flächenmapping ist nur für den Renderer" nicht. Natürlich sind OSM Daten so > zu strukturieren, das ein Renderer sie "verdauen" kann, und daraus > Landkarten herstellen kann (steckt sogar im Namen des Projekts: OpenStreet > *Map*). Aber wir erfassen Fakten und das machen wir nicht ausschliesslich um eine "Schönen visuellen Eindruck" zu bekommen. Das sind z.b. die ganzen Vorgärten die als landuse=grass eingetragen werden was einfach nur eine Vergewaltigung der landuse tags ist. Und ja - wir wollen Straßen irgendwann als Flächen erfassen aber für das routing bringt das nichts. Das ist eben nur damit es schöner aussieht was MIR relativ egal ist. Und wenn jemand das einträgt ist das eben NUR für das schicke aussehen. Die Aussage zwischendurch "... IMO nur da verwendet werden, wo eine Bewegungsrichtung nicht sinnvoll ist." suggeriert das ein Flächenmapping irgendwas mit Bewegungsrichtungen zu tun hat ist halt falsch. Die Fläche ist eben nur schick zum ansehen und hat mit Bewegung im Routing/Navigation nichts zu tun. Und Fläche ersetzt nicht den eigentlichen Weg sondern ergänzt den nur. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?
Hi, On Wed, Jun 24, 2020 at 10:10:10PM +0200, Hubert87 wrote: > Dem würde ich widersprechen. > hw=* + area=yes sollte IMO nur da verwendet werden, wo eine > Bewegungsrichtung nicht sinnvoll ist. z.B. Marktplätze. Dann aber ohne > zusätzlichem hw=* (vom gleichen Typ) "quer" über diese Fläche. Quer über die Fläche geht mit aktueller Technik sowieso nirgends. Jegliches Flächenmapping ist nur für den Renderer. > @Manuel: Bitte schau mal nach, ob ggf area:highway etwas für Dich ist. > Wird aber noch nicht auf osm.org gerendert, aber das steht sowieso auf > einer anderen Seite. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?
On Tue, Jun 23, 2020 at 07:18:37PM +0200, Manuel Reimer wrote: > Hallo, > > bei uns gibt es in der Nähe mehrere Ansammlungen von Garagen. Die Zufahrten > dazu habe ich alle mit "highway=service" und "service=driveway" eingetragen. > Allerdings entspricht das eigentlich nicht den örtlichen Gegebenheiten. > Für's Routing wäre es nicht falsch (sofern es wirklich jemand nötig hat sich > bis in seine Garage routen zu lassen) aber eigentlich ist die ganze Fläche > vor und zwischen den Garagen-Reihen gepflastert. Man könnte einen beliebigen > Weg über dieses Pflaster zur Garage nehmen. > > Wäre es nun richtig, bzw. sinnvoll die Fläche *zusätzlich* zu den Wegen mit > "area=yes" und den gleichen Tags wie für die Wege zu versehen um > darzustellen das die ganze Fläche "driveway" ist? Falsch ist das nicht. Für das Routing ändert das nichts. Sieht vielleicht nur "hübscher" in der Karte aus. Ich mache sowas nicht weil ich immer denke "je mehr Objekte des komplizierter das zu maintainen". Also trage ich Zeugs ein was FÜR MICH Sinn ergibt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [OSM-talk] Facebook kauft Crowdsourced Mapping Firma Mapillary
On Fri, Jun 19, 2020 at 09:19:46AM +0200, Martin Koppenhoefer wrote: > > > sent from a phone > > > On 19. Jun 2020, at 09:09, Florian Lohoff wrote: > > > > Ja das ist > > eine Datenkrake aber bisher ist doch nichts passiert!?! > bei Facebook ist schon einiges passiert. Klar, kann einem evtl. egal sein, > aber zu sagen bisher ist überhaupt nichts passiert, trifft es eher nicht für > mich. Bei Facebook schon aber nicht bei Mapillary. Da werden gerade Pferde scheu gemacht obwohl noch nichts passiert ist. Vorsorgliche schonmal alles löschen. > > Also warum die > > aufregung. Wenn die dann die mapillary app einstellen und an eine > > facebook id koppeln dann können wir immer noch maulen. > > dann wird es auch dem letzten klar werden, aber “machen” kann man dann > nichts mehr. Noch kann man sich die eigenen Bilder kopieren (falls man > sie nicht sowieso auch lokal in Kopie gehalten hat) und hoffen dass > jemand irgendwann einen alternativen Dienst anbieten wird, wo man sie > hochladen kann. Machen kannst du auch heute an der nummer schon nichts mehr. Wir sind und waren eh immer nur Beifahrer. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [OSM-talk] Facebook kauft Crowdsourced Mapping Firma Mapillary
On Fri, Jun 19, 2020 at 08:52:55AM +0200, Hessler, Klaus-Michael wrote: > Danke Michael und Markus, > > > Weitergeleitete Nachricht > > > Betreff: [OSM-talk] Facebook acquires crowdsourced mapping > > > company Mapillary > > > Datum: Thu, 18 Jun 2020 22:32:42 + > ich war kurz davor, mich dort anzumelden und die Funktionen zu nutzen. > > Ist die OSMF oder sonstwer dabei, eine Alternative zu schaffen? > Was ist mit OpenStreetCam > <https://wiki.openstreetmap.org/wiki/OpenStreetCam>(DE > <https://wiki.openstreetmap.org/wiki/DE:OpenStreetCam>), gefunden über > AlternativeTo.net <https://alternativeto.net/software/openstreetview/>? Was > kann OpenStreetCam nicht, gibt es bessere Alernmativen? OpenStreetCam kann keine Wege die nicht von Autos befahren werden. Sprich. OSC mapped Bilder auf die Wege in OSM - Sind die Wege nicht dar oder nach deren Meinung nicht befahrbar siehst du die Bilder nicht auf der Karte (Sie sind aber da). Hat den Nachteil das du nur Fotografieren kannst was schon da ist, und halt auch nur Auto zentrierte Infrastruktur. Mapillary ist um längen zuverlässiger und passt deutlich besser zu OSM. Ich sehe die Übergang zu Facebook nicht als so gravierend. Ja das ist eine Datenkrake aber bisher ist doch nichts passiert!?!? Also warum die aufregung. Wenn die dann die mapillary app einstellen und an eine facebook id koppeln dann können wir immer noch maulen. Ich sehe da gerade einen Vorteil denn ich habe mich immer gefragt wie Mapillary den Storage bezahlt. Ich alleine hab da vermutlich ein Terrabyte an Bildern reingeschoben. Und das ja nur für einen ganz kleinen teil der Welt. Die Kosten müssen explodiert sein was die "lagerung" der Daten angeht. Hier kann halt Facebook aushelfen. Für die sind die Datenmengen peanuts. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
On Wed, Jun 03, 2020 at 11:06:58AM +0200, pbnoxious via Talk-de wrote: > Hallo, > > ich finde gerade die Diskussion oder den Wiki-Eintrag nicht mehr, aber > in meiner Erinnerung war für "sidewalk" und "lit" die Regel, dass > Straßen innerorts (also v.A. highway=residental, aber auch größere > Straßen) normalerweise sowohl beidseitige Gehwege haben als auch > beleuchtet sind, während es außerorts genau anders herum ist. Besonders > Abweichungen von der Beleuchtung (also z.B. unbeleuchtete Straßen > innerorts) sind ja in Deutschland wirklich eher die Ausnahme als die Regel. Sowas würde und kann sich nicht durchsetzen weil wir dann erstmal alle Straßen taggen müssten die Inner oder Ausserorts sind. Da wir das nicht machen folgt dem das wir alles wohl explizit setzen müssen. Und bei den tags wie sidewalk, shoulder, cycleway, lit, surface mache ich das - Bei oneway nicht. Und da stellt Volker natürlich zurecht die Frage warum. Und das einzige was mir als Unterscheidungskriterium einfällt ist die Statistische Verteilung der tag values Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
Hola, On Tue, May 26, 2020 at 12:04:11PM +0200, Protoxenus via Talk-de wrote: > Flo schrieb: > > > > > > Wenn kein Fußweg/Radweg da ist, wird auch keiner getaggt, das ist das "NO". Keiner getagged heist kein tag - nicht sidewalk=no > > Wenn du das damit aufweichst, öffnest du damit wieder die Büchse der Pandora. Ich weiche nichts auf - Das ist wie es heute läuft. Wenn etwas nicht da ist wird es nicht getagged. Siehe Beispiel oneway=no. Die frage ist eben wie wir "Zustand unbekannt" und "Nicht getagged d.h. nicht existent" unterscheiden. Und da gibt es kein Patenrezept für. Wenn ich Gebiete nach Mapillary Bildern überarbeite dann kriegen alle Wege ein lit=yes/no shoulder=no/left/right/both sidewalk=no/left/right/both cycleway=no/left/right/both surface= lanes= maxspeed= (Ausser living_street) source:maxspeed= ggfs dann noch: priority_road=designated hazmat=designated > Einmal das > > "NO", es ist nicht erlaubt: -> du darfst hier nicht lang > und > "NO" es ist nicht da: -> keine Beleuchtung Nein - Der unterschied - "Wir wissen es nicht" und "Keine beleuchtung" Die Absenz des "lit=no" kann heissen - "Hat sich keiner drum gekümmert" oder eben "Es gibt keine Beleuchtung" Deshalb ist das explizite taggen eben dann die Aussage - "Ja - Ich habe hingesehen - Nein - es ist nicht beleuchtet". Aber wie weit treiben wir das. Auch in tags die eine Verteilung von 99.999% zu 0.001% haben? Dann haben wir demnächst noch überall ein tunnel=no covered=no auf allen wegen. Also bei welchen tags machen wir das und bei welchen nicht? Und wie unterscheiden wir - "Hab ich mir angesehen - ist nich da" und "Hab sich niemand angesehen" > Wir haben einen "Grundzustand", der ist = "nichts", alles Andere wird > hinzugefügt. Falsch - Implizit sind auf allen wegen access tags. Siehe auch die wiki Seite zum Thema routing access tags und es ist eben ein oneway=no angenommen. D.h. es gibt ganz viele implizites wissen das wir erstmal annehmen aber nicht taggen. > Als ich bei OSM angefangen habe, galt die Regel: Was nicht da ist, > wird auch nicht getaggt. Leder wird das immer mehr aufgeweicht. So - Straßenbegleitender Radweg - Linksseitig nutzbar und ggfs sogar angeordnet - Taggst du den mit oneway=no? Taggst du alle anderen die nur rechtsseitig Nutzbar sind mit oneway=yes? Ich finde hier das taggen von oneway=no bei angeordnetem linksseitigem Radweg für extrem hilfreich weil es eben genau diese information beinhaltet. Macht das Sinn das auf allen Wegen zu machen die keine Einbahnstraße sind? Und wenn wir tags haben mit einer Verteilung von 50:50 dann macht das taggen beider Zustände richtig viel Sinn, dann wird klar - haben wir uns angesehen. Ab welcher Verteilung macht das keinen Sinn mehr weil der "yes" fall so selten ist das das taggen von "no" Unsinn wird. Absolute ausnahmen wie covered oder tunnel machen sicherlich keinen Sinn. Shoulder? Lit? Oneway? Sidewalk? Cycleway? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] openstreetcam tot?
Hola, On Mon, Jun 01, 2020 at 07:00:52PM +0200, Martin Scholtes wrote: > Hallo Flo, > > hättest besser die Mail heute morgen schreiben sollen. Mano. Naja - ich war den ganzen Tag unterwegs neue Bilder machen. Und hab eben gesehen das der immer noch nicht fertig war mit den Bildern. > Aber ich habe es auch gemerckt, das der Upload länger als normal dauert, > und gerade jetzt geht gar nichts mehr. Naja die letzten 2 Wochen hat das immer schon die ganze Nacht gedauert da Zeugs reinzuschieben. Im moment produziere ich am Tag ~6-10k Bilder und wenn ich zwischen 60 und 150 Sekunden je Bild brauche sind das halt 12000 Minuten für den Upload wenn es doof läuft. Sind halt 10 Tage für einen Tag Bilder. Ich uploade noch an den Bildern vom 28.5. Hab im moment noch 34000 Bilder hier liegen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] openstreetcam tot?
Hi, seit ein paar Tagen bin ich wieder intensiv am Bilder aufnehmen und lade die hauptsächlich bei Mapillary hoch. Jetzt hab ich mir gedacht das es ja auch Sinn machen könnte die zu OpenStreetCam hochzuladen. Tja - Upload ist eher so bei 90-150s je Bild. Das war bei Mapillary in 45 Minuten getan ist dauert bei OpenStreetCam jetzt schon 3 Tage. Ich produziere im moment mehr Bilder in 24h als ich sie bei OpenStreetCam hochladen kann. Und das liegt nicht an meiner Bandbreite. Dazu tauchen die Uploads in meiner Seite nicht mehr auf. Uploads von vor 4-5 Tagen sind immer noch im Zustand Processing. Das wirkt irgendwie nicht wie ein lebendes Projekt. Dazu scheint der twitter account seit etwa 1nem Jahr ziemlich tot - Antwort hab ich da auch nicht bekommen. Weiss da jemand genaueres? Gibts da eine Mailingliste/Forum oder einen Bugtracker für das operative Projekt? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Position des FOSSGIS e.V. zu bezahlten Kräften in der OSMF
Hola, On Mon, May 25, 2020 at 10:14:23PM +0200, Michael Reichert wrote: > > Eine gemeinsame Position des FOSSGIS e.V. als Local Chapter der OSMF in > Deutschland zu diesem Thema wird Tagesordnungspunkt auf der nächsten > Vorstandsitzung des FOSSGIS e.V. am Dienstag, den 1. Juni 2020 um 20:00 > Uhr auf dem Mumble-Server podcast.openstreetmap.de sein. > > Welche Meinung habt ihr zu bezahlten Kräften in der OSMF dazu? Stimmt > ihr dem obigen Konsens zu? Oder seid ihr anderer Meinung? Ich habe die original Mail gesehen und hab da nen ganzen Tag so "drauf rum gekaut" und irgendwie fällt es mir schwer eine Tätigkeit zu definieren die nicht dem ein oder anderen auf die Füße tritt. Ich sehe halt den Sysadmin Kram für die OSM Server als eine Baustelle. Das wird irgendwann zu einem Fulltime job den nicht mal irgendwer nebenher macht. Aber wie will man Freiwillige da mit reinziehen. Das ist so ein "ganz oder gar nicht" Nummer. Also Entweder zahlst du dann das ganze Admin Team oder keinen - Aber so einen raus picken der dann Full time dabei ist und noch eine Herde von Zuarbeitern? Ich kann mir nicht vorstellen das so etwas funktioniert. Dann lieber allen einen Halbtagsjob anbieten. Oder sowas wie Nachteinsätze, Bereitschaft oder so zahlen. Aber vielleicht denke ich zu kurz was die OSMF Tätigkeiten angeht. Mit der europäischen Brille ist ja die OSMF eine technische Erfüllungsgehilfin. Das wird in den USA ja anders wahrgenommen. Da ist das ja eher ein "Political body" und da geht es dann vermutlich viel mehr um Community, Lobbying und Co. Und ja - ich fände es auch gut wenn es einen breiten Konsens geben würde welche Tätigkeiten da bezahlt werden und das es quasi abgestimmte Tätigkeitsbeschreibungen gibt. Daher finde ich den Kompromiss gut. Ich habe ja überhaupt keine Links zu der Wikimedia - Aber die haben ja auch irgendwann angefangen Menschen zu bezahlen und haben da den ein oder anderen Fehler begangen. Vielleicht kann man da draus lernen? Und wenn ich die Liste heute durchgucke dann Frage ich mich was die alle machen?! Gefühlt gibt es da für jedes byte einen Senior FooBar. https://wikimediafoundation.org/role/staff-contractors/ Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
On Mon, May 25, 2020 at 01:08:33AM +0200, Tobias Knerr wrote: > Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu > Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja > maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no > access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und > wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung > besteht – lege ich dann jeweils eine Relation mit restriction=allowed > an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem > Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer > Abfalleimer steht, ...? > > Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die > Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht > erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist > (weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den > Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte > Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall > sein. Ich überlege gerade was ist mit lit/cycleway/sidewalk/shoulder ? So einfach ist es eben nicht. Es gibt zwar defaults die auch Sinn machen. Es gibt dinge deren "seltenheit" macht es Unsinning eben den umgekehrten fall zu taggen oneway=no als Beispiel. Aber was ist mit lit? Da sind ja sowohl lit=no wit auch lit=yes eine information. Und bei lit ist die Verteilung eher 80/20. Was ist mit sidewalk=no, cycleway=no? hat ja ggfs im Routing eine Auswirkung je nach Straßenklasse. Auf einem residential mit sidewalk=no will ich vielleicht noch laufen. Auf einem primary mit lit=no, sidewalk=no vermutlich eher nicht - vor allem nicht Nachts. Also die Regel das nur weil etwas NICHT existiert wir es nicht taggen ist zu kurz gesprungen. Ich glaube das funktioniert im Moment nur deshalb weil jeder da seinen Menschenverstand benutzt - oder eben auch nicht. Ich denke man müsste für jedes tag einzeln durchgehen ob es Sinn macht yes UND no zu taggen und wenn ja wann. Und für einiges haben wir defaults, für anderes aber eher so nicht - bzw eher undokumentiert und gefühlt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oneway = no
Hola Markus, On Mon, May 25, 2020 at 08:53:28AM +0200, Markus wrote: > Hallo Florian, > > >> 3 Zustände: > >> - ja > >> - nein > >> - weiss nicht > >> > >> Letzterer muss noch geprüft werden > >> (die anderen Beiden sollen regelmässig auf Änderung kontrolliert werden) > > > > Also nicht das ich nicht gerne label an Objekte hängen würde die ich > > gerne rechecken würde > > Es geht nicht um eine private ToDo-Liste. > Sondern um öffentliche Qualitätsmerkmale der Daten. Naja - Aber alles mit "weiss nicht" erstmal durchtaggen um das nach und nach abzuarbeiten? Ist für mich eine "Private ToDo Liste" Denn am Ende erhebt ja niemand den Anspruch das OSM vollständig ist, ausser vielleicht der Mapper vor Ort, und das ja auch nur für Teilaspekte. > Angenommen, man will möglichst valide Daten, möglichst zeitnah, > dann kommt man um eine Erfassung der Validität nicht herum. Validität steht ja nochmal auf einem vollständig anderem Blatt. Ob es etwas existiert oder nicht oder ob der Zustand unbekannt ist ist ja Vollständigkeit nicht Validität. Bei Validität müssen wir uns ja auf den Mapper verlassen das der Sorgfältig einträgt. Und das es eine scheinbar große Fraktion gibt die gerne nach Gefühl mapped sieht man ja gerade im Access thread im Forum. > Beispiel: > > Viele schreiben "highway=track" an eine Linie, die sie aus dem Luftbild > oder aus Erinnerung vor Ort gemappt haben (weil sie nicht oder nicht > mehr genau wissen, wie das genau war, aber Lage und Form kennen). > Für den Kenner ist dadurch ersichtlich, dass noch etwas fehlt und > verbessern das wenn sie mal vor Ort sind. > (Anfänger denken, dass "track" etwas Genaues bezeichnet, sie aber nicht > genau wissen was). Naja - So funktioniert OSM - Iterativ verfeinern wir Daten. Ich bin mit dem Zeugs was ich eintrage oft nach 10 Jahren noch nicht zufrieden. Nicht weil es unvollständig ist (Was es immer ist) sondern weil es meinen Ansprüchen nach Eleganz und Simplizität nicht entspricht. Also habe ich einen eigenen TaskManager laufen und gehe alle 2-3 Jahre die ganzen Gemeinden durch für die ich mich interessiere. Dauert dann halt 6 Monate sich nochmal alles anzusehen. Und es gibt immer was zu korrigieren. Nochmal zu durchdenken. Auch wenn sich die Realität nicht geändert hat so hat sich mein Anspruch an "Schöne Daten" geändert. Landuses werden verkleinert, anders geschnitten, Multipolygone aufgelöst. Das hat aber nichts damit zu tun das ich erstmal an alle Wege ein "lit=unknown" hänge und das nach und nach abarbeite. > Bei eindeutigen Merkmalen wie "oneway=yes" ist es klar, da steht ein > Schild. Aber wenn ich mich nur erinnere, dass dort "irgendwo" ein Schild > stand, vielleicht in einer anderen oder abzweigenden Strasse, wie kann > ich das dann angeben, damit es Dritte unterscheiden können von "da ist > (vielleicht) was" oder da ist "sicher nichts"? Ich habe 2014-2015 einen Grossteil der Gemeinden stumpf komplett via Mapillary abgelichtet, und bin gerade in einem rerun. Und ja - Ich habe eine neue Einbahnstraße entdeckt. Wie lange die existiert - keine Ahnung. Warum hat die kein anderer Mapper entdeckt? Keine Ahnung. Hätte mir irgendein tag geholfen. Nein - 2014 hätte ich ein oneway=no dran gehängt. Hätte ich mich heute stumpf daran orientiert wäre das heute noch nicht eingetragen. Also ein zu großer Verlass auf Tags ist auch sehr trügerisch - Womit wir wieder bei der obigen Validität sind. Wenn ich mich drauf verlasse was andere eintrage, und das nicht kritisch hinterfrage, ist die Karte innerhalb weniger Jahre unbrauchbar. Es ändert sich ständig was und in Großteilen Deutschlands sind wir seit Jahren im Maintenance Modus. Wie aber bekommen wir mit DAS sich was ändert. Und da hat keiner eine Antwort drauf. Ich Monitore für Adressen die wöchentlichen opendata exporte meines Kreises und kriege Diffs zugeschickt wenn die neue Adressen zuteilen. Und sowas brauchen wir viel mehr. Ich hätte gerne eine Kopie aller Verkehrsrechtlichen Anordnungen - Dann würde man sofort die Geschwindigkeitsänderungen, Einbahnstraßen und Co mitbekommen. Hab ich bloss noch nicht raus bekommen wie ich die bekomme. > Oder bei (strassen)"name=*" bei eindeutiger Ortsstrasse, deren Name ich > nicht kenne? oder bei der es gar keine Namen gibt? > > Je älter OSM wird, desto problematischer werden Konflikte zwischen > "Bekannt" und "Unbekannt". > > Und ja, wenn man das verbessern will: > - brauchen wir definierte Meta-tags > - wird die DB grösser Aber dafür müssten wir ja definieren welche use-cases wir abbilden wollen. Und Vollständigkeit ist ein ganz schlechter Use-Case weil er die Pflege bzw Änderung im Bestand verschleiert. Und ich bin nach wie vor nicht dafür das in die
Re: [Talk-de] oneway = no
On Sun, May 24, 2020 at 09:32:28PM +0200, Markus via Talk-de wrote: > Hi Florian, > > > alle default tags nochmal taggen nur damit einige wenige eine > > Vollständigkeitsstatistik führen können ist auch irgendwie missbrauch > > der osm tags oder sehe nur ich das so? > > Ich habe mal gelernt, dass es da 3 Zustände gibt: > - ja > - nein > - weiss nicht > > und dass Letzterer unbedingt noch geprüft werden muss > (und die anderen Beiden regelmässig auf Änderung kontrolliert werden) Also nicht das ich nicht gerne label an Objekte hängen würde die ich gerne rechecken würde - Hatten wir ja auch schon mit den verschiedenen Proposals was check_date oder survery_date angeht. Da wir ja wissen das Kneipen statistisch nur wenige Monate existieren wäre also ein "wiedervorlage" tag super. Die Frage ist eben nachwievor ob wir diese meta-meta informationen in die OSM Datenbank packen wollen. Ich habe da keine harte Meinung zu aber ICH packe meinen Kram da nicht rein sonst explodiert das was ich mir gerne alles merken würde und dann haben wir hier Streit wegen der ganzen tags ;) Und jedes halbe Jahr ändert sich ja der Fokus was man an Tags komplettieren möchte und dann fängt man wieder an sich mehr meta-meta tags zu erfinden. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oneway = no
On Sat, May 23, 2020 at 07:04:07PM +0200, Volker Schmidt wrote: > Aus welchem Grund siehst du das bei Radwegen anders als bei Strassen? > Das Problem ist genau das gleiche. > Dummerweise gibt es keinen tag value "positivly yes".im Gegensatz zu dem > Ansatz missing tag fehlt = tag with default value. > > Ich wuerde dich dringend bitten, wenigstens in Zukunft keine Loeschungen > von "vollkommen redundanten" tags mehr vorzunehmen. Danke im Voraus. Aeh - Das ist ein großer unterschied. Straßen sind zu 99% und mehr keine Einbahnstraßen. Also macht es keinen Sinn die 99% zu taggen sondern die 1% ALLE Straßenbegleitenden Radwege sind aber oneways. D.h. da sind wir vermutlich bei 70-80% die ein oneway sind - daher macht es bei denen die es nicht sind Sinn diese explizit zu taggen. Hier tagge ich die 20% abweichenden zusätzlich zu den 70% die ich eh taggen muss. Einfach Statistik. Und alle default tags nochmal taggen nur damit einige wenige eine Vollständigkeitsstatistik führen können ist auch irgendwie missbrauch der osm tags oder sehe nur ich das so? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=crossing -> highway=traffic_signals
Hi, On Sat, May 23, 2020 at 04:48:17PM +0200, Volker via Talk-de wrote: > Hat das vielleicht etwas hiermit > https://forum.openstreetmap.org/viewtopic.php?id=69290 > zu tun? Das Proposal ist allerdings > rejected.https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only > Das will ich nicht ausschliessen. Kann es sein das irgendein validator oder QA tool das als Fehler raus wirft und änderungen Analog des proposals empfiehlt? Ich sehe halt Änderungen im routing weil natürlich eine Ampelkreuzung anders als Fußgängerampeln bewertet werden. D.h. bestimmte routen werden "länger" bzw langsamer. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] highway=crossing -> highway=traffic_signals
Hi, ich sehe in den letzten Wochen immer mehr mapper die Fußgängerampeln umtaggen von highway=crossing crossing=traffic_signals zu highway=traffic_signals +++ Gibts da irgendeinen Grund für? Ich halte das für falsch aber vielleicht vertue ich mich da ja auch. Mir ist das nur aufgefallen weil dadurch die travel zeiten im routing hoch gehen weil ein highway=traffic_signals anders bewertet wird als crossing=traffic_signals - Was ja auch richtig ist. Ist das eine Koordinierte aktion? Ist das ein validator der das als Fehler auswirft? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
On Fri, May 22, 2020 at 03:15:14PM +0200, Volker Schmidt wrote: > Bin durch Zufall auf diesen Changeset > <https://www.openstreetmap.org/changeset/43566283> gestossen, in dem > oneway=no entfernt wurden. > Ich persoenlich setze routinemaessig oneway=no um anzuzeigen, dass ich > geprueft habe, dass die Strasse keine Einbahnstrasse ist. In Verbindung mit > dem Aenderungsdatum ist das nuetzlich in Gegenden, wo Strassenrichtungen > haeufig von den Behoerden geaendert werden. > > Daher meine Fragen: > (1) ist das community consensus in DE, dass oneway=no entfernt werden > sollten ? > (2) falls ja, sollte das nicht als Massen-Edit im Wiki dokumentiert werden? > (Falls ich eine entsprechende Diskussion und Entscheidung verpasst habe, > bitte ich um Nachsicht) oneway=no auf Straßen halte ich für overkill. Für 1% der Straßen die Einbahnstraßen sind (Geschätzt) setzen wir auf 99% ein oneway=no - Weiss nicht ob DAS effizient ist. Ich mache das nicht. Ich "bereinige" das aber auch nicht großflächig. Was anderes ist das auf Straßenbegleitenden Cycleways. Da finde ich ein oneway deshalb spannend weil es eben anzeigt das der Beidseitig genutzt werden kann. D.h. Linksseitiger Radweg ist freigegeben. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Wed, Apr 29, 2020 at 01:11:32PM +0200, Volker Schmidt wrote: > Ich halte das mit maxspeed:practical fuer eine ziemliche Kruecke. > Habe mich mal umgeschaut, und die meisten Beispiele, die ich gefunden habe, > waren Strassen, wo fast alle relevanten tags fehlten: > lanes, width, surface, incline, oneway, smoothness, lit > Ich halte es fuer besser den Strassenzustand zu beschreiben, und dem Router > zu ueberlassen, was er daraus macht (auch mit der Analyse der Geometrie), > als mit fiktiven Werten eine erwuenschtes Verhalten zu errreichen. > Ausserdem ist der tag selten (1300 in Deutschland und die beschraenkt auf > kleine Zonen, wo offensichtlich jeweils ein mapper in seiner Umgebung alles > damit voll gepflastert hat). > > Um noch mal auf das urspruengliche Beispiel ( Liemekestrasse > <https://www.openstreetmap.org/way/23737060> ) zurueckzukommen. > Wenn der Router eine Strasse trifft mit maxspeed=100 und > motor_vehicle=designated, width=4 dann geht das schief. Die meisten Router > addieren Strafpunkte oder Bonuspunkte. In jedem Fall hat das falsche > tagging den Effekt, das zwei starke Vorteile (100km/Stunde und reserviert > fuer KFZ), den einen Nachteil (schmale Strasse) "ueberstimmen". Falsches > mappen sollte man nicht austricksen, sondern korrigieren. Im vorliegend > Fall waere der lokale mapper anzuschreiben, dass er die Situation vor Ort > kontrolliert und das tagging korrigiert. Ich kann mir nicht vorstellen, > dass eine 4m breite Strasse in DE nicht Geschwindigkeits-begrenzt ist. Ausserhalb geschlossener Ortschaften gilt 100km/h - Damit gilt am Ende auf jedem Feldweg 100 - Nicht das das fahrbar wäre oder auch dem Vorrausschauenden Fahren entspricht. Rechtlich ist das richtig. Und OSRM macht daraus: if width <= 3 or (lanes <= 1 and is_bidirectional) then width_penalty = 0.5 end D.h. wenn die Breite <3m (Also nur eine Fahrspur) oder eben lanes=1 ohne oneway ist dann ist die penalty 1/2 maxspeed - Also in diesem fall 50kmh. Und ich finde das trifft es ziemlich gut. Deshalb kann man die width taggen (Was ohne vor ort hinzufahren und mal nachzumessen oder zumindest mal schritte zu zählen schwer ist) oder eben lanes=1 - Nachweislich ist es nur eine Fahrspur. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 09:15:39PM +0200, Tom Pfeifer wrote: > On 28.04.2020 17:35, Florian Lohoff wrote: > > Die Frage war wie ihr das mit der relativen Gewichtung von > > Routingalternativen bearbeitet und fixed. > > Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man > realistischerweise auf einer Strasse vorankommt. > https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical > > Auch hierzu das Beispiel Irland - bei der Umstellung der Geschwindigkeiten > von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale > Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die > rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene > Straße, die sich auch alle paar Meter windet, und gleich der Trecker > um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit > 15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router > zu mehr Realismus. OSRM supported das mit dem :practical nach meinem profile nicht - Den nehme ich seit 2013 für die routing analyse weil schnell und prima scriptable. Wer supported das denn? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 05:57:51PM +0200, Volker Schmidt wrote: > lanes=1 ohne oneway=no|yes wird von einigen (auch von mir als moeglicher > Fehler) betrachtet, und ist daher keine gute Idee. Warum? Woher nimmst du diese Erkenntnis? Gibts in irgendeinem Wiki Artikel was zu? Das wäre mir völlig neu. "lanes" beschreibt die Anzahl der markierten! Fahrspuren. D.h. alle Straßen ohne Fahrbahnmarkierungen sind tendentiell lanes=1 - Der lanes Artikel spricht davon das dann auch with benutzt werden KANN bzw das width nützlich sei. > Kennst du die Gegend persoenlich? Ja - Aber nicht mein mapping hotspot - Und es geht mir auch nicht um die millionen Fehler die da rumlungern. Mir sind nur routingänderungen aufgefallen die ich für unsinn halte die durch sparse tagging ausgelöst waren. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 03:17:16PM +0200, Tom Pfeifer wrote: > On 28.04.2020 14:44, Florian Lohoff wrote: > > Nachdem ich dann die neue grünen teil mit lanes=1 > > versehen habe ist soeben die route zurück geschwenkt. > > Entspricht denn lanes=1 der Realität? > Also der Verkehr in beiden Richtungen teilt sich eine Spur? Wenn du aneinander vorbei möchtest muss einer auf die Bankette - ja - Mindest wenn die ein Trecker oder was breiteres entgegen kommt. Ich frage mich aber warum sich alle an DIESEM konkreten fall hochziehen. Die Frage war wie ihr das mit der relativen Gewichtung von Routingalternativen bearbeitet und fixed. Oder bin ich der einziger der sich sowas systematisch ansieht? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 01:12:30PM +0200, Volker Schmidt wrote: > Beispiele? Das war der Schwenk heute morgen. Grün ist neu. Da wird dann der vermeindliche Autofahrer durch eher den Outback geschickt bzw durch die Siedlung (maxspeed=30). Da hatte jemand den dem neuen Grünen teil am westlichen Ende maxspeed=100 getagged. Macht halt wenig Sinn. https://osm.zz.de/routeqa/?rid=187615,203745 Nachdem ich dann die neue grünen teil mit lanes=1 versehen habe ist soeben die route zurück geschwenkt. https://osm.zz.de/routeqa/?rid=203750,203905 Ich weiss aber nicht was das mit der theoretischen Betrachtung von Straßengewichtungen zu tun hat. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gewichtung der Straßen im Routing
Hi, ich habe gerade wieder so zeugs repariert wo jemand im Aussenbereich auf Straßen die eher zur Erschließung der Streusiedlungen gedacht sind mit einem maxspeed=100 bedacht hat. Natürlich ist das rechtlich richtig aber leider völlig an der Realität vorbei. Das hat natürlich sofort dazu geführt das im routing das als "rat-race" Strecke präferiert hat ggü der breit ausgebauten Landstraße die aber vielleicht ein maxspeed=70 hat. Ich habe jetzt da auf dem Rat-Race strecken ein "lanes=1" hinterher geworfen was im routing (Zumindest OSRM) die erwartete maxspeed halbiert was vermutlich (Bestätigung kommt in 1 1/2 Stunden aus meinem Automatismus) das wieder fixed. Relative Gewichtung von Straßen untereinander sollte ja wenn alles sauber getagged ist in 95% der Fälle die Priorität des "offiziellen" Straßennetzes wiedergeben. Leider ist unser tagging was maxspeed, lanes, shoulder, surface, width angeht ja eher so sparse was das routing ziemlich "kaputt" macht. Wir als OSM wollen ja nicht Leute quer durch die Siedlung schicken wenn es eine Bundesstraße gibt. Wie handhaben hier andere so dinger? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vergleichsplugin Amt/OSM ? e: Datenqualität open data NRW und OSM
Hola Ludwig und Co,
On Tue, Mar 10, 2020 at 10:11:00PM +0100, Ludwig Baumgart wrote:
> Hallo Otto,
>
> wenn Du als QGIS-ler-Spezialist mit einem Plugin etwas für uns OSM-ler
> entwickeln könntest, fände ich das sehr gut.
>
> Ganz im gleichen Sinn wie Florian und Martin:
>
> Hier in BaWü sind zwar nicht einmal die amtlichen Luftbilder für OSM
> freigegeben, aber es gibt in nahezu jeder Kommune (über deren Rahmenvertrag
> mit dem LGL-BW) die umfänglichen amtlichen Datensätze (NAS-Format für
> PostgisDB) incl. Luftbild. Da wäre ein solcher "Gebäude-Vergleichs-Plugin"
> zwischen OSM-Gebäuden und amtlichen Gebäuden sehr wertvoll.
Am Ende brauchst du da kein großes Plugin.
Mit ogr2ogr bekommst du die NAS Daten in eine Postgis (Das dauert aber
17 Jahre und noch 2 Schneewittchen lang - Was ein ineffizientes Format)
Danach lädst du dir mit osm2pgsql ein pbf des Ausschnittes in dieselbe
Datenbank - Der rest ist SQL.
Mein primäres sql diff ist das hier. Ich sammel mir für jedes ALKIS Gebäude
alle schneidenden OSM Gebäude zusammen (ST_Union) - Dann baue ich da ein
diff drauf (Wenn keine schneiden dann ist mein Diff = 100% des ALKIS Gebäudes)
Die Tabelle ax_gebaeude_diff kopiere ich dann mit ogr2ogr in ein
sqlite. Dann reichere ich die sqlite mit metadaten an (Boundary,
styles etc) und dann schiebe ich die in meine
Visualisierungsgeschichte (https://github.com/flohoff/spatialite-rest)
auf http://osm.zz.de/dbview
select *
intoax_gebaeude_diff
from(
select *,
ST_Area(ST_Transform(diff, 25832)) area,
ST_Area(ST_Transform(alkisgeom, 25832)) alkisarea
from(
select ogc_fid,
gml_id,
coalesce(ST_Difference(geom, building), geom) as diff,
geom as alkisgeom,
building as osmgeomcollection
from(
select g.ogc_fid,
g.gml_id,
g.geom,
ST_Union(p.way) as building
fromax_gebaeude g
left outer join planet_osm_polygon p on (
ST_Intersects(p.way, g.geom) and p.building <> '' )
where ( g.lagezurerdoberflaeche is null or
g.lagezurerdoberflaeche <> 1200 )
group by g.geom,ogc_fid,gml_id
) foo
) bar
) baz
where area > 5
;
ogr2ogr -f SQLite \
-dsco SPATIALITE=YES \
-nln alkisnotinosm \
${BASE}/${OUTPUT} \
PG:"dbname='osm'" \
-sql "select ogc_fid as id, gml_id as gmlid, diff as geom, area,
alkisarea, 'Area ' || trunc(area) || 'm²' as text, 'default' as style from
ax_gebaeude_diff"
Ich mache das ganze processing in docker containern. Also NAS Import bzw
convert in ein pg_dump und das processing gegen OSM Daten.
(NAS Import mache ich nur manuell, OSM diff läuft jede stunde - dann nehme
ich nur den pg_dump)
Ich habe mal meine Pipeline hier abgekippt:
https://github.com/flohoff/nas-osm-diff
Die run-* scripte sind die die dann einen docker spawnen um in dem docker daten
zu prozessieren.
Die process-* scripte laufen dann IM docker.
Ich benutze im Kreis GT auch nur die NAS files weil die zur Verfügung
gestellten Shapes
nur Hauptgebäude enthalten. Also keine Garagen, Schuppen etc was natürlich
Bullshit ist.
Der diff ist auch problemlos gegen shapes zu machen. Die kann man sich
entsprechend
ja auch mit ogr2ogr direkt in eine postgis schieben.
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenqualität open data NRW und OSM
On Fri, Mar 06, 2020 at 10:19:16PM +0100, Martin Koppenhoefer wrote: > im Prinzip, in einem Land mit hoher Mapperdichte wie Deutschland, > sicherlich ja, aber zunächst sind es ja nur Abweichungen, die man > durch den Vergleich der Daten feststellen kann, um rauszubekommen, > welche Version richtiger ist, muss man vor Ort nachschauen. > “Integrieren“ ist sicherlich gut, aber das heißt natürlich nicht blind > ersetzen von allem was wir gemappt haben durch amtliche Daten... Das kann ich nur unterschreiben. Auch das ALKIS hat definitiv Abweichungen von der Realität. Ich sehe die jeden Tag. Was aber Spaß macht ist das ALKIS und derer Veränderungen als Indikator zu benutzen zu sehen wo sich etwas ändert. Zugeteilte Adressen, veränderte, neue, abgerissene Gebäude. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenqualität open data NRW und OSM
On Fri, Mar 06, 2020 at 01:24:46PM +0100, Tobias Knerr wrote: > On 06.03.20 12:42, Florian Lohoff wrote: > > On Fri, Mar 06, 2020 at 11:30:53AM +0100, Otto Dassau wrote: > >> * Könnten/Dürften die Daten NRW genutzt werden, um die OSM Daten > >> flächendeckend z.B. für NRW zu optimieren? > > > > Am Ende nein. Gucken darfst du, aber übernehmen nicht. > > Vor ein paar Tagen wurde im Forum die Neuigkeit verbreitet, dass die > "Geobasisdaten NRW" jetzt unter der Datenlizenz Deutschland Zero stehen, > die meines Wissens mit OSM kompatibel ist: > https://forum.openstreetmap.org/viewtopic.php?pid=779174#p779174 > > Ich bin mir jetzt nicht sicher, ob da die hier diskutierten Daten auch > darunter fallen? Jau - Saucool: https://www.bezreg-koeln.nrw.de/brk_internet/geobasis/opendata/index.html Da steht die neue Lizenz für die WMS Dienste. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenqualität open data NRW und OSM
On Fri, Mar 06, 2020 at 11:30:53AM +0100, Otto Dassau wrote: > Hallo, > > das Thema wurde wahrscheinlich schon häufiger diskutiert, ich habe dazu aber > bisher nichts gefunden. Es geht um den Vergleich zwischen den Daten, die vom > Land NRW bereitgestellt werden und OSM. > > Ich habe hier ein Beispiel abgelegt, um es zu verdeutlichen: > https://www.gbd-consult.de/download/vergl_odnrw_osm.png Ach guck - Sowas ähnliches baue ich auch gerade - Allersdings für den Kreis Gütersloh der Wöchentlich die NAS Daten des ALKIS als OpenData veröffentlicht. > Man sieht, dass die Übereinstimmung der Gebäudegrenzen zwischen OSM und den > roten Linien der NRW Daten im linken Fenster (Bsp: Düsseldorf) gut, im > rechten Fenster (Bsp: Lüdenscheid) nicht so gut ist. Die Qualität scheint > also unterschiedlich zu sein. > > Meine Fragen dazu sind: > > * Könnten/Dürften die Daten NRW genutzt werden, um die OSM Daten > flächendeckend z.B. für NRW zu optimieren? Am Ende nein. Gucken darfst du, aber übernehmen nicht. Das ist leider im Rahmen der INSPIRE umstellungen auf OpenData verloren gegangen (Also unsere Sondererlaubnis) > * Wenn ja, gibt es dazu bereits Ansätze, wenn nein, wie könnten die > aussehen? > > Ich würde gerne wissen, was man als Nutzer und/oder als Kommune, wie > Lüdenscheid machen kann, wenn man OSM gerne nutzen möchte, die Qualität > aber scheinbar nicht so gut ist. Da wir die offiziellen ALKIS Daten nicht nutzen dürfen kannst du wenig machen. Du kannst vielleicht Daten von der Stadt Lüdenscheid bekommen unter einer besseren Lizenz die mit OSM kompatibel ist. Oder vielleicht ist die Lageungenauigkeit auch nur durch abzeichnen von Bing gekommen und wenn man die Gebäude mithilfe der ESRI Daten korrigiert ist der Fehler kleiner. Mich interessiert gerade weniger die absolute Lagegenauigkeit - Mal ein paar centi/decimeter daneben - So what. Mich interessiert wo sich im Gebäudebestand was getan hat. Also Abrisse, Neubauten. Da fehlen dann ganze Gebäude. D.h. ich versuche gerade was zu basteln wo ich mit die "Difference" der Gebäudefläche ansehe und wenn aus dem ALKIS ein Gebäude mehr als X m² nicht in OSM ist gebe ich diese Differenzfläche aus. Im QGis habe ich das schon - Will ich jetzt noch als web view exportieren. So sieht das gerade aus - Das sind neubauten die mal irgendwann grob eingezeichnet wurden - Da fehlen dann jetzt die Garagen z.b. https://silicon-verl.de/home/flo/tmp/2020-03-06-missingfromosm.jpg Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] foot=yes on highway=primary / StreetComplete
On Tue, Feb 18, 2020 at 07:57:28AM +0100, Ferdinand wrote: > Dieser Tag sollte eigentlich nur von street complete hinzugefügt werden > wenn es keinen Sidewalk giebt. Und warum? Nur weil es keinen Sidewalk gibt darf ich trotzdem als Fußgänger die Fahrbahn nutzen? Oder steht da in der StVO mit einem mal das die Fahrbahn nur für Motorisierte KFZ ist? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] foot=yes on highway=primary / StreetComplete
On Mon, Feb 17, 2020 at 11:11:46PM +0100, Bernhard Weiskopf via Talk-de wrote: > Die Defaults betrachte ich als Vermutung, nicht als gesichert. (default > = in Ermangelung von ...) Aeh das sieht das Wiki und die Datennutzer anders: https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions Und primary sieht für foot/bicycle ein yes als default an. Ich halte das taggen dieser defaults für einen bug. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] foot=yes on highway=primary / StreetComplete
Hi, Ich bin gerade über einige Changeset gestolpert in denen StreetComplete foot=yes auf primarys gepackt hat. Mich wundert das so ein bisschen weil grundsätzlich war ich davon ausgegangen das alles ausser motorway als default foot=yes hat. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Daten über Restriktionen und Vorrangrouten ?für den Schwerlastverkehr in NRW
On Thu, Nov 28, 2019 at 06:03:55AM +0100, Georg Verweyen wrote: > Hallo zusammen, > > Erst einmal Danke an Tom, dass er die erste einleitenden Worte zur > Einordnung gebracht hat. > > Als ich die Mail von von Herrn Spitzley gelesen habe, habe ich nur > gedacht „Was für eine riesige Aufgabe“. Und ich bin mir tatsächlich > immer noch nicht im klaren, ob wir die Erwartungshaltungen in Deckung > bringen können. Deshalb habe ich es gerade auf die Themenliste für den > Dezember OSM Stammtisch von Bonn gesetzt Ich habe vor Jahren mal das Amtsblatt des Kreises Gütersloh über die festlegung des Gefahrgutstraßengrundnetzes durchgearbeitet und alles getagged. https://f.zz.de/posts/200908121002.openstreetmap_gefahrgutstrassengrundnetz/ So sah das mal 2009 für den Kreis GT und einen klein bisschen nördlich von Bielefeld aus. Mittlerweile ist das ein bisschen in die Jahre gekommen und ich habe auch inkonsistenzen gefunden. Sowas wie hgv=destination und hazmat=designated geht ja nicht. Und es ändert sich auch was - Leider hab ich nie wieder eine neue Fassung des Gefahrgutstraßengrundnetzes für den Kreis gefunden. Oder es gibt scheinbar auch highway=pedestrian und hazmat=designated und andere konstruktionen. Das werde ich in meinem wayproblems layer auch aus. Ich glaube nicht das das Gefahrgutstraßengrundnetz durch Fußgängerzonen geht. Hier so ein paar Beispiele: way=51924597 problem="hazmat=designated with hgv=no is suspicious" way=51924599 problem="hazmat=designated with hgv=no is suspicious" way=565285675 problem="hazmat=delivery is not in known value list" way=639771859 problem="hazmat=designated with hgv=no is suspicious" way=644805366 problem="hazmat=designated on highway=living_street is suspicious" way=665809563 problem="hazmat=designated with hgv=no is suspicious" way=68654334 problem="hazmat=destination with hgv=no is suspicious" way=712332156 problem="hazmat=designated with hgv=no is suspicious" way=71745922 problem="hazmat=delivery is not in known value list" Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] destination:ref auf *_link?
Hi, ich analysiere so ein bisschen refs auf Höherklassigen Straßen. Dabei hat mich ein user darauf aufmerksam gemacht das *_link kein ref sondern ein destination:ref tragen sollten. Ich habe versucht das im wiki nachzuvollziehen und scheitere ein wenig. Das scheint zum einen eine Deutsche sonderlocke zu sein, und zum anderen ist das original destination:ref nur ein proposed artikel. Die ganzen highway=*_link Artikel enthalten nichts davon. Lediglich die Deutschen Varianten enthalten was davon. Was ist denn da jetzt so der "Standard" - Alles was *_link ist trägt ein destination:ref aber kein ref? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 09:59:10AM +0200, Martin Koppenhoefer wrote: > Bitte nicht da-sch Doch - und er macht ungehindert weiter. In den letzten Stunden wieder 10 Changesets mit massiver verklebeaktivität. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 11:13:43AM +0200, pbnoxious via Talk-de wrote: > On 22/10/2019 10.41, Florian Lohoff wrote: > >> Da ist die Ecke - Alles was rot leuchtet sind Verklebungen: > >> > >> > https://osm.zz.de/dbview/?db=wayareaconflicts-mv=wayareaconflict#54.12473,11.69829,14z > > Wenn ich die bisherigen Diskussionen richtig in Erinnerung habe, war das > Ergebnis, dass es für beide Seiten schon Argumente gibt (mit iirc einer > Tendenz von mehr Leute gegen verkleben), aber auf jeden Fall nicht > systematisch Gegenden von einer Variante auf die andere geändert werden > sollten. Der Entwurf einer Policy von Frederik spricht sich klar GEGEN das Verkleben aus. Aber egal ob nun die eine oder andere Weise. Es war ganz klar angesagt hier keine Mass Edits auszuführen um noch schnell "zu gewinnen". > Der von dir angeführte Link zeigt aber nur, dass da Wege und Flächen > sich Nodes teilen und nicht, dass das systematisch in den letzten Tagen > gemacht wurde. Um hier nicht wieder die gleiche generelle Diskussion > für/wider gemeinsame Nodes zu führen, finde ich das eher eine schlechte > Visualisierung. Siehe initiale Mail - Da hatte ich EINEN Changeset exemplarisch verlinkt. Geh einfach die Changesets von da-sch durch - Jeder zweite verklebt massiv vorher unverklebte Flächen. Ich habe die angefangen im OSMCha als "bad" zu markieren. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 10:35:33AM +0200, Martin Koppenhoefer wrote: > Am Di., 22. Okt. 2019 um 10:29 Uhr schrieb Florian Lohoff : > > Da ist die Ecke - Alles was rot leuchtet sind Verklebungen: > > > > https://osm.zz.de/dbview/?db=wayareaconflicts-mv=wayareaconflict#54.12473,11.69829,14z > > > wobei man bei Feldwegen ggf. unterscheiden muss, ob das "echte" Wege sind > (also z.B. außerhalb der Parzellen/Flurstücke), oder welche, die auf > privatem Ackerland verlaufen. Mache ich persönlich zwar nicht, wäre m.E. > aber akzeptabel wenn man in solchen zweiteren Situationen die Wege auf dem > Ackerland verlaufen lässt. Bei Straßen ist das allerdings nie der Fall. Wenn der nur DRÜBER läuft wird das nicht rot. Rot wird das hier nur wenn es Nodes gibt die in einer area (typischerweise landuse) und einem weg sind. D.h. erst wenn du die beiden Äcker rechts und links des Feldweges da dran klebst wird das rot. Und selbst das halte ich für falsch. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 09:59:10AM +0200, Martin Koppenhoefer wrote: > Bitte nicht da-sch > Ich erinnere mich auch so, dass man bis auf weiteres weder im großen Stil > diese Probleme der falsch verbundenen Flächen fixt, noch weitere solcher > Fehler durch Vergrößern bereits an ihrer Grenze endender Flächen hinzufügt. > Vielleicht ist die Info einfach nicht angekommen, liest ja nicht jeder > überall mit. Auswertung für MV ist durch: Da ist die Ecke - Alles was rot leuchtet sind Verklebungen: https://osm.zz.de/dbview/?db=wayareaconflicts-mv=wayareaconflict#54.12473,11.69829,14z Und obacht - er lädt nur 1000 Segmente - Steht rechts. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Moratorium beim Flächen verkleben
Hi, ich bin ja einer der Streithähne beim Flächenverkleben und bevor ich jetzt wieder Diskussionen anfange mit einem User (da-sch) will ich hier einfach drauf hinweisen. Es läuft da gerade ein "Blutbad" in MV - da-sch löst Flächen die derzeit getrennt gemapped sind auf und verklebt die mit den Straßen - Und das in ganz großem Stil. Ich hatte die Diskussion eigentlich so verstanden das wir da ein Moratorium haben und nicht hier in die eine oder andere Weise massenweise umgetagged wird? Hier ein Beispiel: https://www.openstreetmap.org/changeset/76015440 Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postalische Eigenständigkeit / admin boundarys
On Thu, Oct 17, 2019 at 02:03:37PM +0200, Georg Feddern wrote: > Weder andere noch schöne - eher ein Gegenargument: > Denn dieses Zusatztagging hilft vielleicht bei solch eindeutigen > Sonderfällen - aber es bleiben eben immer noch die 0,8 % der anderen > Sonderfälle, wo Randerscheinungen einfach dem postalischen Zustellbereich > der Nachbargemeinde zugeordnet werden, die sich nicht so leicht kennzeichnen > lassen. > Lohnt sich dann für diese 20%-Erfolgsrate solch eine Sonderlocke? > Und wenn, dann bin ich voll bei Dir: Für reines QA-Tagging bitte einen qa: > Namensraum statt allgemeiner keys bitte! > > PS: Kann man das nicht durch einen zusätzlichen QA-Check gegen die > PLZ-Relation (mit postal_code und name) erkennen/prüfen/false-positiven? Da bin ich auch fein mit - Wo und wie man das abbildet - qa: namespace o.ä. Fände das halt nur doof "Ausnahmenlisten" zu pflegen ausserhalb von OSM - Dann muss das jeder der sich damit beschäftigt wieder selber machen. Wenn man das irgendwo ablegen kann. Das das mit dem addr:city und dem name auf dem Admin Boundary vielleicht in Deutschland super funktioniert aber woanders kaputt geht ist mir schon klar. Die postal_code relation werte ich ja auch aus - postal_code ist ja identisch für Harsewinkel und Marienfeld 33428 - Aber eben der addr:city nicht. D.h. der postal_code validiert super - Nur der city name nicht ;) Deshalb ja auch die mail - mehr an die die sich mit dem QA auf Adressen beschäftigen. 1) Wo gibts noch so postalische Sonderlocken? 2) Was ist der schlauste Weg das abzulegen? 3) Wie machen andere das. Ich kenne halt keine weitere postalische Eigenständigkeit. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Postalische Eigenständigkeit / admin boundarys
Hi, ich mache so einiges an Adress QA und u.a. überprüfe ich ob das addr:city zu dem name (und name:suffix) auf dem admin_boundary mit dem admin level 6 bzw 8 passt. Das geht auch in 99% der Fälle gut und funktioniert. Es gibt aber einige Gemeinden die im Zuge von Eingemeindungen ihre postalische Eigenständigkeit erkämpft haben. Z.b. ist hier 33428 Marienfeld genannt (gehört zu 33428 Harsewinkel) Marienfeld ist eigentlich "nur" ein Stadtteil von Harsewinkel. https://osm.zz.de/dbview/?db=addresses-nrw=addresserror#51.95246,8.28361,14z Jetzt suche ich irgendeinen weg wie man das erkennen kann oder halt entsprechend taggen. D.h. auf dem admin_boundary mit dem admin_level 10 von Marienfeld ein addr:city=Marienfeld hinterlassen z.b. https://www.openstreetmap.org/relation/9609627 Jemand ne andere schöne idee. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Tue, Oct 15, 2019 at 10:19:28PM +0200, Martin Koppenhoefer wrote: > > > sent from a phone > > > On 15. Oct 2019, at 19:56, Florian Lohoff wrote: > > > > Dann müsste ja am Anfang der Parallelfahrbahn ein Schild zum Aufheben der > > Geschwindigkeitsbeschränkung stehen. > > > > Und nein - Da steht nix: > > > > https://www.mapillary.com/map/im/s0p8LimdBltpy1uTD4gmtA > > ich würde es auch so sehen dass man auf der Parallelen die Strecke > nicht verlässt, während wer ganz rechts raus fährt verlässt die > Strecke Ich habe mal weil es scheinbar zumindest hier keinen Dissens gibt das maxspeed=none auf der Parallelfahrbahn entfernt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Tue, Oct 15, 2019 at 01:06:24PM +0200, Roland Olbricht wrote: > Hallo Michael, [ ... ] > Verbindungsrampen werden oft mit Entwurfsgeschwindigkeiten von 40 km/h > bis 60 km/h konzipiert. Schaut man sich die Kurvenradien der Kleeblätter > am Autobahnkreuz in Werl an, so sind dort auch eher 40 km/h oder weniger > konzipiert worden. Ein explizites Schild gibt es an solchen Kurven nur > vereinzelt (speziell Werl kenne ich nicht, bei anderen Autobahnkreuzen > gibt es beide Fälle), aber OSRM hat meines Wissens auch keinen > Präprozessor, der Kurvenradien auf Geschwindigkeitsgrenzen umrechnet. > Damit bleibt außer dem Tag highway=motorway_link aus Sicht der Routers > kein besserer Indikator. In Werl ist das Thema ja nicht das Kleeblatt sondern die Parallelfahrbahn. Und IMHO ist die eben wenn vorher ein maxspeed=signals gilt, dann gilt nicht plötzlich maxspeed=none auf der Parallelfahrbahn. Dann müsste ja am Anfang der Parallelfahrbahn ein Schild zum Aufheben der Geschwindigkeitsbeschränkung stehen. Und nein - Da steht nix: https://www.mapillary.com/map/im/s0p8LimdBltpy1uTD4gmtA Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Tue, Oct 15, 2019 at 01:23:53AM +0200, Martin Koppenhoefer wrote: > > > sent from a phone > > > On 14. Oct 2019, at 15:00, Florian Lohoff wrote: > > > > Merke: Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben wird (Und > > eine Einmündung hebt sie nicht auf) > > die Geschwindigkeitsbegrenzungen gelten für die „Strecke“, d.h. wenn man die > Strecke verlässt gelten sie nicht mehr. Praktisch sind an allen Stellen wo es > zu Unklarheiten kommen könnte normalerweise Schilder. Welcher teil der Autobahn ist denn die Strecke? Es ist ja eine Parallelfahrbahn die denselben Anfangs und Endpunkt hat. Mir würde das jetzt schwer fallen da eine eindeutigen Strecke zu identifizieren bzw deren abweichung. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Sun, Oct 13, 2019 at 10:24:33AM +0200, michael spreng wrote: > Ich interpretiere das leicht anders. routing.openstreetmap.de braucht > einen anderen Regelsatz: > https://github.com/fossgis-routing-server/cbf-routing-profiles > > Die auf/abfahrt ist mit maxspeed=none gemappt, welches in 140kmh > übersetzt wird. > maxspeed=signals hingegen ist dem Profil unbekannt, und es wird der > weltweite default für motorway von 90kmh angenommen. > > Wäre es nicht sinnvoll, die auf/abfahrten mit demselben maxspeed zu > tagen wie die parallele Autobahn? > > Was für eine Geschwindigkeit sollte vom routing bei signals angenommen > werden? Das werden wir dem "router" schon sagen müssen. Eine allgemeingültige Antwort gibts da ja nicht. Die Frage ist ist da tagsüber nichts und zur Rushhour 100? Oder ist das zwischen 100 und 130? Vermutlich macht es Sinn das mit maxspeed:signals= zu taggen. Dann hat ein Automat die Chance das rauszufinden. Ich stelle da aber mal eine ketzerische Frage. Woher kommt das maxspeed=none auf der Parallelfahrbahn? Vor dem Abzweig gilt ein maxspeed=signals - Wenn die abzweigt gilt das weiter - Das ist ja nicht mit einem mal aufgehoben. Man könnte Argumentieren das das für die neu auf die Autobahn einbiegenden gilt aber wir betrachten hier den fall der durchfahrenden. Daher plädiere ich dafür die Parallelfahrbahn ebenfalls auf maxspeed=signals zu taggen bzw das maxspeed=none _mindestens_ zu entfernen es sei denn am Begin der Parallelfahrbahn steht ein Schild das die bestehende Geschwindigkeitsbegrenzung aufhebt. Merke: Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben wird (Und eine Einmündung hebt sie nicht auf) Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kreuz Werl - seltsame Spurnutzung
Hi, ich habe eben meine Routenüberwachung ein wenig ausgedehnt auf teile der A44 und A1 Dabei ist mir der hier aufgefallen: https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=51.5349%2C7.9014%3B51.5332%2C7.8828#map=17/51.53369/7.89198=N Wenn man von ost nach west auf der A44 durch das Kreuz Werl routet wird die Nebenfahrbahn präferiert - In Gegenrichtung ist das nicht so. Grundsätzlich scheint die zu gehen - nur eben schlechter bewertet. Hab ich so spontan nicht verstanden. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vehrkehrszeichen 250
On Thu, Oct 10, 2019 at 05:29:23PM +0200, Martin Koppenhoefer wrote: > Am Do., 10. Okt. 2019 um 16:35 Uhr schrieb Florian Lohoff : > > > Ich bin dagegen access restrictions nach Gefühl oder interpretation > > einzutragen. Wir tragen das ein was da und verifizierbar ist. > > > > Der Algorithmus kann sich dann das richtige daraus bilden. > > +1, eine Straße die an einem See endet könnte auch noexit=yes sein, und > trotzdem könnte jemand mit einem Amphibienfahrzeug auf dem Wasser > weiterfahren. > Oder jemand mit einem flugfähigen Fahrzeug überfliegt die Schranke ;-) noexit=yes müsste auch eigentlich qa:noexit=yes sein - Das ist nur für die validatoren. Das hatte ich ja sowieso mal vorgeschlagen das wir für die qa/validator annotation einen namespace wie qa:* nehmen. qa:noname=yes qa:noexit=yes Und dann eben listen haben mit annotations um false-negatives zu annotieren für alle möglichen checks. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vehrkehrszeichen 250
On Thu, Oct 10, 2019 at 12:23:47PM +0200, Sebastian Dicke wrote: > Hallo, > > > im Wiki (DE:Verkehrszeichen_in_Deutschland) wird für das deutsche > Verkehrszeichen 250 angegeben, dass man die betroffenen Straßen/Wege mit > vehicle=no taggen soll. In der Straßenverkehrsordnung steht dazu > allerdings: „Krafträder und Fahrräder dürfen geschoben werden.“ Sollte > man solche Straßen/Wege deshalb nicht eher mit vehicle=no, > bicycle=dismount, motorcycle=dismount, mopded=dismount und mofa=dismount > taggen, um diese Vorschrift abzubilden? Außerdem könnte das beim Routing > helfen, wenn Router lieber ein Stück Fußweg einplanen als den Fahrer > einen großen Umweg zuzumuten. Multimodale router ;) Du must ihm halt beibringen das ein Radfahrer auch zum Fußgänger werden kann - Aber vielleicht nicht auf treppen. Und nein - Das steht kein Schild "Radfahrer absteigen" sondern "Gesperrt für Fahrzeuge aller art". Ich bin dagegen access restrictions nach Gefühl oder interpretation einzutragen. Wir tragen das ein was da und verifizierbar ist. Der Algorithmus kann sich dann das richtige daraus bilden. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-IDs
On Thu, Oct 10, 2019 at 11:43:42AM +0200, Martin Scholtes wrote: > Hallo, > > die ID´s werden hochgezählt und nicht neu vergeben, da sonst ja die > history i-wann kaputt geht. Aeh ja - für NEUE Objekte wird die nicht wiedervergeben. Die API erlaubt es dir aber gelöschte Objekte wiederzubeleben dann kann die ID wieder auftauchen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen, Anregung eines Neulings
On Wed, Oct 02, 2019 at 02:58:16PM +0200, Roland Olbricht wrote:
> Sehr geehrter Herr Mehl,
> nach den Routing-Regeln
> https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua
> schaut, dann findet man, dass
>
> avoid = Set {
> [...]
> 'construction',
> 'proposed'
> },
>
> d.h. es wird in der Tat die Route von routing.openstreetmap.de nicht
> genutzt, weil "construction=yes" gesetzt ist. Hier wäre jetzt die
> Einschätzung gefragt, ob das Tag "construction=yes" gerechfertigt ist.
> Aus der Erfahrung und Beschreibung auf
> https://wiki.openstreetmap.org/wiki/DE:Key:construction
> liest man, dass das Tag nicht verwendet werden sollte (sondern
> "highway=construction" + "construction=motorway", wenn und nur wenn die
> Fahrbahn unbefahrbar ist).
Meist sind die construction=XYZ überbleibsel von einer "Ehemaligen
Baustelle". D.h. das highway= tag wird korrigiert wenn die Baustelle
durch ist, aber jemand vergisst das construction=XYZ tag. Damit
ist das für OSRM nicht nutzbar, in der Karte sieht man das aber
nicht weil highway beim rendering über construction=XYZ steht.
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] boundary=administrative ohne admin_level
Hi, ich bin eben beim prozessieren von Adressen über 2 Boundarys gestolpert die als boundary=administrative ohne admin_level eingetragen sind: Mittlerer Oberrhein https://www.openstreetmap.org/relation/898410 Region Stuttgart https://www.openstreetmap.org/relation/377632 Ich vermute das beide nur für die TMC Geschichten existieren oder? Eine Verwaltungsgliederung gibt es auf der ebene ja vermutlich nicht. Deshalb frage ich mich warum die ein boundary=administrative tragen. type=boundary sehe ich ja noch ein Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spielregeln fürs Tagging
Hi Roland, On Tue, Sep 10, 2019 at 06:43:17AM +0200, Roland Olbricht wrote: > Hallo zusammen, > Mängel im Informationsfluss > > Zwar sind viele Teile von OpenStreetMap gut übersetzt, > aber die Tagging-Dokumentation hat spürbare Mängel. Bei einer Stichprobe > von 10 Tags sind zwar per Tag zwischen 2 und 18 Sprachen gelistet > worden, aber nur wenige der Übersetzungen sind vollständig und aktuell > (in der Stichprobe 2 für Deutsch, 3 für Französisch). Hier wäre mal zu klären ob die Wiki Seiten in !=en_GB überhaupt die führenden Seiten sind und die Landessprachen nur Übersetzungen. Defakto ist das heute nicht so. Jede Landessprache enthält beliebige Anpassungen die zum Großteil nur Partikularinteressen oder Verständnis ohne breiten Konsens darstellen. Wenn wir denn annehmen das en_GB die Führende Sprache ist sollten wir uns drauf einigen das Abweichungen davon auch als solche markiert werden und nicht jeder da irgendwas in die Landessprachlichen Seiten rein schreibt. > Ein anderes Defizit ist, dass Tag-Dokumentationen auf den Wiki-Seiten > auch dann erheblich geändert werden können, wenn das Tag längst breit in > Gebrauch ist. > > Es kommt zudem ebenso vor, dass ein Tag ohne jegliche Dokumentation > eingeführt wird. Wenn dies durch normale Mapper passiert, ist dies > üblicherweise langsam genug um das Tag deuten zu können; so können > Imports oder Organisiertes Editieren die De-Facto-Bedeutung eines Tags > substantiell verschieben, unabhängig davon ob es verbreitet, > dokumentiert oder beides ist. Ich glaube ich hatte mich da vor >10 Jahren schonmal zu geäussert das bei der Dokumentation im Wiki nicht wichtig ist was ein Tag darstellt sondern das eine klare Abgrenzung zu anderen Tags wichtig ist. Das ist ein wenig besser geworden aber eben nicht Strukturiert. Ich verweise da auf die immer wieder aufflammenden Diskussionen zum Thema track/service oder service/residential oder residential/unclassified oder auch tracktype= etc etc. > Bedarf nach mehr Struktur > > Die Tag-Übersetzungen mischen sich mit einem anderen Problem: > verschiedene Features können sehr unteschiedlich in verschiedenen > Regionen aussehen. Z.B. sehen ein highway=primary und > highway=unclassified gegenüber highway=track in Deutschland deutlich > anders aus als in Island oder dem ländlichen Afrika. Es passiert > schnell, dass lokale Unterschiede nur in die Übersetzung der jeweils > dominanten Sprache eingehen, obwohl z.B. die Tagging-Anforderungen in > den französischsprachigen Ländern Belgien, Kanada und Niger spürbar > verschieden sind. Umgekehrt gibt es keinen sinnvollen Grund, die > Tagging-Regeln in Brüssel pro Häuserblock zu ändern. Das Thema Track/Unclassified etc vor allem wenn wir in Länder kommen die nicht alles Asphaltieren eine andere Geschichte. Hier ist IMHO das Problem das wir zwar "Map whats on the ground" haben aber das bei Straßen eben nur teilweise gilt. Hier mappen wir die Nutzungsart die ja nicht sofort sichtbar ist und attributieren nach der physischen Beschaffenheit. Das ist eben nicht intuitiv. Für einen "Stadtmenschen" der einen Ausflug aufs Land macht ist dann alles hinter dem Ortsschild ein track. Für jemanden der da wohnt ist klar das da der Postbote fährt, der Schulbus und da noch 100 Leute Wohnen und das das kein Track sein kann. Da kann eben das was hier nach track aussieht in Madagaskar auch eine primary sein. Diese Differenzierung habe ich im Wiki so nie klar gefunden - Das ist überliefertes Kopfwissen von >10 Jahren OSM. Und das wird auch in den Diskussionen auf den Mailinglisten immer klar das das so nicht jedem klar ist. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] admin_level=8 name != addr:city - Postalische Eigenständigkeit
Hi, wir haben hier ein Dorf das hat sich mal die postalische Eigenständigkeit erkämpft (Schon mehreren Dekaden). Der Wikipedia Artikel erklärt das: https://de.wikipedia.org/wiki/Marienfeld_(Harsewinkel) Jetzt habe ich das korrekt umgetagged weil eben die Adressen nicht 33428 Harsewinkel sondern 33428 Marienfeld sind. Marienfeld liegt im admin_level=8 von Harsewinkel und ist formal nur ein Stadtteil. Der Vergleich mit anderen Adressbeständen ist jetzt richtig und grün, dafür fällt mein eigener Adressvalidator auf die Backe der überprüft ob in addr:city auch der name vom admin_level=8 (bzw 6) steht - Da ist jetzt alles rot :) Die Frage ist ob es hier eine Liste gibt von Postleitzahl/Ortsnamen die eine ebensolche postalische Eigenständigkeit haben. So als Ausnahmenliste für den Validator. Andere Beispiele wo es andersherum gelaufen ist (Eingemeindungen): https://ol.wittich.de/titel/1607/ausgabe/5/2019/artikel/13124159-OL-1607-2019-12-5 http://www.seeburg-city.de/Amtsbote/2004JanFeb/Postleitzahlen.htm https://www.stadt-zoerbig.de/de/archiv/aenderung-der-postalischen-bestimmungsortangaben-fuer-den-ort-06369-schortewitz-2419.html Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenstand OSRM/Graphhopper Main Page
Hi, weiss jemand ob man den Datenstand des OSRM und Graphhopper Instanz auf der Hauptseite irgendwo sehen kann? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Tue, May 21, 2019 at 12:05:41AM +0200, wambac...@posteo.de wrote: > Jetzt mal Butter bei die Fische: > > Hast du den Export der Boundaries überhaupt ausprobiert? Ich könnte auch > in den Logfiles nachsehen, aber warte erstmal ab. Ich habe bei dir schon so viel Boundarys exportiert ;) Das mit dem buffer ist mir bisher nicht aufgefallen. > "Komische" Poly-Files hab ich bei meiner Software übrigens schon lange > nicht mehr erlebt.( muss ca 6-7 Monate her sein, dass es da mal ein > Ticket zu gab) Das http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000 wirft komische polys. > Was brauchst du denn genau? > - Mehr als eine Grenze auf einem Schlag? No Problem. Jaja - ich kenne das und benutze das reichlich wenn ich wieder irgendwo shapes oder polys brauche. Bisher war mir nicht aufgefallen das ich einen buffer setzen kann. > Und natürlich alles bei Bedarf mit frei definierbaren Buffern ohne > Überlappungen. Siehst du - den hatte ich noch nicht entdeckt. Dann hast du ja alles was mein Herz begehrt .. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
Hi, On Mon, May 20, 2019 at 09:32:25PM +0200, Jochen Topf wrote: > > besorgt - Problem ist das entgegen der Doku die durch > > das ST_Simplify doch kleiner werden und schneiden können. Muss man > > also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus > > mal seltsame Multipolygone. > > Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit > "osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen. > Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die > Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze > etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern > oder so rumärgern. Ich habe halt hier für meinen ganzen Auswertungsramsch diverse sub PBFs von Deutschland die ich derzeit mit osmupdate/osmconvert update und neu beschneide. Dafür brauche ich halt polys. osmupdate/osmconvert ist da ein wenig eigenwillig was das ausschneiden angeht. Daher ist mir dann OWL/Regierungsbezirk Detmold um die Ohren geflogen. Ich würde ja einfach auch osmium umstellen in der pipeline aber da fehlt mir das mit dem dem automatisch update eines pbfs d.h. download der change files. Ich will doch einfach nur ein geographisches .pbf auf dem aktuellen stand halten. Und das "consumerdevice" um das zu machen ist halt osmupdate mit dem -B poly und schon läuft das für doofe. Die 50+ Jobs werfe ich dann einfach alle 2 Stunden mir slurm in die Luft und der scheduled mir die durch mit den dependencies. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Fri, May 17, 2019 at 07:22:06PM +0200, wambac...@posteo.de wrote: > Moin > > Am Ende war es vieles - poly von download.geofabrik.de der an einer > > winzigen stelle einen node schneidet einer boundary. > > osmupdate/osmconvert mit dem poly schneiden dann da einen teil der > > boundary weg. > > Die Poly-Files der Geofabrik sind fast alle händisch erstellt worden, > daher einfach und relativ schnell. Wenn sich aber eine Grenze verändert > haben sollte, kann das (nie wieder angefasste) Poly-File schon mal > falsch sein. > > Mein Tip: / > /- https://wambachers-osm.website/boundaries// > > - bpoly mit einem Buffer von 1-2 km wählen und dann sind die > *tagesaktuell*. ;) Da geht nen buffer? Das habe ich wohl übersehen. Habe mir jetzt bei http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000 besorgt - Problem ist das entgegen der Doku die durch das ST_Simplify doch kleiner werden und schneiden können. Muss man also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus mal seltsame Multipolygone. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Fri, May 17, 2019 at 08:36:07AM +0200, Jochen Topf wrote:
> > und wenn Du die Relationen und deren Member evtl. rekursiv mitfilterst?
> > Oder nur die Relationen mit members?
> > Nur die ways klappt natürlich in dem Fall nicht, aber da kann man dem
> > Osmium keinen Vorwurf machen.
>
> Osmium kannste eh keinen Vorwurf machen, wenn dann Osmosis :-)
>
> Florian: Warum nimmste nicht einfach Osmium, das ist auch noch
> einfacher:
>
> osmium tags-filter detmold-regbez-latest.osm.pbf a/boundary=administrative -o
> output.osm
osmium steckt noch nicht so in den fingern. Und so zeugs brauche
ich dann einmal in 5 Jahren ;) Und meine zeugs was ich versucht habe zu
debuggen ist auch libosmium basiert und ich vermutete den Fehler erst
da.
Am Ende war es vieles - poly von download.geofabrik.de der an einer
winzigen stelle einen node schneidet einer boundary.
osmupdate/osmconvert mit dem poly schneiden dann da einen teil der
boundary weg.
Seltsamerweise ist die boundary bei mir jetzt heile, jetzt wo ich
auf den weg auch ein boundary=administrative gepackt habe. Das hier ist
der code den ich verwende. Wollte noch hinterhersuchen warum das
kaputt ist.
AreaIndex boundaryindex;
osmium::TagsFilter boundaryfilter{false};
boundaryfilter.add_rule(true, osmium::TagMatcher{"boundary",
"administrative"});
osmium::area::MultipolygonManager
boundarymp_manager{assembler_config, boundaryfilter};
AreaIndex postcodeindex;
osmium::TagsFilter postcodefilter{false};
postcodefilter.add_rule(true, osmium::TagMatcher{"boundary",
"postal_code"});
osmium::area::MultipolygonManager
postcodemp_manager{assembler_config, postcodefilter};
osmium::relations::read_relations(input_file, boundarymp_manager,
postcodemp_manager);
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Thu, May 16, 2019 at 08:04:48PM +0200, chris66 wrote: > Moinsen, > > > Die Fragen die sich mir jetzt stellen: > > > > - Sollen alle ways die eine boundary darstellen ein > >admin_level/boundary=administrative unabhängig von ihrer relation > >tragen? > > Sie *dürfen* die Info tragen, als Kompatibilitätskrücke für Anwendungen, > die Probleme mit Relationen haben. Der Punkt ist das auch die Dokumentation kaputt ist - Es wird halt im Wiki das dieses osmosis --read-pbf file=detmold-regbez-latest.osm.pbf --tf accept-ways boundary=administrative --used-node --write-xml output.osm Grenzen extrahiert - und das ist falsch. Es exportiert eben Wege ohne boundary=administrative nicht. Damit sind die Grenzen kaputt. (Dafür werden andere Objekte exportiert die nichts mit boundaries zu tun haben) > > - Bei Flüssen - verdoppeln der Wege (übereinander) oder > >zusätzliche tags auf dem river way? > > Wenn der Fluß tatsächlich per Gesetz die Grenze darstellt, dann > kommt er in die Relation, eine zusätzliche Linie wird dann nicht > gezeichnet. Der Fluß von 1970 stellt die Grenze dar. Das ist vermutlich heute nicht mehr die Flußmitte. > Üblicher ist es allerdings eine Grenze parallel zum Fluß einzuzeichnen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] boundarys / river als boundary / admin_level?
Hi, ich suche seit ein paar Monaten sporadisch nach einem Fehler in meinem Addressextrakt das bestimmt boundary polygone mit libosmium nicht "parsebar" sind, bzw die an verschiedenen Stellen kaputt sind. Meine Arbeitshypothese war bisher das das poly zu klein ist und deshalb die boundary (Kreis, Stadt) nicht mit drin ist. Heute habe ich mir dann mal das mit osmosis auseinander geschnitten und gefiltert und im josm geladen. osmosis --read-pbf file=detmold-regbez-latest.osm.pbf --tf accept-ways boundary=administrative --used-node --write-xml output.osm Dabei ist mir aufgefallen - Da fehlen Stücke in der relation. Die sind wenn ich die via API lade aber da. Die Stücke die fehlen sind Teile bei denen die Boundary ein Fluß ist. Hier ist (war) in der Boundary nur der Fluß drin der keine Tags wie boundary=administrative/admin_level trägt, diese sind ausschließlich in der relation. Ich habe den weg jetzt dupliziert und entsprechend admin_level und boundary=administrative da hinterlassen. Die Fragen die sich mir jetzt stellen: - Sollen alle ways die eine boundary darstellen ein admin_level/boundary=administrative unabhängig von ihrer relation tragen? - Bei Flüssen - verdoppeln der Wege (übereinander) oder zusätzliche tags auf dem river way? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] QA annotation/hinting Was: iD führt nosquare=yes für nicht rechtwinklige Gebäude ein (WAS: Besorgt über den iD-Editor)
Hola, On Fri, May 10, 2019 at 09:56:11AM +0200, Martin Koppenhoefer wrote: > > On 9. May 2019, at 22:55, Michael Reichert wrote: > > > > Wenn ihr eine Meinung zu der Sache habt, egal welche, steht es euch > > natürlich frei, euch auf GitHub, auf dieser Mailingliste oder auf der > > Mailingliste Talk zu äußern. > > > Danke für Deinen Einsatz, ich sehe das Monieren von nicht > rechtwinkligen Gebäuden auch als Problem und von daher auch den tag > als kritisch. > > (im Gegensatz übrigens zu noname und dem neuen nohousenumber) Ich würde da gerne eine generische Debatte sehen zu object annotation für die validation/qa tools. Und ich fände es nicht schlecht das ganz klar in eine Hierarchie zu gliedern um deutlich zu machen das es hier nur um annotation/hinting für die Validatoren geht. In das noexit wird immer viel rein interpretiert. qa:rectangular=no qa:exit=no qa:name=no qa:housenumber=no Oder es als Liste ausprägen - Am ende werden ja nicht so viele validation hinting je Objekt hinterlegt werden müssen. validation_hint=noexit;noname;norectangular;nohousenumber Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
On Sun, May 05, 2019 at 11:51:22AM +0200, René Falk wrote: > Am 4. Mai 2019 18:22:32 MESZ schrieb Florian Lohoff : > >Ja - aber tracks sind keine Hofzufahrten. Wenn das eine Hofzufahrt ist > >dann fährt da der Postbote häufiger als der Trecker -> Kein track. > > Aha, hat sich also nichts geändert in all den Jahren, wo ich hier nicht aktiv > war. > Immer noch die Streitfrage was mappen wir: > Das wo nach es aussieht oder wie es benutzt wird? Wie es benutzt wird - Und das ist bei OSM ziemlich eindeutig. Sonst wären in halb Afrika selbst Motorways als track eingetragen. In Madagaskar sind signifikante Teile der Staatsstraßen nicht asphaltiert, trotzdem sind sie das höchstklassige Straßennetz, also Primary. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
Hi Georg, On Sun, May 05, 2019 at 04:42:58PM +0200, Georg Feddern wrote: > Moin, > > einerseits mag ich Dir recht geben - für's Routing ist es dasselbe. > Andererseits besteht zwischen einer öffentlichen Straße (Widmung) mit > Einschränkung auf Anlieger und einem Privatweg schon noch ein Unterschied. > Permissive ist für mich auch nicht dasselbe. Ja - Aber wir sollten hier mal "Eigentümerschaft" oder "Unterhaltungspflichtig" von Zufahrtbeschränkung trennen. highway=service ist _für mich_ die Aussage das es sich eben nicht um eine öffentliche Straße handelt. Wenn ich Wege habe die explizit ein "Privatweg" tragen dann tagge ich das als "ownership=private" und auch mit einem Note das da ein Schild steht mit "Privatweg" und eben dem exakten Wortlaut. Privatweg heisst aber doch nicht das ich da nicht durch darf. Es gibt jede Menge Straßen die über Privatgrund gehen die aber der Öffentlichkeit Freigegeben sind. Für mich sagt das Schild "Privatweg" auch nur das eben der Straßenunterhaltungspflichtige jemand anders ist. Das ist eben eine Aussage zur Haftung nicht zur Zufahrtsbeschränkung. > Beim Routing würde ich > - private - wie destination - immer nur auf der letzten Meile > - permissive auch im Transit > akzeptieren. Wenn das wie destination ist warum taggen wir das nicht als destination? Es ist eine Beschränkung - Und IMHO sollte die da nur stehen wenn da auch Schilder stehen die das explizit sagen. Diese ganze Nummer das wir jede Zufahrt mit access=private taggen auch wenn da NULL Schilder stehen die eine Nutzung einschränken ist absolut kaputt. Ich tagge die access tags wie foot/bicycle/vehicle/motor_vehicle etc nur wenn da wirklich ein explizites Verbot durch Beschilderung existiert. Das ist eben die OSM Grundregel - "Map whats on the ground" Das ganze verteilen von access tags "nach gefühl" macht halt das Routing kaputt und das Wiki ermuntern auch noch was das access=private auf service angeht dazu. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
On Sat, May 04, 2019 at 11:29:58AM +0200, chris66 wrote: > Am 03.05.2019 um 12:58 schrieb Florian Lohoff: > > > Ein access=private/access=no ist gar nicht zu benutzen. > > bzgl access=no stimme ich zu. access=private sollte IMO als > destination gewertet werden, ansonsten können Anwohner sich > nicht von/zu ihrem eigenen Haus routen lassen. Korrekt - das ist bei allen gängigen Routern so. Wenn wir access=private überall wie access=destination werten können wir das auch gleich abschaffen und ein service/driveway immer wie ein motor_vehicle=destination bewerten. Das ist ja das was ich sage - Dieses gefühlte access=private tagging macht das routing kaputt. Und das ist einfach nur "Matter of fact" - Und eben das versuche ich da wo ich so mappe einfach mal zu bereinigen. Die mit der Gießkanne verteilten access tags und tracks. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
On Fri, May 03, 2019 at 10:15:38PM +0200, Rainer wrote: > Hallo Roland, > > vielen Dank. Ich schaue mir gerade die Ergebnisse an. Im ländlich > geprägten Raum habe ich noch highway=track in die Auswahl hinzugefügt, > weil viele Einzelgehöfte wirklich nur über Feldwege erreichbar sind. > Zumindest zwei Fälle, in denen die Zufahrtswege fehlen, habe ich auf die > Schnelle gefunden. Ja - aber tracks sind keine Hofzufahrten. Wenn das eine Hofzufahrt ist dann fährt da der Postbote häufiger als der Trecker -> Kein track. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
On Sat, May 04, 2019 at 01:27:58PM +0200, René Falk wrote: > In NRW sind alle Wirtschaftswege einschließlich der Feldwege > grundsätzlich Privatwege, auch wenn sie im Besitz von Städten und > Gemeinden sind. Sie sind nicht als öffentliche Straßen oder Wege > gewidmet. Hast du da mal die Rechtsgrundlage für? Auch die definition von Wirtschaftsweg. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
Hola, On Fri, May 03, 2019 at 12:47:39PM +0200, Georg Feddern wrote: > > Für mich ist "gar nicht erschlossen" dasselbe wie "track" oder > > "access=no/private" auf einem service/driveway. > > Also meiner Meinung nach macht ein Router - wie auch ein Anwender - einen > Fehler, wenn er private = no wertet. > destination wäre m. M. n. richtiger - und zielführender im wahrsten Sinne > des Wortes Zu track siehe unten. Wenn das ein destination is dann tag das. access=no/private heisst: Keiner darf da rein. Auch nicht der Postbote, Müllabfuhr oder Schulbus. > > Defakto "verweigern" die gängigen Routingengines Autos auf Tracks > > (Meiner Meinung nach zu recht) so das hier diverse Höfe und > > ländliche Gebäude routingtechnisch nicht wirklich "erreichbar" sind. > > Was denn nun bei den tracks? > Verweigern oder über unclassified+destination stellen und bevorzugen? > Tracks (im Sinne von schmalen Fahrwegen) sollen "nach Möglichkeit" > vermieden werden, ja - aber die letzte Meile bietet nun mal keine > andere Möglichkeit. > Wo ist also das Problem den Malus sehr hoch zu setzen? Eine Zufahrt zu einem Haus ist kein Track. Ein Track ist ein überwiegend für die Landwirtschaft genutzter Weg. Wenn das eine Hauszufahrt ist, dann fahren da mehr Postautos als Trecker -> Kein track. Und diese Einschätzung findet sich eben in den Routern und den Priorisierung wieder. > > Auch eine Hofzufahrt mit "Privatweg" > > als access=private zu taggen halte ich für falsch. Postbote, > > Lieferdienst, Schulbus, Müllabfuhr fahren da mitunter rein. > > Richtig - ihnen wird das private Recht der Benutzung eingeräumt. > Trotzdem gelten dort private Nutzungsrechte. > Schulbus bis auf den Hof? Nett, kenne ich so nicht ... Meine Kinder werden so abgeholt. Die letzten 800m sind "Anlieger Frei" und ich bin der einzige Anlieger. Nicht Asphaltierter Waldweg. > > Das sind eben die letzten 2-3% Adressen die mit aktuellen Tags und > > Software nicht lösbar sind. > > Sehe ich eben ganz anders - durchaus lösbar mit den aktuellen Tags und > Software. Ich bin da seit 10 Jahren dran - ich habe mich mit routing/navigation und dem tagging in OSM beschäftigt - und nein - Das was bei OSM getagged wird ist leider "unbrauchbar". So lange mapper "gefühlte" Beschränkungen taggen ist das halt kaputt. Und access=private ist halt an sich kaputt. Es sagt nichts aus. Es trennt nicht zwischen Eigentümer bzw Unterhaltungspflichtigem und den wirklichen Zufahrtbeschränkungen. Nur weil das ein Privatweg ist oder das auf Privatgrund ist heisst das nicht das ich da nicht drauf darf. Das Thema haben wir auch bei Tracks. > > Und die ganze nach Gefühl gemappten access=private/no auf jeder Hauszufahrt > > machen eben die navigation für diese Adressen kaputt. Wenn das im > > Wohngebiet nur die 10m Hauszufahrt sind - geschenkt. Wenn aber > > das Haus/Hof 800m neben der Straße im Wald oder Tal/Berg liegt und ich > > das nicht einmal sehe bzw der nächstgelegenene Punkt auf einer Öffentliche > > Straße auf einer Straße ist von der keine Zufahrt möglich ist das halt > > ziemlich suboptimal. Dann ist OSM für diesen Anwendungsfall auf dieser > > Adresse einfach kaputt. > > Ne - nicht OSM, sondern der Auswerter (sofern eine Zuwegung bis zum Haus in > OSM existiert). Die Zuwegung ist ein Track - Wenn du also umstellst ein Trecker zu sein dann wird er dich da durch schicken. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
On Fri, May 03, 2019 at 11:56:17AM +0200, Rainer wrote:
> Hallo Florian,
>
> wie Navigationssysteme das handhaben, ist eine Sache. Mein altes Navigon
> sagt immer "das Ziel liegt in einem beschränkt befahrbaren Bereich" in
> Fällen wie Anlieger frei, Fußgängerzone, Waldweg. Das wäre m.E. im
> Router handhabbar.
Das ist nicht so einfach wie sich das anhört. Einfaches A*/Dijkstra geht
da eben nicht. Viele/Alle? Router machen schon den Fehler bei
access=destination das die Kosten für die Strecke steigt - Das ist
falsch. Wenn ich Anlieger bin darf ich da rein - Das erzeugt keine
"Kosten" in der Path suche sondern das ist ein Attribut das die Route
am Anfang oder Ende eben in einer Destination ist aber nicht im transit.
Dazu kommt das diese Entscheidung ein Übergang von einem weg
access=yes -> access=destination am Ende sein darf und am Anfang
ein access=destination -> access=yes - Aber eben nicht umgekehrt oder
sogar mittendrin. Es darf aber am ende ein access=destination ->
access=destination sein. Erzeugt auch keine weiteren kosten.
Stand heute würden dich alle router durch eine access=destination
schicken wenn nur die Ersparnis an Route/Zeit drumherum hoch genug ist.
Ich habe da wo ich wohne aber das Problem das die allermeisten Routing
engines mich sofort verzweifelt versuchen von meiner Anliegerstraße auf
dem kürzesten Weg runterzuschicken. Und das auch von einer Asphaltierten
Straße auf einen track grade2 oder grade3. Der ist immer noch besser als
die access=destination an der sogar mein Ziel oder Start liegt.
Da sieht man wie kaputt sich so access tags auswirken können und wie
blauäugig im moment so routing funktioniert. 98% funktioniert super,
die letzten 2% sind halt totaler murks.
> Interessanter finde ich die Fälle, in denen ein Weg existiert, aber
> nicht in OSM eingezeichnet ist.
> Wie hast du die Auswertung erstellt, mit Overpass turbo evtl.? Kannst du
> die Abfrage bekanntgeben?
> Ich würde in meiner Gegend mal nach solchen Fällen schauen.
Das ist mehrstufig. Erstmal exportiere ich alle Adressen:
https://github.com/flohoff/addressextract
Der baut admin boundary polygone und plz polygone etc und versucht dann
Adressen zu finden und ggfs über die Polygone zu vervollständigen.
Da plumpst dann ein json bei raus das für NRW alleine
-rw-r--r-- 1 flo flo 916M May 1 08:00 nrw.json
900MByte hat. Das läuft leider relativ lange deshalb mache
ich das nicht in meinem normalen batch. Da extrahiere ich nur
Ostwestfalen-Lippe alle 2 Stunden.
Jede Adresse sieht dann so aus:
{
"lat" : "50.915591",
"geomsuburb" : "Zollstock",
"id" : "359460",
"lon" : "6.941247",
"geompostcode" : "50969",
"geomcounty" : "Köln",
"errors" : [
"No city",
"No postcode"
],
"housenumber" : "107",
"source" : "node",
"street" : "Höninger Weg"
}
Dann prozessiere ich einen NRW Extract für OSRM und starte den mit
dem Extrakt. Und dann habe ich ein kleines perl script das die
Adressen alle einzeln in den OSRM rein wirft mit der "nearest"
Funktion und aus dem resultat die distance und die lat/lon des waypoints
mit der Adresse zusammen raus schreibt. Das braucht dann auch so ein
paar Stunden (Ja - OSRM kann batches - war mir erstmal egal - erstmal
brute forcen - CPUs sind auch bei stupider Tätigkeit genügsam)
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
On Fri, May 03, 2019 at 08:23:20AM +, Michael Brandtner via Talk-de wrote: > Ich finde, dass du hier teilweise Unzulänglichkeiten der > Rotuing-Engines den Mappern anlastest. Ich sehe keinen Grund, warum > nicht auf Tracks geroutet werden sollte, wenn diese der einzige Weg zu > einem Ziel sind. Auch access=destination sollte geroutet werden, wenn > es nicht als Durchfahrt genutzt wird, sondern das Ziel sich an dem so > getaggten Weg befindet. Wenn lange Zufahrten als access=private > gemappt sind, ist es natürlich schwierig. Das stimmt ja nur, wenn der > Weg tatsächlich vollständig über privaten Grund führt. Wäre aber für > mich auch vor allem eine Einstellungssache des Routers. "Privatwege > kurz vor dem Ziel erlauben" als Option programmieren, Problem gelöst. access=destination wird gerouted. Nur wenn man verstanden hat wir Dijkstra, A* oder dieserlei Algorithmen funktionieren - Es geht immer um "Kosten". Und die einzige möglichkeit sowas wie destination abzubilden ist den weg "teuer" zu machen - D.h. es wird "teurer" den zu benutzen. Ein access=private/access=no ist gar nicht zu benutzen. Und ob das Privatgrund ist hat nichts mit dem access tag zu tun. Es gibt reichlich öffentliche Straßen die auf Privatgrund sind. access tags beschreiben die rechtlichen Nutzungseinschränkungen. Wenn da ein Schild steht mit "Privatweg" dann tagge ich ein "ownership=private" - Wenn da ein "Durchfahrt Verboten" steht dann mache ich ein "vehicle=destination" da drauf. Ich kenne aber viele mapper die aus einem "Privatweg" oder "Durchfahrt verboten" ein access=no machen. Damit ist es dann halt kaputt. Aber das ist doch im Sinne der tags komplett richtig. Wenn da ein no oder private drauf ist wird ein router das nicht benutzen und das ist richtig so. Dieser teil Straße wird nicht in Betracht gezogen das es laut access tags _nicht genutzt werden darf_. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
Hi Martin, On Fri, May 03, 2019 at 02:57:14AM +0200, Martin Koppenhoefer wrote: > sent from a phone > > > On 2. May 2019, at 23:46, Florian Lohoff wrote: > > > > Egal - Hier sind die Daten für NRW - Vielleicht findet die ja jemand > > anderes auch Spannend. > > spannender wären die überhaupt nicht erschlossenen (in OSM). Soweit > ich deine Ausführungen verstanden habe sind hier alle enthalten, die > weiter als 75m von einer allgemein mit dem Kfz befahrbaren Straße > liegen, also auch alle die über längere Privatzufahrten erschlossen > sind oder in Fußgängerzonen liegen, usw. Für mich ist "gar nicht erschlossen" dasselbe wie "track" oder "access=no/private" auf einem service/driveway. Defakto gibt es keinen legalen weg bis "vor die Tür" zu navigieren. Und die Privatzufahrten sind mit drin - also werden benutzt - so weit sie nicht durch access tags verboten sind. Also ganz normales standard OSRM Car Profile. Ich habe zuhause ein ähnliches Problem. Unbefestigter Waldweg vor der Tür. Ist klar ein Service bzw ein unclassified weil öffentlich. Trägt aber ein motor_vehicle=destination und ich bin der einzige Anlieger. Drumherum gibt es reichlich Forstwirtschaftliche Wege. Wenn ich mit OSMAnd versuche nach hause zu navigieren dann werde ich Kreuz und quer durch den Wald geschickt weil die kosten für eine unclassified mit motor_vehicle=destination höher sind als die eines tracks. Das sind eben die letzten 2-3% Adressen die mit aktuellen Tags und Software nicht lösbar sind. Und die ganze nach Gefühl gemappten access=private/no auf jeder Hauszufahrt machen eben die navigation für diese Adressen kaputt. Wenn das im Wohngebiet nur die 10m Hauszufahrt sind - geschenkt. Wenn aber das Haus/Hof 800m neben der Straße im Wald oder Tal/Berg liegt und ich das nicht einmal sehe bzw der nächstgelegenene Punkt auf einer Öffentliche Straße auf einer Straße ist von der keine Zufahrt möglich ist das halt ziemlich suboptimal. Dann ist OSM für diesen Anwendungsfall auf dieser Adresse einfach kaputt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Erreichbarkeit von Adressen
Hi, ich habe mal damit gespielt alle Adressen in einem OSM Ausschnitt zu exportieren und dann für jede Adresse im OSRM den nearest point auf routingfähigen Straßen gesucht. D.h. car profile. Dann habe ich mir die Adressen die mehr als 75m von der nächsten befahrbaren Straße entfernt sind angesehen. Von diesen Adressen gibt es alleine in NRW 26341 Adressen. Nachdem ich da durchgesehen habe gibt es so ein paar wiederkehrende Kategorien: Im Urbanen sind das: - Große Industriegebäude von denen ich einen Geometrischen Centroid nehme, bzw große Industriekomplexe ohne Zufahrten/Service roads auf dem Gelände. - Fußgängerzonen in den Innenstädten - Nachverdichtung d.h. Bebauung in 2. Reihe Im ländlichen Bereich: - Lange Zufahrten die mit access tags unbefahrbar gemacht worden sind. access=private, motor_vehicle=no etc etc - Kilometerlange Tracks die Wohngebäude und Hofstellen erschließen. - Fehlende Hofzufahrten von abseits gelegenen Höfen, Forsthäusern etc. Ich weiss das jetzt einige wieder mit Grundsatzdiskussionen zum Thema access tags oder track vs. service anfangen. Defakto "verweigern" die gängigen Routingengines Autos auf Tracks (Meiner Meinung nach zu recht) so das hier diverse Höfe und ländliche Gebäude routingtechnisch nicht wirklich "erreichbar" sind. Auch eine Hofzufahrt mit "Privatweg" als access=private zu taggen halte ich für falsch. Postbote, Lieferdienst, Schulbus, Müllabfuhr fahren da mitunter rein. Den ländlichen Bereich finde ich persönlich viel spannender, da ein Gebäude was 400m weit weg ist mitunter nicht einmal zu sehen ist wenn OSMAnd oder OSRM meinen "Sie haben das Ziel erreicht". Ganz zu schweigen davon das mit zunehmender Distanz die Fehlerquelle auf eine völlig andere Straße/Zufahrt gemapped zu werden halt steigt. Egal - Hier sind die Daten für NRW - Vielleicht findet die ja jemand anderes auch Spannend. http://silicon-verl.de/home/flo/tmp/20190502-1837-nrw-maxdist-75.csv Spalten sind: id;object;postcode;city;street;housenumber;response;distance;wp lon;wp lat;addr lon;addr lat id - OSM Objekt ID object - way oder node je nachdem woher die Adresse kam postcode/city/street/housenumber - adresse response - return code aus dem OSRM distance - Distanz zum nearest waypoint aus der OSRM response wp lon/lat - Lon/Lat des Waypoints addr lon/lat - Lon/Lat der Adresse Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstimmung: associated-Street Relationen in DE abschaffen
On Tue, Apr 23, 2019 at 02:51:22PM +0200, chris66 wrote: > Am 23.04.2019 um 14:20 schrieb Florian Lohoff: > > Da konnten wieder einige Mapper es nicht abwarten. Heute gab > > es eine Reaktion der Stadt die die Nutzbarkeit der Straßenschlüssel > > bestätigte. Leider hatten mapper ohne Regionalbezug schon alle > > Relationen gelöscht. > > 1.) Ist (war) der Schlüssel "ref" für eine interne BI-Nummer schlicht > ungeeignet. sie könnte, da die Stadt Bielefeld aktiv mit mapped, zum Abgleich genutzt werden - wie ja die Antwort der Stadt auf der owl liste besagt gibt es einen eindeutigen Schlüssel. > 2.) Wurde auf mehreren Kanälen gefragt, ob die Daten genutzt werden, > es hat niemand bejaht. Ich habe gesagt (Siehe exakt diesen Thread) mit Bielefeld bitte zu warten weil wir das Diskutieren. > 3.) Eine CSV-Liste "Straßenname;BI-Nummer" kann bei mir per email > angefordert werden. Darum geht es hier nicht. Was mich ärgert ist das diese Relationen seit 10 Jahren in der Datenbank sind und sich jemand in Bielefeld viel Arbeit gemacht hat die refs einzutragen - Und dann müssen ganz plötzlich alle Relationen da raus und das möglichst gestern. Dazu Bestand überhaupt keine Notwendigkeit. Aber die die das angezettelt haben haben waren einfach gleichgültig gegenüber anderer Leute Arbeit und Historie und konnten auch nicht einfach mal Entscheidungen lokaler Gremien abwarten. Genau für solche Entscheidungen haben wir die aber. Deshalb bin ich ungehalten - Ich habe in Punkto Bielefeld hier ganz deutlich gesagt es bitte zu unterlassen weil die OWL Gruppe das diskutiert vor allem auch mit der Stadt. Bums - Alles gelöscht. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstimmung: associated-Street Relationen in DE abschaffen
On Mon, Apr 15, 2019 at 05:22:30PM +0200, chris66 wrote: > Putzaktion beendet. > > Es gibt keine AS-Relationen in Deuschland mehr. Zumindest für Bielefeld war das echt eine scheiß Aktion. Da konnten wieder einige Mapper es nicht abwarten. Heute gab es eine Reaktion der Stadt die die Nutzbarkeit der Straßenschlüssel bestätigte. Leider hatten mapper ohne Regionalbezug schon alle Relationen gelöscht. Ich muss bei sowas im Strahl kotzen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Mon, Apr 22, 2019 at 04:02:23PM +, Michael Brandtner wrote: > Parkraumbewirtschaftung ist unter bestimmten Umständen schon möglich, siehe > Beschluss des VG Gelsenkirchen vom 23.01.2014, Az.: 14 L 1856/13. > Wird z.B. im Hafengebiet Eckernförde praktiziert. Hast du da auch ein Volltext des Hauptsacheverfahrens? Das ist ja nur die Einstweilige Verfügung die abgelehnt wurde oder? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstimmung: associated-Street Relationen in DE abschaffen
On Thu, Apr 11, 2019 at 10:47:41PM +0200, chris66 wrote: > Hallo, > die Bielefelder Relationen wurden bisher verschont, weil sie > eine ref Nummer tragen, vermutlich eine BI-interne Straßennummer. > > Der Mapper der sie eingetragen hat ist nicht mehr aktiv. > > Frage: Benötigt noch irgendwer diese Nummer? Wird gerade auf der osm-owl liste Diskutiert. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Tue, Apr 09, 2019 at 12:11:57PM +0200, Hartmut Holzgraefe wrote: > Gegenbeispiel: > > https://osm.org/go/0GwAqppMc?m= > > Hier ist die Gutenbergstraße durchgehen verkehrsberuhigt, auch über die > Wittekindstraße > hinweg. D.h. auf der Wittekindstraße steht da in beiden Richtungen ca. 10m > vor der Kreuzung ein blaues Schild, man muss (in der erlebten Praxis eher: > müsste) dort also einmal auf Schrittgeschwindigkeit runter, > aber es ist klar zur Durchfahrt gedacht. > > Inwieweit so eine Konstruktion sinnvoll ist sei jetzt mal dahingestellt ... IMHO dürfte das sogar nicht StVO konform sein bzw nicht konform der VV StVO. 4 IV. Zeichen 325.1 ist so aufzustellen, dass es aus ausreichender Entfernung wahrgenommen werden kann; erforderlichenfalls ist es von der Einmündung in die Hauptverkehrsstraße abzurücken oder beidseitig aufzustellen. Hier steht das sogar auf der "Hauptverkehrsstraße". Ich halte die Schilder für rechtswidrig. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Tue, Apr 09, 2019 at 10:35:29AM +0200, Volker Schmidt wrote: > > Deshalb halte ich auch die default routing Tags für Deutschland 1) für den > > Verkehrsberuhigten Bereich für falsch. Der Satz > > "... überwiegend Aufenthalts- und Erschließungsfunktionen haben." > > sagt das es eigentlich wie "access=destination" zu behandeln ist. > > > > Fuer Oesterreich scheint das korrekt zu sein, fuer DE gilt das nicht. > Wikipedia <https://de.wikipedia.org/wiki/Verkehrsberuhigter_Bereich> sagt: > " ... in der Wohnstraße <https://de.wikipedia.org/wiki/Wohnstra%C3%9Fe> in > Österreich (*bei demselben Verkehrszeichen!*) ein Durchfahrtsverbot..." In Österreich ist es explizit erwähnt - In Deutschland kann man die Definition des verkehrsberuhigten Bereich so interpretieren. Wenn das nicht für den Fahrenden sondern den ruhenden und erschließenden Verkehr ist kann IMHO da kein quer oder Durchgangsverkehr erlaubt sein. > Bleibt das Problem: wie kann ich eine Verkehrsberuhigte Strasse in DE, wo > jeder durchfahren darf, aber nur mti Schrittgeschwindigkeit und Prioritaet > fuer Fussgenger uusw, fuer einen routing algorithm verdaubar machen? highway=living_street Alles gesagt. > access=destination ist eine tagging-Kruecke dafuer, und maxspeed=5 (oder 7 > oder 3) eine andere. > Uebrigens mit access=destination muesste man immer auch maxspeed=xx setzen, > sonst duerften Anlieger da drin so schnell fahren wie sie wollen. > ... und mit access=destination muesste man immer auch bicycle=yes setzen, > sonst werden auch Fahrraeder drum herum geroutet. > Ich denke, dass von beiden Kruecken maxspeed=5 (oder 7 oder 3) die bessere > ist. access=destination setzt du ja nur wenn da wirklich ein Schild steht. 1) 2) Und Zeichen 325 soll nach der Verwaltungsvorschrift mit keinerlei weiteren Zeichen eingeschränkt werden: "5 V. Mit Ausnahme von Parkflächenmarkierungen sollen in verkehrsberuhigten Bereichen keine weiteren Verkehrszeichen angeordnet werden. Die zum Parken bestimmten Flächen sollen nicht durch Zeichen 314 gekennzeichnet werden, sondern durch Markierung, die auch durch Pflasterwechsel erzielt werden kann." Deshalb hat meine Heimatgemeinde auch die Verkehrsberuhigten Bereiche in der Innenstadt zu Zone 20 gemacht weil im Verkehrsberuhigten Bereich keine "Parkraumbewirtschaftung" erlaubt ist, was eben genau an dieser Regel hängt das keine weiteren Schilder aufgestellt werden sollen. Flo 1) Dazu kommt das ein access=* in 95% der Fälle falsch ist - Es gibt nach StVO kein Schild was "access=*" einschränkt. Das maximale ist Zeichen 250 und das ist ein vehicle=no - Damit sind aber immer noch Fußgänger erlaubt was bei access=no nicht wäre. 2) Access restrictions sollten nur getagged werden wo sie explizit beschildert werden. OSM ist eine Faktensammlung keine "Sammlung von gefühlten fakten" -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Fri, Apr 05, 2019 at 01:29:28AM +0200, Garry wrote: > Am 27.03.19 um 00:08 schrieb Bernhard Weiskopf: > > Wenn ein Schild "7" steht, tagge ich "7". > > Wenn ein Schild steht, das "Schrittgeschwindigkeit" impliziert, tagge ich > > "walk". > > > > Ich maße mir nicht an zu entscheiden, ob "walk" nun 5 km/h, 6 km/h, 7 km/h, > > ... bedeutet. Das hat weder der Gesetzgeber festgelegt, noch haben das > > Gerichte einheitlich entschieden. > > > Mal so ausgedrückt: > > Was unter 7km/h liegt ist kein Fahren mehr, das ist Rangieren. Viele KFZ > müssen dann schon unterhalb "Leerlauf 1. Gang" betrieben werden und > Zweiradfahrer mit dem Gleichgewicht halten kämpfen - das ist kein > sicheres Fahren mehr. > > Das Augenmerk liegt dann nicht mehr bei der Tachonadel sondern darauf > nicht mit der Umgebung zu kollidieren. > > Mit diesem Hintergrund gibt es da auch keine Rechtssicherheit mehr durch > Gesetzgeber und Richter in Form eindeutiger Vorschriften und Urteile. > Gewünscht ist die langsamste mögliche Geschwindigkeit die sicher zu > fahren ist. Die ist technisch je nach Fahrzeug und Fahrer individuell > und somit nicht rechtssicher in Form von Messgrößen allgemein > (Fahrzeugtyp unabhängig) zu beschreiben. > > 7km/h ist daher ein sinnvoller Wert um dieser Thematik gerecht zu > werden. Wenn die Anwendungen dann noch eine Toleranz von 2-3 km/h > erlauben sollte man auf der sicheren Seite sein nicht wegen reiner > Geschwindigkeitsüberschreitung belangt zu werden. Das entbindet nicht > davon jederzeit bremsbereit sein zu müssen und derart vorausschauend zu > fahren dass ein Unfallrisiko minimiert wird. Das Betriebsrisiko bleibt > immer und man wird bei einem Unfall auch bei 1km/h kaum schuldfrei aus > der Sache herauskommen. Wenn man aber seine Konzentration darauf setzt > das Fahrzeug unterhalb der "passiven Mindestgeschwindigkeit" (ohne > schleifende Kupplung, "Zweiradakrobatik",.. ) zu betreiben steigt das > Risiko eines Unfalles wieder an was kaum im Sinne des Gesetzgebers sein > kann. Ein Numerischer wert ist eben einfach falsch und entstammt nicht der StVO oder einem Schild sondern einem Gerichtsurteil. Und ja - Exakt - es ist Rangieren. Das ist genau die Definition eines Verkehrsberuhigten Bereiches. Verkehrsberuhigte Straßen sind eben nicht zum Fahren sondern für den ruhenden Verkehr. Aus der Verwaltungsvorschrift für Zeichen 325: 2 II. Örtliche Voraussetzungen Die Kennzeichnung von verkehrsberuhigten Bereichen setzt voraus, daß die in Betracht kommenden Straßen, insbesondere durch geschwindigkeitsmindernde Maßnahmen des Straßenbaulast- trägers oder der Straßenbaubehörde, überwiegend Aufenthalts- und Erschließungsfunktionen haben. 3 III. Bauliche Voraussetzungen 1. Maßgebend für die Beschilderung von verkehrsberuhigten Bereichen sind - neben der damit angestrebten Erhöhung der Verkehrssicherheit - Gesichtspunkte des Städtebaus, insbesondere der Verbesserung des Wohnumfeldes durch Umgestaltung des Straßenraumes. 4 2. Die mit Zeichen 325 erfaßten Straßen müssen durch ihre Gestaltung den Eindruck vermitteln, daß die Aufenthalts- funktion überwiegt und der Fahrzeugverkehr hier eine untergeordnete Bedeutung hat. Dies kann u.a. dadurch erreicht werden, daß der Ausbau der Straße sich deutlich von angrenzenden Straßen, die nicht mit Zeichen 325 beschildert sind, unterscheidet. In der Regel wird ein niveaugleicher Ausbau für die ganze Straßenbreite erforderlich sein. 5 3. Straßen, die mit Zeichen 325 beschildert sind, dürfen von Fußgängern zwar in ihrer ganzen Breite benutzt werden; dies bedeutet aber nicht, daß auch Fahrzeugführern ermöglicht werden muß, die Straße überall zu befahren. Daher kann es im Einzelfall zweckmäßig sein, Flächen für Fußgänger zu reservieren und diese in geeigneter Weise (z. B. durch Poller, Bewuchs) von dem befahrbaren Bereich abzugrenzen. Deshalb halte ich auch die default routing Tags für Deutschland 1) für den Verkehrsberuhigten Bereich für falsch. Der Satz "... überwiegend Aufenthalts- und Erschließungsfunktionen haben." sagt das es eigentlich wie "access=destination" zu behandeln ist. Flo 1) https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Sat, Mar 30, 2019 at 06:23:44PM +0100, Andreas Labres wrote: > On 27.03.19 10:30, Martin Koppenhoefer wrote: > > aber wir schreiben seit 10 Jahren darüber > > Das wundert mich grade... ich dachte, das wäre längst irgendwie fixiert... https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dliving_street "In Deutschland sollte kein maxspeed gesetzt werden. Die offizielle Geschwindigkeit ist in der StVO mit Schrittgeschwindigkeit angegeben und alle numerischen Werte nur einer, sehr unterschiedlichen, Rechtsprechung entspringen. " Aber es gibt immer wieder jemanden der halt in seiner Umgebung alles mit maxspeed=3,5,7,10,11,12 tagged und dann andere das wieder entfernen und dann kommt von zeit zu zeit eine neue Diskussion. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erlaubte Höchstgeschwindigkeit in DE (was: Verkehrsberuhigter Bereich - maxspeed)
Hola Martin, On Sun, Mar 31, 2019 at 12:20:59PM +0200, Martin Scholtes wrote: > Eine Geschwindigkeitsbegrenzung gilt solange, bis sie entweder > widerrufen wird durch ein anderes Verkehrszeichen oder einen neuen > Straßenabschnitt. Das beste Beispiel ist das Schild für die > Vorfahrtstraße. Wie soll ein andere Verkehrsteilnehmer an einer Kreuzung > wissen, das er nach dem Abbiegen auf eine Vorfahrtstraße sich darauf > befindet. Nur durch nochmaliges Anzeigen des Schildes. Genau so bei den > Geschwindigkeiten: Wenn nichts angegeben gilt immer der default-Wert für > die den entsprechenden Bereich (ala Zone). Das ist Gerichtlich bereits anders entschieden. Auch ein nicht wiederholtes Schild entfaltet rechtliche Bindungskraft wenn der Automobilist ortskundig ist oder gar nicht eingebogen ist. Eine Geschwindigkeitsbeschränkung bzw alle Streckenverbote gelten bis sie aufgehoben werden. Sie wird nicht durch Einmündungen aufgehoben. Das behauptet zwar der Volksmund weil die Straßenverkehrsbehörden meist so "nett" sind und die Schilder wiederholen. Insoweit wird bei OSM oft falsch gemapped - Aber darüber haben wir hier schon oft diskutiert. https://www.burhoff.de/rspr/texte/ab_00028.htm "Dem Gesamtzusammenhang des Urteils kann jedoch entnommen werden, dass der Betroffene Angaben zur Sache gemacht hat und sich dahingehend geäußert hat, dass er das Zeichen 274 zwar wahrgenommen, er aber angenommen habe, das Streckenverbot sei nach der Kreuzung aufgehoben gewesen. Insoweit unterlag er jedoch einem vermeidbaren Verbotsirrtum. Entgegen der Auffassung des Betroffenen ist die Tatrichterin zu Recht davon ausgegangen, dass für den Betroffenen an der Messstelle die zulässige Höchstgeschwindigkeit durch Zeichen 274 auf 50 km/h beschränkt war. Er ist nach den vom Amtsgericht getroffenen Feststellungen nämlich nicht erst aus einer Seitenstraße kommend auf die Wittener Straße eingebogen, sondern befuhr diese bereits vor dem die Geschwindigkeit beschränkenden Zeichen 274. An diese Feststellungen ist das Rechtsbeschwerdegericht gebunden. Wie die Generalstaatsanwaltschaft in ihrer Stellungnahme zutreffend ausgeführt hat, gilt eine Streckenvorschrift nicht nur jeweils bis zur nächsten Straßeneinmündung -oder Straßenkreuzung. Es ist einhellige Meinung in Literatur und Rechtsprechung, dass eine durch Zeichen 274 angeordnete Geschwindigkeitsbeschränkung als sog. Streckenverbot erst an einen gemäß § 41 Abs. 2 Nr. 7 StVO aufgestellten Zeichen 278 endet (vgl. Hentschel, Straßenverkehrsrecht, 36. Aufl., § 3 StVO Rdnr. 46 m.w.Nachw.; Beschluss des Senats vom 8. Juli 1996, abgedr. in NZV 1996, 247). Zwar verlangt der Sichtbarkeitsgrundsatz die Wiederholung aller Streckenvorschriftszeichen hinter jeder Kreuzung oder Einmündung auf der Straßenseite, für die das Gebot oder Verbot besteht; dies gilt jedoch nur für den Einbiegeverkehr. " Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Besorgt über den iD-Editor
On Fri, Mar 29, 2019 at 03:32:47PM +0100, Frederik Ramm wrote:
> Hallo,
>
> ich benutzte "iD" selbst nur selten, aber es ist klar, dass dieser
> Editor ein Aushängeschild von OSM ist - ein Großteil der Neu-Mapper
> lernt OpenStreetMap durch iD kennen.
Für mich ist der unbenutzbar langsam - deshalb von Anbeginn Josm.
> Nach dem, was ich beurteilen kann, ist die meiste Arbeit, die in iD
> fliesst, solide und relativ un-kontroverse Ingenieursarbeit - da werden
> Algorithmen optimiert, das User Interface verbessert, Bugs gefixt. Und
> iD erhökt durchaus positives Feedback aus der Community (z.B.
> https://twitter.com/iandees/status/344426994024448). Zugleich
> äussern sich die Entwickler gern auch mal geringschätzend über das Wiki
> oder Tagging-Diskussionen und nehmen sich eben das Privileg heraus, neue
> Features einfach einzubauen, die sie gut finden, nach dem Motto "wir
> machen was WIR für richtig halten", und da frage ich mich bei
> Vollzeit-Angestellten natürlich manchmal, inwiefern das eben auch das
> ist, was der Arbeitgeber bzw. dessen Geldgeber wollen. Gleitet uns, der
> OSM-Community, hier die Kontrolle über unser eigenes Projekt aus der
> Hand, weil wir die "Doocracy" ("wer macht, entscheidet") unüberlegt auch
> für Firmen anwenden, die "machen lassen"? Kann man für den Jahrestarif
> von zwei Vollzeitgehältern praktisch das Tagging in OSM komplett an sich
> reissen?
>
> Müssen vielleicht jetzt schon Grenzen gezogen werden, weil es sonst
> irgendwann zu spät ist?
Zumindest fände ich es gut wenn das Templating ein wenig Konsensualer
passieren würde.
Ich habe mehrfach changeset kommentiert die mir komisch vorkamen und die
Antwort "Das hat mir der Editor so vorgeschlagen". Bisher war das noch
nicht so das ich gesagt habe das geht so gar nicht, aber mit einem
gewissen mulmigen Gefühl gucke ich da auch. StreetComplete ist mir
an der Stelle schon deutlich häufiger negativ aufgefallen. (Nicht
falsch verstehen - Ich finde StreetComplete super - Aber die
Entscheidungen die da getroffen werden was wie getagged werden muss
sind eben noch viel weniger konsensual und es gab/gibt die ich
schwierig finde z.b. access=yes auf leisure=playground)
> Oder läuft das Ganze eher noch unter "dem geschenkten Gaul schaut man
> nicht ins Maul" und unterm Strich ist es ja ein guter Editor?
Zumindest sollten wir uns als Community nicht bedrängen lassen oder
gezwungen sehen jede Änderung in Id einfach so zu übernehmen.
Und ich finde es schwierig das zu beurteilen. Alleine die Lokalisierung
von ID finde ich sehr schwierig, schiebe das aber eben drauf
das ich eben der Oldtimer bin. Es versteckt die Komplexität vor
dem Mapper - und Komplexität verstecken ist eben eine Medaille mit
2 Seiten.
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Fri, Mar 29, 2019 at 09:45:54AM +0100, Florian Lohoff wrote: > Korrekt - Es darf keine weiteren Straßenschilder geben, das Parken ist > nur in markierten Flächen erlaubt, er darf keine > "Parkraumbewirtschaftung" geben d.h. keine Parkscheinautomaten etc. > Fußgänger haben "vorfahrt" d.h. Priorität auf der "Fahrbahn" > > Deshalb sind in Gütersloh in der Innenstadt viele Verkehrsberuhigungen > zu Zone 20 gemacht worden weil man DA Parkscheinautomaten aufstellen > darf. Ach ja - Und noch eine Sache die oft vergessen wird. Das 325.2 also Ende Verkehrsberuhigt ist gleichbedeutend mit einem "Vorfahrt Gewähren". d.h. als jemand der den verkehrsberuhigten Bereich verlässt bin ich wartepflichtig. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Thu, Mar 28, 2019 at 10:46:28PM +0100, Martin Koppenhoefer wrote: > sent from a phone > > On 28. Mar 2019, at 22:42, Florian Lohoff wrote: > > > > Das ist schon im highway=living_street. Das ist nach der bisherigen > > tagging praxis ein verkehrsberuhigt und damit Zeichen 325 und damit > > Schrittgeschwindigkeit. > > > > Mehr ist einfach falsch weil du alles was du zusätzlich taggst falsch > > ist. > > vermutlich dürfen dort keine weiteren Geschwindigkeitsbegrenzungen > (explizit) aufgestellt werden, oder? Weil das Argument für das > explizite taggen eines impliziten Limits ist normalerweise, dass man > so angibt, dass kein explizites Limit besteht (im Gegensatz zu: man > weiß es nicht, im Fall von keinen weiteren tags). Korrekt - Es darf keine weiteren Straßenschilder geben, das Parken ist nur in markierten Flächen erlaubt, er darf keine "Parkraumbewirtschaftung" geben d.h. keine Parkscheinautomaten etc. Fußgänger haben "vorfahrt" d.h. Priorität auf der "Fahrbahn" Deshalb sind in Gütersloh in der Innenstadt viele Verkehrsberuhigungen zu Zone 20 gemacht worden weil man DA Parkscheinautomaten aufstellen darf. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Thu, Mar 28, 2019 at 10:30:11PM +0100, Martin Koppenhoefer wrote: > Wenn man sagen will dass kein Schild explizit die Höchstgeschwindigkeit > vorgibt kann man z.B. > source:maxspeed=DE:livingstreet verwenden. Das ist schon im highway=living_street. Das ist nach der bisherigen tagging praxis ein verkehrsberuhigt und damit Zeichen 325 und damit Schrittgeschwindigkeit. Mehr ist einfach falsch weil du alles was du zusätzlich taggst falsch ist. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Wed, Mar 27, 2019 at 10:30:08AM +0100, Martin Koppenhoefer wrote: > ob jemand 10 oder 3 fährt, es wird nicht die Geschwindigkeit sein, wegen > der man Probleme bekommt falls man jemanden umfährt. Wenn 7 km/h zu schnell > ist, dann ist 3 km/h immer noch zu schnell. > Im Prinzip ist es völlig egal ob man Pi nimmt oder ölf, aber wir schreiben > seit 10 Jahren darüber ;-). Der Punkt ist wenn du ein maxspeed=10 einträgst müsstest du auch ein maxspeed:type=legal: Andernfalls kannst du das von einem beschilderten Maxspeed 10 nicht unterscheiden. > Das größte "Risiko" hat wahrscheinlich "walk", weil wenn man es nicht > berücksichtigt ein default Wert genommen werden wird, der vermutlich > signifikant höher wäre. > Bei den nicht-numerischen maxspeeds spielt "walk" praktisch keine Rolle, es > führen "none" mit 41k, RU:urban 37k und RU:rural mit 12k, dann signals mit > 6k, RO:rural 2,8k und dann erst walk mit 2,3k (0.02% von 10,5M maxspeed). Mir geht es darum das WENN wir dinge in die Datenbank aufnehmen das die dann richtig sind und nicht geraten. Wir haben eh ein massives problem mit "gefühlten access restrictions" da müssen wir das mit den maxspeeds nicht auch noch anfangen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On Tue, Mar 26, 2019 at 01:21:30PM +0100, Andreas Labres wrote: > Hallo! > > Mit welcher maxspeed (und ggf. source:maxspeed) taggt Ihr in DE einen > Verkehrsberuhigten Bereich? > > 7 km/h? (ist in AT üblich für die "Wohnstraße", wie das Schild dort heißt) Gar nicht - Es gibt keinen numerischen Wert der in der StVO steht. Wenn überhaupt ginge maxspeed=walk - Da die maxspeed value aber als numerischen Wert definiert ist ist das broken. Die 7km/h war ein Urteil eines Gerichts. Da gibt es aber alles zwischen 3 und 7km/h - Welches Gerichtsurteil tragen wir das jetzt ein? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektes Tagging eines Feriengebiets
On Sun, Mar 24, 2019 at 05:20:03PM +0100, da370...@gmail.com wrote: > Hallo zusammen, > > ich stehe gerade vor dem Problem, nicht genau zu wissen, ob ein Tagging > korrekt ist. Es geht um ein Gebiet, welches mit Ferienhäusern bebaut > ist. Die Ferienhäuser gehören zu einem Freizeitpark und werden zwischen > Frühling und Herbst an Urlauber vermietet - meist für ein bis zwei > Wochen. Im Winter ist das Areal komplett geschlossen. > > Das Gebiet ist aktuell mit landuse=residential getaggt. Ich halte das > für falsch, da es keine Häuser zur dauerhaften Miete sondern eben nur > Ferienhäuser für Kurzaufenthalte sind. Dort "wohnt" daher niemand fest. > Andernfalls dürfte landuse=recreation_ground - das wäre der > naheliegendste Gedanke - ebenfalls falsch sein, da die Gegend nicht Teil > des eigentlichen Freizeitparks ist. Ich finde landuse=residential nicht so falsch. Am ende ist das Wohnen - Nur auf Zeit - aber nicht falsch. Auch in Hotel wird ja zum Wohnen genutzt (Udo Lindenberg wohnt Jahrzehnte Atlantic), deshalb ja auch die Anmeldung nach dem Meldewesen ;) Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] EU-Urheberrechtsrichtlinie: Banner und Aktionsseite für openstreetmap.de
Hi Michael, On Fri, Mar 08, 2019 at 12:31:36AM +0100, Michael Reichert wrote: > Hallo, > > in seiner Sitzung hat der FOSSGIS-Vorstand sich vorletzte Woche mit den > gewohnten Veränderungen an openstreetmap.de einverstanden erklärt. Diese > habe ich jetzt vorbereitet. Dabei handelt es sich um: > > - Die Aktionsseite (die übrigens immer noch online, aber nicht mehr > verlinkt war) habe ich aktualisiert. Zu den Änderungen bitte ich um > Kommentare. > - Für die Aktionsseite in ihrer alten Fassung habe ich eine englische > Übersetzung erstellt. Mithilfe bei der Aktualisierung der englischen > Fassung ist hier willkommen. > - Ich habe etwas dezentere (dunkelgraue statt schwarze) Banner für die > Start- und Kartenseite eingebaut. > > Auf https://michreichert.de/osm/openstreetmap.de/index.html könnt ihr > sehen, wie es aussehen wird. Die Änderungen gegenüber dem Status quo > könnt ihr im Quellcode unter > https://github.com/fossgis/openstreetmap.de/pull/26/files > anschauen. > > Ich habe mittlerweile drei Seiten mit Listen von Demonstrationen > gefunden. Ist der Protest v.a. in Mittel- und Osteuropa aktiv oder sind > mir noch keine Seiten für West- und Südeuropa über den Weg gelaufen? Als Aktionsseite kenne ich noch: https://botbrief.eu/ und eben https://pledge2019.eu/ Für die Linksammlung unter "Was kann ich dagegen tun?" Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell
On Fri, Jan 25, 2019 at 08:32:40PM +0100, Richard wrote: > > Und bicycle=no ist wieder genau so eine Überladung von tags die wir > > nicht brauche können. Damit kannst du Straßen bei denen ein Fahrrad > > wirklich verboten ist, und eine Straße bei der ein Radweg angeordnet > > ist nicht mehr voneinander unterscheiden. > > wenn der Radweg verpflichtend ist, ist die Straße de facto verboten? Das ist der Unterschied zwischen einem Verbot und einem Gebot. Die Straße ist nicht verboten. Ist der Radweg blockiert durch ein Auto oder eine Baustellen dürfen Radfahrer auf die Straße. Ist der Radweg nicht zumutbar (Weil z.b. entgegen der Fahrbahn) nicht von Schnee geräumt gehe ich davon aus das die Fahrbahnnutzung ebenfalls zulässig ist. Es ist eben was komplett anderes ob die Straße für Fahrräder gesperrt ist (z. B. Kraftfahrtstraße) oder eben es eine Benutzungspflicht für den Radweg gibt (Gebot) > Wenn Radweg nur in eine Richtung geht wäre die Straße dann > oneway für bicycle. Da gibt es ja alle Konstellationen. Ja nach meinem Verständnis sind Straßenbegleitende Radwege, ob angeordnet oder nicht, erstmal Fahrtrichtungsgebunden es sei denn Schilder wie "Fahrrad frei" geben den linksseitigen Radweg frei. (Wobei man sich dann lieber für die Fahrbahn entscheiden sollte aufgrund der Unfallstatistik) So wie ich das sehe können Benutzungspflichten auch einseitig ausgesprochen/angeordnet werden. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell
On Fri, Jan 25, 2019 at 07:48:36PM +0100, Florian Lohoff wrote: > > Wenn man eine Stadt hat die sich da sperrt musst du am Ende jede > einzelne Benutzungspflicht vor dem Verwaltungsgericht wegklagen. > Hier z.b. die Bewerbung meiner Heimatstadt Gütersloh um den Platz als Fahrradunfreundlichste Stadt in Deutschland: https://www.nw.de/lokal/kreis_guetersloh/guetersloh/21834790_Freigabe-des-Stadtrings-fuer-Radfahrer-kostet-Stadt-guetersloh-24.000-Euro.html "Unterdessen fordern aus der Politik einige Fraktionen die Stadtverwaltung auf, nach Wegen zu suchen, das Radfahren auf der Fahrbahn des Stadtrings entgegen des Richterspruchs auch künftig verbieten zu dürfen." Da ist teilweise 70 und LKW Verkehr. Trotzdem sieht das Verwaltungsgericht keine Notwendigkeit für eine Benutzungspflicht. Hier das Urteil: http://docplayer.org/63357868-Die-beklagte-traegt-die-kosten-des-verfahrens.html Am Ende war die Stadt Sauer. Im Ergebnis heisst das, das vermutlich 90% der Benutzungspflichten widerrechtlich sind. Proaktiv geht das aber keine Kommune an sondern wartet lieber bis sich einer beschwert oder eben klagt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell
Hola Richard,
On Fri, Jan 25, 2019 at 07:27:33PM +0100, Richard wrote:
> On Thu, Jan 24, 2019 at 08:26:32PM +0100, Hubert87 wrote:
> > Hallo Flo,
> >
> > das "Problem" mit bicycle=designated/yes ist leider so eine Sache.
> >
> > Einen eindeutigen Tag "Dieser Radweg ist benutzungspflichtig" gibt es leider
> > immer noch nicht.
> >
> > Stattdessen wird versucht dies mit der Unterscheidung zu bicycle=yes (imo
> > unzuverlässig) zu erreichen. (Und von mir über traffic_sign=* und
> > Straßenbezug ("cycleway/path=sidepath"))
> >
> > Im Grunde wird versucht durch "yes" alle nicht-benutzungspflichtigen Radwege
> > zu kennzeichnen, so dass für die benutzungspflichtigen Radwege nur
> > "designated" übrig bleibt.
>
> eigentlich ist nicht der Radweg bunutzungspflichtig sondern die Straße
> bicycle=no
Das ist eine Spitzfindigkeit die die Autolobby versucht zu verstecken.
Aber ja - In der Benutzungspflicht geht es um "Freie fahrt für freie
Bürger" d.h. Fahrräder von der Fahrbahn.
Defakto wollen wir zum einen die Straßen markieren die einen
Verpflichtenden Radweg haben. Zum anderen wollen wir den Radweg als
solchen kenntlich machen.
Und bicycle=no ist wieder genau so eine Überladung von tags die wir
nicht brauche können. Damit kannst du Straßen bei denen ein Fahrrad
wirklich verboten ist, und eine Straße bei der ein Radweg angeordnet
ist nicht mehr voneinander unterscheiden.
> Und soviel ich weiß wurden die Regeln für "benutzungspflichtig" in letzter
> Zeit so aufgeweicht, daß es fast immer irgendwelche ausnahmen gibt?
Das ist unerheblich. Wenn das Blaue Lolli da steht ist der erstmal
verpflichtend (Solange - Wir zitieren die Rechtssprechung: Der Weg zumutbar
ist).
Das die verkehrsrechtliche Anordnung zur Errichtung des Blauen Lollis
widerrechtlich, überholt oder veraltet ist, ist hier unerheblich.
Wenn das dingen da steht, du hälst dich nicht dran, dann wollen die
Sheriffs im Zweifelsfalle 15€ von dir.
Wenn man eine Stadt hat die sich da sperrt musst du am Ende jede
einzelne Benutzungspflicht vor dem Verwaltungsgericht wegklagen.
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell
On Fri, Jan 25, 2019 at 05:58:54PM +0100, Georg Feddern wrote: > Moin, > > nun ja - jeder benutzungspflichtige Radweg muss ja "designated"(*) sein - > sonst wär er ja nicht benutzungspflichtig. > 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.) > > 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. > Ein benutzungspflichtiger Radweg kann dann noch durch "is_sidepath=yes" > hervorgehoben werden. is_sidepath ist jetzt sprachlich keine "benutzungspflicht" genausowenig wie designated. Und in den verschiedenen Modellen Radinfrastruktur zu mappen haben yes/official/designated unterschiedliche Bedeutung. Mal davon abgesehen das ich von is_sidepath noch nie gehört habe. Wie ja schon in meiner initialen mail geschrieben ist für mich Radinfrastrukturmapping großflächig kaputt. Und je länger ich mich damit beschäftige desto mehr verstehe ich warum. Es gibt so viele verschiedene Proposal und alle überladen irgendwelche tags mit doppelbedeutungen so das am Ende die interpretation kaputt ist. Weil ein Weg für Fahrräder vorgesehen ist (designated) heisst das ja Sprachlich nicht das der Benutzungspflichtig ist. Auf der eigentliche Straße das bicycle=use_sidepath ist da ziemlich eindeutig. Aber der Weg der zu benutzen ist ist eben nicht kenntlich gemacht. Und hier sollte mal getrennt werden zwischen - Es gibt Radinfrastruktur - Wie ist die Radinfrastruktur physisch beschaffen - Wie ist die rechtliche Stand Wenn ein tag 2 dieser Bereiche überlappend beschreibt dann ists kaputt. Für teil 1 und 2 sehe ich gute Ansätze mit dem Lübecker Modell. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell
On Wed, Jan 23, 2019 at 10:03:39PM +0100, Hubert87 wrote: > Hallo Flo, > > bei dem Thema gibt es leider im Detail keinen abschließenden Konsens in der > entsprechenden Community. > > Das Lübecker Schema hast Du soweit, wie Du es beschrieben hast, im Kern Was mich halt immer stutzig macht das die existenz von etwas durch die absenz eines Tags angedeuted wird. Damit sind die zustände "nicht vollständig erfasst" und "da ist was aber es ist anders" nicht unterscheidbar. > richtig verstanden. Bitte schaue Dir im Vergleich dazu auch nochmal die > Seite > https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren > an. (Disclaimer: vor einiger Zeit hauptsächlich von mir überarbeitet.) Für mich ergibt sich nach 2 Minuten der erste Widerspruch zum Lübecker Modell. Für mich war immer - "angeordnet" -> "designated". Nicht angeordenet aber benutzbar "yes". https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren Getrennter Fuß- und Radweg ohne Benutzungspflicht cycleway:right:bicycle=designated In dem Modell nur durch traffic_sign=none erkennbar. *Soifz* Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Radverkehrsinfrastruktur / Lübecker Modell
Moin, ich tue mir glaube ich wie viele Mapper mit dem Thema Radverkehrsinfrastruktur extrem schwer. Die Matrix mit "An der Straße", "Separat", "Benutzungspflichtig", "Radfahrstreifen", "Schutzstreifen", "Benutzbarer Mehrzweckstreifen", "Richtungsgebunden", "path vs cycleway", "Linksseitig - Radfahrer frei" etc ist einfach gigantisch. Ich bin jetzt hier drüber gestolpert: https://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren_L%C3%BCbecker_Methode Und habe da eine Verständnisfrage: Wenn ich das Modell richtig verstehe dann habe ich auf einer Straße die die tags für den Radweg beinhaltet cycleway:left=track cycleway=left D.h. ich habe beides. Korrekt verstanden? Das habe ich meinem tag Fehlerfinder bisher IIRC anders drin. Dann habe ich eine Frage zum Thema Schutzstreifen vs. Radfahrstreifen. Hier sagt das Modell das ein angeordneter Radfahrstreifen ein bicycle=designated bekommt. Ein Schutzstreifen bekommt ein bicycle=yes (Beide haben cycleway:*=lane.) D.h. ich habe bei Schutz-/Radfahrstreifen jetzt diese Kombinationen: Angeordneter Radfahrstreifen: cycleway=left cycleway:left=lane cycleway:left:bicycle=designated Schutzstreifen cycleway=left cycleway:left=lane cycleway:left:bicycle=yes Nicht angeordneter Radfahrstreifen: cycleway=left cycleway:left=lane Korrekt? Ich finde das ganze Thema Radinfrastruktur trotz Fahrradaffinität einfach nur ultrakompliziert. Und das Tagging in weiten teilen von OSM (Zumindest in Deutschland) spiegelt das wieder. Es wird irgendwas, irgendwie gemapped damit das in der Karte wie ein Radweg aussieht. Dann finden sich da bicycle=official oder designated oder yes und in wildesten kombinationen. Mal ist es separat gemapped mal an der Straße. Dann fehlen auf den Separaten wegen die oneways (Völlig unüblich) etc Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Network Relationen
On Mon, Jan 07, 2019 at 11:34:23PM +0100, Martin Scholtes wrote: > Nabend zusammen, > > bin derzeit wieder für den PT am arbeiten und musste feststellen das ich > einige Relationen zwar in der Datenbank finde, sie aber nicht über > ID/PL2 oder JOSM bearbeiten kann. > > ID 1991320 u. 1389631 als Beispiel. > > Weiß jemand wie ich dran ran komme? JOSM - Bus stop runterladen. Rechts klick auf die Relation und "Relation Selektieren" und dann ctrl-alt-d (Download parents). Dann fortpflanzen über die Relationen. Hat bei mir gerade geklappt. Gut das ich sowas nicht bearbeite ;) Gruselig. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung
On Tue, Dec 25, 2018 at 02:13:38PM +0100, sepp1...@posteo.de wrote: > Tom, > > OsmAnd läuft weder auf dem Rechner, noch auf dem Garmin, noch auf einem > Windowsphone, etc., noch werden die Daten im openrouteservice ausgegeben. > Heißt im Klartext, ich kaufe mir entweder ein googleverseuchtes Androidphone > oder die teure Navisoftware für Lkw - das ist doch nicht Sinn der Sache? Aus > "Don't tag for the renderer." wird "Tagging for the OsmAnd." oder wie soll > ich das verstehen? Es steht dir frei Google freie Android Versionen zu installieren. Es gab jetzt wirklich JEDE MENGE Lösungen für dein Problem. Die scheinst du nicht sehen zu wollen sondern beharrst auf dein "Ich will das aber gerendert haben". Habe ich das richtig verstanden? > Sorry - das ist nicht zufriedenstellend. Siehe Lösungen in vorrangegangenen Mails. Es gibt OSM Lösungen mit denen das geht. Todays Menu - Take it or leave it. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feature Proposal - Abstimmung von "Empfehlung zur Verwendung von Multipolygonen"
On Wed, Dec 19, 2018 at 10:41:43PM +0100, Tigerfell wrote: > Wikiuser Flohoff (4.12.): > > "Es fehlt der Nachweis das dieses ein weit verbreitetes Problem ist. Ja - > > es gibt regionale Häufungen die von einigen wenigen Mappern verursacht > > worden sind. Es ist aber kein "Massenphänomen". Diesewenigen Mapper wird > > man auch nicht "bekehren" können." > Die Tatsache, dass etwas möglicherweise nicht weit verbreitet ist, schließt > eine Regelung nicht aus. Durch die vielen Kommentare habe ich den Eindruck, > dass die Angelegenheit vielen Beitragenden am Herzen liegt und das ist für > mich bereits ausreichend. Der Punkt ist das wir uns in Detailverliebtheit verrennen. Wenn es kein Problem ist sollten wir es nicht regeln - Ansonsten haben wir bald ein Regelsatz gegen den das Deutsche Steuerrecht wie ein Pixi Buch wirkt. Wir haben heute schon das Problem das wir hunderte von unausgesprochenen Regeln haben wie wir mappen. Das hindert ganz massiv das hinzuwachsen von neuen mappern. Alles was wir jetzt drauf packen ist einfach nur eine neue Hürde neue mapper zu finden. OSM muss einfacher werden - nicht komplizierter. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Path / Pfade / Mehrzweckwege
On Mon, Dec 17, 2018 at 06:55:01PM +0100, Volker Schmidt wrote: > Diese Aussage ist sachlich falsch, und im Widerspruch zum Wiki. > Die änderung das tracktype auf etwas anderem als track sinn macht oder nutzbar ist stammt aus Mai 2018 und ist IMHO nicht konsenzfähig. Nur weil da jeder drin editieren darf entspricht das nicht einem konsenz. Das wiki sagt in: https://wiki.openstreetmap.org/wiki/Key:tracktype Description Provides a classification of tracks. Und zwar nur für tracks. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Path / Pfade / Mehrzweckwege
On Mon, Dec 17, 2018 at 10:16:29AM +0100, Leonhard Lenz wrote: > Wenn es das gleiche System sein soll, warum nicht einfach komplett mit > den gleichen Tags und Keys übernehmen? Auch wenn dort tracktype steht, > ist ja eigentlich egal. > > tracktype wird ja auch ab und zu für residential oder service verwendet. Das sind Unfälle die durch splitten entstehen und dadurch das mapper dann die tracktypes nicht entfernen. Und DAS habe ich statistisch untersucht weil tracktype auf != highway=track einer meiner dinge ist die in den waytags als Fehler hochkommen. 100 Mapper die ich anschrieb sagten: Ich habe das gesplittet und vergessen. Tracktype ist und war ein doofes konzept das es eigentlich auszurotten gilt. Es verlangt vom mapper eine klassifizierung und generalisierung die eben total subjektiv ist. Genau das wollen wir aber nicht. Wir wollen fakten sammeln. Also sind tags wie surface/lanes/lit viel besser weil die eben validierbare fakten beschreiben. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
