talk-ch February 2019

talk-ch@openstreetmap.ch

12 participants
12 discussions

Update GWR Strassennamenvergleich
by Simon Poole 13 Nov '19

13 Nov '19

Ich habe über die letzten paar Wochen alle Dienste auf qa.poole.ch auf einen neuen Server gezügelt, speziell auch http://qa.poole.ch/ch-roads/ Ich habe die Gelegenheit auch genutzt um die GWR Daten auch wieder mal zu erneueren, sie sind jetzt auf dem Stand von September 2017. Ausser, natürlich, einigen zusätzlichen Strassen (1400) scheint sich die Liste in sofern geändert zu haben, als das Objekte in der früheren "unbekannt"/"unbekannt" Kategorie (in meiner Erfahrung waren, dass hauptsächlich Objekte im Bau, oder in sehr faule Gemeinden) jetzt in der Kategorie "kein Typ"/"none" sind, was aber schlussendlich für uns keine grosse Rolle spielt (d.h. aber auch das die Kolonne "GWR unknown" 0 sein sollte, sonst schaut man sich die alten Daten an). Wenn man noch vergleichen will: alte Site http://hz2.poole.ch/qa/ch-roads/ noch für ein paar Tage, neue http://hz3.poole.ch/qa/ch-roads/. Ansonsten muss noch dazu gesagt werden, dass es immer noch eine relative grosse Anzahl an Nullern hat (auch noch einer im Kanton Bern), und noch eine erhebliche Anzahl an Gemeinden mit sehr viel abweichenden Schreibweisen oder Tippfehler, die nicht überprüft wurden (siehe auch http://wiki.openstreetmap.org/wiki/OSM_-_GWR_Street_and_Place_Names_Compari… dazu). Eigentlich wäre es eine kleine Sache mindestens die Fälle abzuklären. Simon

3 13

mobility - Vorschlag für einen (halb-)mechanischen Edit
by Simon Poole 28 Feb '19

28 Feb '19

Vor mehreren Jahren wurden Die Mobility Standort in der Schweiz nach OSM importiert, die Geschichte und die Irrungen und Wirrungen darum sind aber nicht um was es geht. Sondern all die ehemals importierten Standorte haben noch die folgende Tags note:de Mobility Standorte werden automatisch in OSM importiert durch Benutzer Teddych. Ändern Sie die Daten nicht in OSM, sondern melden Sie Änderungen direkt an Mobility. note:en Mobility stations will be imported into OSM automatically by user Teddych. Do not update them in OSM, report changes to Mobility directly. note:fr Mobility emplacements sont importer automatiquement dans OSM. Annoncez des changement direct à Mobility. Die Tags waren vermutlich nie wirklich sinnvoll, jetzt treffen sie aber definitiv nicht mehr zu und halten möglicherweise Mapper davon ab die Daten zu verbesseren. Ich wäre dafür diese Tags ersatzlos zu entfernen. Simon

10 33

Wochennotiz Nr. 448 12.02.2019–18.02.2019
by Wochennotizteam 25 Feb '19

25 Feb '19

Hallo, die Wochennotiz Nr. 448 mit vielen wichtigen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/blog/2019/02/wochennotiz-nr-448/ Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz einreichen könnt, ohne Mitglied zu sein? Einfach auf https://osmbc.openstreetmap.de/login mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. Viel Spaß beim Lesen Euer Wochennotizteam

1 0

Wochennotiz Nr. 447 05.02.2019–11.02.2019
by Wochennotizteam 17 Feb '19

17 Feb '19

Hallo, die Wochennotiz Nr. 447 mit vielen wichtigen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/blog/2019/02/wochennotiz-nr-447/ Viel Spaß beim Lesen!

1 0

Experimentelles Öffnungszeiten-Webtool
by Stefan Keller 16 Feb '19

16 Feb '19

Liebe alle In meinem Lab experimentieren wir manchmal mit Software und zurzeit ist ein simples Öffnungszeiten-Webtool namens "Web to OSM Opening Hours" am Entstehen. Das Tool soll die Tipp-Arbeit abnehmen und versucht die Öffnungszeiten einer Webseite in die maschinenlesbare Form von opening_hours konvertieren. Ein typischer Ablauf ist, dass man auf einer Webseite den Text zu den Öffnungszeiten mit der Maus auswählt und per Copy & Paste ins Textfeld des Webtools kopiert. Beispiel - Input: Dienstag bis Freitag: 07:30 - 12:00 und 13:15 - 18:30 Uhr Samstag: 07:30 - 16:00 Der Output wäre hier "Tu-Fr 07:30-12:00,13:15-18:30; Sa 07:30-16:00". Zurzeit werden nur deutschsprachige Öffnungszeiten unterstützt. Wir experimentieren mit zwei unterschiedlichen Implementationen: * A's Version https://codepen.io/AlejoFab/full/WLbBQr und * B's Version https://codepen.io/BSee/full/WLbLGW ! Feedback willkommen - hier oder als Issue im Repository! Schöne Festtage wünscht, Stefan

4 6

Probleme mit Bremgarten
by wambacher＠posteo.de 15 Feb '19

15 Feb '19

Hi, irgendwas stimmt was nicht mit den Grenzen von Bremgarten(8) https://www.openstreetmap.org/relation/3411166 und Bremgarten AG(8) https://www.openstreetmap.org/relation/1684279. Bremgarten(8) sieht für mich ok aus, aber Bremgarten AG(8) liegt genau drüber. So, als ob es ein Stadtteil wäre - aber das kann ich nicht beurteilen. Entweder muss das weg oder ein höheres Admin Level (9?) bekommen. danke und Gruss walter -- My projects: Admin Boundaries of the World <https://wambachers-osm.website/boundaries> Missing Boundaries <https://wambachers-osm.website/index.php/projekte/internationale-administra…> Emergency Map <https://wambachers-osm.website/emergency> Postal Code Map (Germany only) <https://wambachers-osm.website/plz> Fools (QA for zipcodes in Germany) <https://wambachers-osm.website/fools> Postcode Boundaries of Germany <https://wambachers-osm.website/pcoundaries>

2 1

funktioniert die Verteilung über die Auflösungsebenen nicht richtig?
by Ludwig Baumgart 12 Feb '19

12 Feb '19

hallo , kann mir jemand sagen, ob ich mit meinen Einträgen über josm einen Fehler mache oder funktioniert die Verteilung über die Auflösungsebenen 17 18 19 nicht richtig? Denn es dauert Tage und Wochen, bis Häuser und Hausnummern erscheinen z.B. in Tengen https://www.openstreetmap.org/#map=19/47.82076/8.66763 oder Blumenfeld oder Steisslingen. Joachim K. hatte mich auf https://forum.openstreetmap.org/viewtopic.php?id=64772 hingewiesen, aber weitergeholfen hat das nicht wirklich. Was habe ich falsch gemacht? mhG Ludwig Baumgart (lubaum)

2 1

Kanton Bern Adress-Import (GEBADR)
by Stefan Berger 11 Feb '19

11 Feb '19

Hallo zusammen, nach dem Hintergrundlayer der Gebäudeumrisse sind mittlerweile auch die Adressdaten im Tasking Manager aktualisiert (Stand 1. Jan 2019). Die OSM-Import-Daten werden ja aus dem GEBADR-Datensatz prozessiert. Diesbezüglich gibt es zwei Anpassungen im Vergleich zu früher: - der Kanton gibt die Höhe über Meer nicht mehr im GEBADR-Datensatz an. Folglich gibts den OSM-tag "ele" auch nicht mehr. - die Art der Gebäudenutzung ("NUTZUNG" im GEBADR-Datensatz) dient als Grundlage zur Klassifizierung von verschiedenen OSM building types. Diese NUTZUNG-Einträge sind neuerdings bilingue anstatt nur Deutsch, z.B. 'Wohn- und Geschäftshaus / Habitation/commerce'. Die Namensänderungen musste ich im Script anpassen, die OSM building types sollten schlussendlich aber praktisch die gleichen sein wie bisher. Wie so oft ein grosses Merci an Michael, der die Daten dann gemeindeweise in den Tasking Manager eingebunden hat. Erfreulicherweise sind bereits über 80 % der Fläche im Kanton Bern adressiert. :-) Wünsche euch weiterhin frohes Mappen! Liebe Grüsse Stefan

1 0

Vorgeschlagene mechanische Bearbeitung: Löschung von addr:suburb=*-Tags in Bern
by Markus 10 Feb '19

10 Feb '19

Hallo zusammen Mir ist aufgefallen, dass die Problematik mit den falschen addr:suburb=*-Tags in Bern noch nicht erledigt ist. [^1] Zur Erinnerung: addr:suburb=* sollte nur verwendet werden, wenn die Post sie benötigt, um ansonsten identische Adressen in einer Stadt zu unterscheiden. [^2] Dies ist in Bern nicht der Fall – die in den addr:suburb=*-Tags erfassten Quartiersnamen gehören nicht zur postalischen Adresse. Die addr:suburb=*-Tags wurden hier fälschlicherweise verwendet, um darüber Auskunft zu geben, in welchem Quartier sich eine Adresse, Haus oder POI befindet. Wie in einem älteren E-Mail bereits erwähnt ist dies meines Erachtens überflüssig, da die Information zum Quartier bereits effizienter in den boundary-Relations enthalten ist. Eigentlich wollte ich deshalb nun vorschlagen, addr:suburb=* in is_in:quarter=* umzuwandeln. Nun habe ich aber festgestellt, dass z. B. im Quartier Muesmatt von insgesamt 504 addr:suburb=* nur 43 den Namen des Quartiers Muesmatt enthalten, die anderen 470 jedoch den Namen des benachbarten Quartiers Länggasse. [^3] Aufgrund dieser hohen Zahl an Fehlern schlage ich nun vor, die insgesamt 4'608 addr:suburb=* in Bern zu löschen. Übrigens habe ich die Adressen, die sich innerhalb der Gemeinde Bern befinden, aber deren postalischer Ort nicht Bern ist (sondern z. B. Wabern [^5] oder Worblaufen [^6]) bereits bereinigt. [^1]: <http://lists.openstreetmap.ch/pipermail/talk-ch/2018-May/thread.html#9523> [^2]: <https://wiki.openstreetmap.org/wiki/Key:addr> [^3]: <http://overpass-turbo.eu/s/FL0> [^4]: <http://overpass-turbo.eu/s/FL2> [^5]: <https://www.openstreetmap.org/node/631795115> [^6]: <https://www.openstreetmap.org/node/622967620> Grüsse und einen schönen Sonntag Markus

2 3

Wochennotiz Nr. 446 29.01.2019–04.02.2019
by Wochennotizteam 09 Feb '19

09 Feb '19

Hallo, die Wochennotiz Nr. 446 mit vielen wichtigen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/blog/2019/02/wochennotiz-nr-446/ Viel Spaß beim Lesen!

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

talk-ch February 2019