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!
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…
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?
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.).
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.
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:
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.
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
Auch wenn die Blitzer hier OT sind
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.
Gerade bin ich zufällig über diesen Edit von “FriendofMaps” mit dem Kommentar “+PoIs as Points” gestolpert (Tags werden am Gebäude gelöscht und in ggf neu erzeugte Nodes gesteckt) und musste an diesen Thread denken.
Vielleicht mag sich jemand weitere Edits dieses Nutzers anschauen?
Ich will erst einmal meine derzeitige Arbeit zu Ende bringen.
Ich sehe hier keine Probleme durch FriendOfMaps. An dem Gebäude gibt es einen Node am Eingang, der die Adresse beinhaltet (entrance=main/yes fehlt halt noch) und das Gebäude sollte keinen Namen haben, sondern das Restaurant heißt halt so.
Kann man so oder so sehen, ist aber nichts kaputt.
Zum Topic: Ich kann dem Threadersteller ganz und gar nicht zustimmen, die Punkte sind bereits genannt, aber ganz besonders finde ich pyrams Aussage:
Genau das sehe ich nämlich auch, wenn ich ein Gebäude sehe, dass POI-Tags hat, dann sehe ich das eher als Gebäude (building=*) UND getrennt davon die Ausdehnung des POIs. Wenn nun der Mapper der Meinung ist, dass der ALDI so groß ist, wie das ganze Gebäude, dann ist das sein gutes Recht (dass viele Menschen - auch nicht-Mapper - das so sehen, hatten wir ja schon).
Das sehe ich auch oft und das ist gut, denn das Schulgelände ist das POI, die Gebäude sind building=school. Auch bei Krankenhäusern seh ich diese Methode öfter mal. Anwendbar auch auf andere Dinge z.B. Hotels: z.B. das hier http://osm.org/go/0DaQ0bcTx–
Ich mappe wenn möglich (und es mir sinnvoll erscheint) immer als Polygon.
Wenn ich bestimmte interessante Orte als Polygon auf der Karte darstellen möchte, dann brauche ich den Zusammenhang zwischen dem sogenannten POI und dem Polygon. Ansonten kann ich das nicht so darstellen wie ich das haben will.
Falls man sich tatsächlich irgendwann mal darauf einigen würde, dass man für bestimmte Objekte nur Punkte benutzt, dann könnte man ein Skript schreiben der alle Polygone weltweit zu Punkten umwandelt. Andersrum ist das schlicht nicht möglich!
Was ist überhaupt ein POI? Leute interessieren sich für die verschiedensten Dinge. Ist ein Campingplatz ein POI? Der wäre mit einem Punkt auf jeden Fall sehr ungenau gemappt.
Ich kann die Bedenken durchaus verstehen, und wir hatten auch schon damals solche Diskussionen. Mit Punkten lässt sich halt am einfachsten Arbeiten, wenn man nur ein simple Anwendung baut, die nicht mehr benötigt.
Es fehlt einfach ein Tool mit dem man POIs als Punkt aus der Datenbank ziehen kann, egal als was sie eingetragen sind. Ich kann ich kaum glauben, dass es sowas bis heute nicht gibt.
Yepp, ein POI Befehl fuer die Overpass Api waer was feines.
Ansonsten gibt es schon was : mkgmap kann es standardmaeßig und osmfilter hat eine all-to-nodes Option.
Aber ich muss dem Threadersteller schon recht geben. Das ist einfach zu kompliziert. Man muss erstmal Software installieren, und die noch mit Kommandozeilenbefehlen ausführen. Viele geben da wohl schon auf.
Was ich meinte wär eher ein Onlinetool. So, dass man die Daten direkt als POI bekommt und nicht erst umwandeln muss. POI-Befehl für die Overpass API wär super, wenn dann auch jemand ein Tool mit Eingabemaske baut.