Ich habe zu wenig Ahnung von Maperative, aber der entscheidende Unterschied zu dem unteren Teil des Waldes scheint zu sein, dass es sich oben um ein Multipolygon mit 3 outer und sehr vielen Inner handelt.
Der untere Teil Wald ist noch nach altem Schema getagt. Dort hat der Way als Outer die tags vom landuse. Das Mulitpolygon ist frei von weiteren Informationen. Diese Art des taggings ist meiner Meinung nach nicht mehr stand der Zeit.
…mmh wer lesen kann ist klar im Vorteil. Vielen Dank! Verstehe aber das nicht. Ich habe ältere Karten von da und da ist der Wald vorhanden. Jetzt mußte ich zuerst die die neue Version 0.5E runterladen. Ich hatte die bestimmt noch nie im Einsatz…
Liest sich interessant. Aber diese Experimente muß ich auf ein anderes Mal verschieben, wenn ich dafür viel Zeit habe.
Mein erstes GPS war/ist ein PDA von 02 Betriebssystem winmobile. Ist schon etwas älter. Könnte sein, daß ich das seit 2006 habe. Tut’s aber immer noch. Da ziehe ich vorzugsweise Ausschnitte aus MagicMaps drauf. In Objektordnern ist eine Sammlung von verschiedenen Tracks hinterlegt. Das gefällt mir sehr gut. Ist aber eher zum Wandern geeignet. Beim Reiten nutze ich lieber einen in die Jahre gekommenen Forerunner205 (Mai 2008) und ein auch nicht mehr ganz neues etrexVistaHCx (2009). Letzeres habe ich mir zunächst nur deshalb gekauft, weil ich damals keine Möglichkeit fand, Ausschnitte der Wanderreitkarte auf mein PDA zu bekommen. Ich bekam nur irgendein anderes Programm zum Laufen, das die OSM-Karten jedoch in einem Layout renderte, das mir so ganz und gar nicht gefiel. Inzwischen weiß ich aber auch andere Vorzüge des VHCx und vor allem die Vorzüge einer Vektorkarte zu schätzen.
Im Prinzip hast Du ja recht. Die hohe Zoomstufe wird auch nur dort benötigt, wo die Straßen und ihre Namen so eng zusammen liegen, daß ein Teil verdrängt, also nicht angezeigt wird. In dünn bebauten Gebieten bringt diese Zoomstufe keinen Mehrwert. Im Gegenteil: die Karte verliert in dieser Zoomstufe an Informationsgehalt. In Innenstädten, wo viele Gebäude beschriftet sind, ist diese Zoomstufe dagegen durchaus sinnvoll. Ich habe eine Weile mit den Zoomeinstellungen dieser Beschriftungen herum gespielt und feststellen müssen, daß viele Texte so lang sind, daß diese in detailliert gemappten Gebieten in zoom15 und teilweise auch 16 das Kartenbild massiv stören. Erst ab z17 stehen Häuser-Beschriftung und Kartenobjekte in einem akzeptablen Größenverhältnis zueinander. Die Berücksichtigung von POI-Symbolen lasse ich dabei mal völlig außer Betracht. Die würden die Problematik noch zusätzlich verschärfen.
Dafür hab ich ja die Vektorkarten/OSM-Garmin-Karten. Und die find ich auch wesentlich praktischer, als die Rasterkarten (die aber schöner aussehen. Deshalb beschäftige ich mich ja damit ). In Vektorkarten stecken in jedem Element (mehr oder weniger) Informationen, die mit dem Mauszeiger abgerufen werden können. So erfährt man bei Berührung einer Fläche (z.B. landuse=residential) die hinterlegte Bezeichnung. Das ist sehr praktisch. So braucht man nicht in der Karte suchen, wo der Punkt mit dem Ortsnamen steckt. Man berührt einfach die Fläche und schon ploppt er auf. Wenn kein Ortsname hinterlegt wurde, ploppt dann leider nur die Objektbezeichnung z.B. Wohngebiet auf. Da “freue” ich mich dann immer.
Wenn ich am Kartenbild arbeite, möchte ich auch Zugriff auf die Kartenelemente haben. Das Inkskscapeformat erlaubt das. Jedes Objekt läßt sich, wie in Vektorgrafiken üblich, einzeln fassen und bearbeiten. So kann man schlecht positionierte Beschriftungen oder Icons weg ziehen, oder die Schriftgöße nachjustieren. Auch lassen sich angeschnittene Worte aus dem Bildrand heraus ins Bild holen. Aus verschiedenen Gründen entstehen in OSM-Karten immer wieder sinnlose Doppelungen von Texten oder Icons. Die lassen sich in Inkscape mit einem Klick löschen. Da wird nicht wie in Pixelgrafiken retuschiert, sondern eben das Objekt bearbeitet (verschoben, gelöscht, dupliziert, eingefärbt usw.). Wenn die Ref-Nummern der Straßen nicht besonders schön verteilt sind, ist es ein Leichtes, die an bessere Positionen zu verschieben. Mit wenigen Klicks läßt sich da also eine Menge machen.
vorher - nachher - nur mal so als Beispiel:
Danke für den Tipp!
Drag&Drop - Coole Sache!
Damit kann ich dann in 0,nix die Track-Aufzeichnungen einer Saison in die Karte ziehen. Sehr schön!
Um Tracks zu bauen nehme ich lieber MagicMaps. Von da aus läßt sich der erstellte Track in alle benötigten Formate (PDA, eVHCx, FR205) exportieren. Mit dem Programm arbeite ich gerne.
Das Drag&Drop-Verfahren (siehe oben) ist dazu eine einfache, sehr bequeme Alternative. Guter Tipp!
Von Phyton hab ich keine Ahnung. Aber der Geistesblitz kam inzwischen. Es ist total einfach!
Den gewünschten Bildausschnitt suchen und ausprobieren, in welcher Zoomstufe die gewünschten Karteninformationen sichtbar werden.
Den Kartenausschnitt so im Fenster justieren (verschieben & zoomen), daß der gewünschte Extrakt komplett zu sehen ist.
In der Kommando-Zeile (im Bild gelb hinterlegt) hinter dem export-Befehl die Zoomstufe angeben. z.B. zoom=12
enter
Nach erfolgreicher Erstellung der Datei zeigt Maperitive im Protokoll den Pfad an, unter dem die *.svg-Datei abgespeichert wurde.
Das war’s auch schon.
Die Suche nach Koordinaten kann man sich sparen.
Achso? Genau so hatte ch das Wiki aber interpretiert, dass auch mehreren outer eine Fläche gebaut wird. Man kann sogar mehrere sich nicht berührende Flächen zusammenfassen. Jedenfalls ist es so definiert worden.
…nur zur Sicherheit die Funktion “Place Geometry Bounds” und “Printing Bounds” kennst du? Comandzeile oder Kontextmenü (rechte Moustaste auf der Map) DenRahmen kannst du dann beliebig veränder. Mouse langsam ander Linie/Ecken der Box bewegen. Die nachfolgenden Operationen beziehen sich dann auf diese Grenzen
In der History ist nachlesbar, von wann diese Definitionen sind. Ursprünglich gab es diese zerstückelten Polygone nicht. Ich kann mich mit denen auch nicht anfreunden. Die machen nur allen das Leben schwer.
Aber wo ist denn der Unterschied zu einer Route? Dort mache ich auch aus verschiedenen Wegen einen Weg. Jetzt ist das für ein MP nur konsequent wenn aus drei Wegen einer wird und der eine Fläche bildet. Jedenfalls besser als 10 Wege übereinander. Finde ich.
Es war ziemlich genau der 22. Februar 2010. Ist also auch nicht mehr ganz taufrisch.
Im englischen war es übrigens schon der 24. November 2009.
Der Artikel selbst stammt vom 14.09.2009 Es war also etwas mehr als 2 Monate nach Entstehung des englischen Artikels.
Der deutsche Artikel stammt schon vom Dezember 2008.
Ah! Gut! Danke!
Den über das Kontextmenü aufziehbaren Rahmen hatte ich noch nicht entdeckt.
Weiter oben hab ich ja gelistet, was ich im Handbuch und auf der Wiki-Seite gefunden habe.
Mein Versuch, aus den Befehlen ein Script zu bauen scheiterte jedoch an der Syntax der Koordinateneingabe. … Kein Wunder … die Beschreibung ist laut braincrunch veraltet. grmmpf
Aber jetzt klappt das ja.
Ich hatte mir mit dem Verziehen des Windowsfensters (Was für ein Doppelgemoppel im 2Sprachenmix!) geholfen. Das geht auch. Denn wenn man keine Printing Bounds aufzieht, dann wird das in die Druckdatei kopiert, was man im Fenster sieht.
Stimmt schon. Hab mich da etwas zu knapp und mißverständlich ausgedrückt.
Anfangs traf man in der Praxis auf diese zusammengesetzten Polygone nur sehr selten. In meiner ersten Mapperzeit fiel mir kein einziger auf. In meinem Bereich gab es sie meines Erachtens schlichtweg nicht.
Solange es keiner übertrieb, gab es ja auch keine Probleme mit den zusammengesetzten Polygonen.
Nur dann entwickelten sich immer mehr von diesen Monsterpolygonen und die sind einfach furchtbar unübersichtlich und führen immer wieder zu ärgerlichen Renderfehlern.
Mit der aktuellen ComposerVersion ist es beispielsweise nicht möglich, fehlerfreie Kacheln zu rendern, wenn die automatisch berechneten Schnitte “irgendwie unglücklich” auf Multipolygone treffen. Je größer die Multipolygone sind, um so auffälliger sind die Fehler an den Schnitträndern. Um brauchbare Vektorkartenkacheln zu erhalten, muß ich aktuell die Kartenausschnitte von Hand so wählen, daß der Inhalt in einer einzigen Kartenkachel angezeigt werden kann. Ansonsten werden automatische Aufteilungen der Kacheln provoziert, die entlang der Schnittlinien zu kaputten Flächen führen. Ich höre jetzt schon wieder das Argument durch die OSM-Hallen schallen, daß da eben die Renderprogramme besser mitziehen müssen. Na toll. Und wer “bezahlt” die Rechnung?
Ich sag/schreib ja nicht, daß es falsch ist, nur daß ich mich damit nicht anfreunden kann. Ich verstehe, wie sie gebaut werden. Aber ich mag sie nicht, weil diese Art von Multipolygonen zwar ein raffiniertes Konstrukt sein mag, aber gerade deshalb schlecht zu warten, fehleranfällig und schwer zu händeln sind. Es mag Fälle geben, in denen solche Polygonkonstrukte die einzige Lösung für ein Problem sind. Doch die sind meiner Mappererfahrung nach selten. Übereinanderliegende Wege und Polygonbegrenzungen sind für mich kein Argument. Dafür gibt es in JOSM Filterfunktionen und in Potlach den Rotationsbefehl. Darüber hinaus gehöre ich zu denjenigen, die Wege und Flächenränder im allgemeinen nebeneinander legen. In Vektorkarten habe ich kein Problem damit.
Der Vergleich mit Routenrelationen hat einen Haken:
Die Informationen, wie der einzelne Weg aussehen soll hängt am einzelnen Weg. Ebenso die Information der Zugehörigkeit zu diversen Relationen.
Die Darstellung eines einzelnen Wegstücks ist völlig unabhängig von den restlichen Wegstücken der Routenrelation und auch von der Routenrelation selbst.
Der Weg ist das Greifbare, die Route eine Idee.
Bei den Flächen ist das ganz anders. Sobald ein Teil der Kette fehlt und sich dadurch nicht mehr schließt, ist die Fläche keine Fläche mehr, sondern nur noch eine Linie. Außerdem ist die Fläche nicht einfach nur eine Idee, sondern im Fall von Wäldern, Wiesen etc. etwas konkret Faßbares, was man von Grenzrelationen wiederum nicht sagen kann, obschon die ja auch Flächen bilden. Zur Abbildung einer durch eine Boundingbox zerschnittenen Fläche ist immer das Hinzuladen der außerhalb der Box liegenden Relationselemente notwendig. Bei einer Route ist das nicht notwendig. Denn die wird ja auch als Teilstück korrekt dargestellt.
Die Verschachtelung der Flächen führt zu komplexen Strukturen, bei denen ein Innen und Außen beim Füllen der Flächen berücksichtigt werden muß. Theoretisch sind nicht nur eine sondern mehrere eigentlich unabhängig voneinder gezeichnete Verschachtelungen möglich. Werden solche komplexen Strukturen zerschnitten, sind Fehlinterpretationen nie ganz auszuschließen. Oder doch?
Ich glaube nicht, daß man die Flächen der Multipolygone im Prinzip wie Routen betrachten kann.
nur der volständigkeitshalber: In der neuen MOBAC Version 1.9.3 ist die oben angesprochene Toolunterstützung drin. Leider ist das aber (noch) nicht dokumentiert.
Man muß ein Subdir …/tools anlegen und kann dann in MOBAC ein “Tools” Menü konfigurieren, mit dem man externe Tools aufrufen kann.
Allgemeiner Konfigfile in Tools sieht so aus und muß für eigene Zwecke entsprechend abgeändert werden:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
Name shown in tools menu
cmd.exe /c start mybatch.cmd
MIN_LON MIN_LAT MAX_LON MAX_LAT MIN_ZOOM MAX_ZOOM MAPSOURCE_NAME MAPSOURCE_DISPLAYNAME NAME_EDITBOX
true
Schön das deine Bemühungen Früchte tragen und wir wieder ein Stück “kundenfreundlicher” Karten selbst erstellen können. Auf diesem Wege auch einen Dank an den Entwickler von Mobac welcher dies mit ermöglicht.
). In Vektorkarten stecken in jedem Element (mehr oder weniger) Informationen, die mit dem Mauszeiger abgerufen werden können. So erfährt man bei Berührung einer Fläche (z.B. landuse=residential) die hinterlegte Bezeichnung. Das ist sehr praktisch. So braucht man nicht in der Karte suchen, wo der Punkt mit dem Ortsnamen steckt. Man berührt einfach die Fläche und schon ploppt er auf. Wenn kein Ortsname hinterlegt wurde, ploppt dann leider nur die Objektbezeichnung z.B. Wohngebiet auf. Da “freue” ich mich dann immer.
