PS: wenn du wie in den Kommentaren hier: http://blog.openstreetmap.de/2013/10/wochennotiz-nr-168/#comment-96035 (zum jetzigen Zeitpunkt noch nciht freigeschaltet) vorgeschlagen ein hashtag für den changeset-comment vorgibst, kann man hinterher schöne Statistiken und Animationen über die Aufräumaktion machen.

Gruss, Chaos

Ich nutze auch seit kurzem die QA-Skripts in JOSM und mache mich ans fixen der Fehler in meiner Region. False Positives markiere ich dabei bei keepright, allerdings bleiben diese ja meines wissens nach nicht dauerhaft ausgeblendet, sondern poppen beim nächsten Lauf wieder auf. (Oder zumindest, falls das Objekt in einem changeset neu auftaucht.)

Viele beinahe-Verbindungungen enstehen bei mir hier durch das verwenden von highway=platform, wenn diese nur in der Mitte und nicht vorne und hinten angeschlossen wird. Auch Fussgängerzonen, in denen dann unangeschlossene Einzelwege liegen machen Probleme. KeepRight (und die Router) kommen mit begeh/fahrbaren Flächen einfach noch nicht zurecht.

Mal ein Gegenargument zu landuse-an-highways:

Ihr sagt, “In Wirklichkeit grenzt doch das Feld an die Strasse.”

Nun zeichnen wir Straßen aber nicht als Flächen, sondern repräsentieren sie lediglich durch ihre Mittellinie.

Suche ich mir jetzt einen beliebigen Punkt ca. 1m von dieser Mittellinie entfernt, sagt eure Karte “Feld!”. Schau ich an der selben Koordinate in der Wirklichkeit nach, stehe ich auf Asphalt.

Also klebe ich Flächen nicht an Linien-Features, da die absolute (!) Lage der Fläche nicht der Wirklichkeit entspricht.

Nun kann man trefflich streiten, ob nun die absolute oder relative Genauigkeit der Abstraktion zum Opfer fallen sollte. Ich trage lieber Flächen mit absoluter Genauigkeit ein, also mit ihren Grenzen dort, wo sie auch in Wirklichkeit liegen. Damit gibt es dann auch keine Probleme, wenn dann doch noch ein Radweg zwischen Straße und Feld muss. Und nebenbei versaut man nicht die Flächenberechnung des Feldes nebenan. Das wir Straßen als Linien abstrahieren wird sich ja irgendwann in ferner Zukunft auch mal rauswachsen.

Das nutzen der selben Nodes bei zwei angrenzenden Flächen ist hingegen wirklich nur eine Frage des bequemen Editierens (oder halt nicht).

I’m really sorry that I mis-interpreted your question. I should devote more time into research before I fire up those newbie-answers. My dearest apologies.

Hi vVvA,

you might want to take another look at the beginners guides in our wiki:

osm.wiki/Beginners%27_guide

If you have really just uploaded traces (= gpx-tracks direktly from your GPS unit), you are missing a key step before you can enter more data to it. Those traces need to be, well, traced over before the can become ways in our database.

Contributing your traces is already a first and valuable step, but those are not suited to be directly displayed on a map as streets or ways. We tend to only use them as guidelines where the streets may be and then draw in the real ways by hand. You will need to use an editor like Potlatch2 (the one in the “edit” above the map on openstreetmap.org) or JOSM to do that. To these hand-drawn ways you then can add more data like type of way, name, speed limits etc.

Please take the time to read through the beginners guide before you start editing ways. That’s already step two on the complexity ladder. You might want to start with simple point-features like a post box or a park bench.

Feel free to ask again if you need more help.

Regards, Chaos

Sehr toll. Wie ich sehe, führst du die Analyse jetzt auch als Postprozess auf einem PC durch. So wie ich mich an die erste Diskussion erinner, ging es noch darum, das live auf dem Telefon zu machen. Das wäre zwar eleganter (weil nur dann ein Foto gemacht würde, wenn auch ein Schild zu sehen ist), stellta ber wie bei dir beschrieben bisher schwer erfüllbare Anforderungen an die Hardware.

Hast du vor, den Quellcode deines Programms zu veröffentlichen? Z.B. auf GitHub o.ä.? Ich würde das durchaus gerne mal ausprobieren. Ich hab hier noch GoPro Material herumliegen.

Und die Einarbeitung in OpenCV schieb ich auch schon sehr lange vor mir her.

Gruss, Chaos

Das “dass man in der Realen Welt an jeder Stelle von der Straße auf den Fußweg kommt” ist leider genauso eine unzulässige Vereinfachung wie dass man jeden Weg ohne sidewalk/path/footway tag als Fußgänger begehen kann.

Den 6-spurigen Stadring überquert man besser nur an den vorgesehenen Übergängen und nicht ‘uberall’. Auch wenn es keine physischen Barrieren gibt. Das für viele bereits eine Bordsteinkante ein unüberwindbares Hinderniss darstellt, wurde schon angesprochen.

Das Problem beim Routing ist, dass auf Grund fehlender Tags eben primaer auf Straßen geroutet wird, egal ob sie einen sidewalk haben oder nicht. Schaltete man dies ab (also Routing nur auf dedizierten Fußwegen und auf Straßen mit Sidewalk) würde plötzlich ein ‘Leidensdruck’ entstehen, der sicher in kürzester Zeit zu ordentlichen sidewalk-tags und guter Konnektivität von Fusswegen führte.

Bis dahin wäre das Routing aber komplett kaputt.

Ja, momentan scheitert es noch an der Software. Bilderkennung ist nun mal kein Pappenstiel.

Und mal nebenbei: bist du sicher, das dein Raspberry mal eben ein Full-HD Videostream (die Profis haben gleich mehrere … ) prozessieren kann und NEBENBEI noch eine Bilderkennung und -verarbeitung hinbekommt?

Also mein 2006er MacBook schafft sowas nicht in Echtzeit. Mag natürlich auch an der eingesetzten Software liegen.

Im Wiki findet sich auch ein Projekt, wo jemand schon mal eine lernfähige Software für belgische Verkehrszeichen zusammengestrickt hat. (Erkennen, Ausschneiden, Geotaggen) Das wäre ein Anfang.

Gruss, Chaos