Re: [Talk-de] Küstenlinien-Generalisierung
Hi, On 01/04/2013 12:11 AM, Christoph Hormann wrote: ich habe in der letzten Zeit an einem Verfahren gearbeitet, für eine gut lesbare Darstellung bei niedrigen Vergrößerungen eine Generalisierung der Openstreetmap Küstenlinien-Daten zu produzieren, und zwar in einem automatischen Prozess und jeweils individuell angepasst für jede Zoom-Stufe. Interessant! Wie rechenintensiv ist denn dieser Prozess - koennte man damit problemlos jeden Tag fuer jede Zoomstufe weltweit alle Kuestenlinien ausrechnen? Zum Einen: Für die, die am Karten-Rendering arbeiten der Hinweis, dass so was existiert. Was heisst denn genau dass so was existiert? Wirst Du das regelmaessig anbieten oder Deinen Code veroeffentlichen? Auf [3] kann man recht schön einige durch ein ungünstiges taggen von Flüssen und Kanälen als coastline verursachte Probleme sehen (z.B. beim Suez-Kanal). Hamburg/Bremen sehen auch etwas komisch aus, aber gibt es hier wirklich eine Patentloesung - was waere denn das guenstige Tagging, insbesondere im Anblick der Tatsache, dass wir nicht fuer unterschiedliche Zoomlevel unterschiedlich taggen? Oder muesste man sowas einfuehren? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien-Generalisierung
On Wednesday 09 January 2013, Frederik Ramm wrote: Interessant! Wie rechenintensiv ist denn dieser Prozess - koennte man damit problemlos jeden Tag fuer jede Zoomstufe weltweit alle Kuestenlinien ausrechnen? 'jede' Zoomstufe ist ja ein etwas dehnbarer Begriff... :-) Ich hab das von Stufe 8 abwärts gemacht und da kommt ein Tag etwa hin (ich habs nicht gestoppt und auch zwischendrin noch etwas optimiert). Wie das skaliert hab ich noch nicht genau ermittelt, aber zoom=n+1 dauert irgendwo zwischen zweimal und viermal so lange wie zoom=n. Man muss dazu sagen, dass bei den höheren Zoomstufen die Generalisierung auch nicht so wichtig ist. Ich denke spätestens ab 12 ist es fast überall nicht mehr nötig zu verdrängen und zu vereinfachen - man müsste dann eher die künstlichen Ecken in der Linie über splines glätten, dafür fehlt dann aber die Information, welche Ecken echt und welche nur Artefakte sind. Was heisst denn genau dass so was existiert? Wirst Du das regelmaessig anbieten oder Deinen Code veroeffentlichen? Falls da ein Interesse besteht, kann ich das für alle unteren Zoomstufen zur Verfügung stellen und auch regelmäßig aktualisieren. Das Programm als Open Source zu veröffentlichen hab ich bereits ins Auge gefasst, ich möchte allerdings zunächst einige noch bestehende Fehler (inbesondere das mit den Inseln) korrigieren. Hamburg/Bremen sehen auch etwas komisch aus, aber gibt es hier wirklich eine Patentloesung - was waere denn das guenstige Tagging, insbesondere im Anblick der Tatsache, dass wir nicht fuer unterschiedliche Zoomlevel unterschiedlich taggen? Oder muesste man sowas einfuehren? Eine einfache Trichtermündung wie bei der Elbe ist eigentlich kein großes Problem, entscheidend für die Generalisierung ist, dass die Ufer spätestens ab der ersten Engstelle nicht mehr Küstenlinie sind, denn sonst kann das in ungünstigen Fällen dazu führen, dass ein 'See' abgetrennt wird (das passiert bei der Weser). Bei der Elbe wäre das schon auf Höhe Brunsbüttel, bei der Weser auf Höhe Bremerhaven. Letztendlich müsste das aber natürlich mit einer passenden Generalisierung der Flüsse kombiniert werden. Als Grundsatz für das Mapping würde ich sagen: man sollte vom Meer aus gesehen ab der ersten Stelle, an der man eindeutig eine Grenze ziehen kann die 'coastline' beenden und den 'river' beginnen. Und für eine spätere Generalisierung der Flüsse sollte deren Mittellinie am besten ein Stück (~eine Flussbreite) ins Meer hineinragen. Schwieriger sind eigentlich Fälle wie das IJsselmeer - also großräumig künstlich gestaltete Küstenabschnitte. Ich denke, dass vielleicht ein Zusatztag für künstliche Küstenabschnitte (Dämme, Häfen, etc.) günstig sein könnte. So ein Tag dann tatsächlich angemessen zu berücksichtigen ist aber auch nicht trivial. Grüße, -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien-Generalisierung
Christoph Hormann chris_horm...@gmx.de wrote: ich habe in der letzten Zeit an einem Verfahren gearbeitet, für eine gut lesbare Darstellung bei niedrigen Vergrößerungen eine Generalisierung der Openstreetmap Küstenlinien-Daten zu produzieren, und zwar in einem automatischen Prozess und jeweils individuell angepasst für jede Zoom-Stufe. Inwiefern ist dieses Programm ein Ersatz oder eine Komplettierung des coastline-tools von Jochen Topf? Ich habe eigentlich die Erfahrung gemacht, dass es relativ unproblematisch funktioniert auch auf kleinen Zoomleveln mit den hochaufgelösten Küstenlinien zu arbeiten, das verbraucht IMO keine relvante Rechenzeit. Ich verwende beim deutschen Stil für alle Zoomlevel die gesplitteten land-polygons von Jochen. Gruss Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien-Generalisierung
On Wednesday 09 January 2013, Sven Geggus wrote: Inwiefern ist dieses Programm ein Ersatz oder eine Komplettierung des coastline-tools von Jochen Topf? Ich habe eigentlich die Erfahrung gemacht, dass es relativ unproblematisch funktioniert auch auf kleinen Zoomleveln mit den hochaufgelösten Küstenlinien zu arbeiten, das verbraucht IMO keine relvante Rechenzeit. Hallo Sven, die Rechenzeit für das Rendern ist kein entscheidendes Argument, aber die Küstenlinien mit allen Details bei niedigen Zoomstufen zu verwenden führt zu: Erstens: Artefakten, d.h. manches feine Detail, was man dann in der Karte sieht ist nicht wirklich eine in den Daten vorhandene Form, sondern nur ein Artefakt. Wenn Du beispielsweise auf [1] die Schären vor Turku anschaust ist das ein einziges Rauschen ohne erkennbare Strukturen. Wenn Du dann umschaltest auf [2] sieht das klarer aus, aber hier ist die Landschaft mit ihren vielen keinen Inseln als solche kaum noch zu erkennen (die dort verwendete NaturalEarth Küstenlinie verschluckt nämlich mehr Inseln, als sie sollte). Meine Variante im Vergleich dazu in [3]. Zweitens: Manche wichtige Strukturen (insbesondere Meerengen und Landbrücken) werden nicht dargestellt, da zu klein, obwohl sie von der Bedeutung her dargestellt werden müssten. Das was ich hier zeige ist ein Bearbeitungsschritt für die Daten nach der Extraktion mit osmcoastline und vor dem Rendern der Karte für eine bessere Darstellungsqualität bei niedrigen Zoomstufen. [1] http://tools.geofabrik.de/map/?type=Geofabrik_Germanlon=19.3lat=60.3zoom=6 [2] http://tools.geofabrik.de/map/?type=Geofabrik_Topolon=19.3lat=60.3zoom=6 [3] http://www.imagico.de/map/map.php?zoom=6lon=19.3lat=60.3 -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien-Generalisierung
Am 09.01.2013 um 16:40 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Ich habe eigentlich die Erfahrung gemacht, dass es relativ unproblematisch funktioniert auch auf kleinen Zoomleveln mit den hochaufgelösten Küstenlinien zu arbeiten, das verbraucht IMO keine relvante Rechenzeit. ja, es geht nicht um die Rechenzeit sondern um die Darstellungsqualität. Wenn Du z.B. hier einen ähnlichen Fall ansiehst: http://www.openstreetmap.org/?lat=40.7508lon=17.7167zoom=12layers=M (ist zwar admin Grenze und nicht coastline, aber das Thema ist dasselbe) wirst Du merken, dass je nach Strichstärke und verwendetem Linienverbindungstyp (ob Ecken eckig oder rund werden sollen und bei welchem Winkel) extrem störende Artefakte entstehen können (spitze Ecken, die rel. groß sind und weit über das eigentliche Gebiet hinausragen bei dicken Strichstärken). Auch wird es einigermaßen zufällig, wie eine sehr detaillierte Linie aussieht, wenn man sie auf wenigen Pixeln rendert (ggf. wird das dann ein dicker Brei, oder Inseln werden zugekleistert von der Coastline). Im Hauptstil von Mapnik wird das geschickt umschifft, indem die Küstenlinie überhaupt nicht gerändert wird, aber für manche Kartenstile will man das halt machen, z.B. bei den üblichen Physischen Karten: http://www.mygeo.info/landkarten/amerika/mittelamerika_cia_2007.jpg (Im vg. Beispiel von der CIA kann man auch gleich ein paar Probleme sehen, wie z.B. Land, das meerseitig unter der vereinfachten Küstenlinie hervorlugt (Norden von Kuba), oder Brei wenn es im Küstenbereich eng wird (Orinoco Mündung in Venezuela)). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Küstenlinien-Generalisierung
Hallo, ich habe in der letzten Zeit an einem Verfahren gearbeitet, für eine gut lesbare Darstellung bei niedrigen Vergrößerungen eine Generalisierung der Openstreetmap Küstenlinien-Daten zu produzieren, und zwar in einem automatischen Prozess und jeweils individuell angepasst für jede Zoom-Stufe. Eine etwas längere Erklärung zum Hintergrund findet sich in [1]. Ich wollte das hier mal kurz vorstellen und zwar unter zwei Gesichtspunkten: Zum Einen: Für die, die am Karten-Rendering arbeiten der Hinweis, dass so was existiert. Es werden ja gelegentlich (so zum Beispiel beim Geofabrik 'topo' Stil) die 'natural earth' Küstenliniendaten bei den niedrigen Vergrößerungen verwendet, die haben aber den Nachteil, dass sie nur in drei Stufen erhältlich sind, nicht für die bei slippy-maps verwendete Kartenprojektion erstellt wurden und eine andere Datenbasis haben, also nicht optimal zu den OSM-Daten passen. Derzeit habe ich nur eine Detailstufe bereitgestellt [2], kann aber weitere bei Bedarf auch zur Verfügung stellen. Das Verfahren ist noch nicht ganz ausgereift, zum Beispiel werden Inseln derzeit nicht immer richtig nach der Größe eliminiert. Zum Anderen: Ich möchte etwas dafür werben, beim Mapping und bei der Gestaltung von Mapping-Richtlinien die Notwendigkeit der Generalisierung im Auge zu haben. Bei der Küstenlinie betrifft das vor allem die klare Trennung zwischen Küstenlinien auf der einen Seite und Flussufern und Kanälen auf der anderen Seite. Auf [3] kann man recht schön einige durch ein ungünstiges taggen von Flüssen und Kanälen als coastline verursachte Probleme sehen (z.B. beim Suez-Kanal). Grüße, Christoph [1] http://www.imagico.de/map/coastline_de.php [2] http://www.imagico.de/map/coastline_de.php#data [3] http://www.imagico.de/map/map_de.php -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
