glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Hier schon mal die Version, die Koordinaten ohne Komma annimmt.
Vielen Dank, werde ich gleich probieren.
das Hauptproblem ist, die auf gemeinsame Feldnamen zu bringen.
Warum nicht einfach das ausgeben was kommt und am Ende die wichtigsten (zumindest meine) Felder darstellen, ähnlich wie bereits beim Ort und bei der Straße: Ich wiederhole nochmal meine Felder: [IPTC] 0x005a City
[IPTC] 0x005f Province-State
[IPTC] 0x0064 Country-Primary Location Code
[IPTC] 0x0065 Country-Primary Location Name
[XMP] - Country Code
[XMP] - Location # PLZ
[XMP] - GPS Altitude
[XMP] - GPS Altitude Ref
[XMP] - GPS Latitude
[XMP] - GPS Longitude Was ich gerade bei "37.08972, -8.16611" gesehen habe, dass da keine Höhe ausgegeben wird. Bei Höhe sollte auch 0 ausgegeben werden. In der Satellitenansicht sieht man, dass das nicht auf Meeresniveau ist, sondern etwas darüber. Kannst du mir mal eine Datei mit gesammelten Problem-Koordinaten geben, damit ich interessante Punkte zum Testen habe?
Ich habe zufällig getestet und weiß nicht mehr was genau, die "37.08972, -8.16611" waren bis jetzt am schlimmsten daneben. Wenn ich wieder was entdecke poste ich es, da tue ich mich aber leichter, wenn ich deine Abfrage in mein Skript integriere und das dauert sicher einige Zeit. Meine Überlegung ist, dass man einen anderen Server probieren soll können, wenn man merkt, dass es gar nicht passt. Wenn man annimmt, dass Fotos oft nahe beeinander gemacht wurden, dann könnte es eine Alternative sein, wenn der andere Server bessere Daten liefert. Ich glaube zum Testen, kommt es da gar nicht so sehr auf meine Einzelfälle an. "45.52723769, 13.56811946" ist auch so eine Sache, der wird der Ortsname in 2 Sprachen ausgegeben.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Da scheint jemand die ab 2013 neu zusammengefasste Gemeinde als Stadt genommen zu haben: Albufeira_e_Olhos_de_Água
Ooops, hatte ich überlesen, sehr kreativ. ~$ python3 /usr/local/bin/geoinfo.py -i "45.52723769 13.56811946"
usage: geoinfo.py [-h] [--cachedir CACHEDIR] [--tzname TZ] [--timedelta DELTA]
[--language LANGUAGE]
GPXFILE|COORDINATES [IMAGE [IMAGE ...]]
geoinfo.py: error: unrecognized arguments: -i
python3 /usr/local/bin/geoinfo.py -i "45.52723769, 13.56811946"
usage: geoinfo.py [-h] [--cachedir CACHEDIR] [--tzname TZ] [--timedelta DELTA]
[--language LANGUAGE]
GPXFILE|COORDINATES [IMAGE [IMAGE ...]]
geoinfo.py: error: unrecognized arguments: -i Ich glaube nicht, dass ich eine alte Version erwischt habe. Kannst du vielleicht eine Versionsabfrage dazu machen?
b170c67dee5a17c4f1696598313497bc /usr/local/bin/geoinfo.py
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Hatte ich dich da falsch verstanden? Ich dachte, du wolltest das ohne "-i" machen können: seahawk1986 schrieb: Ok, dann gibt es noch ein zusätzliches Startargument -i, bei dem man die dezimalen Koordinaten angeben kann, also z.B.
Ivh finde, das sollte default sein, fügt sich leichter in Maps ein
Dann löse ich es so, dass er das erste Argument als Koordinatenset interpretiert, wenn es keine weiteren Argumente für die Bilder gibt.
Also z.B. ./geoinfo.py -lde "48.1374300, 11.5754900"
# bzw.
./geoinfo.py -lde my.gpx my.jpg
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ok, das hatte ich nicht mehr im Kopf. Funktioniert so, danke!
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Damit ich mit der Integration in mein Script beginnen kann, brauche ich aber unbedingt die Ausgabe der Höhe und die fehlt bei der Übergabe der Koordinaten, während es bei der Angabe des Fotos angezeigt wird. ### POINT START ###
name=TP2639
latitude=49.6100383
longitude=6.1404299
elevation=273.0
time=2016-05-27 12:58:06
timezone_name=Europe/Luxembourg
coordinates=49.6100383, 6.1404299
location=Batterie du Rham, Trierer Straße, Grund, Luxemburg, Kanton Luxemburg, 2427, Luxemburg
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code3=LUX
country_code=lu
country=Luxemburg
state=
state_district=
county=Kanton Luxemburg
postcode=2427
city=Luxemburg
town=
suburb=Grund
city_district=
neighbourhood=
road=Trierer Straße
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
place_of_worship=
hotel=
loc_name=Luxemburg
street_name=Trierer Straße
unused attributes: castle
### POINT END ### Da fehlt also offesichtlich elevation: $ python3 /usr/local/bin/geoinfo.py "49.6100383, 6.1404299"
### POINT START ###
coordinates=49.6100383, 6.1404299
latitude=49.609459
longitude=6.140583175
location=Batterie du Rham, Rue de Trèves, Grund, Luxembourg, Canton Luxembourg, 2427, Lëtzebuerg
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code3=LUX
country_code=lu
country=Lëtzebuerg
state=
state_district=
county=Canton Luxembourg
postcode=2427
city=Luxembourg
town=
suburb=Grund
city_district=
neighbourhood=
road=Rue de Trèves
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
place_of_worship=
hotel=
loc_name=Luxembourg
street_name=Rue de Trèves
unused attributes: castle
### POINT END ###
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Ja, OSM liefert keine Höheninformation bei der Rückwärtssuche und eine gpx-Datei, die die Höhen-Informationen enthält, übergibst du in dem Fall ja nicht. Ich kann das wie schon früher geschrieben prinzipiell über die GoogleMaps API abfragen (mit einem kostenlosen API-Key gelten die dort genannten Beschränkungen). Vielleicht kannst du mal auflisten, was für deinen tatsächlichen Use-Case insgesamt noch an zusätzlichen Anforderungen an das Programm besteht (neben einem weiteren Geocoder und der Abfrage der Höheninformation bei der Übergabe von Koordinaten statt einer gpx-Datei), das macht die Implementierung leichter als im Nachgang immer wieder etwas zu ergänzen.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Du hattest mal das vorgeschlagen um Variablen für mein Script zu genieren, das funktioniert aber nicht. staat=$(grep -Po "(?<=^state=).*$" <<< $out) So hole ich mir die Ausgabe: GPSINFO=`python3 /usr/local/bin/geoinfo.py -lde "$GPXFILE" "$FIRSTFILE"` Die Ausgabe schaut dann so aus, dh die Felder stehen nicht in 1 Zeile ### POINT START ### name=TP2639 latitude=49.6100383 longitude=6.1404299 elevation=273.0 time=2016-05-27 12:58:06 timezone_name=Europe/Luxembourg coordinates=49.6100383, 6.1404299 location=Batterie du Rham, Trierer Straße, Grund, Luxemburg, Kanton Luxemburg, 2427, Luxemburg licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright country_code3=LUX country_code=lu country=Luxemburg state= state_district= county=Kanton Luxemburg postcode=2427 city=Luxemburg town= suburb=Grund city_district= neighbourhood= road=Trierer Straße pedestrian= address29= path= house_number= townhall= ruins= attraction= place_of_worship= hotel= loc_name=Luxemburg street_name=Trierer Straße ### POINT END ### Ich frage mich wie man das Ende des Feldes erkennen kann, es nicht immer ein Leerzeichen. Könntest du bitte ein Beispiel bringen, wie ich das am besten mache? Vielleicht ist sed eine Idee? Aber letztlich ist es mir egal womit.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Vielleicht kannst du mal auflisten, was für deinen tatsächlichen Use-Case insgesamt noch an zusätzlichen Anforderungen an das Programm besteht
Eigentlich nichts mehr, sorry ich komme da auch erst darauf, wenn ich dein Script in mein Script integriere. Die Höhe ist aber schon wichtig und wurde auch anfangs erwähnt. Vieles kann ich dann ja selber auch in der Bash machen, zB eine Höhengruppierung in 500m-Schritten, zB 0-500m, 501-1000m. Also wenn du sowas zusätzlich einfach ausgeben kannst, bitte gerne, ist aber nicht wirklich nötig. Das Problem ist einfach, wie brauchbar ich die ausgegebenen Daten sehe und da kann man programmtechnisch nichts machen, außer eine Alternative anbieten und wenn das auch nicht passt, muss ich die Angaben manuell erzwingen, das soll aber möglichst vermieden werden.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Mir fällt gerade auf, dass es nicht viel Sinn macht, die Höhe genauer als auf 1m anzugeben. Ich kann das aber auch selber runden. Beim Erzeugen der Variablen f+r mein Bash-Script bin ich ein wenig weiter. Da muss man beim Quoten genau aufpassen. latit=`echo $gpsinfo | grep -oP "(?<=latitude=).*(?= longitude=)"` Quotet man $gpsinfo funktioniert es nicht mehr. Ich probiere nun den Fall bei mir durchzuspielen, wenn eine gpx-Datei vorhanden ist.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Geonames bringt extrem unterschiedliche Höhenangaben zu OSM. Das können mehr als 50m sein. Mir ist das nicht so wichtig, ich wollte es nur erwähnen. Ich versuche über die Höhe zB Bergfotos oder Meerfotos zu finden. Ich habe in mein Script jetzt an vielen Stellen dein Python-Script zu Anwendung gebracht. Dabei fiel mir auf, dass ich Kontrollabfragen mit dem geonames-Server gemacht habe, ob zB bei der Abfrage der PLZ der gleiche Ort genannt wird. In Österreich können mehrere Orte die gleiche PLZ haben und dann habe ich den Ort genommen, den Wikipedia als 1. nennt (oder so ähnlich, müsste da bei geonames nachlesen, was die da genau machen).
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
glaskugel schrieb: Mir fällt gerade auf, dass es nicht viel Sinn macht, die Höhe genauer als auf 1m anzugeben. Ich kann das aber auch selber runden.
Ich kann das auch einbauen, dass das Skript das ganzzahlig ausgibt, bei der Google Maps API sind die Nachkommastellen bei den Höhenangaben sowieso etwas übertrieben, wenn man die sich Messgenauigkeit vor Augen hält... Beim Erzeugen der Variablen f+r mein Bash-Script bin ich ein wenig weiter. Da muss man beim Quoten genau aufpassen. latit=`echo $gpsinfo | grep -oP "(?<=latitude=).*(?= longitude=)"` Quotet man $gpsinfo funktioniert es nicht mehr.
Eventuell tust du dir leichter, wenn du die Ausgabe des Skripts in eine Datei (auf ein tmpfs-Dateisystem wie /tmp oder /run) schreiben lässt, dann kann grep zeilenweise suchen - also z.B.:
| geoinfo.py -lde my.gpx my.jpg > /tmp/geoinfo.tmp
latit=`grep -oP "(?<=latitude=).*" /tmp/geoinfo.tmp`
|
glaskugel schrieb: Geonames bringt extrem unterschiedliche Höhenangaben zu OSM. Das können mehr als 50m sein. Mir ist das nicht so wichtig, ich wollte es nur erwähnen. Ich versuche über die Höhe zB Bergfotos oder Meerfotos zu finden.
Die Höhenangaben stammen nicht von OSM, sondern von aus deinen gpx-Dateien. Wenn ich die mit den Werten vergleiche, die die Google Maps API liefert, dann passt das eigentlich recht gut (auch wenn ich jetzt keine allzu große Vergleichsbasis habe):
| <trkpt lat="49.609896600" lon="6.132854900">
<ele>304.000000</ele>
<time>2016-05-27T12:45:42Z</time>
<name>TP3153</name>
</trkpt>
|
| >>> import googlemaps
>>> g = googlemaps.Client(key='secret')
>>> g.elevation([(49.609776600,6.132824900)])
[{'resolution': 152.7032318115234, 'location': {'lat': 49.60978, 'lng': 6.13282}, 'elevation': 304.23388671875}]
|
In dem Fall waren die vermessenen Referenzpunkte, aus denen ein Mittel errechnet wurde maximal 152,7 Meter entfernt. Ich habe in mein Script jetzt an vielen Stellen dein Python-Script zu Anwendung gebracht. Dabei fiel mir auf, dass ich Kontrollabfragen mit dem geonames-Server gemacht habe, ob zB bei der Abfrage der PLZ der gleiche Ort genannt wird. In Österreich können mehrere Orte die gleiche PLZ haben und dann habe ich den Ort genommen, den Wikipedia als 1. nennt (oder so ähnlich, müsste da bei geonames nachlesen, was die da genau machen).
Ich sehe da den Sinn bei einer Geoquelle, die alle Informationen am Stück liefert nicht ganz - sowohl OSM als auch die Google Maps API liefern dir für ein Koordinatenset ein Datenset mit den nötigen Informationen zurück, das ist die beste Zuordnung, weil Koordinaten (sieht man mal von den GPS-Ungenauigkeiten ab) ein eindeutiges Kriterium für den Ort sind, alles andere ist potentiell eine 1:n Zuordnung. Was genau ist der Vorteil davon da nochmal die Wikipedia nach dem Ort für die PLZ zu fragen? Da man für die GoogleMaps API einen API-Key benötigt, würde ich den aus einer Konfigurationsdatei auslesen, weil es sonst nervig ist, den für jeden einzelnen Aufruf anzugeben - die Struktur könnte dann so aussehen, die einzelnen Einstellungen kann man beim Aufruf durch das Setzen von Argumenten übersteuern, wenn man will:
[main]
# default geoparser: osm|googlemaps
geoparser = osm
# preferred language for geo informations
langugage = de
[googlemaps]
apikey = secret Das Skript würde dann die erste gefundene Konfigurationsdatei aus den Pfaden ~/.config/geoinfo.cfg und /etc/geoinfo.cfg nehmen.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ich kann das auch einbauen, dass das Skript das ganzzahlig ausgibt,
Bitte.
Eventuell tust du dir leichter, wenn du die Ausgabe des Skripts in eine Datei (auf ein tmpfs-Dateisystem wie /tmp oder /run) schreiben lässt,
Das mit den Variablen ist gelöst, ich hatte nicht richtig gequotet 😉 zB latit=`echo "$gpsinfo" | grep "^latitude=" | cut -f2 -d"="` oder so: `echo "$gpsinfo" | grep -oP "(?<=county=).*"` oder so:
`echo $gpsinfo | grep -oP "(?<=county=).*(?= postcode=)"` Man beachte das unterschiedliche Quoting von gpsinfo
Die Höhenangaben stammen nicht von OSM, sondern von aus deinen gpx-Dateien.
Ok, dann hatte ich meine gpx-Datei mit geonames verglichen. http://api.geonames.org/srtm3?lat=""$latit""&lng=""$longit""&username=""$user"
Was genau ist der Vorteil davon da nochmal die Wikipedia nach dem Ort für die PLZ zu fragen?
Ich wollte einfach nur die Problematik erwähnen. Auf die Schnelle finde ich keine dieser besonderen Fälle. Es geht darum, die theoretische PLZ 1234 kann gültig für die Orte A, B und C sein und wenn die Ausgabe über die Koordinaten nicht passt, könnte man probieren den Ort zu verwenden, der als 1. gefunden wird. Letztlich ist das alles theoretisch und am besten erzwingt man dann die Angabe.
Da man für die GoogleMaps API einen API-Key benötigt, würde ich den aus einer Konfigurationsdatei auslesen
ist denkbar, mache das wie du das möchtest
weil es sonst nervig ist, den für jeden einzelnen Aufruf anzugeben
in einem Script als Variable nicht. Also wenn das nicht zu kompliziert ist, dann hätte ich gerne auch diese Variante. Das hat den Vorteil, dass mein Script dann auch ohne dieser Datei auf anderen PCs läuft und verschidene Keys unterschiedlicher User nur 1x definirt werden müssen. Es ist einfach die Frage wie aufwendig das ist. Vielleicht kann man das so machen -a $APIKEY, wenn das nicht angegeben ist, dann wird nach einer cfg-Datei gesucht.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Bei der Google Maps API bekommt man hierarchisch organisierte Felder (mal nach "_level_1" suchen) zurück: https://developers.google.com/maps/documentation/geocoding/intro?hl=de#Results bzw. https://developers.google.com/maps/documentation/geocoding/intro?hl=de#Types - reicht dir das, wenn du da den jeweiligen Level bekommst oder soll ich versuchen das auf die OSM-Bezeichnungen zu mappen (auch wenn das vermutlich nicht verlässig für alle Länder klappt)?
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Das ist schwer zu beantworten. OSM-Bezeichnungen müssen es nicht unbedingt sein, aber pro Feld brauche ich eine Zeile. Wenn ich mir das Toledo-Beispiel bei https://developers.google.com/maps/documentation/geocoding/intro?hl=de#Types ansehe, dann kann ich damit nicht viel anfangen. Für die Google-Variante gibt es 2 Gründe, einmal die Höhe und vielleicht die besseren Daten, das muss man aber testen. Ich hoffe, ich habe da nichts übersehen, folgendes nutze ich je nach Fall mit OSM: latitude=49.6100383
longitude=6.1404299
elevation=273.0
country_code3=LUX
country_code=lu
country=Luxemburg
state=
state_district=
county=Kanton Luxemburg
postcode=2427
city=Luxemburg
town=
suburb=Grund
city_district=
road=Trierer Straße
pedestrian=
loc_name=Luxemburg
street_name=Trierer Straße Irgendsowas in der Richtung sollte auch bei Google rauskommen. Ich habe entdeckt, dass ich den Country-Code 2 und 3stellig verwende.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
glaskugel schrieb: Das ist schwer zu beantworten. OSM-Bezeichnungen müssen es nicht unbedingt sein, aber pro Feld brauche ich eine Zeile. Wenn ich mir das Toledo-Beispiel bei https://developers.google.com/maps/documentation/geocoding/intro?hl=de#Types ansehe, dann kann ich damit nicht viel anfangen.
Das geht ja in die umgekehrte Richtung, da wird mit dem Suchbegriff "Toledo" nach Informationen gesucht - wenn man schon Koordinaten hat, dann nimmt man das reverse Geocoding: https://developers.google.com/maps/documentation/geocoding/intro?hl=de#reverse-example
|