BTW: Meckert der josm validator das eigentlich an?

Leider ist das nicht immer so offensichtlich wo der Fehler ist. Richtig ist das die tag kombination von living_street und maxspeed kaputt ist. (Was vielleicht ginge wäre ein maxspeed=walk - was es auch gibt).

In Ostwestfalen-Lippe haben wir seit langem schon bugs auf den ganzen Fehlern auf (Noch aus OpenStreetBugs). Die muss man halt alle vor Ort kontrollieren und leider ist oft auch die klassifikation als living_street falsch - da steht eben kein Zeichen 325.

Ist ein langfristiger Prozess.

Wie brauchen sowas wie maproulette für Leute am Handy. Pokemon Go für OpenStreetMap - Zeig mir einen note, fixme oder tag inkonsistenz in meiner Nähe. Sowas …

Und dann gleich mit Lösungsvorschlägen d.h. “Wähle die richtige Kombination:”

a) maxspeed=30, highway=residential b) highway=living_street

Flo

Da muss ich ganz entschieden widersprechen. Diese “Relevanzdiskussion” zum Thema “Detailtiefe” hat schon die Wikipedia kaputt gemacht. Wir sollten damit nicht anfangen.

Solange es Mapper gibt die das Pflegen wollen und können sollten wir das machen. Details schaden nicht so lange sie das große ganze nicht kaputt machen und das sehe ich hier mal gar nicht.

Wenn das Taggen länger dauert dann kennst du deine tools nicht. Ich empfehle Josm:

• Adresspreset verwenden
• Adresspreset auf eine Taste legen (Ich habe “!” benutzt)

Dann je Adresse

• Doppelklick um einen Node zu setzen ohne eine linie zu zeichnen
• shift-1 (Adress preset öffnet - alles bis auf die Hausnummer ist da)
• Hausnummer eingeben und enter - Es bietet sich vor allem das NumPAD an.

Ach ja - Auch wenn ich das auf Gebäude outlines mache nehme ich erst Nodes.

Wenn dann die Nodes da sind braucht man das “Terracer Plugin” - Node anwählen, Gebäude outline gleichzeitig anwählen (shift oder ctrl) Dann ctrl-shift-t und schon werden die tags des nodes auf das outline verschoben und der node entfernt.

Flo

access=* is in 90% of all times broken and wrong. Most of the time it SHOULD be motor_vehicle= or vehicle= .. There is no possibility at least in Germany to sign a public road beeing inaccessible to ANY mode of mobility (Which access=* means). At least you are allowed to walk there.

So when you see a public road e.g. not highway=service with a access=private or access=destination its wrong in 90% of the cases.

For the special routing case - For ANY routing device all restrictions whatever they mean should be treated as “access=destination” - The tail end or the front end of your route may ALWAYS be in an access restricted part of the road network and its the only way to reach your destination so in the end - you guide your user towards the destination and you need to announce once the restricted part of the tail end comes up. ( Mercedes build in dashboard navigational systems exactly do this - Warning - Access restricted road )

When you do it really correct its getting even much more complicated. Today all routing engines simply increase the graphs cost on the parts of the road network with access restrictions which typically causes the route to avoid those parts of the road network. The problem here is that it sometimes causes VERY strange routes trying to avoid some more meters on restricted surface. This is broken. The edges of the graph in your route do not get more expensive. You have a ONE TIME cost entering the restricted subgraph in your road network. Once you are on a motor_vehicle=destination based subgraph there is no point in leaving it again to avoid parts of the road network beeing restricted.

Flo

An offset between Sat/Aerial Imagery and GPS Tracks is in 99% caused by broken imagery georeferencing. So you better stay with GPS tracks and fix the imagery offset.

Very cool - I am talking about something like this for years. Critics always said that the 100% accuracy would not be possible and it would be to complicated to maintain the data. I was always advocating that one day we’ll have millions of users giving feedback about correctness and completeness of map data.

There we are …

Thanks a lot for proving this valuable feedback from your telemetry data.

Du nutzt josm? Du kennst das “building” plugin und dann “b” - damit ist das automatisch rechtwinkelig und hat ein building tag - Das geht relativ schnell da durchzunudeln. Wenn man dann noch weiss wie man mehrere überlappende flächen merged und das “extrude” x kennt dann sind buildings halb so wild.

Spontan bei Youtube gefunden: https://www.youtube.com/watch?v=8DC73B_01fo

ich empfehle aber mal die Tools anzusehen.Er macht da auch sachen die deutlich einfacher gehen. Ich empfehle “extrude” mal anzusehen.

I had a QA prototype running for years since OSRM was released. The problem i have and had is that OSRM does not in all cases produce reproducible results. In case there are multiple routes you’ll one of them or all - you cant reliably tell which. The cause here is that OSRM does some rounding on the travel time and thus it is easy to have exact same distances e.g. travel times. Now the sort order of the osrm indexes will decide which route you’ll get returned. As the sorting of the index is multithreaded on preparation of the index the order changes and voila - you get random results.

My QA system recreated the OSRM index every 4 hours and then calculated ~100-150K routes between selected nodes. I then compared the lengths of the routes and when the length changed by more than 300m or 10% i got an email with a link of the 2 route geometries. This caused a wide network of important roads to be checked. Also motorway exits were checked if you would be allowed to leave or enter a motorway.

The problem with the non reproducible routes is that suddenly certain routes started to flap between alternates and there is no way to stop this with OSRM.

See this thread: https://lists.openstreetmap.org/pipermail/osrm-talk/2015-June/000858.html

In the end i ended the RouteQA with OSRM. I need to have a look at graphhopper or the valhalla stuff. OSRM is unsuitable for this.

Flo

You should rename to “Map God” because you seem to be infallible. I havent met a lot of Gods like you - but thanks for reminding me.

Ich fände das sinnvoll in eine Android App zu gießen - D.h. ich kriege Objekte in der Nachbarschaft angezeigt (Radius konfigurierbar) die lange nicht überprüft wurden und kann dann deren existenz oder lage validieren. D.h. mit 2-3 klicks einfach nur “Ja existiert noch” was zu einem changeset mit einem lastcheck führt oder einem “Nein - existist nicht mehr” oder “Hat sich in der Lage verändert” oder “Attribute haben sich geändert” die zu einem OSM Note führen.

Ich bin gerade dabei Recyclingcontainer zu überprüfen. Da hat sich bei uns viel getan. Nach der Einführung der Papiertonne durch die Gemeinde werden zunehmend Papiercontainer abgebaut wobei die Glascontainer stehen bleiben. Dazu ist die Telekom gerade beim VDSL/Glasfaserausbau wodurch jede menge neue “street_cabinets” entstehen.

Aber mir fallen noch andere punktförmige Gebilde ein:

• Straßenlaternen
• Briefkästen
• Hydranten
• Telefonzellen
• traffic_calming
• barriers
• Recyclingcontainer
• street_cabinets / MFG/VDSL Kisten der Telekom

Danach sind natürlich auch andere Objekte bzw Attribute Spannend. Wie z.b. Geschwindigkeitsbeschränkungen.

Flo

I love the z10 z11 residential road change. I’d like to keep them in z12 for the moment. Residentials often make one get an impression on residential areas and population density. That would get lost. In z10/z11 you cant distinguish between roads so thats a plus to remove them.

Ich zerschneide so zeugs auch gerne wenn das im ALK z.b. ersichtlich ist das es unterschiedliche Flurstücke sind etc - Ob das physisch ein Gebäude ist ist mir in dem moment egal. Ich finde das wie es da ist erstmal nicht schlimm. Funktioniert ja.

Hi Simon, Nakaner,

according to some dataset i have here there should be something like 19.6-20MIo Adresses in Germany. I have 20.6 Mio but i know there are approx. 5% faulty/non existant addresses in there. I occasionally do regional compares against that Dataset.

http://f.zz.de/posts/201503291129.osm_fehlende_adressen_buckeburg_und_stadthagen/

So i guess we are at 2/5th of the Adresses done in Germany. That number sounds high but most of them are in very dense Urban Areas. The rural Germany is not that well covered.

My guess is that Citys like Hamburg, Berlin, Munich e.g. Citys above 3-400K residents are mostly done.

I have a simple rule. If there is any regular non agricultural traffic e.g. there is a residential building on that road then it CANT be a track. The traffic to and from residential buildings outweight the agricultural usage by an order of magnitude. You’ll have the Waste Lorries, Postman etc coming through that road.

If there is no such use and no public is allowed to use that road except for agricultural use then its a track.

In parts wie schould tag stuff that is not as it clearly shows somebody did a survey and its not unknown. With a pure “yes” you cant differentiate “unknown” from “no”.

For example lit=yes - A lit=no is useful. It shows somebody did a survey.

I dont really see the point. The problem with “entrance=*” or “building=entrance” is that there is no use case. If there would be user you would have a feedback loop for people to change their tagging. No user of your data -> broken data.

This is why i am against tagging every little small detail to obscure tags. As long as there is no use case there wont be any maintenance. This is for example true for number of parking lots on an amenity=parking or stuff.

Flo

Das ist keine Firma sondern das Landesvermessungsamt NRW. D.h. die Daten die du da siehst sind mit unser aller Steuergeldern erstellt und zusammengetragen worden. Es ist also eigentlich eine Selbstverständlichkeit das diese Daten dann auch den Bürgern zur verfügung gestellt werden.

Das das erst so spät passiert ist hat was damit zu tun das OSM jetzt auch ernster genommen wird. Und besser jetzt als gar nicht.

Doof finde ich noch das wir jetzt nur noch die DOP40 bekommen (Also 40cm Bodenauflösung). Es existieren deutlich bessere Daten beim Landesvermessungsamt und die waren auch über Jahre auf dem NRW DOP Viewer zu sehen. Leider sind die jetzt dort auch verschwunden.

I’d propose to look at the OSM Inspector Adresslayer processing. Its a libosmium based c++ tool which AMAZINGLY fast crunches through an osm.pbf file and generates an sqlite/spatialite output file with a lot of information - geometries, streets, housenumbers, point on next street (if there is no streetname etc). Probably not enough for the address lists but that should be easily doable.

Everybody could use an OSM Extract of the region of interest to process and compare to the addresslist.

As with the Changeset comment function which i like a lot this must be a lot more improved to actually be able to review changes. We need

• A better Changeset viewer like this: http://nrenner.github.io/achavi/
• A better way to track changesets in a certain area I use an RSS feed by http://simon04.dev.openstreetmap.org/whodidit/scripts/rss.php?bbox= This must be integrated with OSM itself and be usable without an RSS feed e.g. people have 1-many watched areas in the user config and can have a look at changes of the e.g. last 30 days in that area.
• Telling people to COMMENT on their changeset. 80% of the changesets in my area have an empty or non descriptive changeset comment. So its useless to review as i have no clue what the intention of the mapper was.
• As the nomenclatur of OSM changesets is not the one of a VCS in software development as its not atomic, not self contained there is no way of peer review in the sense of e.g. github. So we need some way to get more people to comment on changes and by thus improving the quality of changes people make.

Its a long way to go but OSM has already come far.