seen und insel bei coastline

Ich experimentiere aktuell an einem simplen Flash-Renderer herum, der mir u. a. Seen anzeigen soll.
Die Abfrage erfolgt mittels XAPI:
http://www.informationfreeway.org/api/0.5/way[natural=coastline][bbox=16.3,47.5,17.1,48.3]


Was ich gemacht habe:

Bei Seen muss man mit ‘coastline’ arbeiten.
Holt man sich die Daten zum Neusiedlersee, bekommt man 9 ways.
Einige dieser ways kann man aneinanderhängen (Endpunkt des einen ways ist der Anfangspunkt des anderen ways).

Letztendlich erhält man dann 3 ways:
Der erste way ist der See.
Der zweite und der dritte way sind Inseln im See.


Jetzt meine Frage:

Wie erkenne ich denn, ob der way der See oder eine Insel im See ist?
Kommen zuerst immer die ways zum See und dann immer die ways der Inseln? Ist dieser Reihenfolge garantiert?


Und noch eine generelle Frage zu coastlines:

Frage ich ein Gebiet ab, könnten sich mehrere Seen darin befinden. Woran erkenne ich denn, welcher way zu welchem See
gehört? Ich finde leider keinerlei Gemeinsamkeiten, wenn man sich die ways in der XML-Datei anschaut. Bei vielen ways habe ich ein ‘name’ angegeben (‘Neusiedler See’). Aber nicht bei allen ways.

Wäre toll, wenn mir wer weiterhelfen könnte :slight_smile:

Die Rollen stehen in der zugehörigen Multipolygon-Relation.

Interessant!

Wie kommt man denn zu diesen Daten?
Aktuell habe ich nämlich nur so etwas zur Verfügung:

<?xml version='1.0' standalone='no'?>
<osm version='0.5' generator='osmxapi: OSM Extended API' xmlns:osmxapi='http://www.informationfreeway.org/osmxapi/0.5' osmxapi:uri='/api/0.5/way[natural=coastline][bbox=16.3,47.5,17.1,48.3]' osmxapi:planetDate='200904171809' osmxapi:copyright='2008 OpenStreetMap contributors' osmxapi:instance='zappyHyper'>
  ...
  <node id='334670260' lat='47.796617' lon='16.699907' user='Marko Knöbl' osmxapi:users='plan_at_Upload_by_Wolfgang_Wasserburger,Marko Knöbl' timestamp='2009-01-25T12:44:45Z'>
  </node>
  <way id='30344623' user='Marko Knöbl' osmxapi:users='plan_at_Upload_by_Wolfgang_Wasserburger,Marko Knöbl' timestamp='2009-01-25T12:44:45Z'>
    ...
    <nd ref='334844524'/>
    <tag k='...
  </way>
  ...
</osm>

EDIT: Habe weiter herumgeforscht.
…/api/0.5/way[natural=water][bbox=16.3,47.5,17.1,48.3] liefert mir am Ende:

...<relation id='102218' user='PA94' osmxapi:users='PA94' timestamp='2009-03-20T15:07:17Z'>
    <member type='way' ref='30337895' role='inner'/>
    <member type='way' ref='32342292' role='outer'/>
    <tag k='type' v='multipolygon'/>
  </relation>
</osm>

Aber leider liefert mir:
…/api/0.5/way[natural=coastline][bbox=16.3,47.5,17.1,48.3]
keinerlei derartiger Daten.

Für die Darstellung des Neusiedlersees brauche ich aber anscheinend unbedingt ‘coastline’.

Normal sollte natural=water plus multipolygon ausreichen. Warum glaubst Du daß Du coastline brauchst?

Die Daten in Deinem ersten Zitat sehen mir ein wenig nach Massenimport aus. Bist Du sicher, daß die wirklich gepflegt sind?

Weil ich den Neusiedlersee mit ‘water’ nicht bekomme; nur mit ‘coastline’. Ist halt ein großer See.

Ich übernehme die Daten, so wie sie nach einem XAPI-Request reinkommen. Keine Ahnung, ob die “gepflegt” sind.

Aber ich glaube, das ist nicht mehr so wichtig. Habe eine mathematische Lösung für das Problem gefunden. Kann aufgrund von Winkel entscheiden, ob ich einen See oder eine Insel im See habe. Ist zwar nicht optimal, sollte aber normalerweise funktionieren (sofern sich ways nicht kreuzen dürfen).

Ich arbeite noch immer an den Seen rund um den Neusiedlersee.

Kann das sein, dass dort über 100 kleinere Seen (Teiche) alle verkehrtherum eingetragen wurden?
Abfrage mit:
http://www.informationfreeway.org/api/0.5/way[natural=water][bbox=16.3,47.5,17.1,48.3]

Habe mir z. B. den way 33130812 angeschaut:

  <way id='33130812' user='Marko Knöbl' osmxapi:users='Marko Knöbl' timestamp='2009-04-13T16:43:53Z'>
    <nd ref='374179937'/>
    <nd ref='374179942'/>
    <nd ref='374179944'/>
    <nd ref='374179949'/>
    <nd ref='374179937'/>
    <tag k='natural' v='water'/>
  </way>

Er dreht sich gegen den Uhrzeigersinn. Alles, was sich gegen den Uhrzeigersinn dreht, ist eine Insel. Alles, was sich im Uhrzeigersinn dreht, ist ein See. Stimmt doch, oder?

Die Regel galt mal für Mapnik, nicht aber für andere Renderer. Ich weiß nicht ob diese Restriktion immer noch aktuell ist.

Auf jeden Fall wird häufig beim Einzeichnen nicht auf die Wegrichtung geachtet, daher gibt es viele die falschrum laufen.

Es gibt kein “falschrum”. Es ist keine Richtung gefordert, das ist/war nur eine Einschränkung von mapnik.

Mag sein … Wie auch immer … Fakt ist, dass man sich auf die Wegrichtung nicht verlassen kann.

Thanks! Das war schon mal sehr informativ! :slight_smile:

Obwohl ich das auch als Mangel ansehe. Auch ein kleiner See kann eine Insel haben. Man kann dann nicht mehr zwischen See und Insel unterscheiden (zumindest ich kann das dann nicht mehr).

Für coastlines gilt das hoffentlich nicht. Da bin ich unbedingt darauf angewiesen, dass diese Regel immer eingehalten wird. Dass also in way-Richtung das Wasser immer auf der rechten Seite ist.

Noch 2 Fragen zu Flächen:

D. h. bei natura=water muss ich also alle ways als Wasserflächen betrachten. Damit das funktioniert, setzt das aber voraus, dass ich IMMER geschlossene ways erhalte. D. h. wenn ich eine XAPI-Request mache, muss ich immer alle nodes zu alles ways erhalten, die mir der XAPI-Response liefert (way-Fragmente wie bei coastline sind dann nicht mehr erlaubt). Ansonst kann ich die Wasserflächen nicht mehr richtig anzeigen. Ist dieses Verhalten garantiert?

Noch kurz eine Frage zu allen anderen Arten von Flächen. Ich zeichne z. B. auch Stadtgrenzen mit boundary=*. Ich vermute, dort gilt diese ‘Fläche=rechts vom way’-Regel auch nicht. Richtig?

Eine Insel in einem kleinen See sollte statt mit natural=water mit natural=land getaggt sein, oder als inner in einer Multipolygon-Relation des Sees stehen.

Bei coastlines sollte soweit ich weiß das Wasser immer auf der rechten Seite sein. Damit haben sonst die Standard-Renderer auch Probleme.

Außer coastline bestehen alle Flächen immer aus einem einzigen Way oder aus einer Relation. Beides bekommst du komplett, wenn du die XAPI abfragst. Eventuell musst du dir bei Relationen die fehlenden Ways nachladen.

Richtig. In erster Linie stellen die ways mit boundary=* auch nur die Grenze und nicht die Fläche dar. Die Fläche bekommst du dann wieder über die Relation.

Super!! Hat mir wieder weitergeholfen!!!

Jetzt ist aber leider noch eine Frage aufgetaucht:

Wenn man sich mittels XAPI und natural=coastline die Daten zum Neusiedlersee holt, erhält man wie schon erwähnt:

  • die ways zum See
  • und zusätzlich ways zu 2 Inseln im See

Bei dem folgenden Beispiel gehe ich davon aus, dass ich ein sehr kleines Sichtfenster wähle. Also vielleicht nur 1km Breite und 1km Höhe. Weiters angenommen, ich erhalte nach dem Request nur 1 way zurück, der nicht geschlossen ist. Dieser way könnte jetzt zum See oder zu einer der Inseln im See gehören. Alleine aufgrund der Response-Daten kann man das nicht unterscheiden.

Woher weiß ich jetzt also, ob ich einen See oder eine Insel zeichnen soll?

Kann ich vielleicht davon ausgehen, dass derartige Inseln IMMER als geschlossener way ausgeliefert werden? Das würde dann nämlich mein Problem lösen.

Das Wiki sagt dazu:

http://wiki.openstreetmap.org/wiki/DE:Coastline

Die Definition kenne ich. Leider beantwortet das meine Frage nicht. Meine Frage bezieht sich nämlich nicht auf die Seen, sondern vielmehr darum, wie ich die ways zu Inseln im See erkenne.
EDIT: Ne, falsch. Hilft doch weiter. Es müssen sich ja auch die Inseln an diese Regeln halten.

Hallo … ,

natural=coastline bezeichnet die **Küstenlinie **zwischen Meer und Land.
Sie liegt immer auf 0 m.ü.M
Dabei liegt das Meer immer rechts von der Küstenlinie und das Land links davon.

Inseln im Meer werden durch natural=coastline gekennzeichnet.

Seen hingegen haben keine “coastline”. Sie werden als natural=water gekennzeichnet.
Unterschieden werden die Seen durch ihren Namen.

Inseln im See werden durch natural=land gekennzeichnet und als Multipolygon von See (outer) und Insel(n) (inner) dargestellt.

Gruss, Markus