App-Idee - Straßenschilder automatisch Knipsen

Ja, scheint genauso passend zu sein, wie ein Potenzmittel-Post

Es ist spät - leg dich hin und träum weiter. :wink:

Gruss
walter

Irgendwie erscheinen mir diese von dir angegebenen Kosten für eine Bilderkennungs-App unrealistisch. Meines Erachtens ist das Fantasie oder der Programmierer war recht langsam.

Falls die Kosten wirklich entstanden sein sollten. Wie willst du jemals diese Kosten mit den paar Kröten pro Installation mit diesem Nischenprodukt wieder reinholen? Es ist ja nicht so, dass das Produkt eine Masse an Leuten anspricht.

Versteh mich nicht falsch. Ich finde die Idee toll. Mit den schon oben angesprochenen GPX Funktionen wäre das sicher auch was für einige User hier. Aber die Begründung mit den Kosten irritiert mich etwas.

Hmm, zugegeben ich habe nach Schilderkennung und App gegoogelt. Der tiefere Sinn des Forums war mir nicht sofort klar.

Vielleicht können wir tauschen. Ich suche Polygone aller bewohnten Bereiche d.h. alle Bereiche in denen man 50 fahren sollte. Die Genauigkeit muss nicht allzu hoch sein (100m). Im Gegenzug könnte ich einen XML-Export für die Schilder einbauen, die man selbst gefunden hat. So mal als Idee.

“Irgendwie erscheinen mir diese von dir angegebenen Kosten für eine Bilderkennungs-App unrealistisch. Meines Erachtens ist das Fantasie oder der Programmierer war recht langsam.”

Wenn Du Glück hast, so wie ich das hatte, und Du spontan einen Ansatz wählst der am Ende funktioniert ist der Aufwand ca. 1,5 Mann Jahre. 200 - 300 Tage Aufwand. Du kannst aber auch das 10 fache an Aufwand verbrennen. Geht ganz einfach.

… und auf einmal hat die App einen Sinn für mich :wink:
Die Daten sind vielerorts ja schon vorhanden ( als Polygon, als maxspeed-Tag, oder auch als Ortseingangsschild), es besteht allerdings ein kleines “Henne-Ei” Problem. Aber ich bin mir sehr sicher, dass wenn es ein funktionsfähiges Werkzeug (hier dann ja :Geschwindigkeitserkennung-App) gibt, sich die Datenquantität, wie auch -qualität rasch verbessern wird!

Ich wäre mit dem “Tauschangebot” einverstanden :slight_smile:

Btw.: Ich will gar nicht wissen, welchen x-stelligen Betrag die Daten diese Projektes “verschlungen” hätten…

Stellt Euch das aber nicht zu einfach vor. Ich habe mir das Ansatzweise schon mal angeschaut. Die Daten haben Löcher. D.h. man braucht schon eine gewissen Intelligenten Algorithmus um einigermaßen brauchbare Polygone daraus zu machen. Wenn interesse besteht kann man ja mal kleine Bereiche tauschen und dann kann jeder ungefähr sehen womit man rechnen kann. Ich bräuchte die Daten als Shapefile.

Noch eine kleine Rechenaufgabe für schnelle Entwickler:

Die App arbeitet mit einem Bild 1280x720. 1 MB x 3 Farben sind 3 MB pro Bild. Gehen wir von 15 Bilder pro Sekunde aus, sind das 45 MB pro Sekunde, 2,7 GB pro Minute, 162 GB pro Stunde. Der Akku hält bei mir ca. 2h d.h. in der Zeit hat die App rund 320 GB nach Schildern durchsucht.

haben wir natürlich: http://osm.wno-edv-service.de/residentials/?zoom=13&lat=49.839&lon=7.89773&layers=B00TFTTFFT
Braust du dir “nur” aus den Daten zu extrahieren.

Gruss
walter

p.s. sind natürlich nicht vollständig. Daher auch diese “Missing Residentials”-Karte, um fehlende Gebiete zu finden und nachzutragen

Guten Abend tmanthey,

deine Beispielrechnung beschreibt sicher einen gangbaren Weg, der allerdings viel Rechenleistung benötigt, da Du offenbar immer die gesamte Bildinformation verarbeitest. Die Objekterkennung in Bildern ist ein ganzes Forschungsgebiet mit vielen Ansätzen, die versuchen “cleverer” vorzugehen, in dem sie beispielsweise erstmal eine Groberkennung machen. Ein Beispiel dafür ist die von Prof. Lowe vorgeschlagene SIFT-Transformation [1]. Man muss als Unternehmer jedoch sicher ein wenig Vorsicht walten lassen, um keine Patente zu verletzten (vgl. [2]).

Es gibt zusätzlich ganze Algorithmen-Bibliotheken, die u.U. bereits brauchbare Funktionen (frei Haus) liefern, wie beispielsweise OpenCV.

Beste Grüße
Peter

[1] http://www.cs.ubc.ca/~lowe/papers/ijcv04.pdf
[2] http://www.cs.ubc.ca/~lowe/keypoints/

Also unsere Daten kannst Du Dir selber runterladen. Weltweit wenn Du möchtest oder erstmal ein Bundesland zum rumspielen. Für sehr viele Straßen liegen bereits Informationen über die zulässige Höchstgeschwindigkeit vor. Nicht als Polygon sondern an der entsprechnenden Straße. Wenn Du zusätzlich noch die Landnutzungspolygone (also Wohngebiet, Gewerbegebiet etc) auswertest, kommst Du auf geschätze >90% Abdeckung in DE. Löcher haben die Polygone eher selten. Das wären dann Multipolygone, aber fangen wir mal einfach an.
Unsere Daten liegen in einer Wikipedia-ähnlichen Lizenz vor. Du kannst die Daten auch kommerziell nutzen, müsstest nur irgendwie ein Hinweis auf die Herkunft in Deine App einbauen…das wars, mehr nicht.
Wenn Du die straßengenaue Erfassung von Höchstgeschwindigkeiten unterstützen willst, stellst Du eine “OSM Community Version” bereit. Sprich ohne den ganzen Schnickschnack. Mich interessiert einzig und allein die Position des erkannten Verkehrsschilds und der Wert darauf. Die anderen Funktionen kannst Du von mir aus in dieser Version ausschalten.

Edit:
weltweite Daten, den sog. planet bekommst Du hier
http://planet.openstreetmap.org/
Kleinere Extrakte hier
http://download.geofabrik.de/

Informationen über unsere Lizenz hier
http://www.openstreetmap.org/copyright

+1
Die Version nehme ich auch!

Und schon wendet sich die Sache in Richtung Interessant. :wink:

Straßengenaue Erfassung kann ich mir noch nicht vorstellen. Wie würde das funktionieren?

Ich weiß, dass die Daten die ich brauche prinzipiell vorhanden sind. Sie sind nur nicht so, wie ich sie brauche. Wenn ich damit anfange brauche ich vermutlich 1-2 Wochen für etwas was ihr in 1-2 Tagen bauen könnt. Die Bereiche in denen man 50 fahren muss sind z.B. alle Wohnflächen, aber auch alle Gewerbeflächen. Die Bereiche brauche ich nicht einzeln, sondern als zusammenhängenden Bereich, wenn sie aneinander grenzen. Was ich haben möchte ist ein Shapefile mit den Polygonen.
Ich baue dafür eine Schnittstelle und einen Userdialog in die App ein. Im Moment haben die Daten keinen festen Bezug zu einem Benutzer. Das wird später auch für die meisten Benutzer so bleiben, es sein denn man will seine Schilder runterladen. Dann stelle ich eine Webseite zur Verfügung in der man sich mit den Userdaten anmelden muss und danach die Daten runterladen kann. Ich liefer die Daten in einem frei von mir gewählten flachen XML-Format und ihr könnt euch die Daten mit einer einfachen XSLT so transformieren wie ihr das braucht.

Nun ja, einfach indem an jeder Straße ein Wert für maxspeed eingetragen wird.

So einfach ist das leider nicht.
Wohngebiete haben heutzutage in Deutschland meist eine Beschränkung auf 30 km/h. Auch in Gewerbegebieten gibt es oft so eine Beschränkung.
Landuse-Flächen werden oft an (größeren) Straßen, Grünflächen, Gewässern, … geteilt. Die Straße ist dann nicht mehr enthalten. Gut ausgebaute Straßen (z.B.2x2 Spuren) können explizt für höhere Geschwindigkeiten zugelassen sein.

Die allgemeine Frage “Was ist innerorts?” lässt sich so einfach nicht beantworten.
Es gibt Indizien wie landuse=residential/industrial/retail/commercial/…, source:maxspeed=DE:urban (auch DE:zone:30) und Schilder für die Stadtgrenzen. Aber die sind nicht überall in den OSM-Daten vorhanden, sprich keineswegs vollständig. Die genannten Landuse können auch außerhalb von Ortschaften vorkommen (… auf der “Grünen Wiese”, Streusiedlungen).
Innerorts im Sinne der StVO beginnt/endet am Ortsschild. Aber gerade diese sind nicht flächendeckend erfasst. Bei Neben-/Wirtschaftswegen fehlen auch in der Realität oft die Ortseingangsschilder.

Eine fertige Lösung für dein Problem gibt es meiner Kenntnis nach nicht. Es gibt Tools (osmfilter, osmosis, …), um aus allen OSM-Daten, diejenigen heraus zu filtern, die dich allein interessieren. Wenn du Polygone im OSM-Format hast, gibt es Tools, die das in Shapefiles umwandeln können.
An Vervollständigung der Daten kannst du / könnt ihr auch selber mitarbeiten.

OSM ist ein Mitmach- / Selbermachen-Projekt. Wenn man etwas braucht, gibt es nur zwei Wege:

  • Sich selber drum kümmern!
  • Andere für die Idee begeistern und auf diesem Weg Mitstreiter suchen.

JM2C
Edbert (EvanE)

Hallo,
die Idee von Wohngebiet auf Geschwindigkeit zu schließen halte ich für sehr ungenau. Ich denke da nur an die vielen 30er-Zonen. Auch soll es Innerorts straßen geben, die mehr als 50km/h erlauben.

Bei uns wirst du die erlaubte Höchstgeschwindigkeit an dem way-Objekt finden, das bei uns die Straße repräsentiert. In deiner Anwendung müsstest du also von der GPS-Koordinate das nächste way-Objekt suchen und dann schauen, welche Geschwindigkeit dort erlaubt ist. Default-Werte für die Geschwindigkeit kann man bspw. aus dem jeweiligen Straßentypen ableiten.

Nur so als grobe Gedankenskizze.

Es scheint, wir sind genauer als Du es vertragen kannst :wink: Aber auch Du wirst zugeben müssen, dass es 30er Zonen oder sog. Spielstraßen innerorts gibt. Oder auch Straßen mit 70 und mehr in einer Stadt wie Berlin mit den Statdautobahnen. Naja, versuchen wir mal weiter zu kommen. Du kannst unsere Daten in eine Postgres/PostGIS Datenbank importieren. Da kann man dann auch Flächen um einen Way (so nennen wir Wege, egal welcher Art Straßen, Feldwege oder auch ne normel Hecke) herum erzeugen und als Shapefile exportieren.
Und mal ganz offen gesprochen: Du kannst unsere Daten nehmen und daraus machen was Du willst. Du musst nichts in Deine App einbauen. Wir würden es nur toll finden. Du musst nur die Quelle angeben.
Aber ehrlich gesagt finde ich Dein “Flächenmodell” nicht so toll. Besser wäre ein “Snap to road”, wie es auch die normalen Navi Hersteller machen.

Ich denke mir reichen die Polygone quasi der bebauten Bereiche. Warum?

Ich will die Daten in Kombination mit der optischen Erkennung verwenden. Ortseingangsschilder sind in Regel gut erkennbar, Ortsausgangsschilder aber nicht. Nachdem ich ein Ortseingangsschild erkannt habe, bin ich innerorts solange ich ich mich im bebauten Bereich befinde oder ich ein anderes Schild erkenne.
Zone 30 ist auch kein Problem, da ich zumindest das 30 Schild erkenne.

An Snap-To-Road würde mich erst ran wagen, nachdem das Zonen-Model funktioniert. Warum? Das Snap-To-Road Modell erfordert viel mehr Daten und Berechnungen. Meine App bewegt durch die optische Erkennung derzeit von 160 GB pro Stunde auf einem Smartphone. Da kann man nicht mehr unbegrenzt Features mit einbauen, ohne dass das Handy eine Kernschmelze einleitet. Man sollte außerdem erst laufen können bevor man zu fliegen versucht… :slight_smile:

Meine Idee, wäre dass einer von euch das macht, da meine Kenntnisse im GIS Bereich doch sehr überschaubar sind. Im Gegenzug baue ich die Schnittstelle. Das sollte vom Aufwand her etwa Balanced sein, d.h. 1-2 Tage.

Du kannst dir hier ja mal einen Überblick über unseren aktuellen Datenbestand zur straßengenauen Erfassung von Geschwindigkeitsbegrenzungen verschaffen:
http://www.itoworld.com/map/35?lon=10.44984&lat=52.25161&zoom=11&fullscreen=true

Wenn es dir darum geht, solltest du ebenfalls nicht die bebauten Flächen als Grundlage nehmen, sondern eher die Ortseingangsschilder. Diese bekommst du als Punkte relativ leicht mit der Overpassapi. Da wäre dann auch so großer Unterschied zu den bei dir bereits gespeicherten Schildern mehr.
Du kannst das ja mal hier ausprobieren: http://overpass-turbo.eu/

(node["traffic_sign"="city_limit"](51.488224,12.24884,53.077528,15.154724););out;

Anschließend kannst du die Daten auch exportieren. Entweder als OSM (xml), GPX oder GeoJOSN

Sieht gut aus, aber wo finde ich die Legende?

Coole API. Ich habs mir mal angeschaut. In der Region Mainz fehlt allerdings noch einiges. Ich glaube die Kombination Optik zur Ortsschilderkennung und Polygon zur Begrenzung funktioniert da besser.