Bezeichnung von Gebirgszügen

Wow, da kann wohl keiner mehr sagen, OSM Karten müssten dröge und langweilig aussehen!

Und wie mappt man das nun?

Nur zur Klarstellung: Der Schriftzug fürs Estergebirge ist handgetippt, handgebogen und handverschoben mit Inkscape…

Gerendert wird da noch nichts, ich wollte nur ein Beispiel für das Plazieren von Beschriftungen in die Leerzeichen einer anderen Beschriftung zeigen. Ich kenne keinen Renderer, das das maschinell erledigen kann.

Möglicherweise kann man den Schriftzug auch halb transparent, bzw. zwischen Karte und restlicher Beschriftung hellgrau drucken.
BingMaps verwendet das auch bei dem Germany-Schriftzug:
http://tools.geofabrik.de/mc/?mt0=bingmap&mt1=mapnik&lon=10.94925&lat=51.37758&zoom=7
Wird aber sicher nicht so klasse aussehen, wie das handgemachte Beispiel!

Wahrscheinlich zu einfach gedacht: Gingen nicht eine oder mehrere Linien die den Gebirgsverlauf darstellen?
Transparent gezeichnet, mit großer Schrift versehen, dann hätten auch die Garminkarten etwas davon.

Gruß Klaus

Nahmd,

Was ich gerade einzeichne, sind die nicht die Kettenverläufe, sondern die (relativ) großen Gebiete aus der Alpeneinteilung der Alpenvereine. Die Gebiete sind mehr oder weniger rund.

Da hat man (zu?) viele Freiheitsgrade für eine Beschriftungslinie.

Aber nur in großen Maßstäben. Einzelne Buchstaben eines Namens sind eher weniger hilfreich.

Gruß Wolf

Bing plaziert das auch recht geschickt. Eine Regel verbietet z.B. Überschneidung von Hauptstadt und Land (gelingt fast immer, nur in Kroatien im Zoomlevel 4 nicht) und ansonsten sucht sich Bing eine freie Fläche (geht auch ziemlich oft, aber in Italien geht es schief im Z=5).

Vor allem haben die riesige Schriften für die Staatennamen, dann ist es egal, ob da noch ein paar Städte über dem Namen stehen. Sowas funktioniert gut bei Deutschland (kurzer Name, grosses Land, paar wichtige Städte), Bosnien und Herzegovina (langer Name aber grosses Land und wenige wichtige Städte, 5 Stück im Z=5). Ich glaube aber, Gebirge sind eher sowas wie Andorra (kleines Land, eine Stadt; das führt zu unleserlich kleiner Beschriftung).

Die Idee könnte aber schon ein guter Ansatz sein, bis jemand einen Algorithmus zum Finden freier Flächen findet. Man nimmt halt an einem Glückspiel teilnehmen, ob gerade wichtige Buchstaben von anderen Namen überdeckt werden. Oft wird es passen, aber dem Leser bleiben immer noch ein paar Buchstaben zu raten ("Gebirge mit “…terstein” und eines mit “Karwe.d…”).

(Beschriftung von Hand plaziert und absichtlich ein “We”, das “n” und ein “el” versteckt)

Ich denke, dass die Garminkarten besser mit Polygonen fahren. Dann kann man sich die Info überall mit einem “Klick” in die Landschaft holen. Bei einer Linie hat man das Problem, dass die Linie dann auch außerhalb des Bereichs sein kann und dann sieht man von dem Namen nichts und kann auch keine Info “erklicken”. Hinzu kommt, dass ein Gebirge nunmal keine Linie ist/sein muss. Nimm bspw. den Harz, der eher kreisförmig ist. Wie soll man da eine Linie zeichnen? Ost-West oder Nord-Süd oder sonstwie?

Nahmd,

Womit würde der gefüttert? Gibt es eine Stelle im Renderalgorithmus, an der die (kleinen, normalen) Texte bereits alle plaziert sind und damit die verbotenen Flächen bekannt?

Gruß Wolf

Jep, Beschriftungen untereinander haben bei mapserver klare Regeln: Texte höchster Priorität werden in Reihenfolge des Eingangs gerendert. Wenn die alle auf ihrem Platz sitzen, werden die Lücken mit den Texten der zweithöchsten Priorität gefüllt. Dabei werden die der höchsten nicht mehr angefasst. Es gibt 10 Abstufungen der Priorität.

Was ich nicht habe ist ein Algorithmus mit Leerzeichenberücksichtigung für das Estergebirge da oben.

Und ich habe keinen, der Texte vergrößern kann oder wenigstens auf einer Fläche schieben und drehen kann bis sie passen (damit wäre das Wettersteinproblem da oben vermutlich auch in 90% der Fälle gelöst und der Rest teilt das Schicksal Andorras auf der Bing-Karte :wink: ).
Alles was mapserver kann ist “Probier 8 Stellen um einen Punkt, ob du den Namen unterkriegst” und “Schieb die Beschriftung so lange auf dieser Linie entlang, bis der Straßenname reinpasst”.

Grüße, Max

Ich kann mir eigentlich keine Gelegenheit vorstellen, wo ein Gebirge für die Navigation sinnvoll ist. Und so viel Platz ist ja nicht auf einem Navi, dass man damit verschwenderisch umgehen kann…

Ist natürlich sehr subjektiv, aber für mich sind Namen von Gebirgen eher nützlich, wenn man über eine Gegend spricht, als wenn man darin rumläuft. Also eher für Beschreibungen wie “Der Berg befindet sich im Westen der Sowiesokette und bietet einen schönen Ausblick auf das Dingsgebirge und das Irgendwietal”, oder “Das Irgendwietal trennt die Sowiesogruppe vom Rest des Dingsgebirges ab”.

Zur Orientierung “nach dem Dingsgebirge links halten” würde ich das eher nicht verwenden. Vielleicht widerspricht mir da aber ein Mountainbiker, die denken ja in größeren Dimensionen und könnten auch mal ein oder zwei kleine Gebirge schnell umrunden…

Grüße, Max

Das macht für die Navigation auch keinen Sinn, sehr wohl aber für die Übersichtskarte - insbesondere in Garmin-BaseCamp.

Gruß Klaus

Die Karte sieht schonmal ziemlich gut aus!
Vielleicht kann man die Gebirgenamen besser lesen, wenn man die weiße Umrandung der Gipfel und Orte unter die Gebirge schiebt!?
(Von unten nach oben: Karte, weiße Umrandung, Gebirgenamen, schwarze Schrift)

Mal ein Zwischenbericht: Der Herr Netzwolf hat inzwischen ganz fleissig die Alpen geteilt und geordnet und Bastelmaterial für Rendertests beschafft… :wink:

Für Übersichtskarten o.ä. halte ich die Gebirge für brauchbar. Sobald man allerdings so weit reinzoomt, dass man sich für einzelne Berge interessiert, stören die Buchstaben nur, finde ich.

Wer selber schauen will: Ich hab hier einen Layer mit “Gebirgsnamen”, allerdings nur über den Rest der Karte drübergelegt, ohne Verdrängung anderer Beschriftungen. Mit den kleinflächigen Gebieten in den Berchtesgadenern kämpfe ich noch und die grossen Gebirge, die andere Gebirge enthalten (Tauern z.B.) hab ich auch erst mal weggelassen…

Grüße, Max

Edit: Der Overlay mit den Namen ist weg, ich hab die Gebirge mit in die Karte genommen und mich an MasiMasters Vorschlag mit grossen Buchstaben unter dem Rest der Beschriftung gehalten. Mal sehn, was sich da sonst noch machen lässt, so ganz gefällt mir die Darstellung noch nicht…

Nahmd,

Ich vervollständige die Ostalpen noch, die Westalpen aber überlasse ich jemand anderem. Denn das ist eine Arbeit für Bekloppte. :confused:

Ich sehe als weitere Nutzungsmöglichkeit eine Gliederung beim Suchen: “Predigtstuhl” ist als Flurbezeichnung ähnlich spezifisch wie “Hauptstraße” :slight_smile:
Außerdem sollten sich Queries “Hütten im Karwendel”, “Gipfel im Wetterstein” jetzt automatisch beantworten lassen?

Klasse :slight_smile:

Sobald ich durch bin, kannst Du der Wikipedia einen Ersatz für das grausliche Datei:Ostalpeneinteilung Vierteilung.PNG zukommen lassen.

Die geschachtelten Unterteilungen habe ich zwar eingegeben, ich habe aber keine Idee, wie man entscheidet, welche hierarchische Ebene man darstellen soll.

Bei “Wetterstein und Mieminger Kette” und “Loferer und Leoganger Steinberge” habe ich den Verdacht, dass die nur zusammengefasst sind, weil einer der Bestandteile zu wenig Material für eine Karte und/oder einen Führer abwirft. Deshalb habe ich die jeweils auch einzeln erfasst.

Was ganz anderes (aber auch alpin): hat sich hier wer schon Gedanken zu diesen Poposals gemacht?
http://wiki.openstreetmap.org/wiki/Proposed_features/ridge
http://wiki.openstreetmap.org/wiki/Proposed_features/Couloir
http://wiki.openstreetmap.org/wiki/Proposed_features/Arete
Lohnt das einen Thread hier?

Gruß Wolf

Bevor die Gebirge ohne mapping bleiben, bin ich persönlich für eine viel einfachere Lösung - weder Polygon noch Relation, einfach ein way, der über den höchsten Gebirgskamm gezogen wird.
In diesem Sinne habe ich auf der Diskussionsseite (hier: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Mountains#Mountain_Range_-_Gebirge)) ein Beispiel eingetragen. Die Kollegen, die sich hier für Polygone einsetzen, lade ich ein, dort die Diskussion zu ergänzen, damit das Proposal aus dem Dornröschenschaf erwacht und vorankommt.
Grüsse aus den Anden,
Federico

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:Proposed_features/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/Proposed_features/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

Nahmd,

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.

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 :wink:

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

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/Thesis.tech.IMMD.IMMD9.automa_48/

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

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

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

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

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.

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

Nahmd,

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.

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.

Mist! Da muss ich jetzt aber ne Menge umtaggen.

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.

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

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).

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