Wofür steht "nd ref" bei den aufgelisteten meta-informationen ?

nd=Node, ref=Referenz
Dein Weg 32309429 enthält also die Knoten 363734879,363734784,.... etc.

naruto25 wrote:

Habe dazu leider nix gefunden

Da mußt Du aber ganz schön schlecht, wenn überhaupt, gesucht haben.
http://wiki.openstreetmap.org/wiki/OSM_XML
http://wiki.openstreetmap.org/wiki/Way

Hallo und danke für die schnellen antworten

@ Oli-Wan: ja hast recht 🙄
danke 😉

@Chris66: ah ok. hatte ich mir schon gedacht. Wollte nur sicher gehen. Mich beschäftigt die Frage, ob ein Bereich z.B. im obrigen fall landuse=farmland mit den sämtlichen knoten eine ausage über die größe des bereichs farmland aussagen? Würde z.b. ein anderes farmland-gebiet mit mehr knoten bedeuten, dass die von der fläche her größer wäre? Beispiel: eine bbox das zu 60% ein farmland gebiet umfasst und zu 40% forest, also waldgebiet. Enthält dann farmland mehr nodes?

Nicht unbedingt. Ein Quadrat (4 Nodes) kann jede beliebige Größe von 1 Quadratmillimeter bis 1000 Quadratkilometer haben. 😉

Jein. Wenn die Ackerfläche detailiert erfasst ist und der Wald noch von "lang ist's her" stammt reicht es möglicherweise auch, wenn die Ackerfläche nur 15% und der Wald 80% ist. Beides lässt sich ja super-detailiert (Acker besser als Wald) oder mit nur ungefähren Ecken erfassen.

logisch 🙂

danke

@rayquaza: danke für die info 😉

naruto25 wrote:

@rayquaza: danke für die info 😉

da du ja unbedingt die Flächen von Landuse&Co brauchst, hier mal 2 Wege:

- Extrakt der Geofabrik mit osm2pgsql in eine temporäre Datenbank importieren. Dort kann man zu allen Flächen - egal ob als einfacher geschlossener Way oder als komplexes Multipolygon - die Area abfragen. (relativ einfach)

- Extrakt in eine permanente DB mit osmosis importieren und darauf PostGis-Funktionen zur Auswertung anwenden. (komplex)

Das ganze hängt etwas von deiner Zielsetzung, deinen Ressourcen und deinen Kenntnissen ab.

Gruss
walter

@wambacher: coole sache. ich werde mir das mal genauer anscchauen. danke 😉

naruto25 wrote:

@wambacher: coole sache. ich werde mir das mal genauer anscchauen. danke 😉

Die erste Lösung ist eigentlich nicht "cool" - das ist das Standardverfahren, das 90% der Kollegen einsetzen, die irgend was mit den OSM-Daten machen wollen (Rendern, Analysen, ...) und dafür eine eigene SQL-DB brauchen. Wenn du auf diesen Zug "springst", dürftest du auch schnell kompetente Hilfe bekommen.

Gruss
walter