Danke für die Blumen, Herr Professor. 
BTW, mit outer-Elementen meinte ich nicht in sich geschlossene outer-Flächen in einer Relation (im Normalfall unnötig), sondern die outer-Ways der Relation. Da ist mir sowas noch nicht aufgefallen. Momentan aber nicht nachprüfbar, da der OSM-Server nicht mal das Lesen zuläßt.
Ich habe jetz noch einmal über die ganze Sache nachgedacht. Eine Sammlungsrelation ist IMO schlecht, da man diese immer kennen müsste, wenn man neue Objekte einträgt. Oder jemand ist ständig am nachtragen => also schlecht.
Wenn man orographische Grenzen hat, würde ich diese auf jeden Fall wieder verwenden um den Gebirsstock einzugrenzen. Der Rest muss dann halt mit einer Verbindungslinie zur nächsten Grenze verbunden werden. Dabei sollte man sich dann wahrscheinlich am besten an Höhendaten halten, also immer den Weg der niedrigsten Höhe wählen. Die SRTM Daten sind jetzt nicht so gut, aber für diesen Fall ausreichend. Um ein komplettes Gebirge zu taggen ist dann wahrscheinlich ähnlich wie bei den Landesgrenzen zu verfahren, indem man die Grenzen mehrfach nutzt. Dürfte zwar aufwendig sein, aber diese Grenzen ändern sich ja zum Glück nicht so schnell.
Bei den Gipfeln würde ich die Neben- und Hauptgipfel schon zusammenfassen, da es regional sehr unterschiedlich sein kann, wann ein Berg ein Hauptgipfel oder Nebengipfel ist. Es gibt meiner Meinung nach genug Berge, wo sonst noch untergeordnete Nebengipfel mitgerendert würden (Grandes Jorasses oder Monte Rosa). Außerdem müsste man zusätzlich OSM und Höhendaten verbinden und diese zusammen analysieren, was ein deutlicher Aufwand wäre.
Für die anderen Regionen (Deutsche Bucht, Norddeutsches Tiefland, Sahara etc.) sollte man wahrscheinlich soweit es geht auf bisherige Landschaftsdaten zurück greifen (Küstenlinien, Bachverläufe etc.) und den Rest mit einem möglichst nachvollziehbarem Verlauf als Grenzlinie darstellen (das läge jetzt in der Hand des Mappers, wenn man damit nicht einverstanden ist, könnte man es ja mit demjenigen diskutieren). Ob da jetzt noch ein fuzzy Tag ran sollte, keine Ahnung. Im Meer wird der Tag wahrscheinlich schwer zu definieren sein, wobei wahrscheinlich bathymetrischen Daten nützlich sein könnten.
Das sollte so ein Fall sein:
Der Dün(wald) ist ein Multipolygon mit einigen outer-ways, die für separate Waldstücke stehen. landuse=forest und name=Dün hängen am MP, nicht an den Wegen.
Alle outer-ways erhalten auf der Mapnik-Karte den Schriftzug Dün: http://www.openstreetmap.org/?lat=51.33163&lon=10.48352&zoom=15&layers=M
Gleiches gilt für das Helbetal: http://www.openstreetmap.org/?lat=51.3584&lon=10.642&zoom=14&layers=M
Soweit klar.
Wenn man von mehreren outer-Elemente spricht, kann man nicht unbedingt davon ausgehen, daß damit separate outer gemeint sind und nicht Teil-ways des outer. Insofern ziehe ich mir den Schuh nicht an.
Wenn die separaten Waldstücke nunmal dazu gehören, sollten diese auch namentlich erkennbar sein (ob nun elegant oder nicht), wenn nicht zusammenghörig sollten die separaten outer getrennt gemappt und nicht mit in die Relation gepackt werden.
Evtl. könnte man die zusammengehörigen Waldstücke auch per site-Relation erfassen, dann wäre der Name nur einmal zu sehen und man kann ihn sogar plazieren.
Fehlt da absichtlich der Name (Berchtesgadener Alpen) an der Sammelrelation ?
Die Child-Relas müssten m.E. type=multipolygon und place=region haben.
Da stimme ich Chris erstmal zu. Was mir noch fehlt: Wie erkenne ich, dass Göllstock ein Teil von den Berchtesgadener Alpen ist? Hier fehlt dann noch ein Tagg unterhalb von region=mountain_area oder eine Abstufung von mountain_area.
Nahmd,
Ja. Die ist nur Arbeitsprovisorium, um die ganzen Relationen zu finden.
Ändert das einfach.
Ich hab erst mal Bastelmaterial bereitgestellt und mir noch keinen Kopf um das Tagging gemacht.
Ja. All das ist zu überlegen / diskutieren.
Wichtig ist auch, was maxbe davon hält, weil ich davon ausgehe (hoffe :)), dass er das als erster rendert.
Gruß Wolf
Puh…! 
Ich bemühe mich, aber bis zur odbl importiere ich keine diffs, dann kommt ein neuer Import und danach muss ich sehn, wies mit Zeit aussieht…
Das Problem beim Rendern ist, dass mein Renderer nicht auf Namen mit Leerzeichen vorbereitet ist. Dass sich in dem Bild da unten zwei Ortsnamen nicht überdecken, wird verhindert. Entweder durch rumwackeln bis es passt, oder durch weglassen einer Beschriftung. Dass sich aber die Beschriftung “Hoher Fricken” elegant in eine Leerstelle von “Estergebirge” schiebt, kann man kaum erreichen (Vorschläge für UMN-Mapserver werden gern angenommen). Und das wird erforderlich sein, weil auf allen Papierkarten ist das auch so, teils sind da 10 Leerzeichen zwischen den Buchstaben eines Namens, so dass der Namenszug fast nicht mehr lesbar ist.
Das nächste Problem wäre die Skalierung (dürfte machbar sein) und die passende Biegung in sowas Ähnliches wie die Mittellinie eines Gebietes (da hab ich noch gar keine Ahnung).
Das Tagging ist mir völlig egal. Irgendwas flächiges halt. Und ich würde keine grosse Hierarchie einbauen, sonst haben wir schnell Verwirrung ob Gebirgsstock “A” ein “Gebirge 5. Ordnung” oder als “Berg 6. Ranges” ein Untergebiet von Gebirge B ist. Das kann ein Renderer auch gut nach Fläche entscheiden oder einfach schauen, ob der Namenszug reinpasst.
Schlimm ist auch, dass die Gebirgsgruppen in den Alpen immer so lange Namen haben…
Aber mal sehn…
viele Grüße, Max
Edit: Bild ausgewechselt, weil ich das Estergebirge zu gross gemalt hab.
Also ich hätte dazu eine Idee, die aber aufwendig ist. Um einen Mittellinie zu bestimmen, musst du das Voronoi-Diagramm deines Poygons bestimmen. Für Postgis sollen dafür im Netz Codeschnipsel herumfliegen. Dabei sollte man aber wahrscheinlich am besten das Polygon vorher vereinfachen um Rechenzeit zu sparen. Die Mittellinie des Renderings wäre dann die längste Strecke, die sich aus den verbundenen Ecken der Polygone ermitteln lässt.
Das ganze ließe sich wahrscheinlich mit einem Preprocessor lösen, also nach dem Import in die Datenbank und vorm Rendering. Dieser müsste aber möglichst intelligent sein. Wenn man diffs einspielt will man ja nicht für alle Polygone gleich die Mittellinie neu berechnen, sondern nur für die die sich geändert haben.
Sehe ich genauso. Die Frage wäre halt, wie mit Haupt- und Nebengipfeln zu verfahren wäre, wenn keine passenden geographischen Grenzen sichtbar sind. Aber das kann man ja auch noch später klären.
Ansonsten sehr cooles Ergebnis.
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 ).
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
