Hi, how do you asses out of the aerial imagery if the pool is permanent or moveable?

If you are only mapping from the Aerial you better not delete anything you are not 100% certain.

This is why i strategically take Mapillary Fotos of the Areas i am mapping. In 10 years i took photos of 6300km of Streetview like imagery with ~1 Mio images.

So whenever there is something uncertain i can go back to imagery.

I now started going back to areas i was in 2014/2015 and update imagery with 360° imagery.

The point is not “build permission” but movable/non permanent structures like small plastik pools.

Sheds are perfectly okay to map and i would consider removing them as vandalism. Removing perfectly valid objects which do exist by fact have a valid point beeing in OSM.

I’d like to bring a new perspective into the game as notes are a matter of Communication and to bring it even further:

"A note is a temporary mailinglist for a certain location on the map"

It may not only be used to “report a failure” or “missing” object, it may also enable multi mappers to share knowledge of an ongoing change on the map.

I tend to use these for building a community of surrounding mappers for long running constructions. Relocating a highway may take years with 100s of small little steps in changing of intersections etc. So you want to get all interested parties to the same state.

I’d like to have new features for Notes:

• subscribe
• unsubscribe
• remind me in X
• reopen in X

Currently you can only subscribe by writing something to the note. For the reminder and reopen i wrote myself a little bot.

Flo

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