Die Frage ist - zumindest für mich - ein wenig unklar formuliert.
Willst du die Flächen exakt an der BBOX abschneiden und nur die Größe der sichtbaren Bereiche berechnen? Oder aber die totalen Größen auch über den Rand hinaus?
Und wo kommen denn deine Daten her? Klar, aus Osm, aber wie?.
Gruss
walter
p.s. ich denke da an PostGis, aber es hängt halt von deinem Umfeld ab. Python sollte da keine Probleme machen.
Wie gesagt, ich will aus min/max lat/lon welche die Boundingbox beschreiben den Flächeninhalt bestimmen. Ich denke das ist, was du mit “sichtbaren” Bereich meinst.
Meinem Verständnis nach ist das ein Rechteck auf der projezierten ausgebreiteten Fläche. Da dort der Elipsoid mit eine Rolle spielt, müsste man das umprojezieren, damit man die Lage der BBOX mit einbezieht und eine längentreue Abbildung hat. Und dann sollte man eigentlich doch mit a*b weiterkommen?
Ich nutze ja bereits pyPROJ für die Distanz und würde gerne auch dabei bleiben:
def getDistance(p1lat,p1lon,p2lat,p2lon):
g = Geod(ellps='WGS84', units="m")
az12,az21,dist = g.inv(p1lon,p1lat,p2lon,p2lat) #fuer grosse und kleine Distanzen ok
return (dist/1000) #in km
Das Polygon ist in Längen- und Breitengraden angegeben. Das ist recht unpraktisch, wenn man Flächen berechnen will, weil die Abstände der Längengrade nach Norden abnehmen. Also verwenden die pyproj, um das Polygon erstmal in eine Projektion umzurechnen, die echte Meter und Quadratmeter verwendet.
Diese Wahl der Projektion (+proj=aea +lat_1=37.0 +lat_2=41.0 +lat_0=39.0 +lon_0=-106.55) ist speziell für die eine Gegend in den USA gut (“aea” ist eine Albers-Kegelprojektion, die nehmen 106° West als Mittelmeridian zwischen 37° und 41° Nord).
Wenn Du hier in der Gegend was machst, solltest Du lieber irgendwas nehmen, was unsere Gegend korrekter abbildet (aea mit 10 Grad Ost und 47 bis 51 Nord z.B., oder UTM oder GK).
Wenn bei g.inv() richtige Meter rauskommen, reicht a*b, solange Du in der Grössenordnung eines Stadtplans bleibst und nicht auf 1/1000 genau rechnen willst. Bei grösseren Flächen wird es immer ungenauer. Deine BBox mit Koordinaten in Längen- und Breitengrad ist in der richtigen kugeligen Welt ja kein Rechteck, sondern eher sowas wie ein Trapez (wenn ein Pol dabei ist, sogar ein Dreieck).
**Keine **ebene Projektion kann eine gekrümmte Oberfläche fehlerfrei abbilden.
Bei sehr großen Flächen müsste man das Kugelsegment aus dem Raumwinkel und dem Radius berechnen. Beim Ellipsoid oder gar Geoid artet das aber in Arbeit aus.
In der Praxis (kleinere Flächen bis Bundesland, nicht in Polnähe) kommt man aber mit allen Projektionen zurecht, wenn man nur die Distanzen parallel zu den Breitengraden korrigiert. Damit wird das (eigentlich sphärische) Trapez in ein Rechteck verformt. Gauß-Krüger und UTM können die Koordinaten deshalb in Meter angeben.
Danke schon mal für eure Hinweise das bestätigt mich darin, dass ich da wohl doch nicht so viele Bretter vor dem Kopf hatte…
Da ich aber weltweite Changeset BBoxen analysiere (ja, die meisten sind sehr klein, was wenig verwunderlich ist), müsste ich es irgendwie hinkriegen, automatisch die passende Projektion zu wählen. Hat da jemand eine Idee wie man da rangehen müsste? Es kommt dabei sicherlich erstmal nicht auf den Meter genau an. Eine andere Alternative wäre sonst einen lokalen Ausschnitt zu nehmen, vielleich ganz Deutschland, aber da leidet ja auch immer die Aussagekraft drunter
Wenn die Boxen ein paar Kilometer gross sind, nimm spherical mercator (epsg 3857 oder 900913) und rechne abcos(breitengrad)*cos(breitengrad).
Alternativ zu Fuß: (Breite_oben - Breite_unten)/360Erdumfang * (Länge_rechts - Länge_links)/360Erdumfang * cos((Breite_oben+Breite_unten)/2)
Ist global, einfach, ganz ohne Umrechnerei mit Ellipsoiden und passt genau genug für eine Changeset-Bbox.
Bei riesigen Boxen hast Du immer ein Problem. Auch wenn Du “aea” nehmen würdest (was theoretisch global anwendbar wäre, weil das ist überall flächentreu, nur am dicken Ende des Kegels recht stark in die Breite verzerrt), müsstest Du erstmal sicherstellen, dass eine Box dort richtig auf ein Stück Kegelmantel projiziert wird, und nicht nur die 4 Ecken mit Strichen verbunden. Damit haben GISe oft Probleme, die hangeln sich oft nur von Punkt zu Punkt.
Oh je. Die meisten Changeset-Boxen dürften zwar klein sein, aber ein paar Riesenexemplare dürften schon dabei sein, wenn jemand z.B. zwei weit auseinanderliegende Gegenden bearbeitet und gemeinsam hochgeladen hat.
Jetzt kommt es darauf an: Wenn solche Edits nicht berücksichtigt werden sollen, weil sie das Ergebnis (z.B. bearbeitete Fläche) massiv verfälschen, hat man das Problem umschifft.
Wenn diese Changesets auch gezählt werden sollen, wird es unschön. Es gibt zwar flächentreue Projektionen, die verbiegen aber über große Distanzen gerade Linien fürchterlich. Da ist es dann nichts mit Breite mal Höhe.
Gegeben: MinLon, MaxLon, MinLat, MaxLat (in Grad).
Die vier Werte definieren vier Punkte auf einer Kugel. Wenn wir diese vier Punkte über Meridianbögen und Parallelkreisbögen verbinden, erhalten wir ein Viereck. Gesucht ist die Fläche dieses Vierecks.
Danke für die vielen Antworten. Ich werde mal eine Stichprobe nehmen und schauen ob mir die Näherung genügt.
Prinzipiell zeigen die Daten nur relativ wenige extreme Ausreißer, von daher denke ich damit schon typische Mapping-Muster belegen zu können (ganz kleine Attribut-Fixe, größere Areale bingen, Botläufe, …). Ist erstmal nur ein Zwischenprodukt, durch das ich einige Parameter sicher ableiten möchte.
Ich weiß zwar nicht, warum Du die Flächen brauchst, aber rechen doch einfach in Quadrat-Grad. Das ist das einfachste und für eine ORdnungsmetrik sicherlich ausreichend.
Ist im Prinzip dasselbe wie die Formel von “Oranger Assistent”, nur Winkelrechteck mit Radiusquadrat multipliziert und Breitenausdehnung korrigiert.
(Flächenelement in Kugelkoordinaten ist RRdλsinφdφ, für geogr. Koordinaten muss φ um 90° verschoben werden. Ohne Breitenkorrektur werden Flächen in höheren Breiten zu stark bewertet.)
das bestätigt mich darin, dass ich da wohl doch nicht so viele Bretter vor dem Kopf hatte…