Bezeichnung von Gebirgszügen

Federico Explorador · 2012-06-03 18:45:00

ok, bin den ganzen Post nochmal durchgegangen, das Beispiel von maxbe ist beeindruckend, und die Arbeit von Netzwolf auch, ich lasse mich überzeugen .
Damit sollte jedoch das Proposal: http://wiki.openstreetmap.org/wiki/Talk … /Mountains vorangebracht werden, ich habe dort den aktuellen Gebrauch nach taginfo eingetragen:

natural=mountain_range: 13 x
mit place=region, region:type=mountain_area=89 x
natural=ridge: 1642 x
ridge=yes: 290 x
natural=massif: 13 x
natural=arete: 140 x
natural=valley: 391 x
natural=bare_rock: 2243 x

Damit verdient insbesondere (neben mountain area) natural=ridge und das proposal natural=bare_rock (http://wiki.openstreetmap.org/wiki/Prop … /bare_rock) gepusht zu werden.

Edit:
place=region hat 3.064 Einträge, die wiki-Seite jedoch stub: http://wiki.openstreetmap.org/wiki/Tag:place=region

Last edited by Federico Explorador (2012-06-03 19:01:05)

Netzwolf · 2012-06-03 22:21:16

Nahmd,

Federico Explorador wrote:

ok, bin den ganzen Post nochmal durchgegangen, das Beispiel von maxbe ist beeindruckend, und die Arbeit von Netzwolf auch, ich lasse mich überzeugen .

Leider sind die Ostalpen noch nicht fertig. Das wird aber noch. Die Arbeit ist relativ nervig, da ich immer wieder man nicht einfach Flüssen und Bächen folgen kann, sondern erst einmal die Grundlagen legen muss. Dazu kommt, dass die Namen aus der textuelle Beschreibung oft nicht mit denen aus der Karte übereinstimmen, was immer wieder mal längere Recherchen braucht. Langer Rede kurzer Sinn: ich brauchte da eine Pause.

natural=mountain_range: 13 x
mit place=region, region:type=mountain_area=89 x
natural=ridge: 1642 x
ridge=yes: 290 x
natural=massif: 13 x
natural=arete: 140 x
natural=valley: 391 x
natural=bare_rock: 2243 x

Meine 2¢ dazu:

natural=bar_rock ist ok.
Da hoffe ich aber, das natural=rock Features automatisiert umgetaggt werden (UPDATE SET WHERE).

natural=mountain_range|massiv|arete:
davon halte ich nichts, weil das zwar von der Geografie (mehr oder weniger) vorgegebene Bereiche sind, aber keine Naturflächen, sondern Bereiche. Daher bevorzuge ich die place=region;region:type= Lösung.

Bei natural=ridge bin ich hin und her gerissen. Zwar habe ich damit angefangen, das aber als Hilfslinien betrachtet, die wieder rausfliegen. Jetzt nutzen das immer mehr. Jedoch: die Linie führt oft nicht über den Kamm, sondern ist eine (grobe) Näherung, hat also mit der lokalen Geografie nur bedingt zu tun.
Auf der anderen Seite kann das (wie die Mountain_area) für Übersichtskarten nützlich sein, um die Struktur eines Gebietes wiederzugeben. Das ist aber dann eine (üblicherweise unerwünschte) Nutzung ausschließlich zum Rendern.

Mit ridge=yes hatte ich begonnen, bin aber auch Wunsch der Österreicher auf natural= umgestiegen. Das sollte (automatisch) umgetaggt werden.

natural=valley: da scheint es mir noch keine wirklich gute Lösung zu geben. Während man Gebirgsregionen noch orographisch definieren kann, ist der Verlauf eines Tales entlang eines Wasserlaufes noch klar, die Flächenausdehnung abernicht wirklich. Ich würde wahrscheinlich einen Wasserlauf zusätzlich mit einem Linienfeature natural=valley belasten (wie auch mit den Grenzen der mountain_areas). Wobei mir die Wasserläufe schon irgendwie leid tun ob der zu tragenden Last

Damit verdient insbesondere (neben mountain area) natural=ridge und das proposal natural=bare_rock (http://wiki.openstreetmap.org/wiki/Prop … /bare_rock) gepusht zu werden.

natural=ridge ← sehr unschlüssig
natural=bare_rock ← ok, aber nicht wirklich wichtig. Umtaggen würde ich erst dann, wenn ich weiß, dass die üblicherweise verdächtigen Karten das rendern.

Gruß Wolf

derstefan · 2012-06-03 22:21:44

Hallo Federico,

ich bin gegen das Kartieren von Gebirgszügen als Ways: Wir kartieren nicht für den Renderer. Wie sollte man denn sonst für alle Zoomstufen kartieren? Wie gesagt - die gerenderte Karte auf osm.org ist weniger als die Spitze des Eisbergs von OpenStreetMap. Ich plädiere weiterhin für Relationen oder notfalls Polygone. Den way, auf dem die Beschriftung letztendlich gerendert wird, muss der jeweilige Kartenersteller selber aus den vorhandenen Daten berechnen. Z.B. sollte beachtet werden, dass die einzelnen Buchstaben nichts wichtiges verdecken oder andere Beschriftungen unmöglich machen.

Also: Algorithmen! Das brauchen wir. Es existieren bereits viele Veröffentlichungen und unterschiedlich gute Implementierungen auf diesem Gebiet, allerdings noch nicht "fertig" für unsere Standardwerkzeuge. Um diesen Umstand hoffentlich mal ändern zu können, ist an der Uni Erlangen ne Arbeit ausgeschrieben worden: http://lgdv.cs.fau.de/theses/Thesis/The … automa_48/

Ich wünsche eine schöne, wiederum kürzere Woche!
Stefan

fkv · 2012-06-03 23:37:25

Netzwolf wrote:

natural=bar_rock ist ok.
Da hoffe ich aber, das natural=rock Features automatisiert umgetaggt werden (UPDATE SET WHERE).

Nonono! natural=rock benutze ich für Felsformationen (z.B. Felstürme, Schalensteine). Das ist was ganz anderes als bare_rock (anstehender Fels).

natural=mountain_range|massiv|arete:
davon halte ich nichts, weil das zwar von der Geografie (mehr oder weniger) vorgegebene Bereiche sind, aber keine Naturflächen, sondern Bereiche. Daher bevorzuge ich die place=region;region:type= Lösung.

natural=arete ist gerade approved worden und im übrigen keine Naturfläche. Genauso wie natural=peak keine Fläche ist.

Bei natural=ridge bin ich hin und her gerissen. Zwar habe ich damit angefangen, das aber als Hilfslinien betrachtet, die wieder rausfliegen. Jetzt nutzen das immer mehr. Jedoch: die Linie führt oft nicht über den Kamm, sondern ist eine (grobe) Näherung, hat also mit der lokalen Geografie nur bedingt zu tun.

Ist ebenfalls approved worden und dient im Wesentlichen nur der Platzierung von Beschriftungen. Die Morphologie holt sich der Renderer sowieso besser vom Laserscan.

natural=valley: da scheint es mir noch keine wirklich gute Lösung zu geben. Während man Gebirgsregionen noch orographisch definieren kann, ist der Verlauf eines Tales entlang eines Wasserlaufes noch klar, die Flächenausdehnung abernicht wirklich.

Wozu brauchst du die Flächenausdehnung? natural=valley ist das Gegenstück zu natural=ridge, nur dass das eine eine Vollform ist und das andere eine Hohlform.

Ich würde wahrscheinlich einen Wasserlauf zusätzlich mit einem Linienfeature natural=valley belasten

Geht im Normalfall aus 2 Gründen nicht:
1.) Wasserlauf hat einen anderen Namen als das Tal
2.) Flüsse mäandrieren, Täler nicht

Netzwolf · 2012-06-04 00:13:19

Nahmd,

fkv wrote:

Netzwolf wrote:
natural=bar_rock ist ok.
Nonono! natural=rock benutze ich für Felsformationen (z.B. Felstürme, Schalensteine). Das ist was ganz anderes als bare_rock (anstehender Fels).

Schau mal nach: bare_rock ist in die Diskussion gekommen, weil natural=rock für Einzelfelsen benutzt werden soll, und also nicht mehr Flächen genutzt werden soll.

Das ist nicht auf meinem Mist gewachsen: ich habe Flächen mit n=rock getaggt.

natural=mountain_range|massiv|arete:
davon halte ich nichts, weil das zwar von der Geografie (mehr oder weniger) vorgegebene Bereiche sind, aber keine Naturflächen, sondern Bereiche. Daher bevorzuge ich die place=region;region:type= Lösung.

natural=arete ist gerade approved worden und im übrigen keine Naturfläche.

Sorry, das war ein Fehler, arete sollte nicht in die Aufzählung. arete ist für mich ein Spezialfall von ridge. Mit den gleichen Überlegungen.

Genauso wie natural=peak keine Fläche ist.

Mist! Da muss ich jetzt aber ne Menge umtaggen.

natural=valley: da scheint es mir noch keine wirklich gute Lösung zu geben. Während man Gebirgsregionen noch orographisch definieren kann, ist der Verlauf eines Tales entlang eines Wasserlaufes noch klar, die Flächenausdehnung abernicht wirklich.
Wozu brauchst du die Flächenausdehnung?

Weil ein Tal keine Linie ist, sondern ein Fläche. Und weil ich es für keine wirklich gute Idee habe, eine Linie zu malen, die willkürlich verläuft und nur dazu dient, dass da Buchstaben aufgereit werden sollen.

natural=valley ist das Gegenstück zu natural=ridge, nur dass das eine eine Vollform ist und das andere eine Hohlform.

Ja. Wenn valley immer an der tiefsten Stelle verläuft. Und da ist in vielen Fällen der Bach.

Ich würde wahrscheinlich einen Wasserlauf zusätzlich mit einem Linienfeature natural=valley belasten.
Geht im Normalfall aus 2 Gründen nicht:
1.) Wasserlauf hat einen anderen Namen als das Tal

Und? Valley ist ein Linienfeature, dass sich über diverse Bachsegmente und auch über mehrere Bäche erstrecken kann. Also ein Paradebeispiel für ein Linienfeature, das durch eine Relation abgebildet wird. Und so einen eigenen Namen tragen kann. Wie eine Buslinie. Wie eine administrative Grenze (die verlaufen in AT sehr oft in Bächen/Flüssen, wsehalb die in sehr viele Segmente aufgeteilt sind. Das ist mir beim Einzeichnen der Bergregionen aufgefallen).

2.) Flüsse mäandrieren, Täler nicht

Und? ich will ja gerade nicht vorgeben, wo die Buchstaben aufgereit werden. Sondern das Tal verläuft entlang der jeweils niedrigsten Stelle – meist eines Wasserlaufs. Und der Plazierungsalgorithmus sucht entlang dieser Linie geeignete Plätze für die Buchstaben des Namens.

Mir ist klar, dass das Tal als Linienfeature entlang von Wasserläufen meinem Wunsch nach einer flächenhaften Darstellung wiederspricht. Ich schrieb ja, dass ich keine wirklich befriedigende Lösung kenne. Ich lasse einfach meine Finger von Valley-Features, wenn mir welche über den Weg laufen.

Gruß Wolf

fkv · 2012-06-04 09:59:00

Netzwolf wrote:

Schau mal nach: bare_rock ist in die Diskussion gekommen, weil natural=rock für Einzelfelsen benutzt werden soll, und also nicht mehr Flächen genutzt werden soll.

Einzelfelsen heißt nicht Node. Genauso wie eine 2x2 m große Kapelle wahlweise als Node oder als Fläche gemappt werden kann, kann auch ein Einzelfelsen wahlweise als Node oder als Fläche gemappt werden. An einer Fläche lässt sich nicht automatisch erkennen, ob ein Einzelfelsen oder eine Oberfläche gemeint ist. Es gibt nur bestimmte Indizien, z.B. ohne zusätzliche Tags (z.B. name=*), ausgenommen source=*, sowie bei größeren Flächen ist wahrscheinlich die Oberfläche gemeint.

Weil ein Tal keine Linie ist, sondern ein Fläche.

Ansichtssache. Bzw. es hängt vom Tal ab: Ein Trogtal wie in Tirol, wo man eine halbe Stunde durch die Talebene geht um auf die andere Seite zu kommen, kann man als Fläche sehen. Ein Kerbtal jedoch nicht. In einem Kerbtal kann man den Wasserlauf nachziehen (sofern es einen gibt!). Ein Trogtal auf eine Linie zu reduzieren ist insofern problematisch, als die Talbeschriftung auf kleinen Kartenausschnitten irreführend wird (Beispiel: 3 km breites Tal, 1x1 km Kartenausschnitt, irgendwo rechts oben steht der Talname). Den Flussverlauf nachzuziehen macht es aber noch schlimmer, weil das den Eindruck vermittelt, das Tal sei nur im unmittelbaren Bereich des Flusses, die Mäander seien also in den Untergrund eingeschnitten.

Ich sehe 2 Möglichkeiten, um das Problem mit den Trogtälern zu lösen:
a) als Flächen erfassen
b) nur als Linie entlang der Talmitte, aber mit width=*

Und weil ich es für keine wirklich gute Idee habe, eine Linie zu malen, die willkürlich verläuft und nur dazu dient, dass da Buchstaben aufgereit werden sollen.

Gerade das ist für die Erstellung normaler Landkarten aber das Wesentliche.

Valley ist ein Linienfeature, dass sich über diverse Bachsegmente und auch über mehrere Bäche erstrecken kann. Also ein Paradebeispiel für ein Linienfeature, das durch eine Relation abgebildet wird.

Es gibt noch keinen passenden Relationstyp, aber ich würde das gut finden.

ich will ja gerade nicht vorgeben, wo die Buchstaben aufgereit werden. Sondern das Tal verläuft entlang der jeweils niedrigsten Stelle – meist eines Wasserlaufs. Und der Plazierungsalgorithmus sucht entlang dieser Linie geeignete Plätze für die Buchstaben des Namens.

Die Talbeschriftung soll aber nicht mäandrieren, wenn das Tal geradeaus geht und nur der Fluss mäandriert. Und was machst du bei einem Fluss, der sich in mehrere Arme aufteilt, die sich weiter abwärts wieder vereinen? Sind das dann mehrere Täler?

borisC · 2012-07-19 11:48:09

Hallo Freunde!

Ich hab ein bisschen ein Problem mit diesen Regions - oder sagen wir mal, Mapnik (und eventuell andere Renderer) haben es. Leider werden die Beschriftungen nicht mittig in das Polygon gesetzt, sondern auf die Randlinien, was z.B. dazu führt, dass der Inn nun mit Karwendel beschriftet wird. Das kann es doch nicht sein, oder?

Möglicherweise würde ein area=yes da helfen? Inhaltlich falsch wäre es ja nicht.

LG, Boris

fkv · 2012-07-19 12:03:58

Bei Mapnik nützt das nichts, siehe http://www.openstreetmap.org/browse/way/94453497.
Du kannst auf https://trac.openstreetmap.org/ einen Bugreport anlegen, der dann aber nicht bearbeitet wird.

Netzwolf · 2012-10-19 19:31:25

Nahmd,

Netzwolf wrote:

Leider sind die Ostalpen noch nicht fertig. Das wird aber noch. Die Arbeit ist relativ nervig, da ich immer wieder man nicht einfach Flüssen und Bächen folgen kann, sondern erst einmal die Grundlagen legen muss. Dazu kommt, dass die Namen aus der textuelle Beschreibung oft nicht mit denen aus der Karte übereinstimmen, was immer wieder mal längere Recherchen braucht. Langer Rede kurzer Sinn: ich brauchte da eine Pause.

[×] done.

Gruß Wolf

maxbe · 2012-10-20 03:00:57

Netzwolf wrote:

[×] done.

Wow. Ich hoffe, Du warst auch mal draussen letzten Sommer

Wenn ich mal wieder Zeit für Bastelarbeiten hab, schau ich mal wie man die Hierarchie hinbekommt (aus der Rolle in dieser Ostalpenrelation oder eigentlich lieber aus der Lage der Flächen).
Viele Gebirge sind ja Teile grösserer Gebirge und jetzt wo so viele eingetragen sind, fällt das auf. Es ist zwar interessant, die Einteilung z.B. des Kaisers auf der Karte zu sehen, aber irgendwie verwirrt das auch...

Grüße, Max

Netzwolf · 2012-10-20 09:50:44

Moins,

maxbe wrote:

Wow. Ich hoffe, Du warst auch mal draussen letzten Sommer

Weniger als geplant. Die erste Hälfte des August hab ich in der Klinik verbracht, die zweite hatte ich Outdoorverbot.

maxbe wrote:

Viele Gebirge sind ja Teile grösserer Gebirge und jetzt wo so viele eingetragen sind, fällt das auf. Es ist zwar interessant, die Einteilung z.B. des Kaisers auf der Karte zu sehen, aber irgendwie verwirrt das auch...

Von mir stammen die Unterteilung von Wetterstein/Mieminger, des Kaisers und der Steinberge sowie die Zusammenfassung der Hohen Tauern.
Die Zusammenfassungen der Dolomiten-Untergruppen und er Niederen Tauern ist der Original-Einteilung entnommen.

Wie man mit Untergruppen vernünftig umgeht, weiss ich nicht. Wenn die Eltern/Kind-Bereiche so deutlich unterschiedlich groß sind wie in den Dolomiten, kann man die Auswahl wohl automatisiert von der Zoomstufe abhängig machen. Wenn sie aber ungefähr gleich groß sind wie beim Kaiser, ist mir völlig unklar, wann/ob man die Gesamtgruppe oder die Untergruppen anzeigt.

Beim Wetterstein/Mieminger ist die Zusammenfassung ziemlicher Unfug und wohl rein pragmatisch, weil die Mieminger weder für eine Karte noch für einen Führer groß genug sind. Ähnliches gilt wohl auch für die Steinberge. Möglicherweise immer, wenn ein “und” im Namen vorkommt . Da kann man die Teile anzeigen und die Zusammenfassung ignorieren.

Gruß Wolf

PS:
1. Das Klinikum Traunstein ist sehr zu empfehlen.
2. Eine Neuroborreliose ist weniger zu empfehlen.

toc-rox · 2012-10-22 09:55:48

Netzwolf wrote:

2. Eine Neuroborreliose ist weniger zu empfehlen.

Off-Topic: Ich hoffe, du hast keine bleibenden Auswirkungen zurück behalten. Den "Gemeinen Holzbock" kann man m.E. auch als "natürlichen Feind" des Feld-, Wald- und Wiesenmappers bezeichnen. Da du dich vermutlich jetzt näher damit befaßt hast: Wie sieht die optimale Abwehrstrategie aus ?

Gruß Klaus

Lübeck · 2012-10-23 11:35:26

HI !

einige Fragen dazu...

* richtig verstanden: wird derzeit nur in der Karte freizeitkarte-osm.de angezeigt und dann auch im basecamp ?
* werden Buchten auch schon unterstützt ?
* gibt es eine verwertbare Quelle für die Begrenzung - z.b Neustädter Bucht [1], Lübecker Bucht [2]

Gruß Jan :-)

[1] http://de.wikipedia.org/wiki/Neust%C3%A4dter_Bucht
[2] http://de.wikipedia.org/wiki/L%C3%BCbecker_Bucht

chris66 · 2012-10-23 11:50:02

werden Buchten auch schon unterstützt ?

Lübecker Bucht ist als place=bay drin (bis V2 als natural=bay):
http://www.openstreetmap.org/browse/relation/1988915

maxbe · 2012-10-23 23:05:44

Lübeck wrote:

* richtig verstanden: wird derzeit nur in der Karte freizeitkarte-osm.de angezeigt und dann auch im basecamp ?

Ich hätte ne Karte, die das darstellt. Allerdings kommen in dem Gebiet, das mich interessiert keine größeren Buchten vor, sondern eher Gebirgszüge. Und das Problem der Hierarchie wird auf dieser Karte noch monatelang ungelöst bleiben...

Ich seh aber auch kein Problem, andere Landschaften ähnlich zu taggen. Diese Gebirge sind einfache Multipolygone, die Bäche und Flüsse als outer enthalten. Gelegentlich mal eine neue Linie, um Wasserscheiden zu überwinden. Hauptarbeit war vermutlich Recherche, nicht das taggen. Sollte bei Buchten auch nicht anders sein, deren Grenzen sind viel Küste und ein Strich draussen auf dem Wasser.

Grüße, Max

Last edited by maxbe (2012-10-23 23:08:31)

toc-rox · 2012-10-28 12:10:55

Lübeck wrote:

... einige Fragen dazu...
* richtig verstanden: wird derzeit nur in der Karte freizeitkarte-osm.de angezeigt und dann auch im basecamp ?
* werden Buchten auch schon unterstützt ?
* gibt es eine verwertbare Quelle für die Begrenzung - z.b Neustädter Bucht [1], Lübecker Bucht [2]
...

Also in der Freizeitkarte ist das Feature nicht drin.

Nach meinem Verständnis ist derzeit jede spezifische Region als "großes Polygon" abgebildet.
In Abhängigkeit von der Größe und Form des Polygons, müßte jetzt der Renderer daraus einen geeigneten Schriftzug ableiten.
Natürlich abhängig vom Zoomlevel ...
... die Alpen als Ganzes, Unterteilung der Alpen (z.B. Dreiteilung), Unterteilung in Regionen (z.B. 36 Regionen), Unterteilung in Gebirgszüge, usw.
Oops, und schon geht's los ... gibt es da doch verschiedene Modelle.

Der Einzigste der sich da bislang an der Darstellung versucht hat ist "maxbe".
Mit den Möglichkeiten der Garminkarten ist das m.E. nicht machbar.
Hier wäre eine stark vereinfachte Variante erforderlich ... vielleicht reichen ja einfache, von Hand platzierte POIs (Nodes).
Berücksichtigen müßte man da natürlich irgendwie die Hierarchiestufen ...

Gruß Klaus

gis_jam · 2012-10-29 09:51:09

Netzwolf wrote:

[×] done.

Die Relation wurde inzwischen gelöscht. Was steckt dahinter?

chris66 · 2012-10-29 11:16:46

Das müsstest Du den User fragen. So große Relationen können schonmal versehentlich beschädigt werden.
Als Editor kam JOSM zum Einsatz.

aighes · 2012-10-29 12:21:07

Ist erstmal wiederhergestellt. Ich denke, dass collection hier nicht gerade gut gewählt ist. Besser wäre es doch das ganze als boundary-Relation zu erfassen und dann die subarea-Role zu verwenden.

http://wiki.openstreetmap.org/wiki/Relation:boundary

OpenStreetMap Forum

#51 2012-06-03 18:45:00

Re: Bezeichnung von Gebirgszügen

#52 2012-06-03 22:21:16

Re: Bezeichnung von Gebirgszügen

#53 2012-06-03 22:21:44

Re: Bezeichnung von Gebirgszügen

#54 2012-06-03 23:37:25

Re: Bezeichnung von Gebirgszügen

#55 2012-06-04 00:13:19

Re: Bezeichnung von Gebirgszügen

#56 2012-06-04 09:59:00

Re: Bezeichnung von Gebirgszügen

#57 2012-07-19 11:48:09

Re: Bezeichnung von Gebirgszügen

#58 2012-07-19 12:03:58

Re: Bezeichnung von Gebirgszügen

#59 2012-10-19 19:31:25

Re: Bezeichnung von Gebirgszügen

#60 2012-10-20 03:00:57

Re: Bezeichnung von Gebirgszügen

#61 2012-10-20 09:50:44

Re: Bezeichnung von Gebirgszügen

#62 2012-10-22 09:55:48

Re: Bezeichnung von Gebirgszügen

#63 2012-10-23 11:35:26

Re: Bezeichnung von Gebirgszügen

#64 2012-10-23 11:50:02

Re: Bezeichnung von Gebirgszügen

#65 2012-10-23 23:05:44

Re: Bezeichnung von Gebirgszügen

#66 2012-10-28 12:10:55

Re: Bezeichnung von Gebirgszügen

#67 2012-10-29 09:51:09

Re: Bezeichnung von Gebirgszügen

#68 2012-10-29 11:16:46

Re: Bezeichnung von Gebirgszügen

#69 2012-10-29 12:21:07

Re: Bezeichnung von Gebirgszügen

Board footer