POI nicht als Polygon eintragen!

Das wird aber auch nicht besser, wenn wir in die DB kippen, was gerade bei den “Verwertern” en vogue ist, wie du so schön sagst. Alles was wir für die tun können, ist vernünftige Schnittstellen zu schaffen, welches Datenmodell denen auch immer zu Grunde liegt. Und grundsätzlich kommt man nun mal nicht drumherum, sich mit dem Datenmodell auseinanderzusetzen, wenn man die Daten vernünftig verwerten will, so viele sollten da also nicht von Außen kommen und dann erwarten, dass alles irgendwie gebrauchsfertig vorliegt. Jedenfalls kritisiere ich, dass ihr behauptet, die vorgeschlagene Variante wäre für “die Auswerter” besser - das stimmt eben nicht. Sie ist für manche Nischen etwas einfacher, korrekt, aber Wege das zu ermöglichen wurden aufgezeigt, aber für andere Nischen wesentlich komplizierter, das wurde ebenfalls schon angesprochen, siehe auch HolgerJeromin über dir, Lösungsansätze dafür wurden aber nicht genannt. Warum also einen Weg forcieren, der zwar manche Auswertungen vereinfacht, andere aber fast unmöglich macht, wenn der aktuell eingeschlagene, natürlich sicher auch nicht perfekte, Weg für praktisch alles, was mir bisher an Auswertungen unserer Daten bekannt geworden ist, zumindest keine besonders großen Hürden aufwirft. Insbesondere ist das Beispiel mit der Wheelmap ungeeignet, denn das Problem war von Anfang an bekannt und obwohl grundsätzlich Lösungen existierten wurde eine halbfertige Anwendung auf die Öffentlichkeit losgelassen.

errt und HolgerJeromin:
+1

Das Beispiel mit Wheelmap ist auch deshalb ungeeignet, weil Wheelmap nicht nur ein Auswerter ist, sondern auch einen POI-Editor über die Internetseite bietet.
Erst die Möglichkeit der Bearbeitung und Rückgabe (Synchronisierung) von Daten in die OSM-Datenbank macht die Sache so aufwändig.

Gruß,
Mondschein

Komisch, ich muß da gerade an ein anderes Programm denken, dass sich wohl mit den gleichen Problemen rumschlagen muß.

Lösungsansatz A: Programm erweitern
Lösungsansatz B: Rohdaten vereinfachen

Ein Schelm, wer da Böses denkt :wink:

Gruss
walter

Errt,

zwei nur? Zähl mal nach.

LG,

-moenk

Mondschein,

das Beispiel ist deswegen gut, weil es zeigt was für ein Rad die für das eine, und erst recht für das andere drehen mussten. Und nur weil POI in Ways und Relationen festgehalten wird.

LG,

-moenk

Christian,

danke auch für Deine Unterstützung. OSM würde an vielen Stellen geholfen, wenn man nicht den genialsten, sondern den einfachsten Weg wählen würde. Sonst fehlt Akzeptanz! Warum wohl die Radarfallen in OSM nicht brauchbar sind? Weil es eine aufgeblasesen Relationskacke rundherum gibt die kaum einer kapiert, statt einfach Punkte zu setzen. Noch mehr Beispiele auf Nachfrage.

LG,

-moenk

Moin,

wo das ja alles ganz einfach ist: Ich habe hier einen einfachen Weg, um POI aus der OSM fürs Garmin aufzubereiten. Allerdings nur für Punkte. Vielleicht krieg ich noch einen sachdienlichen Hinweis, was ich ergänzen muss um auch Polygone (oder Ways, jaja) mit drin zu haben.
http://www.moenk.de/archives/75-Punkte-der-OpenStreetMap-in-Garmin-POI-konvertieren.html
Ist sicher nur eine Zeile, aber ich kann ja kein RTFM und möchte nicht noch ein Kilo Software zu den Standardstools dazuinstallieren die ich eh schon habe. Denn legt mal los!

LG,

-moenk

Weil genau dieses Beispiel zeigt, dass zum Beispiel nicht nur schwarz/weiß vorhanden ist. es gibt Blitzer die blitzen von vorne - da willst du nicht gewarnt sein, wenn du auf Höhe des Blitzers bist. Es gibt Blitzer die blitzen von hinten - da reicht es wenn du gewarnt wirst, wenn du auf deren Höhe bist. Und dann gibt es Blitzer die können gedreht werden.

Und dann gibt es Blitzer die blitzen bei Rotlicht… usw.

Und deine way-to-nodes - da gibt es was von osmconvert… :wink:

Thomas,

schön dass es das was gibt - darum hab ich die Lösung immer noch nicht hier auf dem Tisch. Komm, mach schon, ist doch nur eine Zeile :wink:

LG,

-moenk

Du erinnerst mich gerade stark an jemanden, der auch hier im Forum aktiv ist…

Aber ich bediene auch für dich gerne google: http://wiki.openstreetmap.org/wiki/Osmconvert#Dispose_of_Ways_and_Relations_and_Convert_them_to_Nodes

Thomas,

mir würde reichen wenn der Blitzer überhaupt erst mal eingetragen ist - das Thema fasst aber kaum noch einer an, weil per verkopfter Definition so verkompliziert dass es schon abschreckend ist, seinen Beitrag dazu zu leisten. Verstehst Du nicht dass es Leute gibt, die nicht so schlau sind wie wir und die nur einen Blitzer eintragen würden wenn es einfach ist?

LG,

-moenk

JOSM > Punkt setzen > Vorlage > Straße > Wegpunkt > Radar

(weil ich grad JOSM nur in englisch da hab: JOSM > add point > Presets > highways > Waypoints > Speed camera)

Fertig.

Was ist mit YAPIS (Blitzer eintragen) oder über OSB (hier ist ein “Schwarzblitzer”)?

Richtig ist - die Leute müssen es wissen → also Werbung (in der Gemeinde → die wimmelt ab. Habe mit Mühe eine OSB_Karte auf der Gemeindeseite verlinken können.).

Geri,

YAPIS kenn ich, find ich auch gut, arbeitet auch nur mit Punkten. Was meiste was ich mir zu dem Thema alles anhören muss und wie oft einer um die Ecke kommt, der mich auf diesen “Bug” hinweisen will.

Dieses “POI als Polygon”-Problem ist nur ein sichtbares Symptom der OSM-Community, die alles möglichst universell und perfekt machen will, dabei aber leicht an den Bedürfnissen der Zielgruppe vorbeischießt.

LG,

-moenk

Vorbemerkung: Ich habe die Overpass API noch nie benutzt. Nach ein paar Minuten mit deren Dokumentation komme ich auf folgende Lösung, wie die erste Codezeile zu ersetzen ist:

wget "http://overpass-api.de/api/interpreter?data=node[tourism=hotel](-18,-61,2,-46);out meta;way[tourism=hotel](-18,-61,2,-46);out meta;>;out meta;" -O - | osmosis --read-xml file=- --sort --write-xml file=- | osmconvert32 --all-to-nodes - > hotel.osm

Wer sich mit der Overpass API auskennt, kriegt es zweifellos noch einfacher und eleganter hin. Wie gesagt, dies war meine erste Berührung damit.

Du wirst nun vermutlich darlegen, daß dies den unzumutbar großen Aufwand der Weg-zu-Knoten-Konversion beweist.

Die Radarfallen können ganz simple als Node gesetzt werden. Die Relation ist (optional) on top um die Blickrichtung des Blitzers anzugeben.

Blitzer die als Fläche gemappt sind habe ich noch nicht gesehen. (Hoffe dass ich die Atommapper jetzt nicht angespitzt habe).

Chris,

mittlerweile weiß ich das auch. Vor einiger Zeit wollte ich mich mit dem Thema befassen und hab im Wiki nur entnehmen können dass man solche Relationen dafür braucht.

Nun könnte man mit einem Skript überall wo beim Device das Tag fehlt das automatisch ergänzen. Hab davon aber die Finger gelassen weil solche automatisierten Edits auch wieder schwierig sind (also nicht in der Umsetzung, sondern in der Community).

Wir können daraus lernen: Wir sollten immer einen einfachen Weg anbieten und dann eine kompliziertere Option. Erst die einfache Lösung im Wiki, dann die Variante für Bessermapper.

LG,

-moenk

Oli,

ich lege nun erstmal dar, dass Du da eine geniale Commandline hingezaubert hast. Wo der Tunnelbauer noch auf Wiki-Seiten verlinkt, hast Du schon eine gute Umsetzung dazu gemacht - Respekt!

Man braucht zwar dann noch ein paar Tools, das ist etwas schade, aber so gehts erst mal. Das könnte man als Lösung für diese oft gefragte Aufgabe so stehen lassen. Damit ist der Welt erst mal weiter geholfen. Wenn es mich überkommt mache ich noch einen Nachtrag zu dem Artikel, das ist ja toll dass man nun endlich aus der Overpass-API auch POI-Dateien fürs Garmin machen kann.

Natürlich ändert das nichts an meiner Haltung zur Sache :wink:

LG,

-moenk

Auch wenn die Blitzer hier OT sind :confused:
Eine Idee, um die “Relationskacke” zu vermeiden:
Wie Ampeln werden Blitzer grundsätzlich als node auf den überwachten way gesetzt (und nicht daneben, wo das Gerät steht)
Zusätzliche keys könnten sein:
speed_camera:forward misst in Richtung des ways, speed_camera:backward die Gegenrichtung; speed_camera=both misst beide Richtungen.
Mögliche values für diese keys:
frontside misst den in Richtung auf den Blitzer zufahrenden Verkehr, backside misst den von ihm wegfahrenden Missetäter, both misst beides.

Ein “speed_camera:forward=frontside” würde somit den in Richtung des ways fahrenden Verkehr blitzen, wenn er auf den Blitzer zufährt.

speed_camera:type=* könnte dann noch die Art der Messung erfassen

no relation=no problem
Erste Meinungen? Oder soll ich einen neuen thread aufmachen?

So gerne ich mich nun geschmeichelt fühlen würde: Genial ist daran überhaupt nichts (zum Glück, denn sonst wäre solch eine Lösung tatsächlich einigen wenigen Experten vorbehalten). Es handelt sich um den kombinierten Einsatz dreier Werkzeuge, die genau dafür gemacht sind. Der Weg zu --all-to-nodes hätte mich übrigens genau über die von Dir verschmähte Wiki-Seite geführt, wenn ich die Option nicht zufällig bereits gekannt hätte. Am längsten hat bei mir die Recherche in der Dokumentation zur Overpass API gedauert; da Du diese aber bereits kennst, sollte Dir das noch leichter fallen. Bleibt noch die Sache mit osmosis --sort: Daß dieser Einschub nötig ist, merkt man an der Fehlermeldung von osmconvert.