OpenStreetMap

Diary Entries in German

Recent diary entries

Brisant: Ost-West-Trennung an der Glienicker Brücke wieder aktuell!

Posted by glibbertorsten on 12 February 2016 in German (Deutsch)

Die Trennung von Ost und West ist deutlicher den je! Google hat neue Luftaufnahmen von Potsdam veröffentlicht, auf denen deutlich wird, das der Osten keine Chance mehr hat, den "Rückstand" noch aufzuholen... Es ist sogar schon soweit, das sich die Jahreszeiten verschieben!

Im Westen ist schon Sommer, im Osten noch nicht mal Frühling: google Satellitenfoto Glienicker Brücke

:-) Fröhliches Mappen mit besserer Sicht auf sonst von Bäumen verdeckte Häuser!

Location: Wannsee, Steglitz-Zehlendorf, Berlin, Deutschland

4000 gelöschte Place-Nodes in Deutschland – und nun?

Posted by malenki on 11 February 2016 in German (Deutsch)

Screenshot gelöschter, wiederhergestellter places in Deutschland

Edit: Damit "4000 gelöschte Orte" nicht so abstrakt daherkommen, habe ich auf umap daraus eine Karte erstellt.

Kürzlich stieß ich wieder einmal auf einen der Mapper, der etliche place-Nodes löschte, weil die ja auch am landuse stehen (oder er sie (teilweise) dorthin kopiert hatte).[0]

Nun steht ja im Wiki, dass man places sowohl als node, als auch als way als auch mit beidem mappen kann, also ist das, was die Mapper da treiben, im Prinzip nicht verkehrt. Mich stören aber zwei Dinge: Zum Einen sind die Nodes in der Regel einige Jahre älter als die Umringe der Ortschaften. Mit diesen Löschungen geht ein Teil der OSM-Geschichte verloren. Zum Anderen schaffen es manche der Mapper nicht, alle Tags zu kopieren…

Da ich über längere Zeit etliche solcher Löschungen gesehen hatte, wollte ich nun wissen, wieviel places in Deutschland denn im Laufe der Zeit insgesamt gelöscht wurden.
Dazu habe ich die Overpass API für jedes deutsche Bundesland für September 2012 (Beginn der Overpass-API-Zeitrechnung), die ersten Januare von 2013-15 und Februar 2016 nach allen place=nodes gefragt.[1] Eine Abfrage über ganz Deutschland ist offenbar zu ressourcenhungrig und läuft in einen Timeout.
Die Abfrageresultate für 2012-2015 und die für 2016 habe ich jeweils zu einem deutschlandweiten Datensatz verbunden.

Places mit den Werten "locality, field, location, political_structure, yes, island, islet" habe ich ignoriert:

$ osmfilter 2016-02-10_Germany_places_node.osm --drop="place=locality \  
=field =location =political_structure =yes =island =islet" \  
--keep-tags="all place= name=" > \  
2016-02-10_Germany_places_node_nur_name_und_valide_plätze.osm

Von den places will ich nur die Node-IDs vergleichen:

$ osmconvert 2012-2015_Germany_places_node_nur_name_und_valide_plätze.osm \  
--all-to-nodes --csv="@id" --csv-headline| sort|uniq > \  
2012-2015_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv

Resultate

Wenn man nur die Daten zwischen dem 12.09.2012 und dem 11.02.2016 vergleicht, wurden 5429 places neu erstellt und 3266 gelöscht.

Zieht man noch die Daten von 2013-2015 in Betracht, wurden in diesem Zeitraum weitere 526 places erstellt und wieder gelöscht, so dass die Gesamtzahl gelöschter place-nodes 3792 beträgt.[2] Für die Überschrift habe ich etwas aufgerundet, weil a) 4000 viel reißerischer klingt als so eine krumme Zahl :)und b) sicherlich auch innerhalb eines Jahres place-nodes entstehen und vergehen, die durch mein Raster gefallen sind.

Die IDs habe ich in eine Datei geschrieben[3], etwas umformatiert und über das undelete-Plugin wiederhergestellt. Dort lauert aber seit langer Zeit die Falle, dass Objekte mit einem Redaction-Vorgang in der History nicht wiederhergestellt werden.
(Sinnvollerweise hätte ich gleich die undelete-Tools aus dem OSM SVN-Repository verwenden sollen. Für die nicht wiederhergestellten 85 Nodes war ich zu bequem, diese zu bemühen und habe ein paar gruslige Einzeiler dafür verwendet.)

Von den gelöschten places hatten in der letzten Version 3045 ein name-Tag:

grep -w "'name'" places_gelöscht_wiederhergestellt_inclusive_redacted.osm -c
3045

Nun habe ich die 3792 wiederhergestellten place-Nodes – und weiß nicht, was ich damit tun soll. Die in meiner Region – Landkreis Mittelsachsen – schaue ich garantiert durch, aber alle selbst zu überprüfen und gegebenenfalls selbst wiederherzustellen ist mir zuviel Aufwand. Wären das eine Idee für eine Wochenaufgabe? Für Maproulette? Oder soll ich sie ins Wiki kippen und auf das Beste hoffen?

Wer sich die Daten mit den wiederhergestellten Nodes anschauen will, kann sie hier herunterladen. Die Rohdaten finden sich hier.

Im Forum habe ich einen Thread eröffnet, weil dort mehr diskutierendes Publikum verkehrt.

Fußnoten
[0] Nein, ich habe ihn noch nicht kontaktiert und möchte ihn auch nicht an den Pranger stellen. Er steht hier nur als Beispiel für diese Art Mapper und des Mappens.

[1]

for i in $(less areas); do wget --timeout=1800 "https://overpass-api.de/api/interpreter?data=%5Bout%3Axml%5D%5Btimeout%3A1800%5D%5Bdate%3A%222013-01-01T00%3A00%3A00Z%22%5D%3B%0Aarea%28\  
$(echo "$i"| cut -d "_" -f 2)%29-%3E.searchArea%3B%0A%0A%28%0A%20%20node%5B%22place%22%5D%28area.searchArea%29%3B%0A%29%3B%0Aout%20meta%3B%0A%3E%3B%0Aout%20meta%20qt%3B" -O - > \  
"2013-01-01_$(echo "$i"| cut -d "_" -f 1)_places_node.osm" && sleep 100 && wget --timeout=1800 \  
"https://overpass-api.de/api/interpreter?data=%5Bout%3Axml%5D%5Btimeout%3A1800%5D%5Bdate%3A%222014-01-01T00%3A00%3A00Z%22%5D%3B%0Aarea%28\  
$(echo "$i"| cut -d "_" -f 2)%29-%3E.searchArea%3B%0A%0A%28%0A%20%20node%5B%22place%22%5D%28area.searchArea%29%3B%0A%29%3B%0Aout%20meta%3B%0A%3E%3B%0Aout%20meta%20qt%3B"\  
-O - > "2014-01_01_$(echo "$i"| cut -d "_" -f 1)_places_node.osm" && sleep 100 && \  
wget --timeout=1800 "https://overpass-api.de/api/interpreter?data=%5Bout%3Axml%5D%5Btimeout%3A1800%5D%5Bdate%3A%222015-01-01T00%3A00%3A00Z%22%5D%3B%0Aarea%28\  
$(echo "$i"| cut -d "_" -f 2)%29-%3E.searchArea%3B%0A%0A%28%0A%20%20node%5B%22place%22%5D%28area.searchArea%29%3B%0A%29%3B%0Aout%20meta%3B%0A%3E%3B%0Aout%20meta%20qt%3B"\  
-O - > "2015-01_01_$(echo "$i"| cut -d "_" -f 1)_places_node.osm"; done

"areas" ist eine Liste der deutschen Bundesländer mit Name und der API-internen ID dieser Fläche:

Baden-Württemberg;3600062611
Bayern;3602145268
Berlin;3600062422;
Brandenburg;3600062504
Bremen;3600062718
Hamburg;3602618040
Hessen;3600062650
Mecklenburg-Vorpommern;3600028322
Niedersachsen;3600062771
Nordrhein-Westfalen;3600062761
Rheinland-Pfalz;3600062341
Saarland;3600062372
Sachsen;3600062467
Sachsen-Anhalt;3600062607
Schleswig-Holstein;3600051529
Thüringen;3600062366

[2] comm lieferte die Daten, wc die Zahlen:

$ comm 2012-2015_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv \  
2016-02-10_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv -23|wc -l

3792

$ comm 2012-09-12_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv \  
2016-02-10_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv -23|wc -l

3266

$ comm 2012-2015_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv \  
2016-02-10_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv -13|wc -l

5429

[3]

$ comm 2012-2015_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv \  
2016-02-10_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv -23 > places_gelöscht_ID

$ comm 2012-2015_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv \  
2016-02-10_Germany_places_node_nur_name_und_valide_plätze_nur_id.csv -13 > places_neu_ID
Location: Neunheiliger Weg, Schlotheim, Unstrut-Hainich-Kreis, Thüringen, 99994, Deutschland, Europa

Kartierung von Veranstaltungsarealen

Posted by Toliman on 10 February 2016 in German (Deutsch)

Welche Tools existieren zur Kartierung von Veranstaltungsarealen?

Häufig ist, insbesondere bei größeren Veranstaltungen, wie Volksfesten eine detaillierte Kartierung erwünscht. Wenn das Volksfest im nächsten Jahr wieder stattfindet, sind die Attraktionen häufig wieder am selben Ort errichtet, so daß es sinnvoll ist, für eine Neukartierung die Version aus dem letzten Jahr als Vorlage zu benutzen. Kann man auf diese wieder zurückgreifen? Kann man für bestimmte Areale mehrere austauschbare Karten definieren, was für die Kartierung von Festplätzen sehr sinnvoll wäre.

Welche Tools existieren, um die Route von Umzugsveranstaltungen auf Openstreetmap zu definieren?

In Addition to weeklyOSM

Posted by derFred on 9 February 2016 in German (Deutsch)

Mapa del Asado

#ElMapaDelAsado

Here the statement from Miguel Graziano:

"El Mapa del Asado nació en medio de una situación compleja y con la intención de dar una respuesta al aumento de precios y la pérdida de poder adquisitivo de los salarios. La idea es compartir los datos de los comercios (carnicerías) en donde el producto se ofrece a menor precio para combatir la inflación.

Los comerciantes pueden ver que sus colegas venden a mejor precio y los consumidores cuentan con una herramienta para cambiar el lugar en el que realizan sus compras. El mapa demostrará que muchas veces la relación entre el precio y la calidad es un prejuicio. Y que exactamente el mismo producto, con la misma calidad, se vende a valores muy diferentes en diferentes comercios.

Además, como el gobierno desmanteló los organismos para medir la inflación, sirve también para establecer una estadística sobre la fluctuación del precio del producto. En Argentina, el asado es una excusa para el encuentro entre familiares y amigos, por lo que otra de las ideas que motorizó la creación del Mapa es, frente a la crisis, mantener este acontecimiento cultural que nos reúne alrededor de la mesa."

  • lstryjek@smapache.com.ar said to us: We developed a Collaborative map with the main objective of compare meat price and to know the potential price distribution, lower and higher price by boundary box / zone.

We are currently going trough an inflation process here in Argentina, and meat price is getting higher and higher. This tool helps people find cheap and good meat price near house. It's kind of that simple.

Since we launched the web, it is huge success. The first 2 days people marked three thousand butcher shop with address and meat price.

There was lots of media noise around here. This is a list of media interviews we had:

The next step is to import this data into OSM and keep a updated dataset of butcher shops.

Opening_hours Statistik-porn

Posted by MKnight on 7 February 2016 in German (Deutsch)

Ok, eher Softporno, hab diesmal nicht alles durchgezählt, sonst hätt ich 3 Tage statt einen gebraucht.

In den letzten 4 Wochen wurden deutschlandweit 12.500 Objekte erstellt oder geändert die (zum heutigen Stand) Öffnungszeiten beinhalten. Das ist recht dehnbar, aufgrund solch diffuser Daten ne Statistik zu bauen (wenn wer ne vernünftige Overpass-abfrage parat hat, wo opening_hours hinzukamen, nur her damit), ich versuchs trotzdem:

Da ich etwa einmal monatlich opening_hours korrigiere, kann ich grob übern Daumen abschätzen, dass bei den ("neuen") Objekten etwa 50-80% dabei sind, wo die Öffnungszeiten wirklich neu sind. Bei sage und schreibe 460 Warnungen und Fehlern hab ich ein wenig das Gefühl, dass die Sensibilität endlich etwas steigt und das Abkippen von Phantasie- und "aus-dem-Bauch"-Murx stark abgenommen hat. (Ok, 460 neue Fehler in 4 Wochen ist kein Pappenstiel, das sind etwa 2-5% Abfall aber naja...)

Was wollte ich?

Achja, grobe Fehlerverteilung frei aus dem Kopf und völlig unwissenschaftlich unstatistisch:

  • 40% falsche Wochentage
  • 10% falsch gesetzte Komma oder Semikoli
  • 20% fehlende Komma oder Semikoli
  • 2% Verwendung von Komma statt Semikolon (in aller Regel korrekt und sinnvoll renderbar aber schematisch falsch)
  • 10% Verwendung komischer Zeichen wie langen oder anderen exotischen Bindestrichen etc.
  • 5% Verwendung von Klartext a la: "Küchenzeiten" oder "Auf Anfrage" etc.
  • 2% vertan im Tag a la website (opening_hours=www.example.org) oder Strasse etc.
  • diverse andere

Nach Korrektur aller Werte bleiben etwa 2-5% übrig, die inhaltlich und schematisch korrekt sind, aber nicht "schön". also 9:00 statt 09:00.

Eine neue Funktionalität und kleine Verbesserungen in der Hausnummerauswertung - 2016/01

Posted by okilimu on 4 February 2016 in German (Deutsch)

In den Monaten November und Dezember war ich ziemlich untätig bzgl. meiner Auswertungen. Im Januar habe ich wieder mehr Zeit investiert und einiges produktiv gestellt, das ich hier grob darstellen möchte.

Neu: Prüfung der Distanz zwischen OSM-Hausnummern und offiziellen Geokoordinaten

Direkt erstmal der große Dämpfer in Deutschland: es gibt nur wenige Gemeinden, die Hausnummerlisten mit Geokoordinaten zur freien Nutzung bereitgestellt haben. Nur dann ist die folgende Funktion verfügbar, z.B. in Berlin, Köln, Würzburg und Freiberg. Für die ganzen sächsischen Gemeinden werde ich die Funktion demnächst aktivieren.

Bei den entsprechenden Gemeinden gibt es auf der Auswertungsseite den zusätzlichen Link "vergleichen mit offiziellen Geokoordinaten" (siehe z.B. Freiberg). Es wird dann eine zweiteilige Seite angezeigt, auf der links die Hausnummern mit den größten Distanzen zwischen der OSM-Position und der offiziellen Position aufgelistet werden. Nach dem Klick auf den Link "Karte" werden Soll- und OSM-Ist-Position rechts auf der Karte angezeigt, mit Klick auf "Josm" wird der Bereich im Editor geöffnet.

Distanzen von mehr als 50m können, müssen aber nicht, auf echte Fehler hinweisen. Meist ist dann bei der OSM Adresse die falsche Straße angegeben, oder die offizielle Koordinate ist räumlich nahe an der Straße, während die OSM-Adresse an einem Gebäude auf dem Grundstück (z.B. in einem Schrebergarten) angegeben ist.

Ich hoffe, diese Auswertung hilft, den einen oder anderen Fehler zu finden. Die Funktionalität wurde vom OSM-User malenki angeregt, vielen Dank dafür!

Kleine Verbesserungen

  • Die Nominatim-Suche geht wieder. Leider hatte ich nicht mitbekommen, das dort der Service auf https umgestellt wurde.

  • Manchmal hängt sich die Auswertung auf und wird blockiert, bis ich das herausfinde oder jemand mich darauf hinweist. Jetzt wird eine Blockade erkannt, sodaß der Ausfall nur kurz besteht.

  • Beim Import von Hausnummerlisten wird jetzt immer die Postleitzahl mit importiert, wenn vorhanden. Das erfolgte früher nur für andere Länder, wenn dort die PLZ unbedingt für den Abgleich erforderlich war.

  • In Deutschland vorerst nur für Köln habe ich testweise neben der normalen Auswertung von Straße und Hausnummer zusätzlich die Postleitzahl mit einbezogen. In Köln gibt es relativ viele gleichnamige Straßen. Die neue Funktionalität der Distanzprüfung machte das ziemlich auffällig und so habe ich die Auswertung hier erweitert. Im Laufe der nächsten Wochen werden andere Gemeinden folgen, dazu muss ich nochmal alle Hausnummerlisten sichten und einige neu importieren.

  • Gemeinden, bei denen Geokoordinaten vorliegen, werden jetzt stadtteilbezogen besser ausgewertet. Die offiziellen Geokoordinaten werden verwendet, um eine stadtteilbezogene Sollliste zu erstellen, dadurch wird genau auswertbar, welche fehlenden Hausnummern auch wirklich in diesem Stadtteil sein müssen.

  • Es sind weitere, kleine Anpassungen/Verbesserungen durchgeführt worden.

Experimente in der Oberfläche - Feedback erwünscht

Die Gemeindeauswahlseite war bisher eine superlange Seite und die Suche nach der wünschten Gemeinde war umständlich. Das soll jetzt einfacher sein, indem je Land nur noch die nächste Ebene (in Deutschland die Bundesländer) direkt angezeigt wird und die tiefere Ebene aufklappbar ist. Außerdem gibt es eine seiteninterne Suche. Leider wird dann nur zum passenden Bundesland gesprungen, das Aufklappen bis zur Gemeinde will ich natürlich noch hinbekommen.

Ist eine Gemeinde ausgewählt worden, gibt es auf der Folgeseite, hier Freiberg wie bisher etliche Optionen für die eigentliche Auswertungsseite. Neu ist hier nur, das für die Optionen jeweils ein Tooltip angezeigt wird, damit die ganzen Einstellmöglichkeiten besser erläutert werden.

Beide Anpassungen habe ich erstmal nur auf diesen Seiten durchgeführt, um Feedback zu erhalten, ob diese Benutzung besser oder schlechter als vorher angesehen werden.

Monatliche theoretische Hausnummerauswertung

Die Sonderauswertung für Januar ist fertig.

Ab jetzt gibt es in der Kartendarstellung auch im Fall des ausgwählten Layers "Änderungen der Anzahl Hausnummern" die Möglichkeit, auf eine Gemeinde zu klicken, um die Infos dazu zu erhalten. Vorher war bei diesem Layer kein Anlicken möglich.

Listen-Updates

Potsdam ist die einzige Gemeinde in Deutschland, die von sich aus zweimal im Jahr eine aktualisierte Hausnummerliste zuschickt, Troisdorf hat mir auch schon mal ein Update geschickt, vielen Dank! Es gibt auch schon vereinzelt User, die Updates anfordern. Ich importiere diese natürlich gerne.

In diesem Zusammenhang eine Bitte an Interessierte: bitte fragt bei Eurer Gemeinde nach einer Hausnummerliste oder einer Aktualisierung! In einer Gemeinde mit OpenData-Portal bitte auch nachsehen, ob dort eine Liste oder ein Update zu einer bestehenden verfügbar ist und mich informieren.

Munin-Spielerei

Der Server ist zeitweise sehr ausgelastet und in seltenen Fällen hing auch der gesamte Auswertungsprozess. Deshalb habe ich sowohl für mich selbst als auch für andere Technikverliebte Munin auf dem Server aktiviert und neben den normalen Auswertungen habe ich für die Hausnummerauswertung eine Grafik ergänzt. Es kommt voraussichtlich noch eine für die Straßenlistenauswertung hinzu.

Ausblick

  • Gerade in Deutschland gibt es Hausnummerlisten, die Geokoordinaten enthalten, die wir aber nicht direkt importieren dürfen, also nur für den Abgleich bereitgestellt wurden. Die beschränkte Bereitstellung wird noch nicht berücksichtigt, u.a., um unzulässige direkte Importe in OSM zu unterdrücken. Die Koordinaten sollen in Zukunft aber in den Funktionen berücksichtigt werden, wo sie zulässig genutzt werden dürfen. Das wird u.a. in Sachsen Verbesserungen bringen.

  • Es gibt Sonderfälle in den bereitgestellten Hausnummerlisten oder Auswertungsparameter, die bisher nur je Land eingestellt werden können. Das soll auf Gemeindeebene einstellbar werden und dadurch werden in Einzelfällen bessere Auswertungen möglich werden.

Verbesserungsvorschläge willkommen!

Ich freue mich über Verbesserungsvorschläge oder Hinweise zu bestehenden Fehlern und will diese besser und schneller unterstützen, als ich dies in der Vergangenheit gemacht habe.

edit: Typo

building=terrace...

Posted by MKnight on 30 January 2016 in German (Deutsch)

... Kotzt mich an.

Für einen Englisch-Muttersprachler mag sich das vielleicht aus dem Zusammenhang erschliessen, mir nicht, und etlichen anderen offenbar auch nicht. Ich finde die Benamsung denkbar ungünstig. Dict.cc meint bspw. auch "housing terrace" oder "terrace houses". Klingt mir sinniger. Oder meinetwegen terrace_row.

Ich hab mich grad auf buildings spezialisiert (bzw. überlappende korrigieren) und da stoss ich ständig auf "Terrassen". Richtig, so ne Aussenterrasse am Einfamilienhäusschen mit Wintergarten meist.

Nunja, jetzt hab ich mal ne manuelle Auswertung (für Thüringen) gemacht, um mir ein Bild zu machen.

Es gibt in Thüringen 784 ways mit building=terrace, davon sind 5 Stück "falsche" Terrassen. Ja, ich reg mich schon wieder ab, ich hab ein Brett vorm Kopf, es is alles gar nicht so schlimm.

Sondern viel schlimmer.

Wenn man sich das Tag etwas schönredet und nicht alles auf die Goldwaage legt, findet man 75 Gebäude, die halbwegs ins Schema passen, bleiben nach Adam Riese um die 600 Gebäude übrig, die falsch getaggt sind. Bei den 600 sind recht viele zusammenhängende (terrace) Einzelgebäude einzeln als terrace gemappt:

Sowas:  OSM

Der Wille ist erkennbar ... leider falsch.

In Deutschland angekommen

Posted by Virago on 28 January 2016 in German (Deutsch)

Nach Jahren wieder mal in OSM. In meiner Stadt ist ja schon alles gemapped... Vielleicht finde ich mal ne Kleinigkeit, die man noch ergänzen könnte... Ansonsten weiterhin mit Moped unterwegs...

freimobil.com

Posted by q_un_go on 28 January 2016 in German (Deutsch)

Nun also Testbetrieb - das ging aus dem Pressebericht aber nicht ganz so hervor...

Es sieht stark nach einem aufgebohrten Google Maps aus, da ja Google Maps alle Grundfunktionalität von freimobil.com auch bietet. Hier hat man also eigene, fest definierte POIs - die eigenen Haltestellen und die Bahnhöfe - hinterlegt.

Dass man bei der VAG natürlich bei den Bussen der Meinung ist, man sei alleine im Stadtgebiet unterwegs, ist andererseits nun nicht ganz überraschend.

Probleme gibt es ganz offenkundig bei der Lokalisierung der Haltestellen im IG-Nord.

Das Routing erledigt dann natürlich die Google-Maps-Engine, vielleicht mit Ausnahme des ÖPNVs, da nur VAG und DB/BSB-Routen angeboten werden. Bei den Radwegen führt das zu den üblichen Problemen, weil das Radwegenetz in Google nicht aktuell ist. Andererseits fällt das in Freiburg nicht sonderlich auf, da die Radfahrer dort ja ohnehin fast überall unterwegs sind.

Aber dafür hab ich dem Graphhopper nun den FR2 beigebracht - jedenfalls im Südteil. Im Nordteil muss ich noch nachlegen. So hatte freimobil.com ja doch noch etwas Gutes :-)

Gerade am Couchmappen und da liest mir jemand im Podcast vor:

Posted by tomehb on 27 January 2016 in German (Deutsch)
  1. Kapitel: Der Geograph

Der sechste Planet war zehnmal größer. Ihn bewohnte ein alter Mann, der gewaltige Bücher schrieb.

»Sieh an! Da kommt ein Entdecker!«, sagte er, als er den kleinen Prinzen zu Gesicht bekam.

Der kleine Prinz setzte sich auf einen Tisch und ruhte sich ein wenig aus. Er war schon so viel gereist!

»Wo kommst du her?«, wollte der alte Mann wissen.
»Was ist das für ein dickes Buch?«, sagte der kleine Prinz. Was machen Sie hier?
»Ich bin ein Geograph«, sagte der alte Mann.

»Was ist ein Geograph?«
»Das ist ein Gelehrter, der alle Meere, Flüsse, Städte, Berge und Wüsten kennt.«
»Das ist sehr interessant«, sagte der kleine Prinz. »Das ist endlich ein echter Beruf!«

Er warf einen Blick auf den Planeten des Geographen. Noch nie hatte er einen so majestätischen Planeten gesehen.

»Er ist sehr schön, Ihr Planet. Gibt es hier auch Ozeane?«
»Das weiß ich nicht«, sagte der Geograph.
»Ah!« (Der kleine Prinz war enttäuscht.) »Und Berge?«
»Auch das kann ich nicht wissen«, sagte der Geograph.
»Und Städte und Flüsse und Wüsten?«
»Kann ich auch nicht«, sagte der Geograph.
»Aber Sie sind doch ein Geograph!«
»Das ist richtig«, sagte der Geograph, »aber ich bin kein Entdecker. Mir fehlt es ganz an Entdeckern. Nicht der Geograph geht die Städte, Flüsse, Seen, Meere und Wüsten zählen. Der Geograph ist zu wichtig, um durch die Welt zu streifen. Er verlässt sein Büro nie. Aber er empfängt die Entdecker. Er befragt sie und notiert sich ihre Erinnerungen. Und wenn ihm ihre Erinnerungen bedeutungsvoll erscheinen, stellt der Geograph eine Untersuchung über den Charakter des Entdeckers an.«
»Warum?«
»Weil ein Entdecker, der lügt, eine Katastrophe über die Geographie-Bücher hereinbrechen würde. Ebenso wie ein Entdecker, der zu viel trinkt.«
»Warum?«, fragte der kleine Prinz.
»Weil Säufer doppelt sehen. Der Geograph würde zwei Berge vermerken, wo es nur einen gab.«
»Ich kenne jemanden«, sagte der kleine Prinz, »der würde ein schlechter Entdecker sein.«
»Das ist möglich. Wenn sich aber der Charakter eines Entdeckers als gut herausstellt, dann macht man eine Untersuchung über seine Entdeckung.«
»Wird man nachsehen?«
»Nein. Das wäre zu kompliziert. Aber von einem Entdecker erwartet man, dass er Beweise liefert. Wenn seine Entdeckung zum Beispiel ein großer Berg ist, fordert man, dass er große Steine vorzeigt.«

Da gingen dem Geographen plötzlich die Augen auf.

»Aber du kommst doch von weit her! Du bist ein Entdecker! Du musst mir deinen Planeten beschreiben!«

Nachdem der Geograph sein Register aufgeschlagen hatte, spitzte er seinen Bleistift. Zunächst notiert man die Geschichten von Entdeckern mit einem Bleistift. Sie werden erst dann mit Tinte niedergeschrieben, wenn der Entdecker Beweise erbracht hat.

»Und?«, fragte der Geograph.
»Oh! Bei mir zu Hause«, sagte der kleine Prinz, »ist es nicht sehr interessant, es ist sehr klein. Ich habe drei Vulkane. Zwei aktive Vulkane und einen erloschenen. Aber man kann ja nie wissen.«
»Man kann nie wissen«, sagte der Geograph.
»Ich habe auch eine Blume.«
»Wir notieren Blumen nicht«, sagte der Geograph.
»Wieso nicht! Sie sind das Schönste!«
»Weil Blumen vergänglich sind.«
»Was bedeutet ›vergänglich‹?«
»Die Geographie-Bücher«, sagte der Geograph, »sind die wertvollsten aller Bücher. Sie veralten niemals. Es ist sehr selten, dass ein Berg seine Lage ändert. Es ist auch selten, dass ein Ozean sein Wasser entleert. Wir notieren uns die ewigen Dinge.«
»Aber erloschene Vulkane können aufwachen«, unterbrach ihn der kleine Prinz. »Was bedeutet ›vergänglich‹?«
»Ob Vulkane erloschen sind oder nicht, ist für uns einerlei«, sagte der Geograph. »Worauf es uns ankommt, ist der Berg. Er ändert sich nicht.«
»Aber was bedeutet ›vergänglich‹?«, wiederholte der kleine Prinz, der in seinem Leben noch nie auf eine Frage verzichtete, die er bereits gefragte hatte.
»Es bedeutet ›vom baldigen Verschwinden bedroht‹.«
»Ist meine Blume vom ›baldigen Verschwinden bedroht‹?«
»Natürlich.«

»Meine Blume ist vergänglich«, dachte der kleine Prinz, »und sie hat nur vier Dornen, um sich gegen die Welt zu erwehren! Und ich ließ sie allein zu Hause zurück!«

Dies war sein erstes Gefühl des Bedauerns. Aber er fasste Mut:

»Was raten Sie mir, was soll ich besuchen?«, fragte er.
»Den Planeten Erde«, antwortete der Geograph. »Er hat einen guten Ruf …«

Und der kleine Prinz ging fort und dachte an seine Blume.

Von hier kopiert

In diesem Podcast wird der Text am Ende vorgelesen.

Freiburg mal wieder, die Stadt der Schaumschläger

Posted by q_un_go on 24 January 2016 in German (Deutsch)

Dass Freiburg im Breisgau in puncto IT sich nicht gerade mit Ruhm bekleckert, hat sich ja schon mit der Entscheidung der Remigration zu Microsoft Office gezeigt. Die Freiburger Verkehrs AG steht dem natürlich in nichts nach.

Und so begab es sich, dass man den Internet-Auftritt "http://freimobil.com" kreierte. Google-Karte mit Googles Radwege-Routing und eventuell sogar Googles POIs.

Das Ergebnis spricht für sich.

Fürs Fahrradrouting in Freiburg empfehle ich das da zum Vergleich: https://www.komoot.de/plan/@47.9939425,7.8149700,14z oder, noch besser, das hier: http://map.bikecitizens.net/de-freiburg#/!/2/1/-,-/-,-

VAG halt, wie sie leibt und lebt - mehr kann man dazu nicht sagen. Eine nette Beta, aber irgendwie noch nicht richtig brauchbar.

Ein kleiner Nachtrag, da ich es nun in die Wochennotiz geschafft habe: Das Problem bei freimobil.com: Das Fahrradrouting mit Google Maps ist bekanntermaßen grottenschlecht. Aber das Fahrradrouting mit den Openstreetmap-Standardseiten ist leider auch nicht viel besser, trotz aktuellerer Radwege. Die oben genannten Radroutingseiten machen es aber besser. Warum aber graphhopper oder mapzen nur beim Fußgängerrouting den FR2 korrekt routen und sonst Straßen gegenüber explizit ausgewiesenen Radwegen bevorzugen, erschließt sich mir nicht.

Wie ein Testbericht in der Presse zeigte, waren aber auch andere Routing-Ergebnisse bei freimobil.com nicht sehr viel besser, da einige wichtige POIs nicht gefunden wurden, wie die Pädagogische Hochschule.

Und natürlich stellt sich mir die Frage, warum bei einem auf Freiburg bezogenen Dienst ein städtisches Unternehmen nicht auf Kartenmaterial des städtischen Vermessungsamtes zurückgreift oder des Garten- und Tiefbauamtes mit dessen sehr ambitionierten Plänen zum Ausbau des Radwegenetzes.

Das verstehe wer will. Ich nicht.

Location: Gewerbegebiet Haid, St. Georgen, Schlatthöfe, Freiburg im Breisgau, Regierungsbezirk Freiburg, Baden-Württemberg, 79111, Deutschland

Änderung der Streckenführung der St 2187

Posted by dakonr on 21 January 2016 in German (Deutsch)

Nach einer Baumaßnahme hatte sich die St 2187 geändert. Hier wurde eine gefährliche S-Kurve herausgenommen und durch einen sehr leichten Bogen mit Leitplanken ersetzt. Zudem wurde der Höhenunterschied ausgeglichen.

Ich habe die Daten mit meinem Garmin GPS-Gerät erfasst und eingepflegt.

Location: St 2187, Litzendorf, Landkreis Bamberg, Oberfranken, Bayern, 96123, Deutschland

Fahrstühle...

Posted by MKnight on 15 January 2016 in German (Deutsch)

interessieren mich herzlich wenig.

Was mich aber interessiert, ist, wie das abenteuerliche Tagging zustande kommt, wo ich via QA immer wieder drüber stolpere:

Fahrstühle sind in aller Regel KEINE Gebäude. Steht im Wiki? Nein steht's nicht, richtig lesen hilft:

Kartieren von Aufzügen in Gebäuden
Zeichne die Umrisse des Gebäudes und füge building=yes + elevator=yes hinzu.  

Na? Genau, das eigentliche Gebäude soll die Tags bekommen, nicht der Fahrstuhl. Soweit ich das mit meinen bescheidenen Englischkenntnissen richtig verstehe ist es im Proposal besser und eindeutiger beschrieben:

Elevators located within buildings could also be tagged as a property as building=* 
with elevator=yes if the specific location of the elevator(s) is unknown.

Badusch!

Was ich auch nicht raffe, sind mehrere Fahrstühle übereinander, vorzugsweise in Bahnhöfen (Leipzig bspw. oder Rostock). Josm wirft einen Fehler? Ah der kennt bestimmt noch keine Fahrstühle, schnell hochladen, vielleicht merkts keiner.

Gut, jetzt kann man vlt. einwenden, dass die "Bodenfläche" sich ja "gleichzeitig" auf jeder Etage befindet. Ja? Nein, die Bodenfläche befindet sich auch gleichzeitig NICHT auf jeder Etage.

Was ich von "highway" halte, weiss ich noch nicht genau, auch so ein Doppelding, aber davon erzähle ich ein anderes Mal.

Konsterniert ab.

Download

Posted by Zopp on 11 January 2016 in German (Deutsch)

Kann mir jemand erklären wie man die Karte der Schweiz auf mein Garmin GPSmap st Navi lädt?

Qualitätskontrolle mit Android-Apps

Posted by monotar on 10 January 2016 in German (Deutsch)

Einführung

Daten eintragen ist das eine, was Apps daraus machen, das andere.

In letzter Zeit teste ich vermehrt mit Osmand und Magic Earth. Osmand wird monatlich aktualisiert, Magic Earth wohl so aller 2-3 Monate. Von daher hat man immer eine recht aktuelle Datenbasis.

Für mein Verständnis haben die Apps für den Normalo 2 Hauptfunktionen:

  • POI-Suche
  • Navigation

Die weiteren Funktionen sind für den Normalo teilweise uninteressant, dafür für den Mapper umso wichtiger.

Tags und Probleme in OSM

POI

Die POI-Suche nach Namen ist teilweise bisschen hakelig, da keine Fehler zugelassen werden, da kann aber OSM nichts dafür. Die allgemeine Suche nach POI funktioniert dafür gut. Interessant ist die Funktion in Magic Earth POI als Kontakt im Telefonbuch abzulegen. Es zeigt sich dann, wie wichtig es ist, dass bei einem POI alle Daten angeheftet sind, d.h. auch Adresse usw. an jedem POI heftet, damit es dann auch in den Kontakten landet. Bei beiden Apps kann man die Website des POI direkt aufrufen, ebenfalls sehr gelungen. Was nur bei Osmand funktioniert: Auswertung der Öffnungszeiten, Aufruf weiterer Kontaktmöglichkeiten (twitter, facebook usw.) - alles in allem auch sehr komfortabel, wenn man unterwegs ist (muss dann natürlich eingetragen sein).

Navigation im Simulationsmodus

Osmand und Magic Earth bieten beide einen Simulationsmodus für die Navigation. So kann man sich in Ruhe anschauen, was die Apps aus den Daten machen.

Aufgefallen ist mir folgendes:

  • turn:lanes bei kleineren Kreuzungen sind kein Problem
  • bei größeren Kreuzungen mit eigenen Fahrspuren pro Fahrbahnrichtung gibts immer mal Probleme beim Anzeigen der Spuren auf welchen man sich bewegen soll. Die Apps verhalten sich auch nicht gleich, ein einheitliches Muster fürs Tagging scheint schwer zu etablieren
  • Die Ansagen "geradeaus", "rechts" und "links" werden bei Hauptstraßen oft mal falsch angesagt. Der Fehler liegt hier in den Daten bei OSM selbst. Aus dem Luftbild werden Hauptstraßen an Kreuzungen rund gemalt. Ob man Kreuzungen rund malt, sollte aber nicht vom Luftbild entschieden werden, sondern der Ausschilderung folgen.Zeigt die Ausschilderung eine abbiegende Hauptstraße, sollte diese Kreuzungsgeometrie auch in OSM zu sehen sein; zeigt die Ausschildung keine abbiegende Hauptstraße, kann und sollte man die Hauptstraße ruhig rund zeichnen
  • Die Routenvorschläge sind immer eine Sache für sich: ob hier etwas richtig oder falsch ist, kann jeder für sich beurteilen. Aber man bekommt ein Gefühl, was letztlich aus den Daten gemacht wird. Eine vollständige Datenbasis (Klassifizierungen, maxspeed, smoothness usw.) sollte in der Zielregion natürlich schon vorhanden sein.

Navigation im Feldmodus

Im realen Feld sollte man die Navigation natürlich auch testen. Ich bevorzuge hier ganz klar Osmand. Das einzige was bei Magic Earth interessant ist, ist die bessere Performance bei Langstrecke und die Abbiegehinweise. Bei Osmand kann man sehr gut die eingetragene Höchstgeschwindigkeit kontrollieren. Notizen kann man über Text und Audio aufnehmen, wobei das als Fahrer trotzdem schwierig ist. Beifahrer zu sein ist schon besser.

Sonstige Funktionen

Osmand bietet viele weitere Funktionen an die zur Qualitätssischerung für mich geeignet sind:

  • Straßenbeleuchtung (lit=yes/no)
  • surface
  • smoothness
  • access-Beschränkungen foot/bicycle

Wer in Osmand dazu ein Beispiel sehen will, der kann sich einmal die Stadt Wurzen anschauen, ich habe diese mit diesen Tags unter Zuhilfenahme von Osmand für die Hauptstraßen weitgehend komplettiert. Lässt sich auch wunderbar sammeln, wenn man unterwegs ist und auf dem Handy sofort sieht, was noch alles fehlt.

Probleme protokollieren

Wenn ich draußen unterwegs bin, schreibe ich mir bei Problemen immer einen Favoriten an die jeweilige Stelle und trage das später am PC ein. Osmand bietet noch Foto, Audio oder Video, auch nicht schlecht.

Andere Apps

EB Dirigo habe ich ebenfalls mal angeguckt. Man kann auch dort simulieren, aber leider kann man den Anfangspunkt nicht wählen, wodurch man immer ein FakeGPS braucht. Für mich nicht praktikabel, von daher verzichte ich darauf. Auch sonst sehe ich der App nichts besonderes, eher ein kleiner Funktionsumfang.

Gibt es noch andere gute Apps, die sich zur Qualitätskontrolle eignen?

Sachsen: landesweite Adressliste und Auswertung

Posted by okilimu on 10 January 2016 in German (Deutsch)

Zusammenfassung

Über die OSM-User Nakaner und malenki (vielen Dank an Beide!) habe ich am Freitag die sächsische Mitteilung über die Veröffentlichung von vier Datensätzen gefunden. Den Datensatz über die 932.727 amtlichen Adressen in Sachsen habe ich mit einigen Nacharbeiten gestern importiert und eine erste landesweite Auswertung (grafisch, tabellarisch) durchgeführt.

Lizenzrechtliches

Die Lizenz ist Deutschland 2.0 mit Namensnennung und leider die Daten wegen der notwendigen Namensnennung nicht für uns direkt in OSM nutzbar. Ein informierter OSM-Kollege wird aber nachhaken, ob wir eine extra Freigabe für OSM bekommen können.

Für meine Auswertung reicht die Lizenz aus, weil ich auf der Auswertungsseite jeder Gemeinde die Lizenzangaben aufführe. Die Geokoordinaten sind zwar in der Auswertungsdatenbank gespeichert, derzeit aber auf der Website nicht verfügbar, um einen Mißbrauch in OSM zu verhindern.

Nacharbeiten zur Datenquelle

Zur Auswertung des Adress-Datensatzes musste ich noch zwei Anpassungen vornehmen:

  • Inverse Geokodierung: von der Geokoordinate einer Adresse habe ich die Gemeinde und den Gemeindeschlüssel in OSM geholt. Eigentlich ist bei jeder Adresse der ORT angegeben, der Wert ist aber bei ländlichen Gemeinden der Ortsteil, ein Siedlungsname oder ähnliches.

  • Nach der inversen Geokodierung traten 41 Adressen auf, die mit ihren Geokoordindaten außerhalb der sächsischen Landesgrenze lagen. Mit der Angabe in ORT konnte die richtige Gemeinde zugeordnet werden. Ob der Grenzverlauf ungenau ist oder die Adressen gültig sind, obwohl sie außerhalb der Gemeinde und des Landes liegen, habe ich nicht geklärt (dürfte eher vor Ort herauszufinden sein). Tabelle mit den besonderen Adressen.

Import und ignorierte Hausnummerlisten

Für die Gemeinden Coswig, Dresden, Flöha, Freiberg und Leipzig lagen bereits Hausnummerlisten vor, daher wurden diese vorab herausgefiltert. In Kürze werden die vorliegenden Listen mit dem jeweiligen Stand aus der Landesliste abgeglichen, um die bessere Liste zu verwenden. Für Leipzig und Flöha ist schon klar, das die Liste aus dem sächsischen Adress-Datensatz verwendet werden.

Von den original verfügbaren 932.727 Adressen sind bisher für die Auswertung inkl. der fünf vorher vorhandenen Listen 917.396 Adressen für 429 Gemeinden verfügbar. Ich prüfe kurzfristig, ob der "Schwund" nur auf den o.g. fünf extra Hausnummerlisten und deren unterschiedlichem Inhalt basieren oder ein weiterer Grund vorliegt.

Ergebnis der ersten landesweiten Auswertung

  • 917.396 Adressen landesweit offiziell vergeben und für Auswertung verfügbar

  • 345.904 in OSM übereinstimmende Adressen zur Landesliste (nur Straße und Hausnummer auf Gleichheit geprüft)

  • 21.462 Adressen nur in OSM vorhanden

das ergibt eine landesweite Abdeckung von 37,71% aller Adressen.

Für ganz Deutschland hatten wir am 31.12.2015 eine Abdeckung von 47,12%.

Zyklische Auswertung

Die Hausnummerauswertung für die deutschen Gemeinden läuft zweimal in der Woche, Montags und Freitags früh um 0:04h los und war bisher um ca. 7h fertig. Durch die zusätzlichen Listen wird Deutschland ab Montag vorauss. um 9h komplett fertig sein.

Sächsische Listen für theoretische Hausnummerauswertung nutzbar

Für die monatliche theoretische Hausnummerauswertung wurden in 2014 die damals verfügbaren 49 Hausnummerlisten verwendet, um Formeln zu Ermittlung der ungefähren Anzahl an Hausnummern je deutsche Gemeinde abzuschätzen. Mit der jetzt verfügbaren, landesweiten Liste kann ich die Formeln vorauss. erheblich verbessern.

Dietmar Seifert aka okilimu

regio-osm.de Betreiber

Location: Innere Neustadt, Neustadt, Dresden, Sachsen, 01097, Deutschland

my lastcheck -> check_date

Posted by Lübeck on 10 January 2016 in German (Deutsch)

Moin !

seit längerer Zeit bin ich Verfechter die Daten in OSM zu prüfen und entsprechend zu kennzeichnen. Es gab hierzu auch mehrere diskussionen. Bis heute habe ich immer lastcheck verwendet.

Gestern ist mir erst bewußt bekannt geworden, dass es auch schon check_date gibt welches im Wiki schon dokumentiert ist (http://wiki.openstreetmap.org/wiki/Key:check_date) und auch von der Syntax besser zu start_data, end_date .... entspricht.

Deshalb werde ich künftig dieses verwenden und soweit es mir möglich war habe ich meine Tags geändert.

Ich poste dieses um auch entsprechend Werbung für die QA zu machen.

gruß Jan

i future i will use check_date instead of lastcheck!!!

regards Jan

Location: Sankt Lorenz Süd, Lübeck, Schleswig-Holstein, Deutschland

OSM braucht ein neues openstreetbugs

Posted by monotar on 9 January 2016 in German (Deutsch)

Einleitung

Zuletzt habe ich in OSM markante POI mit verschiedenen Social-Media-Tags ergänzt. Dass diese sinnvoll sein können, zeigen Apps wie Osmand und Magic Earth die z.B. Telefonnummer, Website auswerten und Osmand auch andere Tags wie contact:facebook auswertet und innerhalb der App verlinkt. Im mobilen Einsatz ist es sehr bequem, wenn diese Tags gesetzt sind, da viele Handys appbasiert am effektivsten arbeiten.

Nun ist es ja bekanntlich so, dass viele Geschäfte inzwischen nur noch eine Facebook-Website besitzen, also kommt man um facebook ohnehin nicht umhin. Andere Tags wie twitter, youtube oder alle sonstigen wie vimeo, pinterest oder instagram habe ich gleich mitgesetzt.

Status quo

Während ich in Magic Earth nach POI wie "Flughafen Dresden" suchte, sah ich, dass dieser nur absolut stiefmütterliche Tags besitzt, nicht einmal eine postalische Adresse. Auch andere Gebäude haben durch das Taggen der Nummer auf den Eingang nicht einmal eine postalische Adresse. Die Datenqualität in OSM kann nur als dürftig beschrieben werden.

Klar kann sich nun der OSM-Mapper hinsetzen, aber das kann ja nicht Sinn der Sache sein tausende POI händisch nach Updates zu untersuchen. Bei unserem Konkurrenten google ist es z.B. so, dass jeder User die Fehler in den Daten melden kann. Bei OSM ist das nur über openstreetbugs möglich. Aber sein wir ehrlich: openstreetbugs ist nur für Leute gedacht, die überhaupt verstanden haben was OSM ist, nicht für App-Benutzer, die vielleicht gar nicht wissen, was OSM ist. Bereits das Beispiel MapDust von skobbler zeigte, wie die Nutzer mit unsinnigen Fehlermeldungen das System fluten können.

Anforderungen

Was braucht OSM also? Unter höchstmöglicher Produktivität stelle ich mir das folgendermaßen vor: OSM erstellt eine Bug-API die alle Apps nutzen können. Der User kann dann in der App jegliche Tags, z.B. das Feld "Website" oder "contact:facebook" usw. als fehlerhaft melden. Dann hat er verschiedene Meldegründe:

  • Wert überprüfen: "Website lässt sich nicht öffnen" (würde den Grund dafür optional lassen, gibt OSM aber Möglichkeit nachzugucken, ob etwas noch stimmt)
  • Wert ändern: Seite umgezogen -> Eingabe der neuen Seite
  • Wert hinzufügen: Eingabe der Seite
  • Wert löschen: Website existiert nicht mehr (z.B. geschlossen) --> im Endeffekt hat der Nutzer so die Möglichkeit, jeden Tag als "überprüfen", "hinzufügen", "löschen" oder "ändern" zu markieren und dazu einen neuen Wert sowie Kommentar zu hinterlassen.

Zusätzlich muss der App-Lieferant zusätzlich 3 Tags zu jeder Fehlermeldung protokollieren:

  • Den App-Lieferant (da schlecht designte Apps u.U. uns mit Bugs überfluten, wo sich die Benutzer über die App auslassen o.ä.)
  • Die App muss uns eine anonyme unique User-ID liefern, damit wir die Validität der Datenlieferanten einschätzen können und Spammer blocken können
  • Die ID des zu bearbeitenden Objekts (Relation, Way, Node)

Bearbeitung durch Mapper

Nun sind diese Daten im OSM-Bug-System. Sie sollten aber nicht nur einfach dargestellt werden, wie das bei MapDust oder openstreetbugs der Fall ist, sondern aufgrund der zu erwartenden hohen Fehlerzahlen, muss die Verarbeitung verbessert werden. Da der Datenlieferant uns die Daten bereits auf das konkrete bezogene Objekt und die zu ändernden Daten bringt, wird es für den versierten OSM-Mapper einfach, indem er in einer Web-Oberfläche entscheidet: Im Grunde hat der OSM-Mapper 4 Möglichkeiten:

  • Bug-Mängelmeldung übernehmen: Nach einem Klick auf "übernehmen" werden die vorgeschlagenen Änderungen instant in die Datenbank gebracht (vorher hat der Mapper noch Möglichkeit, selbst kleine Änderungen an Tags vorzunehmen (z.B. Websiteangabe normieren))
  • Bug-Mängemeldung ablehnen: Die Bug-Meldung wird geschlossen, es werden keine Änderungen vorgenommen (optional Kommentar)
  • Bug-Mängelmeldung selbst übernehmen: der Mapper öffnet selbst einen Editor und ändert das Objekt, danach ist der Bug geschlossen (wenn komplizierter Sachverhalt)
  • Bug-Mängelmeldung benötigt lokales Wissen/Vor-Ort Besichtigung: Der Bug ist nicht geschlossen, aber er wurde bereits durch einen Mapper erfolgreich anfangsgeprüft. (So können wir gewähren, dass VorOrt-Bugs die lange rumliegen können, unser System nicht verstopfen und wir neue Bugs trotzdem filtern können)

Schluss

Das ist mein Vorschlag, er würde OSM extrem in der Breite verbreiten und anschließend eine effektive Abarbeitung ermöglichen sowie sogar Spezial-Apps eine Möglichkeit geben, bestimmte Dinge flächendeckend durch User einzutragen lassen. Durch die Kennzeichnung des App-Lieferanten könnten Spezial Mapper (z.B. Eisenbahninfrastrukturmapper) durch Filterung sich extra dieser Bugs annehmen. Sicher muss man an der einen oder anderen Stelle noch etwas verfeinern, aber das wäre das Grundprinzip.

test

Posted by Ziltoidium on 9 January 2016 in German (Deutsch)

nothing here

Speisung des Umspannwerk Jahnsdorf

Posted by Toliman on 7 January 2016 in German (Deutsch)

Wie wird das Umspannwerk Jahnsdorf, südlich von Chemnitz, gespeist? Über ein Erdkabel? Über eine Freileitung von Stollberg / Erzgebirge? Mit welcher Spannung erfolgt die Speisung?

Location: Pfaffenhain, Jahnsdorf/Erzgeb., Erzgebirgskreis, Sachsen, Deutschland
Older Entries | Newer Entries