Wonderful - I love OSMCha but it seemed to deviate into non existance with Mapbox - So good it has a new home …

I am still setting up TM2 whenever i need one because its documentation, requirements and simplicity is great. You can set it up by strictly following the Readme within 5 minutes and off you mapping goes.

I am sysadmin by profession and i failed to even understand or setup a TM3. So i think of fixing some TM2 annoyances instead of looking at TM progress.

@Warin61 - The tagging as service/driveway already says its not a public road. Thats enough. Any access restriction which is not explicitly verifyable by a sign, gate, fence or something is broken.

We do not map/tag anything which is not verifyable with the great exception of boundaries.

And show me one driveway which has more agricultural when people are living there. I am myself living in the middle of the woods with a rough road of 2km as the only access.

As soon as people are living there you have 2 car usages per day for people going to/from work. Show me a track where there are more than 400 tractor movements a year.

And we are not talking about delivery by plane but places where Amazon Logistic goes with the delivery vehicles.

Flo

BTW - Slapping an access=private to all driveways makes them unroutable. Its a bad habbit IMHO to tag access restrictions where they are not explicitly signed.

I call that “felt access restriction”. As OSM maps things which are verifyable on the ground we should NOT tag every driveway with access=private.

I am doing analysis on “non-routeable” addresses for example Nordrhein-Westfalen a part of Germany and we have TONS of addresses which are more than 500 to 1000m from the next legal street to use although they have a driveway which is legally not usable by the access=private

Flo

A track is defined as beeing mostly agricultural. A driveway to a farm is not for agricultural purpose but for living so the tagging as track is broken. There are more Post, Amazon Logistics, parcel deliverys, garbage trucks, School kid transportation etc than there are tractor movements.

So tracks which represent the only way to housing or the primary access to housing should be retagged as service/driveway. If not asphalt probably with different surface tags.

Flo

Zum thema living_street führe ich seit vielen Jahren erbitterte Diskussionen. Jeder Numerische Wert lässt sich in Deutschland nicht mit dem Recht vereinbaren.Die Geschwindigkeit ist “schrittgeschwindigkeit” deshalb entferne ich alle maxspeeds auf den living_streets in Deutschland wo ich sie sehe.

Ich habe mir mal angewöhnt in “maxspeed” nur numerische Werte zu schreiben. Alles andere gehört woanders hin. also maxspeed:source meinetwegen. Die Diskussion habe ich mitgelesen habe das aber weitgehend bisher ignoriert. Die Idee ist das eben klar ist woher das Maxspeed kommt. Durch Nichtbeschilderung und eine wie auch immer geartete andere rechtliche Regelung oder eben explizit durch Beschilderung.

Da allerdings “landstraße” mit “ß” oder sowas zu nehmen finde ich äusserst kaputt. Auch irgendwas nicht numerisches in maxspeed zu schreiben.

Flo

Ich fände sowas in der Art auch spannend. Muss nichtmal als Spiel konzipiert sein aber was wir ja irgendwann vollen ist eine reine “Validation” App. D.h. eine kleine App die mit Ja/Nein features/objekte/tags in der Umgebung (30m) sich bestätigen lässt.

D.h. Karte mit fettem Pfeil an einen Mülleimer - “Ist der noch da?” Ja/Nein … Wenn der noch da sein sollte ggfs ein “last_checked=" an das objekt.

Genauso könnte man:

• Öffnungszeiten
• Telefonzellen
• Postkästen
• Recyclingcontainer (Und ob sie Glas, Papier, Metall nehmen)
• Gebäude
• Geschwindigkeitsbeschränkungen
• Durchfahrtsbeschränkungen

etc abfragen. D.h. wenn ich 3 Minuten zeit habe - Ja/Nein/Weiss ich nicht.

Das man das ggfs mit Punkten versieht und high scores erzeugt - Kann man machen, ich brauche das für die Motivation nicht.

Flo

Nein - macht er nicht - ist ja auch komplizierter weil Landesabhängig:

Ich habe da mal ein ticket aufgemacht:

https://josm.openstreetmap.de/ticket/13211#ticket

Vermutlich fehlt das aber eine API für den Validator das Land zu finden in dem sich ein Objekt höchstwahrscheinlich befindet.

Flo

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.