“Unscharf abgegrenzte Gebiete” lassen sich ihrem Wesen nach kaum “willkürfrei” taggen, was ja gleich wieder einige fordern …
Worum geht’s denn überhaupt? Dass über den Gebirgskämmen die gar nicht wissen wozu sie gehören “TAUNUS” oder “SCHWARZWALD” steht wie in alten Topographischen oder Generalkarten? (allein die edit wars die um Groß- und Kleinschreibung entstehen werden… )
Das haben früher die Kartographen per Hand eingetragen (völiig “willkürlich”)
Ihr erwartet dafür einen Algorythmus der das noch perfekt generalisiert, d.h. für variable Vergrößerungsstufen und Kartenausschnitte?
Aber sonst geht’s Euch noch gut?
Die Generalisierung ist das verstossene Kind (fast) aller Renderer-Entwickler.
(Ich habe das mal mit Waldpolygonen versucht, was beim Taunus ginge, dessen Höhen komplett waldbedeckt sind. Aber das Attribut “name” wird nicht entsprechend der Größe des Polygons mitskaliert. Und sobald es mehrere “outer” Elemente gibt wird jedes einzelne mit dem Namen angezeigt, was auch nicht wirklich elegant ist…)
Naja aber ich würde jetzt sagen, man setzt einfach die nächst höhere Ebene aus der eins niederigeren Ebene zusammen. Also nicht wie bei den Grenzen, sondern wirklich die Relations in eine übergeordnete Relation. Dann müsste es theoretisch gehen, wird aber wahrscheinlich eher hässlich, wenn man mehrere ineinander verschachtelte Relations hat.
Das hört sich doch schon einmal gut an. Die Frage wäre jetzt noch, wie man die Grenzen taggt, die meinetwegen von einem Bachlauf zum anderen Bachlauf über ein Pass führen.
Die Einteilung finde ich an sich in Ordnung, ich würde aber noch teilweise andere Ebenen hinzunehmen. Zzum Beispiel würde ich einen Berg mit seinen Nebengipfeln in eine extra Relation packen. So würde verhindert werden, dass ein unbedeutender Nebengipfel den eigentlichen Hauptgipfel verdrängt. Deswegen würde ich z.B. auch die Unterkategorien bei mountain_range wegwerfen, da man nicht genau sagen, kann wann ein massif, mountain_range, oder mountain vorliegt.
JA.
Und es ist auch möglich, wenn man eine Preprocessor schreiben würde, der auf die von Mapnik verwendete Postgis-Datenbank zugreift und dann mit den Mitteln von Postgis die Daten manipuliert, ist es in 99% der Fälle möglich das zu erreichen. Man könnte damit z.B. die Icons für Gebirgspässe richtig drehen, oder Flächen wie zum Beispiel Norwegen, enlang des mittleren Weges vom Süden bis zum Nordkap beschriften (geschwungener Schriftzug). Von der Zoomabhängigkeit habe ich ja schon gesprochen. Ob es mit den Kartenausschnitten klappt, kann ich nicht sagen, dafür habe ich von Mapnik zu wenig Ahnung.
Den Aufwand könnte man logischerweise nicht für die Hauptkarte Mapnik verwenden, aber eine Spezialkarte könnte es wirklich ausreizen.
Wenn ich so sehe, was für ein Wind um ein IMHO einfaches Ansinnen gemacht wird.
Lassen wir mal die erwähnten Proposals außen vor.
Ich wieder hole mich: ein grob strukturierter Rahmen à la boundray=protected_area, nicht sichtbar in der Karte, als Maßgabe für die Namensanzeige (siehe Posting #2 von fkv) .
Das kann im Prinzip ein einfache geometrische Figur (Rechteck , Oval) sein.
Ich hab mal beim Anlegen eines neuen Waldpolygons nicht aufgepasst und ein “name” statt ein “note” vergeben. Und dann gestaunt, als ich das Ergebnis von Mapnik gerendert sah
Mach es doch einfach wie da beschrieben. Es wird dich keiner aufhalten. Meiner Meinung nach ist das aber halt noch nicht der Weiheit letzter Schluß. Deswegen könnte es doppelte Arbeit werden, aber das dürfte man ja mittlerweile gewohnt sein
Einfach als Strich ohne weitere Attribute. Einzige Semantik ist die Zugehörigkeit zu einer Gebietsgrenze.
Bei den Gipfel bist Du möglicherweise besser bedient, wenn Du mit Hilfe von Höhendaten in einer Region die Parameter Dominanz und Prominenz berechnest und dann an die Gipfel speicherst. Dann hat der Renderer alle zum Zeichnen nötigen Informationen an einer Stelle beisammen.
Sobald die API wieder offen ist, werde ich einmal die Grenzen der Berchtesgadener Alpen und der enthaltenen acht(?) Gebirgsstöcke eintragen. Dann haben wir Material zum Spielen.
Wie wahr, Taunide, wie wahr. Ich finde die Diskussion hier sehr spannend. Die Labelplatzierung muss für Karten wie die OpenStreetMap komplett automatisch ablaufen und das kann man leider nicht ändern. Schließlich müssen Objekte auf der Karte sich ändern können - schlichtweg wir basteln keine statische Karte. [1]
Die einfachste Möglichkeit ist es, Polygone mit name=* und weiteren beschreibenden Tags zu erstellen. Das macht es aber für den Normalmapper nicht gerade übersichtlicher im Editor. Irgendwie hätte ich gerne verschiedene Layer, ähnlich wie bei SVGs in Inkscape… Oo
Das Problem ist, dass osm2pgsql mp-Relationen zerlegt und z.B. aus Relation 62428 (München) zwei Polygone mit der id - 62428 macht: Ein grosses Polygon und ein kleines Polygon, das aus einer Exklave besteht (Way 48912051). Die Tags werden aus der Relation auf diese neu geschaffenen Flächen übernommen.
Vielleicht kann man das irgendwo ausschalten, vielleicht ist das in neueren Versionen anders, aber bei meiner älteren Version im Zustand “frisch aus der Schachtel” wird nicht verhindert, dass der Name dann an sämtlichen Flächen eines MP hängt, auch wenn man die outer ungetagt lässt. Der Renderer könnte es erkennen, wenn er über 2 Polygone mit gleicher (und negativer) ID stolpert, aber (a) kann man sich nicht um alle Sonderfälle kümmern und (b) wie bringt man ihm bei, wie dann zu verfahren ist?
@derstefan: ich warte ja auch ganz gespannt, wie Ihr es schafft, die freien Flächen für die Labels zu finden… Tut sich da was?
Ich hab nämlich gerade probiert, mal ein paar Gebirge zu beschriften. Irgendwie kollidieren die Buchstaben immer mit den Gipfeln und im Zweifel finde ich die wichtiger…
Dass die Schriften “wichtiges” auf der Karte nicht überdecken, ist ein bekanntes Problem bei der Generalisierung, und durch die Renderer zu lösen.
Die bekannteste Ausprägung dieses Problems ist: An welcher Stelle auf der Karte (links, rechts, oben, unten) soll der Name einer Großstadt angezeigt werden? Das wird in normalen Karten manuell bestimmt.
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
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.
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.
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.
)
Tut sich da was?