Freizeitkarte für Garmin BaseCamp und GPSr

Klaus, compliments for your nice map with clean Mapnik look!
I also noticed that you generated the outlines of the border countries (NL, DK, Poland) because the Germany geofabrik extract always stops at the borders and causes floodings. How did you do it?

Regards, Minko

Just a guess, but maybe he took the Germany+50km extract

http://forum.openstreetmap.org/viewtopic.php?id=11792

I don't think so, the Germany+50 dataset ist somehow broken. It is missing some of the Frisian islands in the North Sea. The Freizeitkarte - which btw. is really great! - does contain this data, so i think it is a different cut.

Danke Klaus,

ich habe es gerade mal für Mapsource installiert- klappt (natürlich) auch.
Jetzt fehlt nur noch der Test mit dem 60er.

Moin,
sieht auf den Screenshots schonmal gut aus. 😉

Weshalb benutzt Du Garmin-Road-Klasse 1 nur für Kreisverkehre?

ligfietser wrote:

... I also noticed that you generated the outlines of the border countries (NL, DK, Poland) because the Germany geofabrik extract always stops at the borders and causes floodings. How did you do it?

Hi Minko,

it's a side effect of my strategy to generate the sea polygons.
I use a coastline (from chris66) for this - here are the details:

compiler options (concerning sea polygons):
coastlinefile: C:/Freizeitkarte/data/coast.osm
generate-sea:multipolygon,extend-sea-sectors

polygons style file (concerning land and sea):
natural = sea [0x32 resolution 17]

TYP file (draw priorities):
1 = 4b (background)
2 = 32 (sea)
3 = 3a (land, due to other problems not used for a polygon, maybe not necessary?)
4 = other polygons
...
9 = other polygons

Currently I'm using the standard geofabrik extract for germany.
What you see as land contour is the map background minus the sea.

Regards, Klaus

Hallo Klaus,

ich habe die Karte zwar noch nicht probiert, aber eins will ich loswerden. Die Doku ist perfekt. Das habe ich bei keiner anderen Karte so bisher gesehen.

aighes wrote:

Just a guess, but maybe he took the Germany+50km extract

http://forum.openstreetmap.org/viewtopic.php?id=11792

Henning, is this germany+.osm.xz from http://140.78.94.22/osm/ readable in mkgmap's splitter?

ligfietser wrote:

Henning, is this germany+.osm.xz from http://140.78.94.22/osm/ readable in mkgmap's splitter?

Ok, i'm not Henning but can answer anyway:
Inside the xz-archive is a standard .osm xml-file you can feed directly to the splitter.
You can expand the archive using xz-utils: http://tukaani.org/xz/
But beware, it expands to around 26GB(!!) on disk. 😉

Thanks, I'll have a look.

Hi Klaus,

auf dem GPSMap60Csx ist die Position der Ortsnamen vom eigentlichen Punkt relativ weit entfernt. Da ist die Zuordnung nicht immer einfach.
Ansonsten finde ich das Kartenbild recht ansprechend.

Zunächst einmal Danke für das motivierende Feedback.

Vom Prinzip her verstehe ich die Freizeitkarte Deutschland als ein offenes Community-Projekt mit dem Ziel eine sehr gute Basiskarte bereit zu stellen. Hier wird man sicher nicht alle Anforderungen gleichgut abdecken können - aber die Karte sollte ein sehr guter Kompromiß sein.

Deshalb werde ich in Kürze auch die Entwicklungsumgebung der Karte (lauffähig unter OS X und Windows) veröffentlichen. Damit ist es "leicht" möglich, individuelle Anpassungen (Design, Inhalt, Aktualität) an der Karte vorzunehmen. Zunächst soll die Entwicklungsumgebung jedoch noch einen Betatest durchlaufen - sollte da jemand Interesse haben, bitte melden (am besten per PM).

Noframe wrote:

... auf dem GPSMap60Csx ist die Position der Ortsnamen vom eigentlichen Punkt relativ weit entfernt. Da ist die Zuordnung nicht immer einfach.

Im Moment wüßte ich keine Möglichkeit wie man dies kontrollieren / beeinflussen könnte. Im Zusammenhang mit der Anzeige von Namen würde ich mir auch eine Priorisierung wünschen. Damit könnte man dann z.B. sicherstellen, daß Ortsnamen immer angezeigt werden.

toc-rox wrote:

Zunächst einmal Danke für das motivierende Feedback.

Vom Prinzip her verstehe ich die Freizeitkarte Deutschland als ein offenes Community-Projekt mit dem Ziel eine sehr gute Basiskarte bereit zu stellen. Hier wird man sicher nicht alle Anforderungen gleichgut abdecken können - aber die Karte sollte ein sehr guter Kompromiß sein.

Deshalb werde ich in Kürze auch die Entwicklungsumgebung der Karte (lauffähig unter OS X und Windows) veröffentlichen. Damit ist es "leicht" möglich, individuelle Anpassungen (Design, Inhalt, Aktualität) an der Karte vorzunehmen. Zunächst soll die Entwicklungsumgebung jedoch noch einen Betatest durchlaufen - sollte da jemand Interesse haben, bitte melden (am besten per PM).

Da bin mal gespannt wie so eine Entwicklungsumgebung aussehen könnte.
Freu mich drauf.

Ansonsten finde ich die Karte eine wirkliche Alternative für die Freizeit.

YGruß

Hi toc-rox
Habe gerade mal die Legende durchgelesen.
Dabei fiel mir auf, daß Wege ohne Angabe der Güteklasse mit Wegen der Güteklasse 2 und 3 in einen Topf geworfen werden.
Das macht die Karte für mich unbrauchbar. Angesichts der Umstände, daß gerade in von Mappern wenig frequentierten Gebieten sehr viele Wege von bing abgezeichnet werden, meine ich, daß die fehlende Angabe als Hinweis darauf interpretiert werden sollten, daß solche Wege noch überprüft und dann klassifiziert werden müssen. In der Wanderreitkarte wird das seit einigen Monaten berücksichtigt. Solche Wege werden mit einer speziellen Linie dargestellt.
Ein Blick auf diesen Kartenausschnitt
http://www.wanderreitkarte.de/index.php … 42&zoom=14
sagt wohl alles.
Wegklasse 0 kann alles sein von tracktype=grade1 bis grade5.
Die Sondermarkierung ist Warnung und Animation zugleich.
Wer eine Tour in so einem Gebiet plant, muß sich darauf einstellen, daß er seine Route komplett umwerfen muß.
Eine Karte, die das nicht berücksichtigt, läßt den Nutzer in unerwartete Fallen (z.B. zugewucherte oder aus anderen Gründen unbegehbare Wege) tappen.

Gruß
tippeltappel

tippeltappel wrote:

... Dabei fiel mir auf, daß Wege ohne Angabe der Güteklasse mit Wegen der Güteklasse 2 und 3 in einen Topf geworfen werden. Das macht die Karte für mich unbrauchbar. Angesichts der Umstände, daß gerade in von Mappern wenig frequentierten Gebieten sehr viele Wege von bing abgezeichnet werden, meine ich, daß die fehlende Angabe als Hinweis darauf interpretiert werden sollten, daß solche Wege noch überprüft und dann klassifiziert werden müssen. In der Wanderreitkarte wird das seit einigen Monaten berücksichtigt. Solche Wege werden mit einer speziellen Linie dargestellt. ...

Die Wanderreitkarte ist m.E. eine ganz hervorragende Spezialkarte - da steckt sehr viel Arbeit und Reife drin (Klasse gemacht!).
Ich finde den Vergleich mit einer allgemeinen Basiskarte aber etwas problematisch - eher ein Vergleich von Äpfel und Birnen.

Die größte Schwierigkeit beim Erstellen einer Karte besteht m.E. immer im "Weglassen" von Information - aber verdichten heißt auch vernichten.

Bei den Tracks gibt es insgesamt 6 Kategorien (tracktype 1-5, keine Angabe).
Diese sind zu drei Kategorien verdichtet:
- 1
- 2,3,keine
- 4,5

Tracks ohne Kategorie (tracktype) sind "defensiv" in "2,3" einsortiert (in der Mitte ist die Abweichung am geringsten).
Möglicherweise wäre es aber besser (korrekter?) diese Tracks in "4,5" einzuordnen.
Wie ist eure Meinung hierzu?

Gruß Klaus

PS: In Kürze werde ich die Entwicklungsumgebung der Karte veröffentlichen.
Dann hat "jeder" die Möglichkeit individuelle Anpassungen vorzunehmen.

Von der Freizeitkarte Deutschland ist die Ausgabe 11.10 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 14.10.2011.

Link: http://www.easyclasspage.de/karten/index.html

Ergänzungen / Veränderungen gegenüber der vorherigen Version:
- Kartenbezeichnung geändert in "Freizeitkarte_Deutschland"
- Adresssuche für Städte und Straßen
- viele POIs ergänzt (Geschäfte, Restaurants, ...)
- deutsche Bezeichnungen für häufig vorkommende POIs
- U-Bahn-Strecken ergänzt
- weitere Detailverbesserungen

Die Karte befindet sich im Status "Erprobung".

Gruß Klaus

Bzgl. der Adresssuche: Danke an WanMil für die Entwicklung dieses Features und railrun für die Qualitätssicherung.

Mir gefällt die Karte auch sehr gut. Vielen Dank, tolle Arbeit.

Gibt es eine Chance, dass Du auch mal andere Ausschnitte zur Verfügung stellst. z.B. den Alpenraum so wie es Extremecarver für die OpenMTB Karte macht? Das wäre super.

Deshalb werde ich in Kürze auch die Entwicklungsumgebung der Karte (lauffähig unter OS X und Windows) veröffentlichen. Damit ist es "leicht" möglich, individuelle Anpassungen (Design, Inhalt, Aktualität) an der Karte vorzunehmen. Zunächst soll die Entwicklungsumgebung jedoch noch einen Betatest durchlaufen - sollte da jemand Interesse haben, bitte melden (am besten per PM).

Da wäre ich durchaus daran interessiert (Windows Umgebung)

shammat wrote:

... Gibt es eine Chance, dass Du auch mal andere Ausschnitte zur Verfügung stellst. z.B. den Alpenraum ...

Ich hatte mal Versuche mit den angrenzenden Ländern Niederlande und Österreich gemacht, war aber mit der Qualität nicht zufrieden. In beiden Ländern "fehlten" mir z.B. viele Radwege. Für Österreich ist das wohl korrekt, für die Niederlande m.E. eher nicht. Hier wäre zunächst eine "intensive" Qualitätssicherung erforderlich. Dies bedingt aber sehr detaillierte Kenntnisse des jeweiligen Landes. Für Österreich würde aber ich nochmal einen Versuch starten wollen - Interessierte also bitte (per PM) melden ...

Gruß Klaus

toc-rox wrote:

Für Österreich würde aber ich nochmal einen Versuch starten wollen - Interessierte also bitte (per PM) melden

Mir persönlich würde Österreich vollkommen reichen.

Eigentlich würde mir auch Deutschland Süd/Österreich reichen.

Hallo, ich habe die Karte mal inst. Auf Basecamp gefällt sie mir ganz gut! Die farbliche Abstufung der Wege finde ich gut. Habe sie auf dem ETREX Legend install, dort gefällt sie mir nicht so, die Farben sind zu kontrastlos, schlechte Orientierung im freien.
Gruß Nimra

Von der Freizeitkarte Deutschland ist die Ausgabe 11.11 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 18.11.2011.

Link: http://www.easyclasspage.de/karten/index.html

Ergänzungen / Veränderungen gegenüber der vorherigen Version:

• Großstädte werden mit "rotem Punkt" markiert
• Freigabe der Entwicklungsumgebung
• Schrebergärten werden dezenter schraffiert
• Weinberge werden dunkler als Wald dargestellt
• Anzeige und Routing für Kreisverkehre überarbeitet

Entwicklungsumgebung:
Mit Freigabe der Entwicklungsumgebung, besteht unter OS X und Windows die Möglichkeit, aus der Freizeitkarte Deutschland eine individuelle Karte abzuleiten. Dies kann unter folgenden Aspekten interessant sein:

• Aktualität: Es ist möglich, jederzeit eine "neue" Karte aus "tagesaktuellen" OSM-Daten zu erzeugen.
• Inhalt: In der Freizeitkarte Deutschland vorhandene Standardobjekte können entfernt oder individuelle Elemente können hinzugefügt werden.
• Design: Das Design legt das wesentliche optische Erscheinungsbild der Karte fest. Es kann teilweise oder vollständig verändert und den eigenen Anforderungen und Empfinden angepaßt werden. Insbesondere für alternative Designs besteht meinerseits Interesse diese zusammen mit einer kommenden Kartenausgabe zu veröffentlichen.

Die Karte befindet sich im Status "Erprobung" - hilf mit sie weiter zu verbessern.

Gruß Klaus

toc-rox wrote:

Die Karte befindet sich im Status "Erprobung" - hilf mit sie weiter zu verbessern.

Die Entwicklungsumgebung funktioniert bei mir mit XP und 2GB klaglos. Dauert zwar ne Stunde für NRW, aber das ist ja nichts im Vergleich zu vier Stunden Import und 20 Stunden Renderzeit für die Mapnik-Tiles.
Mit dem Styling muß ich mich erst noch näher befassen.

Gruß,
ajoessen

Also wenn man die Karte im 3D Autoroutingmodus auf'm neuen Etrex nutzt sieht das sehr gut aus.
Dürfte also zur Zeit die einzige Karte sein wo auf den neuen Garmins die Adresssuche geht
und das Routing noch einigermaßen gut ist.
Chris

@ ajo & cris
Wie sind Eure Erfahrungen mit Basecamp?
Lohnt sich die Installation neben MapSource?
Als es neu raus kam, fehlten mir diverse von MapSource vertraute Möglichkeiten, Karteninformationen abzurufen so sehr, daß ich das Programm wieder vom Rechner verbannt habe.

@ toc-rox
Funktioniert die Karte auch mit MapSource? Oder sind da Einschränkungen zu beachten?
Habe nur Hinweise auf Basecamp gefunden.

Gruß tippeltappel

Soviel nutze ich MS/BC nicht. Weiss gar nicht ob MS noch auf Win7 läuft.

Bei mir läuft G-MapSource auf Win7 ohne Probleme.

tippeltappel wrote:

@ ajo & cris
Wie sind Eure Erfahrungen mit Basecamp?
Lohnt sich die Installation neben MapSource?
Als es neu raus kam, fehlten mir diverse von MapSource vertraute Möglichkeiten, Karteninformationen abzurufen so sehr, daß ich das Programm wieder vom Rechner verbannt habe.

Nunja, die Version 3.2x hat natürlich ein paar bugs weniger als die Erstausgabe ;-)

Bei Basecamp kann ich eine Route planen und mit der Gummibandfunktion verfeinern (wenns nicht gerade eine nicht-routbare des Map Composers ist), dann in einen Track umwandeln und aufs Gerät zum Trackback spielen.

Bei MapSource habe ich diese Umwandlung nicht gefunden.

So bin ich vor Überraschungen sicher, wenn das Gerät anders routen will als der PC.

Damit macht das Routen planen erheblich mehr Spaß als das alte Magic Maps, wo ich noch jeden Weg selbst nachzeichnen musste.

Ausserdem zickt das BaseCamp nicht bei der Installation, wenn man keinen gekauften Garmin-Karten hat.
Nur der Programmstart ist halt etwas träge.

Gruß,
ajoessen

@ ajoessen
Ich bin bekennender Trackklicker 🙂
Daher vermisse ich nicht vorhandene Routenfunktionen nicht.
MagicMaps hat die für mich sehr wichtige Schnittstelle Richtung Forerunner und PDA.
Die gab es weder in BaseCamp noch MapSource. Ob die Version MS 6.16.3 mit der ExportVersion inzwischen zumindest auch den alten FR erreicht, hab ich noch nicht getestet. Auslesen konnte MS die reinen Tracks, Routen und POIs des FR schon immer.
In MapSource schnappen die Trackpunkte auf meiner OSM-Garmin-Karte auf den Wegen ein. Da braucht man nicht lange zu zielen und hat sich ziemlich schnell an den Wegen entlang gehangelt. Da ist eine Tour natürlich wesentlich schneller zusammengeklickt, als in MagicMaps. Nur wenn die Wege auf der Karte fehlen, hilft auch die schönste Magnetfunktion und das schönste Routing nichts. 😉 Da muß ich dann wieder zur alten MagicMapsKarte. In fremdem Gelände liegen sowieso immer mehrere Karten nebeneinander entweder auf dem Bildschirm oder auf dem Schreibtisch. Die Tracks sind vor Neuberechnungen sicher. Und als Trackback lassen die sich ebenfalls "abfahren". Also habe ich alles was ich brauche.

Sollt ich mal Langeweile haben, teste ich BaseCamp vielleicht noch einmal. Wenn die Kartenanzeige jedoch nach wie vor keine aktiven Flächen und Icons aufweist, ist das für mich ziemlich uninteressant.

Gruß
tippeltappel

Meine Wünsche an die Freizeitkarte:
Bahnlinien wie in Mapnik malen (schwarz/weiss)
hw=construction rendern
ab Zoom 3 km werden überhaupt keine Straßen mehr gezeigt, ist das beabsichtigt?
Chris

tippeltappel wrote:

Funktioniert die Karte auch mit MapSource?

Funktioniert laut anderer Benutzer auch mit MapSource - ich teste aber nur unter BaseCamp (Windows, OS X).

Gruß Klaus

PS: Die Mac-Version von BaseCamp finde ich um einiges "gelungener" als die Windows-Version.

chris66 wrote:

Meine Wünsche an die Freizeitkarte:
Bahnlinien wie in Mapnik malen (schwarz/weiss)
hw=construction rendern
ab Zoom 3 km werden überhaupt keine Straßen mehr gezeigt, ist das beabsichtigt?
Chris

Bahnlinien wie in Mapnik: Hatte ich zuerst so, führte aber zu Problemen:
- zwei Pixel breite Bitmap-Linien führen unter BaseCamp (OS X) zu "unschönen" Artefakten (warum dies so ist, konnte ich nicht klären)
- nahe beieinander liegende Bahnlinien sehen "unschön" aus (Mapnik reduziert hier einfach die Anzahl an Bahnlinien)
Verwendet wird derzeit die Garmin-Default-Linie für Bahnstrecken.

highway=construction: Hatte ich zuerst so und ist sogar noch im Style-File enthalten.
Ich fand den Informationswert gering, lasse mich da aber überzeugen.

1. Baustelle / im Bau:
   

1. ---

2. Markiert eine Straße, die sich grade im Bau befindet.
   
3. Die Anzeige dieses Features wird als nicht sinnvoll angesehen.
   
4. 0x10e04 = Bitmap 4
   
5. highway = construction | highway = proposed [0x010e04 resolution 23]
   

Vielleicht "construction" reinnehmen, wäre ja eine gute Landorientierung, nicht jedoch "proposed".

Ab Zoom 3 km keine Straßen mehr:
Was würdest du als sinnvoll ansehen? Bitte zwischen GPSr und BaseCamp unterscheiden.

Gruß Klaus

Hi,

auf meinem Garmin eterx legend hcx sieht die selbstgebaute Karte komplett anders aus als in BaseCamp. Scheint so, als würde das Typ-File komplett ignoriert.
Egal, ob ich mit Garmin MapInstall oder mkgmap die gmapsupp.img zusammenbaue.

Gruß,
ajoessen

ajoessen wrote:

Hi,

auf meinem Garmin eterx legend hcx sieht die selbstgebaute Karte komplett anders aus als in BaseCamp. Scheint so, als würde das Typ-File komplett ignoriert.
Egal, ob ich mit Garmin MapInstall oder mkgmap die gmapsupp.img zusammenbaue.

Gruß,
ajoessen

Paßt die family-id ?

Screenshot vom eTrex 20:

Auch Garmin mag anscheinend keine Spur-gemappten Kreuzungen:

😉
Edit: Invalides Spurmapping (keine bauliche Trennung) berichtigt.

Hi Klaus!

Vielen Dank für die neue Karte!
Nachdem ich die Karte in MapSource installiert hatte, probierte ich natürlich trotz meiner Vorliebe fürs Trackklickern die Routingfunktion Deiner Karte aus.
Mit der Option "Fußgänger" / Vermeidung von Kehrtwenden und Fahrgemeinschaftsspuren (Was immer das auch bedeuten mag...) macht die Routingfunktion, was ich von ihr erwarte. Allerdings braucht's unter Umständen eine ganze Menge strategisch gut gesetzter Zwischenpunkte für 25 bis 40km Feld-Wald-Wiesen-Strecke, um dem Programm klar zu machen, daß ich nicht die Straße lang klappern möchte. Diese Punkte sind aber deutlich rascher geklickt, als ein ganzer Track und die Spur liegt stets exakt auf dem Weg.
Ist halt die Frage, ob man genau das so möchte.
Um die Wege auf der Karte besser sehen zu können, klicke ich bei der Trackerstellung nicht exakt jede kleine Kurve aus, sondern fahre nur grob an den Wegen entlang - fein genug, daß der Bezug zwischen Wegen und Routen auch in höheren Zoomstufen sichtbar bleibt, aber eben so, daß der Weg immer wieder ein bissel vor guckt und man die Wegeigenschaften sehen kann.

Wenn man also heraus hat, wo man hinklicken muß, läuft das automatische Routing meistens wie gewünscht über Feldwege. Ganz frei von Merkwürdigkeiten ist das Routing jedoch nicht. An einer Stelle führte das Routing über einen tracktype4-Weg mit einem als Hindernis eingetragenen Sumpfloch (das man nur auf meiner Karte sieht und von Dir nicht ausgewertet wird), anstatt über den nur unwesentlich längeren aber wesentlich besser begehbaren tracktype2-Weg zu führen. An anderer Stelle wurden Wegverbindungen ignoriert und seltsame Sackgassen geroutet, die nur mit mehreren zusätzlichen Zwischenpunkten aufzuheben waren.

Das nachträgliche Ändern einer auf diese Weise erstellten Route ist auf verschiedene Weise möglich. Z.B. kann man ein Zwischenziel mit Rechtsklick anwählen und auf die Option "nächstgelegenen Ort suchen und einfügen" klicken. Sobald man Wegpunkte in die Karte gesetzt hat, erscheint statt dessen die Option "Wegpunkt einfügen". Bei der dann notwendigen Neuberechnung der Route können ziemlich unsinnige Veränderungen entstehen.

Einfacher lassen sich neue Zwischenpunkte setzen, wenn man mit der Auswahlfunktion (weißer Pfeil) auf die Routenlinie klickt und dann den dadurch erzeugten Zwischenpunkt auf seine Position zieht. (=Gummibandfunktion). Vorhandene Zwischenpunkte können beliebig bearbeitet und gelöscht werden. Dabei entstehende unsinnige Routenverläufe korrigiert man durch Einfügen eines weiteren Zwischenpunktes. Das alles klappt auf Deiner Karte ganz prima.

Leider verschwinden die Wege unter der breiten Routenlinie im Bearbeitungsmodus auch dann, wenn man sie transparent geschaltet hat. So kann man dann nicht mehr erkennen, über welche Wege geroutet wurde. Hebt man die Routenauswahl auf, wandelt sich die Routenanzeige in eine so dünne schwarze Linie, daß man sie kaum noch sieht. Das kannst Du natürlich nicht beeinflussen. Im Layout der OpenMtbMap geht diese dünne schwarze Linie ebenfallst unter.

Mit der Autoroutingfunktion Touren zu erarbeiten, ist zumindest für die Planung von Reittouren nicht ganz mein Geschmack, aber wenn es weitgehend funktioniert, ist das doch eine feine Sache! 🙂

Die Umwandlung einer Route in einen Track kann ich in MapSource auch nicht finden.
Da könnte ich auch auf MagicMaps ausweichen.

Aber ich mach's halt bislang anders herum: Track erstellen und im eVHCx als Trackback aufrufen.

Die Motivation für das Zusammenlegen mehrerer Tracktypes kann ich nachvollziehen. Ich finde es aber nicht sinnvoll, weil zwischen den verschiedenen grades meiner Meinung nach zu große Unterschiede bestehen. Grade4 (unbefestigt) und grade5 (kaum noch von der Umgebung unterscheidbar, kann also stark bewachsen oder sogar zugewuchert sein) ist für mich auf keinen Fall dasselbe. Grade1 und 2 paßt auch nicht wirklich zusammen. Die Grenze zwischen grade3 und 4 ist fließend. Für mich stellt diese Vereinfachung daher einen großen Nachteil gegenüber anderen Karten dar.

POIs mit winzigen Buchstabensymbolen darzustellen, sorgt auch im höchsten Detailgrad für ein sehr klares Kartenbild. Das ist sicherlich ein Vorteil. Mir wäre es aber lieber, ich müßte nicht erst die Suchfunktion bemühen, um erkennen zu können, welche POIs sich im betrachteten Kartenbereich befinden. Durch Reduzierung des Detailgrades lassen sie sich ja ausblenden.

Wie dem auch sei: Eine schöne und gute Karte.

Gruß
tippeltappel

toc-rox wrote:

ajoessen wrote:

Hi,

auf meinem Garmin eterx legend hcx sieht die selbstgebaute Karte komplett anders aus als in BaseCamp. Scheint so, als würde das Typ-File komplett ignoriert.
Egal, ob ich mit Garmin MapInstall oder mkgmap die gmapsupp.img zusammenbaue.

Paßt die family-id ?

Welche ist denn "richtig"?

Baue ich mir für meine nähere Umgebung eine Karte nur mit mkgmap und den Styles und Typ-files der openfietsmap von Liegfietser, bekomme ich fast das gleiche Kartenbild im Garmin. Nehme ich stattdessen Style und Typfile der Radkarte von aighes, sieht es auf dem Gerät aus wie in Basecamp. Bei der velomap vom extremecarver gibts da auch keine Differenzen.

Gruß,
ajoessen

tippeltappel wrote:

Die Umwandlung einer Route in einen Track kann ich in MapSource auch nicht finden.
Da könnte ich auch auf MagicMaps ausweichen.

Nee, das ist nicht vergleichbar. In der Route stehen ja nur die von dir gesetzten Zwischenpunkte drin, in dem von Basecamp angelegten Track sind alle Koordinaten der Wege drin.

Gruß,
ajoessen

Das probiere ich heute Abend aus.
Mit GPSies klappt die Umwandlung jedenfalls problemlos: in MapSource Route als *.gpx abgespeichert > Upload auf GPSies > Download als gpx-Track = in MapSource ein Track mit sämtlichen Koordinaten.

Ist natürlich ein Umweg, bei dem Internetzugriff benötigt wird (was ich dann auf meinem Offline-Rechner nicht umsetzen kann). Geht aber bei vorhandener Internetanbindung ruckzuck.

Gruß
tippeltappel

tippeltappel wrote:

Das probiere ich heute Abend aus.
Mit GPSies klappt die Umwandlung jedenfalls problemlos: in MapSource Route als *.gpx abgespeichert > Upload auf GPSies > Download als gpx-Track = in MapSource ein Track mit sämtlichen Koordinaten.

Ist natürlich ein Umweg, bei dem Internetzugriff benötigt wird (was ich dann auf meinem Offline-Rechner nicht umsetzen kann). Geht aber bei vorhandener Internetanbindung ruckzuck.

Kleiner Zwischentest meinerseits:
QLandkarteGT und Magicmaps malen nur die Luftlinie zwischen zwei Wegpunkten, und RouteConverter routet auf ganz anderen Wegen zum Ziel als BaseCamp.

In der gpx sind jede Menge Zwischenpunkte drin, die aber anscheinend von anderen Programmen nicht ausgewertet werden. Mit GPSies hab ich keinen Vertrag.

Gruß,
ajoessen

toc-rox wrote:

highway=construction: Hatte ich zuerst so und ist sogar noch im Style-File enthalten.
Ich fand den Informationswert gering, lasse mich da aber überzeugen.

Vielleicht "construction" reinnehmen, wäre ja eine gute Landorientierung, nicht jedoch "proposed".

Ab Zoom 3 km keine Straßen mehr:
Was würdest du als sinnvoll ansehen? Bitte zwischen GPSr und BaseCamp unterscheiden.

construction:
Ja, find ich sinnvoll.

zoom:
Also ich finde es sinnvoll wenn zumindest die Autobahnen überhaupt nicht verschwinden, ist ja
momentan ein bisschen komisch, wenn die erst verschwinden und beim weiteren auszoomen
(wenn die Basemap übernimmt) wieder erscheinen.

ajoessen wrote:

In der gpx sind jede Menge Zwischenpunkte drin, die aber anscheinend von anderen Programmen nicht ausgewertet werden. Mit GPSies hab ich keinen Vertrag.

Mit WinGDB3 kann man MapSource Routen in Tracks konvertieren, inklusive der Zwischenpunkte.

Gruß,
ikonor

ikonor wrote:

ajoessen wrote:

In der gpx sind jede Menge Zwischenpunkte drin, die aber anscheinend von anderen Programmen nicht ausgewertet werden. Mit GPSies hab ich keinen Vertrag.

Mit WinGDB3 kann man MapSource Routen in Tracks konvertieren, inklusive der Zwischenpunkte.

Ja, funktioniert. Aber nur mit .gdb-Dateien, nicht mit der vorher exportierten .gpx. Als .gpx schreiben will er leider nicht, für QlandkarteGT muß man auf .tcx ausweichen. MagicMaps (zumindest meines) kennt leider weder gdb noch tcx.

EDIT: mit

gpsbabel -r -t -i gdb -f test.gdb -x nuketypes,waypoints -x transform,trk=rte,del -o gpx -F gpsbabel.gpx

bekommt man auch direkt ein magicMaps-taugliches gpx mit allen Zwischenpunkten.

Gruß,
ajoessen

ajoessen wrote:

Ja, funktioniert. Aber nur mit .gdb-Dateien, nicht mit der vorher exportierten .gpx. Als .gpx schreiben will er leider nicht, für QlandkarteGT muß man auf .tcx ausweichen. MagicMaps (zumindest meines) kennt leider weder gdb noch tcx.

Mit der Version 3.70 beta3 kannst Du Input auf Clipboard und Output auf MapSource stellen, dann Route in MapSource auswählen und kopieren > Convert in WinGDB > öffnet neue MapSource Instanz mit Track > den dann als GPX speichern.

Gruß,
ikonor

ajoessen wrote:

toc-rox wrote:

Paßt die family-id ?

Welche ist denn "richtig"?

Die family-id der Karte MUSS mit der family-id im TYP-File übereinstimmen.
Klaus

toc-rox wrote:

ajoessen wrote:

toc-rox wrote:

Paßt die family-id ?

Welche ist denn "richtig"?

Die family-id der Karte MUSS mit der family-id im TYP-File übereinstimmen.
Klaus

Und genau das tut sie nicht. Die individuell angepasste 5819.TYP enthält die familiy-ID 5824. Da scheint in deinem script die Anpassung nicht zu funktionieren. Manuell gesetzt und aufs Gerät geschoben, kommt das richtige Bild.

Gruß,
ajoessen

erstmal vielen dank für die großartige karte 🙂 ich binvor allem von der Indexsuche 🙂 🙂 🙂 absolut begeistert. lieber eine einmal im monat aktualisierte karte als eine tagesaktuelle ohne solche funktionen. auch den an mapnik orientierten style finde ich gut.

und dann die verbesserungsvorschläge.
ich find ja symbolik immer schöner:
könnte man anstatt dem k für das krankenhaus nich kleine rote kreuze da draufzeichnen (auch für flächen)?
angedeutete münzen für den handel
und den kleingarten find ich doch sehr ähnlich mit der gefahrenzone, könnte man da nicht irgendwas grünes(gerne auch grünkariert) nehmen, (ich weiß auch das das bei osm auch so komisch orange-gestreift ist, find ich auch da merkwürdig)

und bäckerein sollten nicht genauso wie restaurants markiert werden, man könnte ja die haken dafür noch ein bisschen drehen

ajoessen wrote:

toc-rox wrote:

ajoessen wrote:

Welche ist denn "richtig"?

Die family-id der Karte MUSS mit der family-id im TYP-File übereinstimmen.
Klaus

Und genau das tut sie nicht. Die individuell angepasste 5819.TYP enthält die familiy-ID 5824. Da scheint in deinem script die Anpassung nicht zu funktionieren. Manuell gesetzt und aufs Gerät geschoben, kommt das richtige Bild.

Noch mal genauer nachgeforscht:

Bei der Installation von Active Perl unter Windows muß C:\Perl\bin; in den Path eingebunden werden. Ich hatte nur die Endung .pl mit dem Programm verknüpft, und das Script mit mt.pl <optionen> gestartet. Das klappt auch, nur das Unterprogramm zur Modifikation des Typfiles wird mit "perl setfid.pl" aufgerufen, und dann kennt DOS das perl nicht. Dummerweise läuft das Hauptprogramm aber weiter durch, sodass man die Fehlermeldung nicht bemerkt. BaseCamp und Garmin MapInstall stören sich auch nicht dran, nur das mobile Gerät eben.

Gruß,
ajoessen

ajoessen wrote:

Bei der Installation von Active Perl unter Windows muß C:\Perl\bin; in den Path eingebunden werden. Ich hatte nur die Endung .pl mit dem Programm verknüpft, und das Script mit mt.pl <optionen> gestartet. Das klappt auch, nur das Unterprogramm zur Modifikation des Typfiles wird mit "perl setfid.pl" aufgerufen, und dann kennt DOS das perl nicht. Dummerweise läuft das Hauptprogramm aber weiter durch, sodass man die Fehlermeldung nicht bemerkt. BaseCamp und Garmin MapInstall stören sich auch nicht dran, nur das mobile Gerät eben.

Schön, daß es jetzt läuft.
Hmm, die Installation von "Active Perl" sollte eigentlich auch die Pfade für die Kommandofenster eintragen ...
Ich werde mal prüfen, ob man den Returncode der Aktion "perl set-typ.pl ..." auswerten kann.

Klaus

Jayjay01 wrote:

... und dann die verbesserungsvorschläge.
ich find ja symbolik immer schöner:
könnte man anstatt dem k für das krankenhaus nich kleine rote kreuze da draufzeichnen (auch für flächen)?
angedeutete münzen für den handel
und den kleingarten find ich doch sehr ähnlich mit der gefahrenzone, könnte man da nicht irgendwas grünes(gerne auch grünkariert) nehmen, (ich weiß auch das das bei osm auch so komisch orange-gestreift ist, find ich auch da merkwürdig)

und bäckerein sollten nicht genauso wie restaurants markiert werden, man könnte ja die haken dafür noch ein bisschen drehen

Bedeutung der Buchstaben auf den Flächen:
- S = Schule, Hochschule
- P = Parken
- C = Camping, Caravan
- I = Industrie, Gewerbe
- H = Handel
- K = Krankenhaus
- NR = Natur-Reservat
- R = Rohstoffabbau (oberirdisch)
- V = Verwaltung, Büros
- Z = Zoo

Es ist in der Tat nur schwer ein Unterschied zwischen Schrebergärten und Gefahrenzonen zu erkennen.
Grün anstatt Braun dürfte besser (und auch logischer) sein.

Ich hatte schon mal überlegt die "Basisversorgung" anders als z.B. Restaurants darzustellen.
Nur war ich mir seinerzeit nicht sicher was alles dazu gehören müßte (Bäckerei?, Metzgerei?, ...).
Frage: Was wäre hier essentiell und sinnvoll?

Klaus

ajoessen wrote:

tippeltappel wrote:

Die Umwandlung einer Route in einen Track kann ich in MapSource auch nicht finden.
Da könnte ich auch auf MagicMaps ausweichen.

Nee, das ist nicht vergleichbar. In der Route stehen ja nur die von dir gesetzten Zwischenpunkte drin, in dem von Basecamp angelegten Track sind alle Koordinaten der Wege drin.

Gruß,
ajoessen

Habe zwischenzeitlich die alte 32bit Systemplatte mit meiner 4 bis 5 Jahre alten MagicMaps-Version reanimiert und muß nun enttäuschenderweise bestätigen, daß die von MapSource berechnete Route nicht erkannt wird. Beim Öffnen der *.gpx wird ausschließlich auf die Wegpunkte zugegriffen.

Ob das nun der aktuelle Stand der Dinge ist, weiß ich nicht.
MagicMaps wurde ja inzwischen weiterentwickelt.

Gruß
tippeltappel

tippeltappel wrote:

Habe zwischenzeitlich die alte 32bit Systemplatte mit meiner 4 bis 5 Jahre alten MagicMaps-Version reanimiert und muß nun enttäuschenderweise bestätigen, daß die von MapSource berechnete Route nicht erkannt wird. Beim Öffnen der *.gpx wird ausschließlich auf die Wegpunkte zugegriffen.

Diese Version (2) hüte ich auch wie meinen Augapfel, weil die noch die alten Topgrafischen Karten enthält (zumindest für NRW; in RLP und Niederchsen ist dort schon die neue Atkis-verseuchte Version). So viele topografische Details wie dort findet man in den neuen amtlichen Karten leider nicht mehr.

Die gpx kannst du ja eventuell auch mit gpsbabel von route nach track umwandeln, sonst eben gdb erzeugen lassen und umwandeln.

Gruß,
ajoessen

Hallo toc-rox
erst mal vielen Dank für deine Freizeitkarte. Von den mir bekannten osm-Karten gefällt sie mir in der Farbwahl am besten. Besonders gut gefällt mir der hohe Kontrast zwischen einem Waldweg und dem Hintergrund. Bitte mache bzw. lasse alle Hintergründe so blass wie möglich, dass man mit kurzem Blick aufs Gerät die Wege gut erkennt.
Franz

frabu wrote:

... Von den mir bekannten osm-Karten gefällt sie mir in der Farbwahl am besten. Besonders gut gefällt mir der hohe Kontrast zwischen einem Waldweg und dem Hintergrund. Bitte mache bzw. lasse alle Hintergründe so blass wie möglich, dass man mit kurzem Blick aufs Gerät die Wege gut erkennt.

Das Design der Karte orientiert sich stark am Mapnik-Stil der OSM-Karte - allerdings mit einigen Abweichungen. Das Grunddesign der Karte werde ich zunächst unverändert lassen, wobei allerdings einige Benutzer (auf den ersten Blick) einen "unzureichenden" Kontrast anmerken. Dies ist sicherlich aber auch vom verwendeten GPSr abhängig. Das Design kann aber, jetzt nach Freigabe der Entwicklungsumgebung, durch jeden Benutzer individuell angepaßt werden. Ich hoffe, daß dies auch einige Benutzer tun. Diese alternativen Kartenstile würde ich, sofern sie mir zur Verfügung gestellt werden, dann "irgendwie" integrieren und allen verfügbar machen wollen.

Klaus

Hallo toc-rox,
danke für deine schnelle Antwort. Was mir an deiner Karte gefällt, ist die gute Erkennbarkeit von Waldwegen. Ich weiss ja nicht, was andere wollen. Kontrast heisst für mich nicht, dass alle Wald- und Wiesenflächen mit satten Farben voll ausgefüllt sind. Gerade dann erkennt man nämlich Pfade nicht mehr so schnell. Also lass die Hintergründe so schön blass und gebe den Wegen satte dunkle Farben.
Franz

noch 2 kurze fragen
sehe ich das richtig, dass maxspeed nicht ausgewertet wird sondern der maxspeed von der straße ausgehend verwendet wird?

Das wenn ich autobahnen vermeide auch keine primary highways verwendet werden?

Jayjay01 wrote:

sehe ich das richtig, dass maxspeed nicht ausgewertet wird sondern der maxspeed von der straße ausgehend verwendet wird?
Das wenn ich autobahnen vermeide auch keine primary highways verwendet werden?

Leider sind weder das Garmin-Kartenformat noch das Routing öffentlich bekannt.
Alle Erkenntnisse basieren auf Reverse-Engineering.
Somit ist insbesondere das Routing als "experimentiell" zu bezeichnen.
Vor Kurzem hat Garmin am Routing Änderung vorgenommen (viele access-Flag werden ignoriert),
so daß es in BaseCamp und neueren GPS-Geräten (eTrex-Serie) nicht mehr wie bisher funktioniert.
Die Freizeitkarte versucht das Problem (sowiet wie möglich) zu umgehen.

Zu deinen Fragen:
maxspeed: Wird ignoriert, es werden die Straßendefaults verwendet.
primary highways: Sollten auch bei "Autobahnen vermeiden" verwendet werden.

Für das Routing gilt generell:
Das Ergebnis der Routenberechnung kann Fehler enthalten oder unzureichend sein.
Jede Routenberechnung sollte durch den Benutzer immer kritisch geprüft werden.

Danke für die neue Karte. In Mapsource sieht das schon mal ganz gut aus.

Für eine "Freizeitkarte" hätte ich noch zwei Wünsche:

1) Ist geplant, eine Karte auch für den Alpenraum anzubieten? Das läge bei einer "Freizeitkarte" nahe.

2) Soweit ersichtlich, werden keine Almen gerendert. Ich fände es gut, wenn sämtliche Gebäude, die einen ele-Tag haben und/oder einen name-Tag haben, gerendert würden. Dann würden Almgebäude nämlich auch angezeigt.

Danke!

Es werden doch alle Gebäude gerendert in der Freizeitkarte?

chris66 wrote:

Es werden doch alle Gebäude gerendert in der Freizeitkarte?

Ich habe mich unklar ausgedrückt: wenn ich es recht sehe, dann werden die Almen nicht mit Namen und Höhe angezeigt. Das fände ich gut, insbesondere, wenn diese Gebäude dann als POI auf dem GPS-Gerät angezeigt werden würden und auf dem GPS-Gerät gezielt danach gesucht werden könnte.

Glücki wrote:

chris66 wrote:

Es werden doch alle Gebäude gerendert in der Freizeitkarte?

Ich habe mich unklar ausgedrückt: wenn ich es recht sehe, dann werden die Almen nicht mit Namen und Höhe angezeigt. Das fände ich gut, insbesondere, wenn diese Gebäude dann als POI auf dem GPS-Gerät angezeigt werden würden und auf dem GPS-Gerät gezielt danach gesucht werden könnte.

Die Alm als Fläche wird wie folgt berücksichtigt:

1. Alm, Matte, Bergwiese, Sommerweide: Bereich oberhalb der Baumgrenze. [point, closedway]
   

natural = fell [0x40 resolution 17]

Berghütten und ähnliches wie folgt:

1. Schutzhütte, Berghütte. [point, closedway]
   

tourism = alpine_hut {name '${name} (Berghütte)' | 'Berghütte'} [0x4803 resolution 24]

1. A lean-to is a building located in the mountains or into the wild intended to provide shelter against rain.
   

tourism = lean_to {name '${name} (Lean-to)' | 'Lean-to'} [0x4803 resolution 24]

1. A Wilderness hut is a building located in the mountains or into the wild intended
   
2. to provide shelter, heating to hikers and climbers.
   

tourism = wilderness_hut {name '${name} (Wilderness hut)' | 'Wilderness hut'} [0x4803 resolution 24]

Ist das Gesuchte dabei?

Gruß Klaus

PS: Für Österreich müßte eine umfangreiche QS gemacht werden - ich suche dafür Interessierte.

toc-rox wrote:

Glücki wrote:

chris66 wrote:

Es werden doch alle Gebäude gerendert in der Freizeitkarte?

Ich habe mich unklar ausgedrückt: wenn ich es recht sehe, dann werden die Almen nicht mit Namen und Höhe angezeigt. Das fände ich gut, insbesondere, wenn diese Gebäude dann als POI auf dem GPS-Gerät angezeigt werden würden und auf dem GPS-Gerät gezielt danach gesucht werden könnte.

Die Alm als Fläche wird wie folgt berücksichtigt:

1. Alm, Matte, Bergwiese, Sommerweide: Bereich oberhalb der Baumgrenze. [point, closedway]
   

natural = fell [0x40 resolution 17]

Berghütten und ähnliches wie folgt:

1. Schutzhütte, Berghütte. [point, closedway]
   

tourism = alpine_hut {name '${name} (Berghütte)' | 'Berghütte'} [0x4803 resolution 24]

1. A lean-to is a building located in the mountains or into the wild intended to provide shelter against rain.
   

tourism = lean_to {name '${name} (Lean-to)' | 'Lean-to'} [0x4803 resolution 24]

1. A Wilderness hut is a building located in the mountains or into the wild intended
   
2. to provide shelter, heating to hikers and climbers.
   

tourism = wilderness_hut {name '${name} (Wilderness hut)' | 'Wilderness hut'} [0x4803 resolution 24]

Ist das Gesuchte dabei?

Hallo Klaus,

hm, leider nein:

1) Almwiesen sind meist mit landuse=meadow getaggt (und ggf. mit einem Namen versehen). Kann dies zusätzlich zu natural=fell berücksichtigt werden?

2) Die Almgebäude, die ich meine sind typischerweise privat, also nicht bewirtet und daher auch keine "alpine_hut", ebensowenig wie wilderness_hut etc. Es sind schlicht private Gebäude der Almbauern, daher als "building=yes" getaggt.

Almen sind trotzdem wichtige Orientierungspunkte im Gebirge ("Aufstieg über die xy-Alm..."), daher wäre es m.E. für eine Freizeitkarte gut und wichtig, wenn man über das GPS-Gerät nach den Almen als POI suchen könnte.

Danke!

Glücki wrote:

Hallo Klaus,

hm, leider nein:

1) Almwiesen sind meist mit landuse=meadow getaggt (und ggf. mit einem Namen versehen). Kann dies zusätzlich zu natural=fell berücksichtigt werden?

2) Die Almgebäude, die ich meine sind typischerweise privat, also nicht bewirtet und daher auch keine "alpine_hut", ebensowenig wie wilderness_hut etc. Es sind schlicht private Gebäude der Almbauern, daher als "building=yes" getaggt.

Almen sind trotzdem wichtige Orientierungspunkte im Gebirge ("Aufstieg über die xy-Alm..."), daher wäre es m.E. für eine Freizeitkarte gut und wichtig, wenn man über das GPS-Gerät nach den Almen als POI suchen könnte.

Danke!

Aber siehst du nicht das eigentliche Problem? Wie soll man denn ein Almgebäude mit building=yes von einem normalen Gebäude mit building=yes unterscheiden? Auch Hausnamen zählen hier nicht! Denn die gibts auch woanders.

Das gleiche ist landuse=meadow. Das ist so allgemein, dass es quasie überall sein könnte. Auch ein entsprechender name ist kein Kriterium für eine Almwiese. Also hier sollte eher das tagging angepasst werden. Denn der Computer kann nicht raten.

Ich hab in meiner Gegend das Gefühl, dass man auf die Höhenangabe ganz gut bauen kann: "Flächen mit building=yes und ele=irgendwas" oder "isolated_dwelling"s mit Höhenwert eignen sich ganz gut zum Erkennen von Almen als Orientierungspunkte.

Aber ich weiss nicht, ob das überall so gilt und bei größeren Flächen am Hang hab ich mentale Schwierigkeiten, eine Höhenangabe zu akzeptieren 😉

Grundsätzlich werden alle Gebäude ausgewiesen (meist als):

1. Gebäude oder Bauwerk allgemein.
   

building = * [0x13 resolution 20]

Zieht man die Maus oder Nadel auf das Gebäude wird der Name (sofern vorhanden) ausgewiesen.
Geplant ist (für 2012) noch eine Version der Freizeitkarte Deutschland mit integrierten Höhenlinien.
Dann hätte man indirekt auch die Höhe des Gebäudes ...

Das ist aber wohl nicht exakt das was du suchst.
Kannst du mal 2 konkrete Beispiele benennen?
Dann könnte man sich das mal ansehen ...

Klaus

toc-rox wrote:

Grundsätzlich werden alle Gebäude ausgewiesen (meist als):

1. Gebäude oder Bauwerk allgemein.
   

building = * [0x13 resolution 20]

Zieht man die Maus oder Nadel auf das Gebäude wird der Name (sofern vorhanden) ausgewiesen.
Geplant ist (für 2012) noch eine Version der Freizeitkarte Deutschland mit integrierten Höhenlinien.
Dann hätte man indirekt auch die Höhe des Gebäudes ...

Das ist aber wohl nicht exakt das was du suchst.
Kannst du mal 2 konkrete Beispiele benennen?
Dann könnte man sich das mal ansehen ...

Klaus

Was ich z. B. meine ist so etwas:

http://www.openstreetmap.org/?lat=47.69 … 7&layers=M

Es handelt sich um eine Alm(wiese) mit einem (Alm-)Gebäude darauf (nicht für die Öffentlichkeit geöffnet). Sowohl die Wiese, als auch das Gebäude tragen den Namen der Alm (Exkurs: es ist eine philosophische Diskussion, ob sich der Almname auf das Almgebiet oder das Gebäude bezieht oder vom Gebäude auf das Gebiet übergeht oder umgekehrt, daher ist beides mit dem Namen getaggt).

Jetzt wäre es gut, wenn man auf dem GPS-Gerät mit "Find" - "alle POI" nach diesem Gebiet oder dem Gebäude suchen könnte, weil das die Orientierung im Gelände erleichtern würde.

Mit allen mir bekannten Karten (All in One Garmin Map, Kleineisel) geht das nicht, was ich schade finde.

Wie in einem anderen Thread bereits geschrieben gibt es kein einheitliches Taggingschema für Almen.
Die aus Deinem Beispiel ist als tourism=alm + amenity=alm getaggt, andere Almen sind wieder komplett
anders getaggt. Da müsst Ihr Alpenmapper euch halt erstmal einigen.

Die im Beispiel benannte Wiese / Alm (Lexenalm) konnte ich via Suche "Alle POIs" finden (BaseCamp Windows 3.2.2).

Die Alm ist wie folgt getaggt:

• landuse: meadow
  
• name: Lexenalm
  

Das Gebäude wie folgt:

• amenity: alm
  
• building: yes
  
• name: Lexenalm
  
• tourism: alm
  

Ich hab mich für meine Kartenspielereien wirklich bemüht, Almen zu erfassen, weil ich halte die auch für wichtig. Aber es ist wie chris66 sagt: Solange es kein auch nur halbwegs einheitliches Schema für Almen gefunden ist, kann man nur im Nebel stochern. Ich hab hier 1200 Dinge in der Datenbank, die "...Alm" heissen und ich finde kaum 100, die ähnlich getagt sind.

Grüße, Max

Und wir drehen uns im Kreis. Die Diskussion hatten wir schon mal:
http://forum.openstreetmap.org/viewtopi … 90#p125790

Meine Meinung:
Alm ist definitiv nicht das Gebäude, sondern die landwirtschaftlich genutzte Fläche (unter speziellen Bedingungen). Ob das ein spezieller tag sein muss, wäre zu diskutieren, da oft meadow zutreffen würde.
Die dortige Hütte muss je nach Nutzung getaggt werden, wobei farmyard, shelter, restaurant, guest_house, chalet usw. infrage kommen 🤔

Edit:
Wikipedia-Links:
http://de.wikipedia.org/wiki/Alm_(Bergweide)
http://de.wikipedia.org/wiki/Almh%C3%BCtte

Mir geht's nicht darum, wie man Almen taggt (das hatten wir in der Tat schon), sondern darum, dass Gebäude und Wiesen (sofern sie einen Namen haben, was auf eine gewisse Bedeutung hindeutet) auf dem GPS-Gerät auffindbar sind.

Offenbar sind mit dieser Karte jedenfalls Wiesen als POI auffindbar. Ich muss mal ausprobieren, ob dies auch auf dem GPS-Gerät funktioniert.

Kann es sein, dass die POI-Suche in der gleichen Karte auf dem Computer anders als auf dem GPS (Garmin GPSmap 60csx) ausfällt?

Glücki wrote:

Mir geht's nicht darum, wie man Almen taggt (das hatten wir in der Tat schon)...

Sorry, ich meinte den post von toc-rox und zwar wegen amenity=alm und tourism=alm an Gebäuden 🤔

hallo,

zunächst einmal: Ich finde die Kartendarstellung am Bildschirm sehr übersichtlich und ansprechend. Für problematisch halte ich allerdings die Farbgebung der Radwege, weil ´normalerweise mit der Farbe "Blau" Gewässer dargestellt werden. Das kann zu Verwirrung führen - bspw. wenn ein kombinierter Rad- Fußweg neben einem Bach verläuft. Wie wär´s mit "Lila"? 😉 Nochmals: "Chapeau!.

Anmerkung: Beim Ausdruck stehen die kleinen Tannenbäumchen auf dem Kopf. Why? (Betriebssystem OSx)

Gruß, harzguide

harzguide wrote:

... Für problematisch halte ich allerdings die Farbgebung der Radwege, weil ´normalerweise mit der Farbe "Blau" Gewässer dargestellt werden. Das kann zu Verwirrung führen - bspw. wenn ein kombinierter Rad- Fußweg neben einem Bach verläuft. Wie wär´s mit "Lila"? ... Beim Ausdruck stehen die kleinen Tannenbäumchen auf dem Kopf. Why? (Betriebssystem OSx)

Dank für das Feedback. Mit der nächsten Ausgabe sollen Gewässer sogar noch deutlich blauer werden.
Damit sind sie auch im Wald erkennbar und werden ihrer Bedeutung als signifikante Landbarriere "gerechter".
Das würde möglicherweise die Verwechselungsgefahr mit Radwegen aber erhöhen (Feedback willkommen).
Hier mal der derzeitige Entwurf:

Aktuell:

Neu:

Das Problem der "kopfstehenden" Polygone (gespiegelt und um 180° gedreht) halte ich (im Moment) für einen BaseCamp-OSX-Defekt.
Sieht bei Flächen wie Parkplätzen (P) oder Schulen (S) sehr unschön aus ... muß ich aber unter Windows nochmal testen.

Gruß Klaus

Hallo,

zunächst mal ´Chapeau´für Arbeit und Mühe. Zu vielen Aspekten ist schon etwas gesagt worden - ich will deshalb darauf nicht noch mal eingehen. Was ich besonders problematisch finde, ist die Farbgebung ´Blau´für die Radwege. Diese Farbe ist in der Kartographie der Konventionen nach Gewässern (künstlich und natürlich) vorbehalten. Daran sollten wir und auch halten, um Verwirrung bei der Interpretation der Karte zu vermeiden.
Dies tritt dann auf, wenn ein so gekennzeichneter Weg neben oder zwischen Gräben verläuft. Ich wollte eigentlich zur Illustration eine screenshot einfügen, das ist mir leider nicht trotz div. Versuche gelungen. (Wer kann mir sagen wie´s geht? Dann kann ich das Bild nachreichen.). Das, u. a. Beispiele finden sich im Naturschutzgebiet Riddagshausen bei Braunschweig.

Gruß harzguide

Ich vermute mal dies ist gemeint:

Schöne Gegend - kenne ich sogar persönlich - ich durfte einige Jahre in Braunschweig verbringen.
Off-Topic: Wieso ist das NSG (und EU-Vogelschutzgebiet) um die Teiche eigentlich nicht eingetragen?

Klaus

Hallo toc-rox

sorry dass ich die Sache heute noch mal aufgegriffen habe, ohne deine Antwort vorher dazu zu lesen - ich habe sie einfach übersehen.

Zu deinen Änderungen: Es ist sicher gut, die Farben intensiver zu machen - insgesamt, nicht nur bei Gewässern. Das löst aber, wie du selbst richtig feststellst, das Problem nicht. Die Farbe ´Blau`sollte unbedingt dem Merkmal ´Wasser´vorbehalten bleiben. Jede/r der mit Karten arbeitet, hat sich daran gewöhnt. Ansonsten würde es immer wieder zu Interpretationsfehlern - zumindest aber zu Irritationen führen. (Ich würde mein Beispielbild gern veröffentlichen, denn daran wird das Problem deutlicher).

Zwei Stunden später:

Nachdem ich einen Blick auf die CyleMap geworfen habe, scheint mit verständlich zu sein, warum du die Farbe ´Blau´für Radwege gewählt hast. In diesem speziellen Fall finde ich das auch (derzeit) vertretbar weil:

1. Für für jede/n unmittelbar ersichtlich ist, dass alle blauen Linien Radwege sind,
und dass
2. Nur Wasserflächen (Teiche, Seen, Talsperren) auf der Karte zu finden sind; Fließgewässer ( Gräben, Bäche, Flüsse), die einen linienförmigen Verlauf haben, hingegen erst gar nicht dargestellt werden.
Damit wird das von mir erwähnte Problem vermieden. Ganz ideal finde ich das zwar nicht (man hätte bspw. auch die Farbe ´Orange´wählen können). Aber wenn die Radfahrer in "ihrer" Karte auf den Verlauf von Fließgewässern verzichten wollen - meinetwegen.

Was ich an "deiner" Freizeitkarte noch besonders positiv finde ist, dass du die Tags "reiten_erlaubt/verboten nicht eingearbeitet hast. Das mit dem taggen der Reitwege ist, wie ich finde noch ein ganz besonderes Kapitel, dass ich an anderer Stelle gern mal genauer unter die Lupe nehmen will.

Mein Vorschlag: Verzichte einfach auf die Differenzierung. Dafür bietet - auch wenn sie noch unvollständig ist - die CycleMap für Radler die entsprechenden Informationen.

Viel Spaß weiterhin bei deiner Arbeit!

Gruß harzguide

Ganz ehrlich! Ich kann deine Kritik nicht wirklich nachvollziehen.
Bei Mapnik werden Radwege (cycleway) auch blau dargestellt. Warum sollte das plötzlich bei anderen Karten ein Problem ist weiß ich nicht.
Ich habe mal zum Spaß verschiedene Radwegekarten angeschaut. Von schwarz über grün, organe bis blau ist da alles dabei. Warum also nicht so lassen wie bisher OSM Standart?

harzguide wrote:

Mein Vorschlag: Verzichte einfach auf die Differenzierung. Dafür bietet - auch wenn sie noch unvollständig ist - die CycleMap für Radler die entsprechenden Informationen.

Nein, verzichte bitte nicht darauf. ich finde diese sehr wichtig. nur weils irgendwo inner anderen Karte die Informationen gibt, braucht man sie hier ja nicht weglassen.
wenn ich in einer Karte vereint alle möglichkeiten habe ist mir das 10* lieber als wenn ich 10 Karten aktuell halten muss.

und wenn die Gefahr zum verwechseln besteht, (vor allem durch das dunkler machen von Gewässer) dann ändere lieber die Farbe als auf die Differenzierung zu verzichten.

Hallo an alle,

danke für eure Beiträge. Hier meine Anmerkungen:

@viw: Ich habe das nicht als Kritik gemeint - und Klaus hat es offensichtlich auch nicht so verstanden. Das in cycleway die Radwege blau dargestellt werden, hatte ich bereits erwähnt. Ich hatte auch bemerkt, dass ich das in diesem Fall nicht so problematisch finde und das begründet. Es mag ja sein, dass du die Begründung nicht nachvollziehen kannst. Einverstanden! Aber ich erwarte schon, dass du meinen post genau liest, bevor du darauf antwortest. Danke.

@jayjay: Ich habe volles Verständnis dafür, dass DU dir wünscht, möglichst viele Informationen auf einer Karte zu finden. Wenn die Karteninformationen allerdings nicht eindeutig zu identifizieren bzw. bestimmten geographischen Gegebenheiten vor Ort zuzuordnen sind, sind es halt keine "wirklichen" Informationen mehr, die dir (u.a.) weiterhelfen (dann landest du nämlich - zumindest theoretisch) in einem Graben und nicht auf einem Radweg. Wenn es möglich sein sollte, für diese Art von Radwegen in der Freizeitkarte eine Farbe auszuwählen, die dieses Problem beseitigt - meinetwegen. Übrigens: Auch dazu findet sich in meiner Antwort an Klaus ein Hinweis. Zitat: "Ganz ideal finde ich das zwar nicht (man hätte bspw. auch die Farbe ´Orange´wählen können). Aber wenn die Radfahrer in "ihrer" Karte auf den Verlauf von Fließgewässern verzichten wollen - meinetwegen." Also auch an dich die freundliche Bitte: Erst genau lesen und erst dann zu meinem Diskussionsbeitrag Stellung nehmen. (Nichts für ungut ist keine Kritik sondern eine Bitte!)

@ Klaus: Du hast mich mal wieder überholt. Nein es ist nicht der Ausschnitt, den ich gemeint habe, aber der ist auch schon ganz aufschlussreich. Mein Kartenausschnitt ist noch etwas prägnanter. Deshalb wiederhole ich meine Bitte mir mitzuteilen, wie ich mein Bild posten kann. Vielen Dank.

Gruss an alle, Burkhard (harzguide)

harzguide wrote:

Zitat: "Ganz ideal finde ich das zwar nicht (man hätte bspw. auch die Farbe ´Orange´wählen können). Aber wenn die Radfahrer in "ihrer" Karte auf den Verlauf von Fließgewässern verzichten wollen - meinetwegen." Also auch an dich die freundliche Bitte: Erst genau lesen und erst dann zu meinem Diskussionsbeitrag Stellung nehmen. (Nichts für ungut ist keine Kritik sondern eine Bitte!)

Ich habe deinen Beitrag sehr wohl vollständig gelesen und verstanden. Ich wollte nur darauf hinweisen, dass ich es bevorzugen würde, eine andere Farbe zu verwenden, bevor man gar keine Unterscheidungsmöglichkeit lässt (wie ich auch schon in meinem letzten Beitrag geschrieben).

Und ich möchte eben nicht in den Verlauf von Fließgewässern verzichten.
Mit der jetzigen Farbgestaltung habe ich allerdings auch kein Problem Gewässer von Radwegen zu unterscheiden. (auf dem etrex30), wie ich aber in meinem letzten Beitrag erwähnt habe, befürchte ich da eine Verschlechterung mit der Sättigung der Gewässerfarbe

zumal ich (danke toc-rox) es jetzt auch geschafft habe meine eigene Karte zu rendern, nimm also auf mich keine rücksicht mehr 😉

Jayjay01 wrote:

... zumal ich (danke toc-rox) es jetzt auch geschafft habe meine eigene Karte zu rendern ...

Sehr schön, daß die Entwicklungsumgebung läuft und du dir deine individuelle Karte erzeugen kannst.
Genau dafür ist die Entwicklungsumgebung gedacht - alle Interessenlagen kann man einfach nicht abdecken.
Laß uns zu gegebener Zeit an deinen Erkenntnissen teilhaben.
Was hat sich bewährt, was ging gar nicht, was sollte in die allgemeine Karte ...
Viel Freude und Erfolg bei der Entwicklung - Klaus

harzguide wrote:

Hallo an alle,

danke für eure Beiträge. Hier meine Anmerkungen:

@viw: Ich habe das nicht als Kritik gemeint - und Klaus hat es offensichtlich auch nicht so verstanden. Das in cycleway die Radwege blau dargestellt werden, hatte ich bereits erwähnt. Ich hatte auch bemerkt, dass ich das in diesem Fall nicht so problematisch finde und das begründet. Es mag ja sein, dass du die Begründung nicht nachvollziehen kannst. Einverstanden! Aber ich erwarte schon, dass du meinen post genau liest, bevor du darauf antwortest. Danke.

Danke für die Blumen,

viw wrote:

Ganz ehrlich! Ich kann deine Kritik nicht wirklich nachvollziehen.
Bei Mapnik werden Radwege (cycleway) auch blau dargestellt. Warum sollte das plötzlich bei anderen Karten ein Problem ist weiß ich nicht.

http://www.openstreetmap.org/?lat=48.70 … 8&layers=M

Ich hatte meinen ersten Satz genau wie du in deinem Beitrag begründet. Und ich habe mit meiner Einschätzung versucht deine Argumente, dass die Fahrradkarte das nur täte weil sie Gewässer nicht blau darstellt, zu entkräften. Daher kann ich deine Schlussfolgerungen auch nicht nachvollziehen.

viw wrote:

...
Bei Mapnik werden Radwege (cycleway) auch blau dargestellt. Warum sollte das plötzlich bei anderen Karten ein Problem ist weiß ich nicht.
...

Für meine altersmüden Augen ergibt sich das Problem dadurch, dass die Radwege in Mapnik als gestrichelte blaue Linie klar von den Fließgewässern als durchgezogene blaue Linie unterscheidbar ist, während die Freizeitkarte kombinierte Rad-/Fußwege durchgezogen blau darstellt 🤔
Die Unterscheidungsmöglichkeit finde ich gut, aber nicht gut dargestellt. Kann man da nicht eine Linienkombination blau-rot im Wechsel einbauen?

hurdygurdyman wrote:

viw wrote:

...
Bei Mapnik werden Radwege (cycleway) auch blau dargestellt. Warum sollte das plötzlich bei anderen Karten ein Problem ist weiß ich nicht.
...

Für meine altersmüden Augen ergibt sich das Problem dadurch, dass die Radwege in Mapnik als gestrichelte blaue Linie klar von den Fließgewässern als durchgezogene blaue Linie unterscheidbar ist, während die Freizeitkarte beides durchgezogen darstellt 🤔
Wäre doch auch 'ne Lösung für die Freizeitkarte 😉

der Screenshot weiter oben zeigt eigentlich genau die gleiche Darstellung. (gestrichelt bzw. durchgezogen)

viw wrote:

hurdygurdyman wrote:

viw wrote:

...
Bei Mapnik werden Radwege (cycleway) auch blau dargestellt. Warum sollte das plötzlich bei anderen Karten ein Problem ist weiß ich nicht.
...

Für meine altersmüden Augen ergibt sich das Problem dadurch, dass die Radwege in Mapnik als gestrichelte blaue Linie klar von den Fließgewässern als durchgezogene blaue Linie unterscheidbar ist, während die Freizeitkarte beides durchgezogen darstellt 🤔
Wäre doch auch 'ne Lösung für die Freizeitkarte 😉

der Screenshot weiter oben zeigt eigentlich genau die gleiche Darstellung. (gestrichelt bzw. durchgezogen)

Sorry, hatte meinen Post gerade überarbeitet.
Welchen screenshot meinst du, Mapnik oder Freizeitkarte?
Ich orientiere mich gerade an dieser Legende. http://www.easyclasspage.de/karten/seite-11.html
da sind Fußwege rötlich durchgezogen und Radwege blau gestrichelt. Die gemeinsame Nutzung allerdings blau durchgezogen.

hurdygurdyman wrote:

... Kann man da nicht eine Linienkombination blau-rot im Wechsel einbauen? ...

Das hatte ich schon versucht - wäre ja auch "sehr" logisch - sah leider aber nicht sehr schön aus.
Klaus

toc-rox wrote:

http://www.easyclasspage.de/karten/imag … Radweg.png

viw wrote:

toc-rox wrote:

http://www.easyclasspage.de/karten/imag … Radweg.png

Das ist Mapnik:
http://www.openstreetmap.org/?lat=52.27 … 7&layers=M

Edit:
Doppelpost 🙁

Hallo,
vielen Dank für deine Karte und insbesondere auch für die sehr gute Legende.
Mir ist aufgefallen, dass alle Wege bereits in einer Zoomstufe verschwinden, in der sie bei anderen mir bekannten OSM-Karten noch sichtbar sind. Gerade für eine sinnvolle Darstellung im ländlichen Raum halte ich es für besser diese oft ortsverbindenden Wege auch in etwas größerem Maßstab noch zu sehen

gruß
CADdog63

toc-rox wrote:

harzguide wrote:

... Beim Ausdruck stehen die kleinen Tannenbäumchen auf dem Kopf. Why? (Betriebssystem OSx)

... Das Problem der "kopfstehenden" Polygone (gespiegelt und um 180° gedreht) halte ich (im Moment) für einen BaseCamp-OSX-Defekt.
Sieht bei Flächen wie Parkplätzen (P) oder Schulen (S) sehr unschön aus ... muß ich aber unter Windows nochmal testen. ...

Unter BaseCamp-Windows (3.2.2) tritt das Problem NICHT auf.
Vermutung deshalb: Spezifisches BaseCamp-OSX (3.2.2)-Problem.

Frage: Könnte jemand das Druckergebnis einer Original-Garmin-Karte unter BaseCamp-OSX (3.2.2) prüfen?

Klaus

Zoomstufen und Straßen:

Anmerkung von chris66: ... ab Zoom 3 km werden überhaupt keine Straßen mehr gezeigt, ist das beabsichtigt? ...
Anmerkung von CADdog63: ... dass alle Wege bereits in einer Zoomstufe verschwinden, ...

Ich habe mir das nochmal angesehen - es gilt:
- Die Zoomstufen zwischen BaseCamp und dem GPS-Gerät unterscheiden sich signifikant.
- Die Zoomstufen in BaseCamp sind abhängig von der Bildschirmauflösung.

Ausgelegt hatte ich das Zoom-Verhalten für eine Full-HD-Auflösung und für eine Dakota-GPS-Gerät.

Hier gilt folgendes:

#␣Level␣/␣Resolution␣/␣Maßstab:
#␣-----------------------------
#␣BaseCamp␣␣␣␣␣␣␣␣␣␣␣␣␣␣Dakota-20
#␣----------------␣␣␣␣␣␣-----------------
#␣0␣=␣24␣=␣␣0.7␣km␣␣␣␣␣␣␣␣␣200␣␣m
#␣1␣=␣23␣=␣␣1.5␣km␣␣␣␣␣␣␣␣␣300␣␣m
#␣2␣=␣22␣=␣␣3.0␣km␣␣␣␣␣␣␣␣␣500␣␣m␣(800␣m)
#␣3␣=␣21␣=␣␣5.0␣km␣␣␣␣␣␣␣1.2␣␣␣km␣(2␣km)
#␣4␣=␣20␣=␣10.0␣km␣␣␣␣␣␣␣3␣␣␣␣␣km
#␣5␣=␣19␣=␣20.0␣km␣␣␣␣␣␣␣5␣␣␣␣␣km␣(8␣km)
#␣6␣=␣18␣=␣50.0␣km␣␣␣␣␣␣12␣␣␣␣␣km
#␣7␣=␣17␣=␣70.0␣km␣␣␣␣␣␣20␣␣␣␣␣km

Die "wichtigen" Strassen sind bis Resolution 20 sichtbar.
In BaseCamp (Full-HD-Auflösung) entspricht dies dem (angezeigten) Maßstab "10km".
Im Dakota entspricht dies dem (angezeigten) Maßstab "12km".

Klaus

PS: BaseCamp (Windows, OS X) mit hoher Bildschirmauflösung stellt eine signifikante Verbesserung dar.

PPS: @CADdog63 - Danke für das Feedback.

toc-rox wrote:

Ausgelegt hatte ich das Zoom-Verhalten für eine Full-HD-Auflösung

Hallo Klaus,
also ist wohl mein Bildschirm, der nur 1280x1024 schafft, nicht unschuldig.
Jedenfalls sind bei mir im BaseCamp die Wege nur bis zoomstufe 300m sichtbar, während es z.B. die Karte OSM_SRTM_Germany von Kleineisel auch bei 500m und 700m noch darstellt, was ich persönlich für mich und meine Anwendung und Gewohnheiten eben angenehmer empfinde. Aber es ist ja deine Karte.

CADdog63 wrote:

... Jedenfalls sind bei mir im BaseCamp die Wege nur bis zoomstufe 300m sichtbar ... Aber es ist ja deine Karte.

Frage: Sind die Maßstabsangaben korrekt ?

Mit einer Full-HD-Auflösung solltest du erhalten:

Klaus

PS: Es ist genauso auch deine Karte - du kannst sie an deine individuellen Anforderungen anpassen (siehe Entwicklungsumgebung).

toc-rox wrote:

Zoomstufen und Straßen:

PS: BaseCamp (Windows, OS X) mit hoher Bildschirmauflösung stellt eine signifikante Verbesserung dar.

Man kann in BaseCamp docht auch die Detailstufe manuell höher setzen.
Die Symbolleiste muß man eventuell erst einschalten mit Ansicht / Symbolleisten / Detailstufe
Wirds dann besser?

Gruß,
ajoessen

ajoessen wrote:

Man kann in BaseCamp docht auch die Detailstufe manuell höher setzen.

ja, ich hatte es aber auf gleicher Detailstufe verglichen
Mich hatte eben nur auch etwas gewundert, wie unterschiedlich doch die Vorstellungen sind, was in welcher zoomstufe zu sehen sein sollte.
Ich habe es jetzt nochmal auf dem Dakota20 verglichen, da zeigt die Freizeitkarte dasselbe Verhalten diesmal z.B. im Vergleich zur aio von computerteddy. Wege sind bis zoomstufe 300m zu sehen, statt 800m bei der aio
Ich bitte dies wirklich nicht als abwertende Kritik zu verstehen. Da ich auch beruflich mit Karten zu tun habe, weiß ich, dass da persönliche Vorlieben und Gewohnheiten sehr wichtig sind.
Ich wollte es eben nur angesprochen haben.

etwas ist mir noch aufgefallen
http://www.openstreetmap.org/?lat=51.15 … 7&layers=M
hier gibt es Gärten (landuse allotments), die über landuse residential liegen.
Ich hatte mit so etwas bisher in keine Karte Probleme bei der Darstellung, in der Freizeitkarte aber liegt aber wohl residential oben

CADdog63 wrote:

etwas ist mir noch aufgefallen
http://www.openstreetmap.org/?lat=51.15 … 7&layers=M
hier gibt es Gärten (landuse allotments), die über landuse residential liegen.
Ich hatte mit so etwas bisher in keine Karte Probleme bei der Darstellung, in der Freizeitkarte aber liegt aber wohl residential oben

Sauberer wäre es, beide zu trennen. Kleingärten gehören nicht unbedingt zu Wohngebieten.

Gruß,
ajoessen

+1
Typischerweise ist das "Wohnen" dort ausdrücklich verboten.

Gruß
Georg

CADdog63 wrote:

ajoessen wrote:

Man kann in BaseCamp docht auch die Detailstufe manuell höher setzen.

ja, ich hatte es aber auf gleicher Detailstufe verglichen
Mich hatte eben nur auch etwas gewundert, wie unterschiedlich doch die Vorstellungen sind, was in welcher zoomstufe zu sehen sein sollte.
Ich habe es jetzt nochmal auf dem Dakota20 verglichen, da zeigt die Freizeitkarte dasselbe Verhalten diesmal z.B. im Vergleich zur aio von computerteddy. Wege sind bis zoomstufe 300m zu sehen, statt 800m bei der aio
Ich bitte dies wirklich nicht als abwertende Kritik zu verstehen. Da ich auch beruflich mit Karten zu tun habe, weiß ich, dass da persönliche Vorlieben und Gewohnheiten sehr wichtig sind.
Ich wollte es eben nur angesprochen haben.

Stell doch bitte mal zwei Screenshots (Windows und GPS-Gerät) ein.
Mich wundern nach wie vor die Zoomstufenangaben "300m" bzw. "800m".

Klaus

PS: Details sollten auf Maximum eingestellt werden.

CADdog63 wrote:

etwas ist mir noch aufgefallen
http://www.openstreetmap.org/?lat=51.15 … 7&layers=M
hier gibt es Gärten (landuse allotments), die über landuse residential liegen.
Ich hatte mit so etwas bisher in keine Karte Probleme bei der Darstellung, in der Freizeitkarte aber liegt aber wohl residential oben

Danke für den Hinweis - das ist wohl ein Defekt - entweder in der Karte oder den OSM-Daten.
In der Karte haben "residential" und "allotments" die gleiche Zeichenpriorität (4).
Ich bin davon ausgegangen, daß beide Flächen gleichwertige "Basisflächen" sind.
Frage: Sollte man die OSM-Daten oder die Zeichenpriorität korrigieren?

Klaus

ajoessen wrote:

Sauberer wäre es, beide zu trennen. Kleingärten gehören nicht unbedingt zu Wohngebieten.

zweifellos
Aber da gibt es auch hier im Forum immer mal Diskussionen, wie kleine Flächen innerhalb großer sinnvoll zu mappen sind
Für mich ist es bisher eine Frage von Aufwand und Nutzen

toc-rox wrote:

Details sollten auf Maximum eingestellt werden.

Dann gibt es wie schon berichtet, keine Probleme
Mit den "zoomstufen 300m bzw 800m" auf dem Garmin Dakota20 meinte ich den in der Kartendarstellung eingeblendeteten Maßstabsbalken

toc-rox wrote:

Frage: Sollte man die OSM-Daten oder die Zeichenpriorität korrigieren?

Klaus

In diesem Falle ersteres. Dann fällt dem Mapper auch gleich der Fehler auf ;-)

Gruß,
ajoessen

ajoessen wrote:

CADdog63 wrote:

etwas ist mir noch aufgefallen
http://www.openstreetmap.org/?lat=51.15 … 7&layers=M
hier gibt es Gärten (landuse allotments), die über landuse residential liegen.
Ich hatte mit so etwas bisher in keine Karte Probleme bei der Darstellung, in der Freizeitkarte aber liegt aber wohl residential oben

Sauberer wäre es, beide zu trennen. Kleingärten gehören nicht unbedingt zu Wohngebieten.

Gruß,
ajoessen

residential <> allotments, definitiv Datenfehler, was eigentlich nicht übereinander liegen sollte, kann auch auf gleicher stufe gerendert werden.
auch kann man nicht definitiv sagen, was dann automatisch richtiger ist, sowohl könnten allotments über residential liegen als auch umgekehrt.

Ich würde die Kleingärten mit Hilfe eines Multipolygons als "inner" aus residential (=outer) "ausstanzen". Dann sollte die Zeichenreihenfolge gleichgültig sein. Genau dafür sind MPs nach meinem Verständnis da.

Gruß
tippeltappel

Frage an die Mapper: Warum gibt es für Hamburg eigentlich keinen POI "place = city" ?

Klaus

ajoessen wrote:

toc-rox wrote:

Frage: Sollte man die OSM-Daten oder die Zeichenpriorität korrigieren?

Klaus

In diesem Falle ersteres. Dann fällt dem Mapper auch gleich der Fehler auf ;-)

Gruß,
ajoessen

gut, der konkrete Fall ist korrigiert.
Allerdings ist mir aufgefallen, dass ich ohne Mühe dutzende Fälle gefunden habe, wo nicht nur Kleingärten sondern auch Friedhof, Rasenfläche und Regenrückhaltebecken über residential liegt , also eigentlich gleichwertige landuse-Flächen übereinander gezeichnet wurden.
Deshalb erscheint es mir nach wie durchaus sinnvoll, ob man beim Rendern der Karte nicht versuchen sollte, diese Fehler so weit wie möglich, auszubügeln. Insbesondere wenn es eben keinen zusätzlichen Aufwand bedeutet.

das problem ist da halt immer, du weißt nicht, ob die leute das kleine Waldstück übers Wohngebiet eintragen oder aber die kleine Siedlung über den Wald.
Wenn es trotz Fehler richtig gerendert wird, fällt der Fehler halt leider nicht so auf und es bleibt weiterhin falsch.

Von der Freizeitkarte Deutschland ist die Ausgabe 11.12 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 10.12.2011.

Link: http://www.easyclasspage.de/karten/index.html

Ergänzungen / Veränderungen gegenüber der vorherigen Version:
- Schrebergärten werden mit grünem statt braunem Gitter dargestellt
- im Bau befindliche Straßen werden ausgewiesen (highway = construction)
- Verbesserung der Adresssuche (in Zusammenarbeit mit Ludwich und Georg V.)
- Vereinheitlichung der Adresssuche für Hamburg
- das Präfix "Gemeinde " ist bei der Ortsangabe nicht mehr erforderlich (z.B. "Spalt" statt "Gemeinde Spalt"; betrifft 658 Gemeinde)
- das Präfix "Stadt " ist bei der Ortsangabe nicht mehr erforderlich (z.B. "Rodgau" statt "Stadt Rodgau", betrifft 67 Städte)
- allgemeine Verbesserung der Entwicklungsumgebung

Die Karte befindet sich im Status "Erprobung" - hilf mit sie zu verbessern - Danke.

Gruß Klaus

Danke, hoffentlich sind die Gewässer so geblieben wie sie waren? 😉

chris66 wrote:

Danke, hoffentlich sind die Gewässer so geblieben wie sie waren? 😉

Ja, die Gewässerfarbe ist unverändert geblieben.
Die Verwechselungsgefahr mit Radwegen ist zu groß.
Das war ja auch das Diskussionsergebnis hier ...

Klaus

vielen dank für die neue Entwicklungsumgebung (und die neue karte),

bin gerade dabei meine Karte zu bauen.

zu meinen erfahrungen mit der entwicklungsumgebung:
lieft alles eigentlich gut, anfangs probleme mit java-heap-space, da er anstatt der 64bit die 32bit version von java genommen hat, da musste ich den PATH entsprechend an die 64bit version anpassen aber seitdem läufts.

die neue version teste ich wie gesagt gerade.

ein fehler ist mir aufgefallen ( bei einem routing)
wenn ich Herxheimer Straße oder Herxheimerstraße bei der Adresssuche eingebe (ich muss mal schauen, welches die richtige schreibweise ist, online finde ich beides^^) und mich Routen lasse (egal ob Fahrrad/Fuß oder Autoeinstellungen) dann schickt er mich erst sonstwohin und dann luftlinie über 2km, egal von wo ich starte. (auch wenn ich in der Herxheimer straße stehe)
Es sind allerdings zwei unterschiedliche Punkte zu denen er mich schick, wenn ich jeweils eine der beiden schreibweisen probiere.

Kann das mal wer ausprobieren, ob das bei euch auch so ist?

Wenn ich manuell einen Punkt auf der Herxheimer straße wähle, funktioniert das routing. Der Punkt der angesteuert wird, wenn ich die Adresssuche nutze liegt etwas neben der straße. Wenn ich jedoch manuell einen Punkt etwas neben der Straße anwähle, funktioniert es auch.

als gerät nutze ich das etrex 30

in BaseCamp geht es, aber da kann ich ja auch nicht in dieser form nach adressen suchen.

So sieht das ganze dann aus:
Gesamtblick:


Wendepunkt für Fußgänger

Und der Wendepunkt für Autofahrer:

Wieso sind die Allotments auf den Screenshots so schwarz ?

Nachtmodus?

Edit: Grade mal am 20er ausprobiert: Yupp, im Nachtmodus sieht die Karte so komisch aus.

toc-rox wrote:

Wieso sind die Allotments auf den Screenshots so schwarz ?

jo, wie chris schon geschrieben hat, liegt das am nachtmodus (der sich mal wieder aktiviert hat, weil mein etrex 30 sowieso nur einstellungen speichert wie es will)

achja, hab vergessen zu sagen, dass das bei der alten freizeitkarten auch schon so war, mit diesem routingfehler. die beiden straßen-schreibweisen waren die einzigen beiden wo mir so ein fehler aufgefallen ist, andere straßen haben funktioniert. das heißt natürlich noch lange nicht, dass alle anderen funktionieren -_-

chris66 wrote:

... Yupp, im Nachtmodus sieht die Karte so komisch aus ...

Ich vermute mal, daß im Nachtmodus beim neuen eTrex der Kartenhintergrund abgedunkelt (schwarz statt beige) wird.
Da Ackerflächen in der FZK als "Kartenhintergrund" dargestellt werden, sollten im Mittel dann ca. 52% der Karte abgedunkelt sein.
Läßt sich diese "dunkle Seite" des neuen eTrex möglicherweise sinnvoll nutzen? Z.B. bei Nachttouren oder -fahrten?

Klaus

Jayjay01 wrote:

ein fehler ist mir aufgefallen ( bei einem routing)
wenn ich Herxheimer Straße oder Herxheimerstraße bei der Adresssuche eingebe (ich muss mal schauen, welches die richtige schreibweise ist, online finde ich beides^^) und mich Routen lasse (egal ob Fahrrad/Fuß oder Autoeinstellungen) dann schickt er mich erst sonstwohin und dann luftlinie über 2km, egal von wo ich starte. (auch wenn ich in der Herxheimer straße stehe)
Es sind allerdings zwei unterschiedliche Punkte zu denen er mich schick, wenn ich jeweils eine der beiden schreibweisen probiere.

Kann das mal wer ausprobieren, ob das bei euch auch so ist?

There could be a mkgmap bug in the styles, if I look in Klaus' scripts he is using routable lines without road_class / road_speed: highway = residential [0x06 resolution 24 continue]

See also http://forum.openstreetmap.org/viewtopi … 81#p208081

ligfietser wrote:

Jayjay01 wrote:

ein fehler ist mir aufgefallen ( bei einem routing)
wenn ich Herxheimer Straße oder Herxheimerstraße bei der Adresssuche eingebe (ich muss mal schauen, welches die richtige schreibweise ist, online finde ich beides^^) und mich Routen lasse (egal ob Fahrrad/Fuß oder Autoeinstellungen) dann schickt er mich erst sonstwohin und dann luftlinie über 2km, egal von wo ich starte. (auch wenn ich in der Herxheimer straße stehe)
Es sind allerdings zwei unterschiedliche Punkte zu denen er mich schick, wenn ich jeweils eine der beiden schreibweisen probiere.

Kann das mal wer ausprobieren, ob das bei euch auch so ist?

There could be a mkgmap bug in the styles, if I look in Klaus' scripts he is using routable lines without road_class / road_speed: highway = residential [0x06 resolution 24 continue]

See also http://forum.openstreetmap.org/viewtopi … 81#p208081

Thx, i changed it in my style-file and now it works.

So, das sollte dann auch in den originalen Stylefiles geändert werden.

ligfietser wrote:

There could be a mkgmap bug in the styles, if I look in Klaus' scripts he is using routable lines
without road_class / road_speed: highway = residential [0x06 resolution 24 continue]

Thanks ligfietser for revising the lines style file.
Yes you are right, there was a defect in the logic.
Some lines were (incorrectly) processed twice.

Regards Klaus

Mein erstes kurzes Feedback, nachdem ich die Karte zum ersten Mal auf ein Garmin 60csx geladen habe.

Was mir gefällt:
- Berge werden mit Höhenangabe angezeigt.
- Namen von Wiesen sind mit POI-Suche auffindbar

Was mir nicht gefällt:
- V.a. die farbliche Darstellung: auf dem GPSmap60csx hat die Karte für meinen Geschmack viel zu wenig Kontraste, z.B. sind alle Wälder grau (statt satt grün wie z. B. bei der All in one), Wiesenlichtungen (blass grün) sind darin kaum erkennbar. So hat man dann oft graue Straßen in grauen Wäldern und man erkennt wenig bis gar nichts. Auch Gewässer sind blass grau. Für die Nutzung im Sonnenlicht m.E. nicht geeignet - für mich als Outdoor Nutzer ein K.O. Kriterium.

- Viele Kartenelemente werden erst angezeigt, wenn man sehr weit in die Karte hineinzoomt (Maßstab 300m oder 500m, z.B. Berge, Bäche). Auch Ortsnamen sind erst bei vergleichsweise großem Zoom erkennbar. Bei Zoomstufe 3 km werden überhaupt keine Straßen mehr angezeigt und auch keine (kleineren) Ort mehr - die Karte weist dann in ländlicher Gegend fast überhaupt keine Infos mehr auf. Die Zoomlevel sollte daher m.E. verändert werden.

Bitte diese Punkte als Anregung zur Verbesserung, nicht als Kritik verstehen, ich finde es toll, wenn es neue Karten gibt und hoffe, die Freizeitkarte weiterentwickelt wird, aber derzeit gefallen mir die AiO und die Kleineisel-Karte von ihrer Darstellung noch deutlich besser.

EDIT: zur Klarstellung: in Mapsource sieht die Karte gut aus. Auf dem Garmin-Gerät 60 csx ist die Darstellung allerdings ganz anders, darauf beziehen sich die obigen Anmerkungen.

Hallo,

ich bin die alten posts zum Thema Freizeitkarte noch mal durchgegangen. toc-rox hatte am 8. 12. darum gebeten, dass Druckergebnis einer Original-Garmin Karte unter BaseCamp zu prüfen. Das habe ich gerade getan. Das Ergebnis: Auch bei dieser Karte stehen die "Bäumchen im Wald" auf dem Kopf.

Gruß, Burkhard

harzguide wrote:

... ich bin die alten posts zum Thema Freizeitkarte noch mal durchgegangen.
toc-rox hatte am 8. 12. darum gebeten, dass Druckergebnis einer Original-Garmin Karte unter BaseCamp zu prüfen.
Das habe ich gerade getan.
Das Ergebnis: Auch bei dieser Karte stehen die "Bäumchen im Wald" auf dem Kopf. ...

Hallo Burkhard,

danke für den Test.

Fragen:
Könntest du noch einen Screenshot davon einstellen oder mir zuschicken?
Bei welcher Original-Garminkarte tritt das Problem auf?
Mit welcher BaseCamp OS X - Version hast du getestet?

Ich würde dann eine Fehlermeldung gegenüber Garmin eröffnen.

Klaus

PS: Anfang nächstes Jahres dürfte die nächste BaseCamp-Version (3.3) kommen.
Für Windows gibt es schon eine Beta-Version, die Mac-Version folgt wohl in Kürze.
Möglicherweise hat sich beim Routing erneut wieder einiges geändert.

Glücki wrote:

Was mir nicht gefällt:
- V.a. die farbliche Darstellung: auf dem GPSmap60csx hat die Karte für meinen Geschmack viel zu wenig Kontraste, z.B. sind alle Wälder grau (statt satt grün wie z. B. bei der All in one), Wiesenlichtungen (blass grün) sind darin kaum erkennbar. So hat man dann oft graue Straßen in grauen Wäldern und man erkennt wenig bis gar nichts. Auch Gewässer sind blass grau. Für die Nutzung im Sonnenlicht m.E. nicht geeignet - für mich als Outdoor Nutzer ein K.O. Kriterium.
- Viele Kartenelemente werden erst angezeigt, wenn man sehr weit in die Karte hineinzoomt (Maßstab 300m oder 500m, z.B. Berge, Bäche). Auch Ortsnamen sind erst bei vergleichsweise großem Zoom erkennbar. Bei Zoomstufe 3 km werden überhaupt keine Straßen mehr angezeigt und auch keine (kleineren) Ort mehr - die Karte weist dann in ländlicher Gegend fast überhaupt keine Infos mehr auf. Die Zoomlevel sollte daher m.E. verändert werden.

Hallo Glücki,

danke für das Feedback.

Bezüglich des ersten Punktes verweise ich mal auf dies: http://www.easyclasspage.de/karten/seite-8.html

Hilf mit !
Du kannst mithelfen diese Karte zu verbessern. Dies ist auf unterschiedliche Arten möglich:

Kartendaten:
Hilf mit die OpenStreetMap-Quelldaten dieser Karte, und damit auch diese Themenkarte, zu verbessern.
Fehlende oder inkorrekte Kartendaten kannst auch du auf OpenStreetMap eintragen oder korrigieren.
Dies geht viel leichter als du vielleicht glaubst. Melde dich hierzu auf OpenStreetMap an und versuche es einfach mal.
Alle anderen Kartennutzer können so von deinem Wissen profitieren.

Kartennutzung:
Falls irgend etwas nicht so wie erwartet funktioniert oder aussieht, solltest du das "Problem" melden.
Nur so kann man den Sachverhalt prüfen und vielleicht schon mit der nächsten Kartenausgabe beheben.

Optisches Darstellung:
Das optische Erscheinungsbild der Karte wird durch ein sogenanntes Typfile definiert.
Du kannst, mit etwas technischem Hintergrundwissen, das Erscheinungsbild der Karte grundlegend verändern.
Sei es, weil dir "dein" Design besser gefällt, oder du für ein spezielles GPS-Gerät Anpassungen vorgenommen hast.
Stelle deine Arbeiten doch allen Nutzern zur Verfügung.

Eigene Karte:
Über die Entwicklungsumgebung der Karte ist es "leicht" möglich,
aus der Freizeitkarte Deutschland eigene oder spezielle Kartenvarianten abzuleiten.
Stelle deine Spezialkarte doch allen Nutzern zur Verfügung.

D.h. ich hoffe auf entsprechend angepaßte TYP-Files.
Bei der Karteninstallation würde man dann sein "Wunschdesign" angeben können.

Bezüglich des zweiten Punktes gibt es in vielen Garmingeräten die Möglichkeit die Zoomstufen
für "Kartenpunkte, Benutzer-Wegpunkte, Strassenname, Landbedeckung" anzupassen.
Vielleicht bringt dich dies "weiter" ...

Gruß Klaus

Hallo Klaus,

ich würde den Kartenausschnitt ja gern an meine Mail anhängen - aber auf die übliche Art wie bei ´normalen´ E-Mails gelingt mir das nicht. Ich habe da irgendwie ein Informationsdefizit (ich hatte schon in vorherigen posts um einen hilfreichen Hinweis gebeten, wie ich das mit dem Anhängen von screenshots geregelt kriege).

Deshalb die Antworten (leider) zunächst ohne screenshot:

1. Das Problem trat auf bei der Garmin-Topo Nord 2010

2. BaseCamp Version 3.2.2.

3. OSX Version 10.6.8.

P. S. Zwischenzeitlich hatte ich Probleme den Server zu erreichen, um die neue Version deiner Karte herunterzuladen. Inzwischen scheint es wieder zu funktionieren.

Gruß, Burkhard

harzguide wrote:

... ich würde den Kartenausschnitt ja gern an meine Mail anhängen ...

Du mußt das Bild auf einen Internet-Server hochladen (z.B. Bilderdienst) und dann hier darauf verlinken.

Gruß - Klaus

Glücki wrote:

- V.a. die farbliche Darstellung: auf dem GPSmap60csx hat die Karte für meinen Geschmack viel zu wenig Kontraste, z.B. sind alle Wälder grau (statt satt grün wie z. B. bei der All in one), Wiesenlichtungen (blass grün) sind darin kaum erkennbar. So hat man dann oft graue Straßen in grauen Wäldern und man erkennt wenig bis gar nichts. Auch Gewässer sind blass grau. Für die Nutzung im Sonnenlicht m.E. nicht geeignet - für mich als Outdoor Nutzer ein K.O. Kriterium.
- Viele Kartenelemente werden erst angezeigt, wenn man sehr weit in die Karte hineinzoomt (Maßstab 300m oder 500m, z.B. Berge, Bäche). Auch Ortsnamen sind erst bei vergleichsweise großem Zoom erkennbar. Bei Zoomstufe 3 km werden überhaupt keine Straßen mehr angezeigt und auch keine (kleineren) Ort mehr - die Karte weist dann in ländlicher Gegend fast überhaupt keine Infos mehr auf. Die Zoomlevel sollte daher m.E. verändert werden.

"Graue Wälder, graue Lichtungen" - kommt mir "merkwürdig" vor ...
Frage: Kannst du zu den beiden Punkten einen Screenshot einstellen?

Gruß Klaus

PS: Keine Sorge, ich verstehe deine Punkte durchaus als Anregung.
Beim Kartendesgin ist es so, dass "3 Leute 4 Meinungen" haben ...

Hallo Klaus,

das mit dem Hochladen auf einen Internet-Server ist mir doch ein wenig zu umständlich (ich muss nicht unbedingt noch einen weiteren (für mich überflüssigen) Account im Netz eröffnen. Schick mir einfach deine E-Mail Adresse und du bekommst (als Anlage) das entsprechende Bild. Meine Mail-Adresse ist: burkhard.braband@mac.com.

Gruß, Burkhard

harzguide wrote:

das mit dem Hochladen auf einen Internet-Server ist mir doch ein wenig zu umständlich (ich muss nicht unbedingt noch einen weiteren (für mich überflüssigen) Account im Netz eröffnen.

Geht auch ohne Anmeldung. Einer von vielen Diensten: http://picr.de

Kleiner Routingfehler bei Recklinghausen (eTrex 20 + BC). Trotz korrekt gesetzter Turn Restriktion nimmt
er die Rechtsabiegerspur.

Einstellung: Auto / Kürzeste Strecke
http://www.openstreetmap.org/?lat=51.63 … 7&layers=M
Standard-mkgmap Karte routet da richtig.

Chris

toc-rox wrote:

Das Problem der "kopfstehenden" Polygone (gespiegelt und um 180° gedreht) halte ich (im Moment) für einen BaseCamp-OSX-Defekt.
Sieht bei Flächen wie Parkplätzen (P) oder Schulen (S) sehr unschön aus ... muß ich aber unter Windows nochmal testen.

Ich habe den o.g. Defekt einmal bei Garmin gemeldet - und zwar im Forum bzgl. der kommenden Mac-BaseCamp-Version 3.3.
Dort verspreche ich mir am meisten davon, da hier (zur Zeit) insbesondere auch die Entwickler mitlesen.

https://forums.garmin.com/showpost.php? … stcount=35

Gruß Klaus

chris66 wrote:

Kleiner Routingfehler bei Recklinghausen (eTrex 20 + BC). Trotz korrekt gesetzter Turn Restriktion nimmt
er die Rechtsabiegerspur.
http://up.picr.de/9037041uiq.jpg
Einstellung: Auto / Kürzeste Strecke
http://www.openstreetmap.org/?lat=51.63 … 7&layers=M
Standard-mkgmap Karte routet da richtig.
Chris

Ja, kann ich nachstellen bei Einstellung "Shortest Distance".
Ist aber korrekt bei Einstellung "Fastest Time".

Klaus

toc-rox wrote:

chris66 wrote:

Kleiner Routingfehler bei Recklinghausen (eTrex 20 + BC). Trotz korrekt gesetzter Turn Restriktion nimmt
er die Rechtsabiegerspur.
http://up.picr.de/9037041uiq.jpg
Einstellung: Auto / Kürzeste Strecke
http://www.openstreetmap.org/?lat=51.63 … 7&layers=M
Standard-mkgmap Karte routet da richtig.
Chris

Ja, kann ich nachstellen bei Einstellung "Shortest Distance".
Ist aber korrekt bei Einstellung "Fastest Time".

Klaus

wobei die strecke ja definitiv länger ist...

Glücki wrote:

Was mir nicht gefällt:
- V.a. die farbliche Darstellung: auf dem GPSmap60csx hat die Karte für meinen Geschmack viel zu wenig Kontraste, z.B. sind alle Wälder grau (statt satt grün wie z. B. bei der All in one), Wiesenlichtungen (blass grün) sind darin kaum erkennbar. So hat man dann oft graue Straßen in grauen Wäldern und man erkennt wenig bis gar nichts. Auch Gewässer sind blass grau. Für die Nutzung im Sonnenlicht m.E. nicht geeignet - für mich als Outdoor Nutzer ein K.O. Kriterium.

Hallo Glücki,
hier muss ich mal widersprechen. Gerade die blasse Darstellung von Waldflächen finde ich sehr gut. Dan kann man z.B. beim Radfahren mit einem schnellen Blick die dunkel gezeichneten Wege gut erkennen. Bei den grellgrünen Waldflächen der All-in-one-Karte kann ich die braunen Wege oft gar nicht mehr erkennen.
Also bitte den Kartenstil so beibehalten.
Franz

kann es sein, dass wenn highway= service/residential/... ist (die niedrigeren typen) wo "zugang = beschraenkt" gesetzt wird keine zusätzlichen routingfähigen fahrradwege erstellt werden, auch wenn "bicycle = yes" bei dem weg gesetzt ist?

gleiches evt. auch bei autos?

wenn ich das style file richtig interpretiere müsste das wohl so sein, beim bicycle ist es mir an einer stelle aufgefallen, wo ich sonst keine erklärung für hätte?

Jayjay01 wrote:

kann es sein, dass wenn highway= service/residential/... ist (die niedrigeren typen) wo "zugang = beschraenkt" gesetzt
wird keine zusätzlichen routingfähigen fahrradwege erstellt werden, auch wenn "bicycle = yes" bei dem weg gesetzt ist?

Könntest du mir das konkrete Beispiel nennen ?

Insgesamt bedarf die Logik des Routings einer Qualitätssicherung.
Hättest du, oder jemand anderes, Zeit und Lust dies durchzuführen.
Interessierte bitte per PM melden - Danke.

Gruß Klaus

hier das konkrete beispiel:
http://www.openrouteservice.org/index.p … ways=false

die osm-daten sollten stimmen, da hab ich schon ausführlich nach fehlern gesucht. (wobei bei osr noch was falsch ist in den routingdaten, habe osr nur zur verdeutlichung verlinkt, wie geroutet werden sollte.

Die unterführung ist eben für autos nicht als durchfahrt gestattet (aber möglich, diverse navis routen auch da lang 😉 ), fahrradfahrer dürfen aber durch. achja, das tagging der straße dort habe ich mir nicht ausgedacht, nur angepasst

als karte verwende ich die hessenkarte mit den geofabrikdaten von gestern. (das bild oben ist mit etwas älteren kartendaten erzeugt, dennoch gleiches problem)
wenn man den schieberegler kleine straßen/autobahnen etwas mehr nach links verschiebt, (auf die 2. stufe von links) routet er auf der anderen seite von der bahn durch den wald... dann will er halt die bundesstraße rechts vermeiden.

Vorab: Ich konnte das (Umleitungs-)Routing gemäß Screenshot nachvollziehen (BC OSX 3.3beta).
Wählt man den Start- und Endpunkt aber etwas anders, so ergibt sich eine "sinnvolle" Route.

Da der Garmin-Routing-Algorithmus aber nicht bekannt ist ...

Gruß Klaus

@JayJay01: Wenn du dich dort in der Gegend auskennst, dann könntest du bei der Flughafenstraße mal ein wenig bei access aufräumen.

Einen Grund für den Umweg kann ich auch nicht in den Daten erkennen. Da kein oneway vorhanden ist und es mit der anderen Strecke klappt, wird es wohl was im Garmin sein, was die Route verlängert.

kann evt. der highway=turning_circle das problem erzeugen?

Ok, hab auch noch einen Fehler (Werdohl):

http://maps.cloudmade.com/?lat=51.25479 … ened_tab=1

Hier macht die Freizeitkarte oben einen Schlenker am Bahnhof vorbei. Standard-mkgmap-Karte (default Style) routet richtig.
Chris

Höhenlinien: Mitte Januar 2012 enthält die Freizeitkarte zusätzlich integrierte Höhenlinien.
Frage: Hätte im Vorfeld jemand Interesse hierzu eine Qualitätssicherung / Bewertung vorzunehmen?

Gruß Klaus

toc-rox wrote:

Höhenlinien: Mitte Januar 2012 enthält die Freizeitkarte zusätzlich integrierte Höhenlinien.
Frage: Hätte im Vorfeld jemand Interesse hierzu eine Qualitätssicherung / Bewertung vorzunehmen?

Gruß Klaus

klar, bin ich dabei

kann es sein das cycleway=opposite nicht oder nicht richtig ausgewertet wird?

--make-opposite-cycleways: ist nicht aktiviert, oder? (seh zumindest nichst in der config)
im style file sehe ich auch nichts, wo cycleway=opposite ausgewertet würde?

//edit wie ich vermutet habe, hilft make-opposite-cycleways auch nicht, da die ja nicht mit mkgmap:carpool=1 ausgestattet werden...

toc-rox wrote:

Vorab: Ich konnte das (Umleitungs-)Routing gemäß Screenshot nachvollziehen (BC OSX 3.3beta).
Wählt man den Start- und Endpunkt aber etwas anders, so ergibt sich eine "sinnvolle" Route.

http://v34375.1blu.de/Bilder/Skitch/Bil … .10.36.png

Da der Garmin-Routing-Algorithmus aber nicht bekannt ist ...

Gruß Klaus

hab grad ne neue karte mit aktuellen daten erstellt, da routet er gleich richtig... vielleicht hat ihn irgend eins der access tags gestört, vielleicht liegts auch an anderen einstellungen an denen ich gespielt habe. daher wäre es schön, wenn jemand von euch das vielleicht bestätigen könnte, der sich auch karten selbst baut?

Jayjay01 wrote:

kann es sein das cycleway=opposite nicht oder nicht richtig ausgewertet wird? ...

Derzeit wird keine der mkgmap-cycleway-optionen verwendet.
Ich habe vor dies in einer der nächsten Ausgaben ggf. zu ändern.
Dies bedingt aber (unter anderem) umfangreiche Tests des Routings.

Zu berücksichtigen sind weiterhin:
- die kommende BaseCamp-Version 3.3 mit Änderungen beim Routing
- korrekte Darstellung der zusätzlichen Radwege (schwierig)

Gruß Klaus

PS: Ca. Mitte Januar folgt eine neue Ausgabe der Karte mit integrierten Höhenlinien als Hauptfeature.

@Jayjay01: Hast du hier eine funktionierende eMail-Adresse hinterlegt ?

toc-rox wrote:

Jayjay01 wrote:

kann es sein das cycleway=opposite nicht oder nicht richtig ausgewertet wird? ...

Derzeit wird keine der mkgmap-cycleway-optionen verwendet.
Ich habe vor dies in einer der nächsten Ausgaben ggf. zu ändern.
Dies bedingt aber (unter anderem) umfangreiche Tests des Routings.

Zu berücksichtigen sind weiterhin:
- die kommende BaseCamp-Version 3.3 mit Änderungen beim Routing
- korrekte Darstellung der zusätzlichen Radwege (schwierig)

Gruß Klaus

PS: Ca. Mitte Januar folgt eine neue Ausgabe der Karte mit integrierten Höhenlinien als Hauptfeature.

@Jayjay01: Hast du hier eine funktionierende eMail-Adresse hinterlegt ?

Email: jetzt schon 😉

Die frage ist eben, in wieweit man die mkgmap cycleway optionen momentan so verwenden kann. denn momentan werden halt zusätzliche straßen erstellt, über die auch autos geroutet werden, was ja nicht der sinn der sache ist...
da müsste man wohl was eigenes im style schreiben.

Wenn die Karte nur Radler routen soll, kann man im style einfach das oneway löschen.

aighes wrote:

Wenn die Karte nur Radler routen soll, kann man im style einfach das oneway löschen.

das soll sie aber nicht 😉

Die Freizeitkarte Deutschland ist in der Ausgabe 12.01 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 10.01.2012.

Link: http://www.easyclasspage.de/karten/index.html

Ergänzungen / Veränderungen gegenüber der vorherigen Version:
- verbesserte Darstellung der ÖPNV-Symbole Bahnhof, Haltestelle, U-Bahn-Eingang
- dezentere Darstellung der Staatsgrenzen
- Darstellung von Autobahnen auch in höheren Zoomstufen
- allgemeine Verbesserung des Routings
- Strichelung von Feld- / Waldwegen geändert (kürzere Striche)
- Logikdefekt bei privaten Feld- / Waldwegen korrigiert
- Darstellung von privaten Feld- / Waldwegen geändert
- Darstellung von Wegen / Pfaden geändert (gepunktete Linie statt Volllinie)
- Logikdefekt bei privaten Wegen / Pfaden korrigiert
- Darstellung von privaten Wegen / Pfaden geändert
- etwas dunklere Darstellung der Wasserflächen (B5D0D0 -> 99CCCC)
- Höhenlinien integriert (Äquidistanz 25 Meter, Beschriftung alle 250 Meter)
- dezente Darstellung der Höhenlinien mit zwei Zoomstufen (C0C0C0)
- Unterstützung von Höhenprofile für Routen

Bei der Erstellung dieser Ausgabe haben unterstützt:
Autor phyghtmap, Autor osmconvert, Garmin-User, Georg V. GerdP, guegafue, koepke, kukuk, mike_hd, Minko, Roman B.

Die Integration der Höhenlinien basiert auf essentiellen Vorarbeiten von:
Garmin-User, kukuk

Die Karte befindet sich im Status "Erprobung".
Hilf mit sie weiter zu verbessern ...

Gruß Klaus

So kannst du die Karte erst ab 1 April veröffentlichen. Höhenlinien und Kartendaten vermischen ist lizenzmäßig nicht erlaubt (zumindest solange du weiter Höhendaten von Jonathan de Ferranti verwendest) - da die Höhenlinien von Jonathan mit CCBYSA 2.0 nicht kompatibel sind - es die Karte im allgemeinen aber sein muss.

Auf Websites wird das daher auch über Layer geregelt. So musst du es auch machen. Höhenlinien in separate Kacheln packen wie die restlichen Kartendaten (zumindest überall dort von Daten von Jonathan benutzt werden. Mit SRTM3 kannst natürlich bzw dagegen machen was du willst).

Zunächst einmal 'Hallo' und einen ganz herzlichen Dank an Klaus und seine Mitstreiter für die Freizeitkarte und insbesondere für die 'Entwicklungsumgebung'. Ich versuche mich gerade in die Erstellung individualisierter Karten einzuarbeiten, und da ist die Zusammenstellung der Tools und Scripte eine wirkliche Hilfe.

Sehe ich das richtig, das im Moment straßenbegleitende Radwege, die z.B. mit highway=residential cycleway=track getaggt sind, nicht als Radwege dargestellt werden? Wie müßte eine Änderung in der lines-Datei aussehen damit solche Radwege in Garmin-BaseCamp angezeigt werden?

Gruß aus dem sonnigen Rheinland
Wolfgang

Druidus wrote:

... Sehe ich das richtig, das im Moment straßenbegleitende Radwege, die z.B. mit highway=residential cycleway=track getaggt sind, nicht als Radwege dargestellt werden? Wie müßte eine Änderung in der lines-Datei aussehen damit solche Radwege in Garmin-BaseCamp angezeigt werden? ...

Ja, in der Straße verlaufende Radwege werden derzeit nicht dargestellt.
Dieses Feature ist aber für eine zukünftige Ausgabe geplant.
Die derzeitige Idee dies darzustellen ist folgende: Straßenränder in "blau"
Dies bedingt dann diverse zusätzliche Linien.
Z.B. "Straße mit grauen Rändern" -> "Straße mit blauen Rändern" (zusätzlich).
Im Stylefile "lines" ist dann die o.g. Bedingung entsprechend zu berücksichtigen.

Klaus

Vielen Dank für die Entwicklungsumgebung. Funktioniert echt prima.

Allerdings tauchen in den von mir generierten Karten (Version 12.01) in BaseCamp bzw. auf dem Oregon keine Höhenlinien auf. In der Anleitung habe ich dazu nichts gefunden.

Habe ich was falsch gemacht, oder ist das noch nicht in die Entwicklungsumgebung integriert?

shammat wrote:

Allerdings tauchen in den von mir generierten Karten (Version 12.01) in BaseCamp bzw. auf dem Oregon keine Höhenlinien auf.
Habe ich was falsch gemacht, oder ist das noch nicht in die Entwicklungsumgebung integriert?

Die Integration der Höhenlinien war etwas aufwändiger - ist jetzt jedoch fast fertig und soll in den Betatest.
Die Freigabe der Entwicklungsumgebung mit Höhenlinien ist für Anfang / Mitte Februar geplant.
Wer den Betatest unterstützen möchte, sollte mir eine PM schreiben - Danke.

Gruß Klaus

toc-rox wrote:

Die Integration der Höhenlinien war etwas aufwändiger - ist jetzt jedoch fast fertig und soll in den Betatest.
Die Freigabe der Entwicklungsumgebung mit Höhenlinien ist für Anfang / Mitte Februar geplant.

Das klingt doch prima, vielen Dank.

Wer den Betatest unterstützen möchte, sollte mir eine PM schreiben - Danke.

PM ist unterwegs...

Hi,
auf meinem Etrex 20 funktioniert mit der aktuellen Version der Freizeitkarte die Adresssuche nicht mehr.
Chris

chris66 wrote:

Hi,
auf meinem Etrex 20 funktioniert mit der aktuellen Version der Freizeitkarte die Adresssuche nicht mehr.
Chris

Merkwürdig, das gmapsupp-Image wurde (diesmal noch) mit MapInstall erzeugt.
Kannst du dir das Image versuchsweise einmal selbst mit MapInstall erzeugen ?

Gruß Klaus

Frage an toc rox: Ich bin Neuling in diesem ganzen Outdoor-GPS. Die Freizeitkarte Deutschland ist super. Gibt es so etwas auch für den Bereich Gardasee?

radenberger wrote:

Frage an toc rox: Ich bin Neuling in diesem ganzen Outdoor-GPS. Die Freizeitkarte Deutschland ist super. Gibt es so etwas auch für den Bereich Gardasee?

All in one Garmin map (z. B. Alpen): http://wiki.openstreetmap.org/wiki/DE:A … ions#Alpen
Kleineisel Alpen: http://www.kleineisel.de/blogs/index.php/osmmap/
Openmtbmap.org: http://openmtbmap.org/de/download/#euro … ndownloads

Hallo radenberger,

zunächst einmal Willkommen im Forum ...
Glücki hat ja bereits einige Karten aufgeführt, die das Gebiet um den Gardasee abdecken.
Für das Frühjahr ist auch eine Freizeitkarte Alpen geplant, die dann ebenfalls den Gardasee enthalten wird.
Was derzeit noch fehlt, ist eine Qualitätssicherung für die entsprechenden Länder bzw. Regionen.
Für Österreich hoffe ich etwas Unterstützung gefunden zu haben.
Wer also sehr gute Ortskenntnisse in der Region hat, wird gebeten sich bei mir zu melden.
Zeit und Lust die Vorabversion der Alpenkarte zu prüfen natürlich vorausgesetzt.

Gruß Klaus

Ich war am Sonntag in Düsseldorf unterwegs und da hat sich das Garmin Gerät (mit der FZK drauf) nicht mit Ruhm bekleckert.

Hauptproblem war, dass bei Straßengabelungen überhaupt kein Hinweis (rechts/links halten) kam.

Zum Glück hab ich jedesmal richtig geraten. 😉

Grüße
Chris

toc-rox wrote:

Für das Frühjahr ist auch eine Freizeitkarte Alpen geplant, die dann ebenfalls den Gardasee enthalten wird.
Was derzeit noch fehlt, ist eine Qualitätssicherung für die entsprechenden Länder bzw. Regionen.
Für Österreich hoffe ich etwas Unterstützung gefunden zu haben.

Sollte das nicht die gleiche Qualität wie z.B. bei der OpenMTB Karte sei da beide auf den OSM Daten beruhen?

Und die Qualität der Daten in der OpenMTB ist zumindest im Bereich Bayrisch/Österreichische Alpen wirklich hervorragend. Gardasee kann ich nicht sagen, aber das Gebiet um Livigno war auf der OpenMTB auch ziemlich gut abgedeckt.

Als einziges ist mir aufgefallen, dass auf der Freizeitkarte_Alpen (die man sich ja problemlos mit der Entwicklungsumgebung erstellen kann) die ganz brandneuen Klettersteige im Rofan Gebiet nicht dargestellt werden, auf der Velomap und der OpenMTB hingegen schon.

Der (relativ) neue "Kufsteiner Klettersteig" im Gebiet des Wilden Kaiser ist auf der OpenMTB und der FZK zu sehen, auf der Velomap hingegen nicht.

Ich vermute mal, das hat was mit der Klassifizierung der Wege zu tun?

Liegt vermutlich an dem sac_scale-Wert, der nicht wirklich velo-tauglich ist. 😉
http://www.openstreetmap.org/browse/way/80803324

shammat wrote:

toc-rox wrote:

Für das Frühjahr ist auch eine Freizeitkarte Alpen geplant, die dann ebenfalls den Gardasee enthalten wird.
Was derzeit noch fehlt, ist eine Qualitätssicherung für die entsprechenden Länder bzw. Regionen.
Für Österreich hoffe ich etwas Unterstützung gefunden zu haben.

Sollte das nicht die gleiche Qualität wie z.B. bei der OpenMTB Karte sei da beide auf den OSM Daten beruhen?

Und die Qualität der Daten in der OpenMTB ist zumindest im Bereich Bayrisch/Österreichische Alpen wirklich hervorragend.
Gardasee kann ich nicht sagen, aber das Gebiet um Livigno war auf der OpenMTB auch ziemlich gut abgedeckt.

In der FZK Deutschland ist einiges auf die deutschen Gegebenheiten ausgelegt.
Dies muss / wird nicht alles (vieles vermutlich schon) für Österreich passen.
Andere für Österreich wichtige Aspekte fehlen möglicherweise.

Klaus

PS: Bezogen auf die OSM-Daten gibt es auch das eine oder andere Probleme.
So ist am Gardasee ein Mega-Polygon aufgefallen, welches nicht verarbeitet wird.

toc-rox wrote:

In der FZK Deutschland ist einiges auf die deutschen Gegebenheiten ausgelegt.
Dies muss / wird nicht alles (vieles vermutlich schon) für Österreich passen.
Andere für Österreich wichtige Aspekte fehlen möglicherweise.

Hmm, darunter kann ich mir jetzt ehrlich gesagt nichts vorstellen. Kannst Du mir ein Beispiel dafür geben?

shammat wrote:

Hmm, darunter kann ich mir jetzt ehrlich gesagt nichts vorstellen. Kannst Du mir ein Beispiel dafür geben?

Dies könnten z.B. abweichende POI-Signaturen (Haltestelle?) aber auch inhaltliche Aspekte sein.
Auf die Niederlande kann man z.B. die deutschen Gegebenheiten bei Radwegen gar nicht anwenden.
Welche Aspekte für Österreich zu berücksichtigen sind, kann nur jemand mit sehr guten Ortskenntnissen beurteilen.
Mir wäre / ist insgesamt der Qualitätsaspekt sehr wichtig (und Qualität kostet eben).

Klaus

chris66 wrote:

auf meinem Etrex 20 funktioniert mit der aktuellen Version der Freizeitkarte die Adresssuche nicht mehr.

Ob's mit dem Update der Firmware auf 2.60 zusammenhängt weisst ich nicht, jedenfalls geht die Suche wieder. 😉

Einige Fragen an die Kartennutzer die in unmittelbarer Grenznähe wohnen oder dort die Karte nutzen:

Da die Karte ja exakt an der Staatsgrenze endet:
- Wäre es sinnvoll eine FZK-D +X km (z.B. +50 km = reicht 50 km ins Nachbarland) zu haben ?
- Wie groß sollte man "+X km" wählen ?
- Oder wäre eine Karte (im gleichen Stil) für das Nachbarland besser ?
- Oder gibt es den Bedarf gar nicht, weil z.B. schon eine optimale Karte des Nachbarlands genutzt wird ?

Klaus

toc-rox wrote:

Einige Fragen an die Kartennutzer die in unmittelbarer Grenznähe wohnen oder dort die Karte nutzen:

Da die Karte ja exakt an der Staatsgrenze endet:
- Wäre es sinnvoll eine FZK-D +X km (z.B. +50 km = reicht 50 km ins Nachbarland) zu haben ?
- Wie groß sollte man "+X km" wählen ?
- Oder wäre eine Karte (im gleichen Stil) für das Nachbarland besser ?
- Oder gibt es den Bedarf gar nicht, weil z.B. schon eine optimale Karte des Nachbarlands genutzt wird ?

Hallo Klaus

Wenn ich an einige Grenzregionen denke, macht das absolut Sinn.
- Euregio Aachen mit intensiven länderübergreifenden Regionalverkehr
- Hohes Venn (Eifel) als länderübergreifendes Naturschutzgebiet
- Oberrheingraben mit Schwarzwald und Vogesen
- ...

Hier wurde schon oft beklagt, dass es sehr aufwändig ist, Karten für solche Grenzregionen zu erstellen.
Die 50 km erscheinen mir ausreichend, soweit es um Tagesausflüge geht.
Wer viel im Nachbarland unterwegs ist, der braucht sowieso eine eigene Karte dafür.

Edbert (EvanE)

EvanE wrote:

... Hier wurde schon oft beklagt, dass es sehr aufwändig ist, Karten für solche Grenzregionen zu erstellen.
Die 50 km erscheinen mir ausreichend, soweit es um Tagesausflüge geht. ...

Der Aufwand ist etwas größer als bei "nur Deutschland", aber durchaus leistbar - vieles ist ja ohnehin automatisiert.
Da es für "Deutschland+" aber keinen geofabrik-Extrakt gibt, muß man mit dem "unhandlichen" Europa-Extrakt arbeiten.

Klaus

Nachtrag: Könntest du mir für "Deutschland+" ein poly-File erstellen ?

toc-rox wrote:

Nachtrag: Könntest du mir für "Deutschland+" ein poly-File erstellen ?

Hallo Klaus,

schau mal hier vorbei:
http://140.78.94.22/osm/
😉

Die Freizeitkarte Deutschland ist in der Ausgabe 12.2 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 17.02.2012.

Link: http://www.easyclasspage.de/karten/index.html

Freizeitkarte: Ergänzungen / Veränderungen in dieser Ausgabe:
- allgemeine Verbesserung der Indexsuche
- Beseitigung von Artefaktlinien unter OS X
- signifikante Symbole für Parkplätze (öffentlich, privat)
- Darstellung der Höhenlinien verbessert
- vollständige Überarbeitung des Themas "Schienen"
- Darstellung von Bahnstrecken geändert
- Darstellung von S-Bahn-Strecken geändert
- Unterstützung von Museumsbahnstrecken
- Unterstützung für rückgebaute Strecken
- Unterstützung von Straßenbahnstrecken
- verbesserte Darstellung der Alpenregion
- Zeichenpriorität und Darstellung von Almen geändert
- Zeichenpriorität und Darstellung von Geröllfeldern geändert
- Darstellung von Buschland geändert
- Berücksichtung der Richtung von Klippen
- Darstellung von Klettersteigen (Via Ferrata)
- andersfarbige Darstellung von Skiliften (Rot)
- Darstellung von Materialseilbahnen
- Differenzierung von Berghütten, Basic-Hut und Lean-Hut
- Unterscheidung von (Wander-)Wegen nach SAC-Skala
- rechteckiger Punkt für Mega- und Hauptstädte
- Anzeige von Schutzhütten in höherer Zoomstufe
- Verkleinerung der Symbole für Moschee und Synagoge
- Begrenzung der Darstellungsebenen (technische Änderung, verhindert überzeichnen von Linien)
- alternative Erstellung des Kartenhintergrunds (technische Änderung für z.B. 60CSx, Nüvi)
- allgemeine Verbesserung von OSM-Daten
- Anzeige von Feld-/Wegen (4,5) auch in höherer Zoomstufe
- Ablesbarkeit von privaten Pfaden und privaten Feld-/Waldwegen verbessert (dunkler Lilaton)
- deutlichere Darstellung von Restaurants, Geschäften, Hotels und Campingplätzen

Entwicklungsumgebung: Verbesserungen / Änderungen in dieser Ausgabe:
- Unterstützung von Höhenlinien
- direkte Erzeugung von gmapsupp-Images
- MapTool (mt.pl) 0.4.8 (statt 0.3.9)
- mkgmap r2188 (statt r2164)
- splitter r200 (statt r198)
- bounds (world) vom 13.01.2012 (statt 07.01.2012)
- coastlines (europe) vom 01.01.2012 (statt 02.12.2011)

Freizeitkarte Österreich:
Erstmalig steht auch eine Freizeitkarte Österreich zur Verfügung.
Inhalt und Design der Freizeitkarte Deutschland wurden hier zunächst unverändert übernommen.
Dies wird möglicherweise nicht in allen Punkten richtig oder günstig sein.

Kartenstatus:
Die Freizeitkarte Deutschland hat den Status "Erprobung", die Freizeit Österreich den Status "Beta".
Hilf mit beide Karten zu verbessern - Danke.

Kartendarstellung in BaseCamp: Berlin, Brandenburger Tor und Stehlenfeld Holocaustmahnmal

Gruß Klaus

Hallo Klaus, ist es möglich auch die Parkbänke und Hochsitze dazustellen oder überläd das die Karte?

Find die Karte an sonsten echt Klasse.

Gruß Jürgen

derjürgen wrote:

Hallo Klaus, ist es möglich auch die Parkbänke und Hochsitze dazustellen oder überläd das die Karte?

Ich tendiere eher zum Gegenteil - so werden z.B. die Bäume (natural = tree) wohl in der nächsten Kartenausgabe "radikal abgeholzt".
Ein Problem des sehr detaillierten Mappens (was ich grundsätzlich gut finde), das der Kartenbauer aber nur schwer / nicht in den Griff bekommt.
Hier ein Beispiel aus dem "sehr grünen" Winterthur (Schweiz): http://www.openstreetmap.org/?lat=47.50 … 6&layers=M
Die Intension für die Darstellung der Bäume war eher die der "signifikanten Landmarke" zur Orientierung, aber nicht die Darstellung jedes Alleebaumes.
Frage in diesem Zusammenhang: Gibt es irgendwie eine Möglichkeit den signifikanten Einzelbaum als Landmarke am Tagging zu erkennen ?

Klaus

toc-rox wrote:

Frage in diesem Zusammenhang: Gibt es irgendwie eine Möglichkeit den signifikanten Einzelbaum als Landmarke am Tagging zu erkennen ?

natural=tree
denotation=landmark

Fabi2 wrote:

toc-rox wrote:

Frage in diesem Zusammenhang: Gibt es irgendwie eine Möglichkeit den signifikanten Einzelbaum als Landmarke am Tagging zu erkennen ?

natural=tree
denotation=landmark

Danke für die Info - "denotation=landmark" wird aber (leider) nicht allzu häufig verwendet (insgesamt nur 270x) - schade.

Klaus

name=xyz könnte man noch dazu nehmen, da kommt aber auch nicht viel Holz zusammen.
und wie wär's mit Mammutbäumen (diameter > 10)... 😎

toc-rox wrote:

Ein Problem des sehr detaillierten Mappens (was ich grundsätzlich gut finde), das der Kartenbauer aber nur schwer / nicht in den Griff bekommt.
Hier ein Beispiel aus dem "sehr grünen" Winterthur (Schweiz): http://www.openstreetmap.org/?lat=47.50 … 6&layers=M
Die Intension für die Darstellung der Bäume war eher die der "signifikanten Landmarke" zur Orientierung, aber nicht die Darstellung jedes Alleebaumes.
Frage in diesem Zusammenhang: Gibt es irgendwie eine Möglichkeit den signifikanten Einzelbaum als Landmarke am Tagging zu erkennen?

Hallo Klaus

Die zitierte Karte zeigt zwei Optionen:
- kleine Darstellung als grüner Punkt.
- Anzeige nur in den höchsten Zoom-Leveln.
Das sollte man auch nutzen. Schließlich können auch Baumgruppen zur Orientierung dienen.

Wirkliche Landmarken möchten man aber wahrscheinlich auch bis zu mittleren Zoom-Leveln anzeigen.

Wie Fabi2 resp. chris66 schrieben, könnte man auf denotation=landmark/cluster/urban/..., name=* und Detail-Angaben zum Baum wie Durchmesser, Umfang, Höhe oder Alter achten.

Das ist aber nur die halbe Miete. Wichtig sind natürlich auch Bäume, die isoliert stehen, wo also z.B. in 100m Umkreis kein weiterer Baum oder anderes Objekt eingetragen ist. Solche Bäume sind nicht zwingend alt, groß oder als Landmarke getaggt, aber eben durch die isolierte Lage auffällig. Eine Umkreissuche dürfte aber ohne GIS-Datenbank eine eher teure Funktion sein.

Edbert (EvanE)

kann jemand dieses routing erklären? der kreis hintenrum ist absolut sinnlos, da man einfach gleich rechts abbiegen könnte.

es gibt weder vor ort noch in den osm daten eine abbiegebeschränkung.

es handelt sich um diese stelle

http://www.openstreetmap.org/?lat=50.10 … 8&layers=M

Jayjay01 wrote:

kann jemand dieses routing erklären?

Das ist der Heuristik des Garminschen Routingalgorithmus geschuldet, welcher Routen mit weniger scharfen
Abbiegungen bevorzugt. Dass solche Heuristiken nicht immer Sinn machen zeigt dieses Beispiel.

chris66 wrote:

Jayjay01 wrote:

kann jemand dieses routing erklären?

Das ist der Heuristik des Garminschen Routingalgorithmus geschuldet, welcher Routen mit weniger scharfen
Abbiegungen bevorzugt. Dass solche Heuristiken nicht immer Sinn machen zeigt dieses Beispiel.

und es gibt momentan keine möglichkeit ihm zu erklären, dass das trotzdem so gemacht werden soll?

Hab grad mal ein bisschen mit den mkgmap Options rumgespielt, demnach scheint remove-short-arcs=2 zu helfen. Ich hab bisher
in meinen Karten immer remove-short-arcs ohne Wert gesetzt, das ist anscheinend nicht optimal.

Der empfohlene Wert ist übrigens 5.4.
Chris

chris66 wrote:

Hab grad mal ein bisschen mit den mkgmap Options rumgespielt, demnach scheint remove-short-arcs=2 zu helfen. Ich hab bisher
in meinen Karten immer remove-short-arcs ohne Wert gesetzt, das ist anscheinend nicht optimal.
http://up.picr.de/9667078xav.png
Der empfohlene Wert ist übrigens 5.4.
Chris

hmm, bei mir hat remove-short-arcs=2 nicht geholfen, bei 3 hats dann funktioniert.
Gibts nachteile wenn ich remove-short-arcs hochsetze?

chris66 wrote:

Hab grad mal ein bisschen mit den mkgmap Options rumgespielt, demnach scheint remove-short-arcs=2 zu helfen.
Ich hab bisher in meinen Karten immer remove-short-arcs ohne Wert gesetzt, das ist anscheinend nicht optimal.
Der empfohlene Wert ist übrigens 5.4.
Chris

Das hört sich ja nach "Grundlagenforschung" an und wirft einige Fragen auf:
- Wie entstehen die "short-arcs"-Objekte ?
- Was passiert eigentlich durch das "remove" ?
- Ist das Verhalten des Routingalgorithmus auf einer Testkarte nachweisbar ?
- Was wäre der optimale Wert für "remove-short-arcs" ?

Von den Antworten könnten möglicherweise alle OSM-Garminkarten profitieren.

Klaus

remove-short-arcs=n verbindet naheliegende Kreuzungspunkte mit einem Abstand <= n Meter. So wird z.B. aus 2 Dreiwege-Kreuzen 1 Vierwegekreuz. Die beteiligten Wege werden entsprechend "verbogen".

Es hat den Vorteil, dass die Komplexität und Detail der Karte reduziert werden. Dies hilft besonders dem Garmin-Routing, da dieses jedes Abbiegen mit einem zusätzlichen Malus belegt (Fußgänger-Routing nicht!). Die Karte wird dadurch zudem insgesamt kleiner.

Leider ist der Algorithmus nicht sehr intelligent und berücksichtigt keine Weg-Prioritäten (primary > secondary > usw.). Das führt zu unschön kantigen Wegen wo eigentlich eine Gerade sein sollte.

Werte kleiner 3 scheinen keinen Effekt zu haben. Wer kein Routing braucht, der sollte remove-short-arcs ganz weglassen.

- speedpilgrim

Super Karte!!

Von der Dartsellung wohl derzeit die beste auf OSM basierende Karte für den Outdoorbereich am Garmin.
Am Dakota find ich den gewählten Stil sehr schön, alles perfekt ablesbar und schön dezente Kontraste.

Danke dass du auch an uns Österreicher gedacht hast, die österr. Geocacher bedanken sich schon mal recht herzlich.

Bitte auch die Österreich Karte in Zukunft aktuell halten ;-)

THANKS !!!

Hallo Klaus,

vielen Dank für die beste Garmin-Karte, die ich bisher gefunden habe! Großartige Arbeit!

Könnte sich mal jemand bei N53° und E7°30' den Küstenkanal ansehen? Da scheint in Surwold in der Freizeitkarte der Ortsteil Börgermoor "überschwemmt" zu werden, zumindest wenn man tiefer reinzoomt. (Gesehen in BaseCamp und auf dem GPSMap62st.) Auf der OSM-Karte und in JOSM sieht dieser Bereich aber richtig aus. Da ich an dieser Position Daten eingepflegt habe hoffe ich, dass ich da nichts kaputt gemacht habe?

Gruß Heinz

HeBri wrote:

... Da scheint in Surwold in der Freizeitkarte der Ortsteil Börgermoor "überschwemmt" zu werden ...

Hallo Heinz,

zunächst einmal "Willkommen im Forum" und danke für dein Feedback.

Meine Vermutung für die Überflutung ist folgende:

Einige Mapper verwenden folgende Wege (als closedway) um Wasserflächen abzubilden:
waterway = canal
waterway = ditch
Dies findet sich z.B. bei einigen "Schloßgräben und Kanälen".
Ich halte dies nicht für korrekt, habe das bislang aber in der FZK berücksichtigt.
In einigen Fällen führt dies aber zu "ungewollten" Überflutungen.
In der nächsten FZK wird diese Logik entfernt.
Ich werde heute Abend mal prüfen, ob der Sachverhalt auf Börgermoor zutrifft.

Gruß Klaus

Hallo Forum, hallo Klaus,
ich würde auch gern mal die Freizeitkarte auf meinem Mac mini ausprobieren. Auf der Homepage seht bei Installation unter Mac OS X "Karte installieren (Doppelklick auf Installerdatei". Nachdem ich die "Freizeitkarte_Deutschland_gmap.zip" entpackt habe, konnte ich keinen Installer finden. Wie installiere ich die Karte? BaseCamp ist installiert und dann...
Danke und Ciao
Holger

Hallo Holger,

für die Installation unter OS X ist zusätzlich das Programm MapManager erforderlich.
Nach der Installation reicht dann ein Doppelklick auf die gmap-Datei.

Gruß Klaus

ich hab mal wieder was zum Routing:

Es geht um die folgende Stelle:
http://www.openstreetmap.org/?lat=46.23 … 7&layers=M

das ist ein Stück Straße, dass über eine Brücke führt und aus ökonomischen Erwägungen hat man die Eisenbahn über dieselbe Brücke geführt (aufgrund von Beschreibungen des Berninapasses scheint das der Realität zu entsprechen). Bevor es über die Brücke geht, sind die typischen Bahnübergangssicherungen.

Egal welche Einstellungen ich für das Routing nehme, er schickt mich immer außenrum und will mich einfach nicht über die Brücke lassen 🤔

Läßt sich das Problem irgendwie lösen?

Die Freizeitkarte habe ich mir mit dem Datenauszug der Alpen von der Geofabrik selber gebaut, an den Typ-Files nichts geändert.

Ja, lässt sich lösen... bspw. in dem man bei einer Straßenkarte bei der Kartenverarbeitung das railway=rail (etc.) löscht, wenn es auch ein highway=* gibt. Oder railway erst nach der highway-Auswertung machen.

aighes wrote:

Oder railway erst nach der highway-Auswertung machen.

Ja, so wie im default-mkgmap style. Diese Art des Taggings sieht man ja auch oft bei Straßenbahnen.
Chris

Danke für die Fehlermeldung (dwausr) und und auch deren Lösung (aighes).

Thematisch "paßt" der Defekt ganz gut, da in der kommenden Ausgabe das Routing von Grund auf neu definiert wird.
Das Routing wird insbesondere in Hinblick auf BaseCamp 3.3 und die neueren GPS-Geräte optimiert (durch Jayjay01).

Den o.g. Defekt habe ich für die kommende Ausgabe korrigiert - es wird dann korrekt über die Straße geroutet:

Vor der Korrektur:

Nach der Korrektur:

Gruß Klaus

@Klaus:

Ich seh zwar in Deinen beiden Bildern keinen Unterschied im Routing (da ich gar kein Routing drauf sehe), aber trotzdem Danke für deine Bemühungen insgesamt - die Freizeitkarte ist echt klasse, ich verwende sie mittlerweile recht rege als Offline-Karte und hab damit auch schon dem einen oder anderen bisher-Nicht-OSM-Nutzer den Mund wässrig machen können, der sie künftig für sich selber auch nutzen will (und damit vielleicht irgendwann zu einem Mapper wird).

Bei mir läuft derzeit ein weiteres "build", mal schauen, ob ich den "Fehler" selber raus bekommen habe oder ob ich mir noch weiteres Wissen anlesen muss ... 🙂

Im folgenden Bereich kommt es auf der Österreich-Karte zur "Überflutung" :

http://www.openstreetmap.org/?lat=48.08 … 7&layers=M

Wenn man sich diesen Bereich auf dem Garmin Gerät ansieht gibt es eine "Überflutung" entlang einer Kachelgrenze, dort wird alles blau eingefärbt, Wege sind aber trotzdem erkennbar.

Liegts an der Karte oder an des OSM Daten? In Mapnik wird alles soweit richtig dargestellt.

Hab mir die Rohdaten in JOSM noch nicht angesehen, könnte vielleicht an der "Wiener Hochquellwasserleitung" liegen die meiner Meinung nach nicht ganz korrekt eingetragen zu sein scheint.

Nochmals Danke für die Karte die ich am Garmin immer mehr zu schätzen lerne!

Danke für den Hinweis - wahrscheinlich ist / war dies die Ursache:

In einigen Fällen werden "waterway = canal" und "waterway = ditch" (inkorrekterweise) dazu verwendet Wasserflächen (z.B. Kanalabschnitte, breite Schloßgräben) darzustellen.
Die FZK hat bislang versucht dies zu berücksichtigen und verarbeitet entsprechende "closedways" als Polygone.
In einigen Fällen erklären sich hieraus die "Überflutungen".
In der kommenden Ausgabe ist diese Logik, und damit auch die Überflutung, nicht mehr enthalten.
Vielleicht kannst du die "Wiener Hochwasserquellleitung" dennoch einmal daraufhin überprüfen.

Gruß Klaus

Nachtrag: Beim Blick auf die eben erzeugte Karte (ohne Überflutung) ist mir aufgefallen, daß viele Bergggipfel dort keinen Namen haben.
Fehlen die oder haben die wirklich keinen Namen ?

Die Freizeitkarten Deutschland bzw. Österreich sind in der Ausgabe 12.3 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 24.03.2012.

Link: http://www.easyclasspage.de/karten/index.html

Freizeitkarte: Ergänzungen / Veränderungen in dieser Ausgabe:
- Darstellung von (Einzel-)Bäumen nur noch in Verbindung mit "Landmarken"
- dunklere Darstellung von Staumauern und Stauwehren
- Darstellung von Brücken für alle Wege
- Optimierung der Darstellung auf dem GPS-Gerät
+Gebäude werden erst im höchsten (logischen) Detailgrad angezeigt
- vollständige Überarbeitung des Routings (durch Johannes Hahn [Jayjay01])
+für Fussgänger, für Radfahrer, für Autofahrer
+kompatibel zu BaseCamp 3.3, kompatibel zu neueren GPS-Geräten
- andersfarbige Darstellung aller für Autos gesperrten Straßen
- Naturschutzgebiete werden im höchsten Zoomlevel nicht mehr ausgewiesen

Entwicklungsumgebung: Ergänzungen / Veränderungen in dieser Ausgabe:
- zusätzliche Höhenlinien mit einer Äquidistanz von 10 Meter
- Vorverarbeitung für Style-Files (mit ppp.pl als Preprozessor)
- MapTool (mt.pl) 0.5.6 (statt 0.4.8)
- mkgmap r2248 (statt r2188)

Kartenstatus:
Beide Freizeitkarten befinden sich im Status "Erprobung".
Hilf mit die Karten zu verbessern - Danke.

Kartendarstellung in BaseCamp: Großraum Frankfurt

Gruß Klaus

Hallo Klaus,

deine Karte entwickelt sich zu einem richtigen Highlight.

Werde die aktuelle Karte diese Tage ausprobieren.

Vielen Dank

Gruß Jürgen

Nochmal vielen Dank für diese super Karte!

Mir ist ein Problem mit dem Routing aufgefallen bei dem ich (mangels OSM Wissen) nicht weiß ob es ein FZK Problem oder OSM Bug ist.

Wenn man eine Route zum Sonnjoch (nähe Achensee, N47 24 44.6 E11 36 18.5) plant, und zwar von der Strasse aus (N47 24 58.3 E11 37 36.5) so werden die letzten Meter des Wanderweges nicht "erkannt", die Route führt dann einmal um den Berg rum.

Der letzte Teil des Weges ist auch andersfarbig dargestellt und wird nur als Bergwanderweg T3/T4 angezeigt, während der Weg "vorher" als "Rad/Fußweg (Routing)" angezeigt wird:

das liegt daran, dass die schwierigkeit des wegs zu hoch ist. um zu vermeiden, dass unwissende sich vom routing dort langschicken lassen, sind diese wege vom routing ausgeschlossen.
solche routen würde ich aber ohnehin nicht automatisch planen lassen.

wenn du deine eigene karte erstellen würdest, könnte man das sehr leicht ändern. Ich kann dir gerne das angepasste style-file schicken, wenn du magst. du bräuchtest dann nur noch die entwicklungsumgebung.

shammat wrote:

... Wenn man eine Route zum Sonnjoch (nähe Achensee, N47 24 44.6 E11 36 18.5) plant, und zwar von der Strasse aus (N47 24 58.3 E11 37 36.5) so werden die letzten Meter des Wanderweges nicht "erkannt", die Route führt dann einmal um den Berg rum. Der letzte Teil des Weges ist auch andersfarbig dargestellt und wird nur als Bergwanderweg T3/T4 angezeigt, während der Weg "vorher" als "Rad/Fußweg (Routing)" angezeigt wird.

(Berg-)Wanderwege der Kategorien 3-6 werden (aus Sicherheitsgründen) explizit vom Routing ausgeschlossen.
Hiermit soll verhindert werden, das "Unbedarfte" über diese Wege geroutet werden und sich in Gefahren begeben.
Für (Hoch-)Gebirgstouren ist die FZK m.E. alleinig nicht ausreichend.

Gruß Klaus

Edit: Oh, Jayjay01 war schneller ...

Jayjay01 wrote:

das liegt daran, dass die schwierigkeit des wegs zu hoch ist. um zu vermeiden, dass unwissende sich vom routing dort langschicken lassen, sind diese wege vom routing ausgeschlossen.

Macht erstmal Sinn, kann ich verstehen.

solche routen würde ich aber ohnehin nicht automatisch planen lassen.

Grundsätzlich gebe ich Dir recht, allerdings mache ich auch nicht wirklich eine "echtes" Routing, sondern setze die Zwischenpunkte immer so, dass sowieso kein anderer Weg verwendet werden kann. Im Prinzip also ein "verbesserter" Track. Ist halt viel schneller erstellt auf diese Weise. Ein Grund dafür ist, dass im Basecamp mit den OSM Karten nur bei geplanten Routen ein Höhenprofil erstellt wird, bei Tracks (wegen fehlender DEM) allerdings nicht. Ein anderer Grund ist, dass ich das Handling auf dem Oregon mit Routen als angenehmer empfinde als Tracks (vor allem beim Mountainbiken, weil man da dann Abbiegehinweise bekommt, bei Tracks aber nicht - wobei das hier jetzt keine MTB Tour werden sollte...)

wenn du deine eigene karte erstellen würdest, könnte man das sehr leicht ändern. Ich kann dir gerne das angepasste style-file schicken, wenn du magst. du bräuchtest dann nur noch die entwicklungsumgebung.

Die Entwicklunsgumgebung verwende ich eh' schon.

Email Adresse ist hinterlegt, Du kannst mir gerne eine PM schicken.
Sehr Nett wäre es, wenn Du kurz erklären kannst was genau die Änderung ist. Vielleicht kapier ich ja den ganzen Prozess der Kartenerstellung ja doch mal 😉

toc-rox wrote:

Für (Hoch-)Gebirgstouren ist die FZK m.E. alleinig nicht ausreichend.

Naja, vom "Hoch"gebirge kann man da noch nicht reden - letztendlich ist es ein normaler Wanderweg (und z.B. in den DAV Karten wird der Weg auch durchgängig gleich dargestellt).

Mir ist aber auf jeden Fall bewusst was das Ziel der FZK ist und das ist auch vollkommen OK!
Deswegen gibt's ja die Entwicklungsumgebung (habe ich mich dafür schon bedankt?)

Vielen Dank für die Antworten!

ich schreib das einfach mal hier, vielleicht hilfts ja auch jemand anderem...

du öffnest die datei lines-master (/style/), und suchst dort nach diesem code: (wichtig: Keine Dateiendung, die Datei einfach in einem editor deiner Wahl öffnen (zum beispiel standard editor von windows)

#␣Bergwege;␣ueber␣Wege␣der␣Kategorien␣3-6␣wird␣aus␣Sicherheitsgruenden␣nicht␣geroutet
highway␣=␣path␣&␣(sac_scale␣=␣hiking␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣sac_scale␣=␣mountain_hiking)␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg12}
highway␣=␣path␣&␣(sac_scale␣=␣demanding_mountain_hiking␣|␣sac_scale␣=␣alpine_hiking)␣␣␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg34;␣set␣access␣=␣no;␣set␣motorcar␣=␣no;␣set␣bicycle␣=␣no;␣set␣foot␣=␣no}
highway␣=␣path␣&␣(sac_scale␣=␣demanding_alpine_hiking␣␣␣|␣sac_scale␣=␣difficult_alpine_hiking)␣{set␣highway␣=␣bergweg56;␣set␣access␣=␣no;␣set␣motorcar␣=␣no;␣set␣bicycle␣=␣no;␣set␣foot␣=␣no}

und ersetzt ihn mit

#␣Bergwege;
highway␣=␣path␣&␣(sac_scale␣=␣hiking␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣sac_scale␣=␣mountain_hiking)␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg12}
highway␣=␣path␣&␣(sac_scale␣=␣demanding_mountain_hiking␣|␣sac_scale␣=␣alpine_hiking)␣␣␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg34;␣set␣motorcar␣=␣no}
highway␣=␣path␣&␣(sac_scale␣=␣demanding_alpine_hiking␣␣␣|␣sac_scale␣=␣difficult_alpine_hiking)␣{set␣highway␣=␣bergweg56;␣set␣motorcar␣=␣no}

du entfernst also die automatisch gesetzten access-beschränkungen bei bergwegen, bei denen eine der 4 unteren sac_scales auftaucht.
möchtest du nur typ 3 und 4 routbar, lässt du die beschränkungen bei bergweg56 drin.
möchtest du, dass alle gleich gezeichnet werden, brauchst du einfach den code:

#␣Bergwege
highway␣=␣path␣&␣(sac_scale␣=␣hiking␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣sac_scale␣=␣mountain_hiking␣|␣sac_scale␣=␣demanding_mountain_hiking␣|␣sac_scale␣=␣alpine_hiking␣|␣sac_scale␣=␣demanding_alpine_hiking␣␣␣|␣sac_scale␣=␣difficult_alpine_hiking)␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg12}

ich hoffe ich konnte helfen, wenn du probleme hast melde dich.

bicycle=no würde ich da auch noch setzen. Bei mountain_hiking würde ich evtl. auch über ein bicycle=no nachdenken.

Jayjay01 wrote:

du öffnest die datei lines-master (/style/), und suchst dort nach diesem code

Super, vielen Dank.

Ich habe jetzt folgende Einstellung verwendet um sicherzugehen, dass ich nicht mit dem Radl zufällig auf solche Wege geführt werde.

highway␣=␣path␣&␣(sac_scale␣=␣demanding_mountain_hiking␣|␣sac_scale␣=␣alpine_hiking)␣␣␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg34;␣set␣motorcar␣=␣no;␣set␣bicycle␣=␣no}
highway␣=␣path␣&␣(sac_scale␣=␣demanding_alpine_hiking␣␣␣|␣sac_scale␣=␣difficult_alpine_hiking)␣{set␣highway␣=␣bergweg56;␣set␣motorcar␣=␣no;␣set␣bicycle␣=␣no}

Und schon klappt das einwandfrei.

Ich werde mir jetzt mal die Seiten aus dem OSM Wiki durchlesen die in der Datei referenziert werden. Vielleicht verstehe ich das dann auch etwas besser.

Vielen Dank für die Hilfe

Klaus, von dieser Deiner Karte bin ich immer noch völlig begeistert!

Mir sind aber 2 kleine Fehler in den von mir (mit der ebenso tollen Entwicklungsumgebung, auch noch mal Danke dafür!) gebauten Karten aufgefallen, die wohl die gleiche Ursache haben. Das eine ist eine Straße (highway = unclassified) die zu einem Platz aufgespannt ist (area = yes). Die Straße wird als "Ring" gemappt.
Das zweite ist ein Industriegebiet, das von einem Zaun umgeben ist. Weder Zaun noch Industriegebiet werden dargestellt. Nur der Name der Firma taucht auf.
Wenn ich es richtig verstanden habe wird nach dem ersten "Treffer" in den Styles die Auswertung abgebrochen. Das kann mit einem "continue" verhindert werden und die Auswertung geht weiter.
Nun ist es aber ja üblich, nach den spezielleren Fällen, die man detailliert gemappt haben möchte noch eine allgemeinere Regel anzuhängen, die die bisher nicht abgedeckten Fälle auffängt. (z.B. nach "shop = supermarket" und "shop = shoes" ... noch ein shop = * für den ganzen Rest.
Würde mit einem "continue" nicht diese allgemeine Regel den vorher schon gesetzten Typ überschreiben? Und müsste nicht auch die allgemeinere Regel noch ein "continue" bekommen, damit im nächsten Style-File nach weiteren Regeln gesucht wird (die Straßen line also zum Platz polygon wird)?
Muss also nicht im Endeffekt quasi überall ein "continue" stehen, damit alle Darstellungen mehrfach getaggter Items auch sichtbar werden? (In diesem Fall also einerseits das highway zusammen mit area=yes und andererseits das landuse zusammen mit fence=yes)
Das hat doch sicher unerwünschte Nebenwirkungen?
Oder übersehe ich irgendwo einen "Schalter" oder eine mkgmap-Option, durch die diese Fälle richtig gemappt werden?

Erweiterungstipp:
Ich habe Dein Script um einen Übergabeparameter "mapkind" erweitert und verwende diesen für eine Angabe des gewünschten style.
Den Ordner style habe ich in freizeit_style umbenannt. Parallel dazu liegen bei mir die aio-styles als weitere Ordner (pkw_style, keepright_style, velomap_style, u.s.w.).
Im TYP-Verzeichnis gibt es entsprechend die zugehörigen TYP-Dateien (Neben freizeit.TYP also pkw.TYP, keepright.TYP, u.s.w.)
Jetzt kann ich mir also auch schnell mal eine maxspeed- oder velomap-Karte erzeugen, wenn ich als letzten Parameter zu allen Kommandos einfach maxspeed bzw. velomap (oder einen der anderen style-Namen) hinzufüge.
So einfach kann Kartenerstellung sein!

Noch mal tausend Dank!
Heinz

Hallo Heinz,

zunächst einmal Danke für dein Feedback.

Bezüglich des Platzes der via "highway = unclassified" definiert ist, hast du recht:

highway = unclassified [0x010106 resolution 21-22]
...

1. Breitere Straßen die als Flächen getaggt sind.
   

highway = residential & area = yes [0x31 resolution 20]
highway = unclassified & area = yes [0x31 resolution 20]
highway = service & area = yes [0x31 resolution 20]

Korrekt müßte es heißen:
highway = unclassified [0x010106 resolution 21-22 continue]

Ich werde das entsprechend ändern.
Kannst du mir die Stelle (zwecks Überprüfung meiner Änderung) als OSM-Permalink schicken ?

Zäune werden derzeit in der Karte nicht unterstützt - hier bin ich bzgl. des Informationswertes skeptisch.
Einige Mapper definieren darüber mittlerweile auch Grundstücksgrenzen.

Das Industriegebiet sollte eigentlich dargestellt werden.
Kannst du mir die Stelle (zwecks Überprüfung) als OSM-Permalink schicken ?

Entwicklungsumgebung:
Ja, da hast du recht.
Man kann die Entwicklungsumgebung sehr gut nutzen, um auch andere Karten zu erstellen.
Wobei die mkgmap-Optionen aber zur Karte passen müssen.

Gruß Klaus

Admin für FZK-Webserver gesucht ...

Ich möchte mit der Freizeitkarte auf einen leistungsstärkeren Server wechseln.
Möchte jemand das FZK-Projekt durch die Betreuung dieses Servers unterstützen?
Der Admin wäre von Anfang an auch für die Installation des System verantwortlich.

Gruß Klaus

PS: Ich stelle in Aussicht, daß freie Ressourcen für OSM-Zwecke genutzt werden können.

Aufgrund der derzeitigen massiven Nutzungseinschränkungen meines Servers,
wurden in den letzten Tagen mehrere (Download-)Mirror-Server eingerichtet.

Auf diesem Server (Schweiz) finden sich alle aktuellen Karten (Ausgabe 12.3):
http://osm.dunkleaura.ch/Freizeitkarte/

Vielen Dank an "Billy" für die Bereitstellung der Ressourcen und die geleistete Unterstützung.

Gruß Klaus

PS: Ebenfalls dort verfügbar sind entsprechende Torrents.

... Phoenix aus der Asche ...

Die FZK-Webseite ist auf neuem Server jetzt wie folgt erreichbar:

www.freizeitkarte-osm.de

... weiterhin viel Freude an der Karte und viele interessante Touren damit ...

Gruß Klaus

Freizeitkarte Wintersport für Garmin BaseCamp und GPSr

Von der Freizeitkarte ist für den kommenden Winter eine "Wintersport-Ausgabe" geplant.
Thematisch wird sich Roman um das Thema kümmern.
Er hat im deutschen "geoclub" dazu einen Thread eröffnet:
http://www.geoclub.de/viewtopic.php?f=7 … d4c482b2c3
Schön wäre es, wenn sich der eine oder andere Wintersportler an der thematischen Ausarbeitung beteiligen könnte.
Dies insbesondere im Hinblick auf die OSM-Daten.

Gruß Klaus

Die Freizeitkarten Deutschland, Österreich und Schweiz sind in der Ausgabe 12.4 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 20.04.2012.

Link: http://www.freizeitkarte-osm.de

Freizeitkarte: Ergänzungen / Veränderungen in dieser Ausgabe (12.4):
- allgemeine Verbesserung des Routings
- allgemeine Verbesserung der Darstellung
+Darstellung des allgemeinen POIs als "rotes Quadrat" (vormals "rotes Kreuz")
+Darstellung von Ruinen und Bunker durch eigene Signaturen
+Darstellung von Beobachtungs- / Funktürmen durch eigene Signaturen
+Unterscheidung der Waldgebiete in Laub-, Nadel- und Mischwald
+Darstellung der Waldgebiet durch die topografischen Standardsignaturen
+hellere Darstellung von Bauland, Bauerwartungsland und Brachland
+eigener POI für Bauernschaft / Weiler (brauner Punkt, braune Schrift)
+eigene Symbole für Tor, Schlagbaum und Umlaufsperre
+korrekte Darstellung von Plätzen (vormals Ringstraße)
+schraffierte Darstellung der Flächen von Kraft- / Umspannwerken
- Implementierung von Skipisten, Loipen und Rodelbahnen (durch Roman, Feature noch nicht aktiv)

Entwicklungsumgebung: Ergänzungen / Veränderungen in dieser Ausgabe (12.4):
- vollständige Vorverarbeitung für Style-Files (Preprozessor)
- ppp.pl 1.2.44
- MapTool (mt.pl) 0.6.0
- mkgmap r2267
- bounds (world) vom 21.02.2012
- jmc 0.6

Kartenstatus:
Alle Freizeitkarten befinden sich im Status "Erprobung".
Hilf mit die Karten zu verbessern - Danke.

Kartendarstellung in BaseCamp: Brunsbüttel, Schleuse

Gruß Klaus

Danke für die regelmäßigen Updates! Die 'Freizeitkarte(TM)' ist mittlerweile zu meiner Standardkarte sowohl im Basecamp als auch auf dem 60CSx geworden.

Schöne Karte, aber:
Bei mir funktioniert die Addresssuche in BaseCamp 3.3.1 nicht mehr...
Wenn ich z.B. die Stadt Eppingen, Landkreis Helbronn suche, lande ich immer in Einzel, Hof, wenn ich nach Einzel such lande ich in Edelshausen, Neuburg-Schrobenhausen usw...
Es sind aber immer Städte mit dem selben Anfangsbuchstaben.
Ich hatte das schon mal mit der Velomap. Kennt das jemand?

Klappt bei mir (BaseCamp OS X, 3.3.2) :

Hast du ggf. noch weitere Infos zu deinem Problem ?

Gruß Klaus

Danke für die schnelle Antwort.
Hab mich vielleicht falsch ausgedrückt:
Wenn ich eine Adresse in Eppingen suche, dann springt er in die falsche Stadt:
Suche nach: "Adresse" in der Nähe von "Eppingen, Landkreis Heilbronn, DEU" enthält "Talstrasse", dann sucht er nach Talstrasse in der Nähe von Einzel, Hof.

Wenn ich erst über Stadtsuche und dann über Suche nahe Mitte der Karte gehe, funktionierts.

Ich hatte schon Karten bei denen auch die direkte Suche funktioniert hatte.

Würde das passen ?

Ja so wärs schön. 🙂
Leider ist es nicht so. (mittlerweile Basecamp 3.3.2 Windows 7)
Der hüpft tatsächlich immer zu einer anderen Stadt mit dem selben Anfangsbuchstaben. 🙁

Hallo, ich benutze die Karte schon länger. Sie gefällt mir gut!!
Nun wollte ich die neueste Karte laden, geht nicht!! Mein Vierenprogramm löscht die EXE Datei. Was kann ich da machen?
Gruß Nimra

Du könntest folgendes versuchen:
- Virenscanner temporär für die Dauer des Downloads und der Installation deaktivieren

Gruß Klaus

Ein Antivirenprogramm welches seine Arbeit nicht ordentlich verrichtet sollte m.M.n. in den Papierkorb befördert werden. 😉

Hallo, jetzt habe ich auch einen Screenshot gemacht:

Kann das mal jemand mit Basecamp 3.3.2 unter Windows 7 nachstellen?

Hi Klaus
kann man die Warnung mit der nicht definierten Variablen beim gmapsupp build ignorieren?

Welche Warnung ?

Hallo alle.

Ich habe mein Problem mit der Adresssuche unter BaseCamp 3.3.2 und 3.3.1 unter Win7 Home Premium gelöst. 😄

Problembeschreibung:
Bei der direkten Suche nach Adressen, also z.B. "Suche Adresse nahe Eppingen, Landkreis Heilbronn, DEU enthält Talstrasse" springt der Kartenausschnitt auf einen anderen Ort mit dem selben Anfangsbuchstaben und sucht dort nach der entsprechenden Strasse.

Problemlösung:
Wenn die selbe Karte in einer anderen (älteren) Version bereits installiert war muss nach der Installation der neuen Karte der Cache unter "C:\Users\Username\AppData\Local\Garmin\BaseCamp\ProductDataCache" und u.U. auch unter "C:\Users\Username\AppData\Local\Garmin\BaseCamp\TileCache" gelöscht werden, sonst stimmt die Zuordnung der Orte zur aktuellen Karte nicht.

Dieses Verhalten betrifft nicht nur die Freizeitkarte sondern (zumindest auf meinem Rechner) wohl alle Karten.

Gruss Johannes

fab-j wrote:

Ich habe mein Problem mit der Adresssuche unter BaseCamp 3.3.2 und 3.3.1 unter Win7 Home Premium gelöst.

Eben wolle ich die Vorgängerversion der Karte wieder installieren, um es zu testen, da schaute ich glücklicherweise noch mal ins Forum 😉
Ich konnte dein Problem exakt nachvollziehen und kann auch die Lösung bestätigen.

Evt kann toc-rox das auf seiner Seite als Info mit aufnehmen.
Die Freizeitkarte wird immer mehr zu meiner Favoritenkarte und ich möchte mich ausdrücklich für die Arbeit bedanken.

Use of uninitialized value $filename_source_mtime in localtime at mt.pl line 151

Hallo Chris,
könnte es sein, daß du den Schritt "create" ausgelassen hast ?
Gruß Klaus

CADdog63 wrote:

Ich konnte dein Problem exakt nachvollziehen und kann auch die Lösung bestätigen.

Danke für ausprobieren.

CADdog63 wrote:

Die Freizeitkarte wird immer mehr zu meiner Favoritenkarte und ich möchte mich ausdrücklich für die Arbeit bedanken.

+1

@fab-j: Könntest du zum Problem und dessen Lösung einen prägnanten Text (so 2-3 Sätze) erstellen ?
Ich würde den Text dann so auf die Webseite (Dies-Und-Das) übernehmen ...

Gruß Klaus

toc-rox wrote:

Hallo Chris,
könnte es sein, daß du den Schritt "create" ausgelassen hast ?
Gruß Klaus

Könnte sein, ja. 😉
Ist meine gmapsupp.img trotzdem ok?

Chris

Die Datei ist vermutlich OK - wobei die Versionsnummer "lustig" aussehen könnte.
Klaus

Jepp, 30.1.
Kleiner Fehler: Feldwege werden in hohen Zoomstufen als [Fuß/Radweg] angezeigt.

Ich versuche gerade Stromleitungen und -masten in der Karte auszublenden, da sie für mich nicht interessant sind. Dazu habe ich in lines-master, die Zeilen:

power␣=␣line␣[0x29␣resolution␣24]
power␣=␣minor_line␣[0x29␣resolution␣24]

entfernt (auskommentiert).

Dann habe ich in points-master die Zeile:

power␣=␣tower␣{name␣'${name}␣(Strommast)'␣|␣'Strommast'}␣[0x6417␣resolution␣24]

entfernet.

Im TYP File habe ich die Einträge für Type=0x064, SubType=0x17 sowie Type=0x29 entfernt.

Im Großen und Ganzen klappt das auch gut, allerdings wird an der Stelle wo die Stromleitung vorher dargestellt wurde, ein weißer Bereich angezeigt.

Gibt es eine Möglichkeit diese weisse Fläche/Linie auch loszuwerden?

Ich habe in polygons-master auf Anhieb nichts gesehen, was dieser Fläche entsprichen würde.

Zur eigentlichen Frage:
Bei der Lücke könnte / dürfte es sich um die (Leitungs-)Schneise im Wald handeln.
Das müßtest du in den Daten einmal prüfen.

Möglicherweise interessant:
- In BaseCamp können die Objekte auch via Karteneinstellungen ausgeblendet werden.
- Dies geht im GPSr dann allerdings nicht.
- Das TYP-File kann man so belassen.
- Die Objekte werden, wenn sie in den Style-Files fehlen, dann ja nicht verwendet.

Preprozessor:
- In der aktuellen Version der Entwicklungsumgebung findet sich ein Mechanismus zur Vorverarbeitung der Style-File (Prepozessor).
- Hierüber kann man in den Style-Files zur Übersetzungszeit (build) Passagen / Objekte ein- oder ausblenden.

Beispiel:
- In lines-master definert man z.B.:

#ifdef␣POWERLINES
power␣=␣line␣[0x29␣resolution␣24]
power␣=␣minor_line␣[0x29␣resolution␣24]
#endif

- Übersetzt man jetzt so, fehlen die Stromlinien:
perl mt.pl build Freizeitkarte_Hamburg

- Übersetzt man alternativ so, sind die Stromlinien (wieder) enthalten:
perl mt.pl build Freizeitkarte_Hamburg DPOWERLINES

Gruß Klaus

toc-rox wrote:

Zur eigentlichen Frage:
Bei der Lücke könnte / dürfte es sich um die (Leitungs-)Schneise im Wald handeln.
Das müßtest du in den Daten einmal prüfen.

OK, das scheint's wohl zu sein.
Danke für den Hinweis.

- In BaseCamp können die Objekte auch via Karteneinstellungen ausgeblendet werden.
- Dies geht im GPSr dann allerdings nicht.

Mir geht's hauptsächlich um die Darstellung auf dem Oregon. Ich möchte gerne die Anzahl der Linien verringern.

Hi,
für alle Flachlandtiroler gibt's nun auf meiner Wikiseite die FZK ohne Höhenlinien.
Chris

Warum werden eigentlich die Häuser so extrem verzerrt auf der Karte dargestellt?

Auf dem screenshot von fab-j ist das auch deutlich erkennbar:

fab-j wrote:

http://i.imgur.com/pF2iB.jpg

Das liegt daran, dass die Präzision der Koordinaten im Garminformat begrenzt ist.

Genau, ich meine die sind nur auf 4 Meter oder so genau. Führt z.B dazu dass Kreisverkehre umso zackiger aussehen, mit je mehr Punkten sie gemappt sind.

aighes wrote:

Das liegt daran, dass die Präzision der Koordinaten im Garminformat begrenzt ist.

Richtig.
Begrenzt ist diese aber eigentlich in jedem Format, bei dem einen mehr, bei dem anderen weniger. 😉
Wenn ich mich richtig erinnere, dann werden hier nur 2 Byte pro Längen- bzw. Breitengrad verwendet.
Somit kommt es bei der Umwandlung eines OSM-Punktes in einen Garmin-Punkt zu einem Informationsverlust.
Entweder wird der genauere OSM-Punkt auf den nächstliegenden Punkt des ungenaueren Garmin-Gitters gelegt oder die Zahl wird einfach am Ende abgeschnitten.
Damit möchte man Speicherplatz und Rechenzeit sparen, ich halte dieses Vorgehen allerdings inzwischen für veraltet.
Dass es auch genauer geht, zeigt z.B. MapsForge, denn dieses Format verwendet 4 Byte pro Längen- bzw. Breitengrad, ich habe es jetzt nicht nachgerechnet, aber damit liegt dann die Auflösung geschätzt im einstelligen Zentimeterbereich.

Gruß,
Mondschein

Die Freizeitkarten sind in der Ausgabe 12.5 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 16.5.2012.

Link: http://www.freizeitkarte-osm.de

Freizeitkarten: Neu in der Ausgabe 12.5:
- allgemeine Verbesserung des Routing
- Freizeitkarte Alpen
- Freizeitkarte Frankreich
- alle Karten auch für QLandkarte

Die Ausgabe 12.5 der Freizeitkarten nutzt erstmalig die Möglichkeiten des neuen Webservers.
Die Generierung weiterer Länderkarten ist damit jetzt möglich.
Danke an Christian, der sich schwerpunktmäßig um die vielen technischen Aspekte gekümmert hat.

Die Freizeitkarten werden vor der Veröffentlichung immer intensiv durch Kartennutzer geprüft - und so soll es auch in Zukunft sein.

Hast du vielleicht Interesse "Karten-Pate" zu werden und an dem Projekt mitzuhelfen ?

Als Pate bist du dann einer derjenigen, der eine Länderausgabe vor der Veröffentlichung überprüft,
in Foren auf Feedback zu "deiner" Karte achtet, länderspezifische Anpassungen vorschlägt oder sogar umsetzt.
Und nebenbei eine ganze Menge Spass dabei hat, eine Geodatenbank aus Bits und Bytes in etwas umzusetzen,
das Menschen im Alltag einsetzen - (d)eine Freizeitkarte.
IT-Profi musst du keiner sein - die Bereitschaft dich einzubringen ist die wichtigste Voraussetzung.
Ein Bisschen was geht immer - und wieviel dies ist, dass bestimmst du selbst ...

Kartendarstellung in BaseCamp: Berlin - Brandenburg, Willy-Brandt-Flughafen (im Bau)

Viel Freude an den Karten ... und viele interessante Touren damit.

Gruß Klaus

Nahmd,

toc-rox wrote:

- Freizeitkarte Alpen

Yeah! Endlich da. 🙂 🙂 🙂

Meine herzlichen Dank. Da macht das Erfassen ja nochmal soviel Spaß!

Gruß Wolf

Hallo Wolf,

die Alpenkarte deckt folgendes Gebiet ab:

Solltest du für deine Mappingaktionen regelmäßigere Updates benötigen, so ist das jetzt auch möglich.

Eine andere Frage noch:

Es wurde angeregt für einige der folgenden POIs auch deutsche Begriffe anzugeben.
Wie wären die deutschen Begriffe oder sind das "feststehende" Bezeichnungen die man nicht "eindeutschen" sollte ?

Gruß Klaus

Nahmd,

toc-rox wrote:

http://i.imgur.com/EBh0G.png

Es wurde angeregt für einige der folgenden POIs auch deutsche Begriffe anzugeben.
Wie wären die deutschen Begriffe oder sind das "feststehende" Bezeichnungen die man nicht "eindeutschen" sollte ?

Ein Versuch:

Alpin Hut (mit Bewirtung) → Berghütte (impliziert eigentlich mit Bewirtung, könnte man aber dennoch in der Legende hinzufügen)

Alpin Hut (ohne Bewirtung) → Selbstversorgerhütte (impliziert das "ohne Bewirtung")
↓
(fließender Übergang)
↓
Wilderness Hut → Einfache Selbstversorgerhütte / komfortable Biwakhütte (ich bevorzuge #1)
↓
(fließender Übergang)
↓
Basic Hut → Biwakhütte

Lean To → kenne ich nicht aus DE/AT. Habe ich zum ersten Mal gesehen in einer TV-Doku über den Apalachien Trail in den USA. Übersetzung vielleicht: “Offene Hütte mit Übernachtungsmöglichkeit”?

Gruß Wolf

lean_to dürften sowas wie Schutzhütten sein. Gibts auch in D...bspw. entlang des Rennsteigs.

http://www.outdoorseiten.net/wiki/Schut … _Rennsteig

Inzwischen gabs eine Abstimmung über die Hütten: alpine hut (impliziert eigentlich Bewirtschaftung) wurde angenommen, wilderness ebenfalls, basic und lean_to wurde abgelehnt.

Man muss sich natürlich nicht dran halten, ich finde die Einteilung der FZK gut, 25 Wähler sind ja auch nicht soooo die grosse Gruppe und viele Leute stellen auch Dinge dar, die es nie in die map features im Wiki geschafft haben. Aber wir sollten beobachten, wie sich die Hütten anderswo entwickeln. Die Alpenkarte hat ja Gebiete in FR, CH, IT dabei, wo die Leute vielleicht anders mappen...

Edit: Links zum Voting nachgereicht

Nahmd,

aighes wrote:

lean_to dürften sowas wie Schutzhütten sein. Gibts auch in D...bspw. entlang des Rennsteigs.

Die würde ich eher als Shelter ansehen. Auch weil die Seite explizit vor dem unbestigten Boden warnt.

Die Hütten am Apalachian Trail haben einen befestigten (Holz-)boden. Soviel Luxus muss aber bei einer Gesmtstrecke von 3500km und Wanderzeit von ½Jahr auch sein 🙂

Wobei der Übergang Shelter→Lean_to fließend ist, die Einstufung also subjektiv. Deshalb würde ich beim Taggen von Rennsteighütten der Vorgehensweise der Locals folgen.

Gruß Wolf

Ich würde das Wort "Schutzhütte" unbedingt meiden und Wolfs Benennung empfehlen.

Viele Hütten verwenden aus Gründen der Tradition die Benennung "Schutzhütte Irgendwas", auch wenn sie inzwischen weit darüber rausgewachsen sind (z.B. Zufallhütte, Sesvennahütte, keine Ahnung, warum ich gerade lauter Südtiroler Hütten ergoogle). Das könnte die Leute verwirren...

@Netzwolf: Nunja...als die getaggt wurden gab es noch kein lean_to 😉

Ich bin als Radreisender auch eher weniger darin zuhause, kenne daher auch nicht die "Spitzfindigkeiten". Wenn aber der Unterschied zwischen shelter und lean_to nur die Bretter zum drauf schlafen sind, dann gibt es am Rennsteig beides.

Nahmd,

ich habe folgende Vorstellung von Hütten:

Shelter ← Dach überm Kopf, schützt (bei nicht zuviel Wind) vor Regen, aber nicht vor Kälte.

Lean_to ← windgeschützt(er) und man kann auf dem Boden schlafen, kein Kälteschutz.

Basic_hut ← man kann die Tür zumachen, also etwas Kälteschutz. Mglw. keine Möglichkeit zum aufrechten Stehen.

Wilderness_hut ← Wie Basic hut, aber man kann herumgehen und überlebt einen eingeschneiten Tag ohne einen Koller zu bekommen.

Alpin_hut ← "Richtige" Hütte, oft mit Kochgelegenheit, oft mit Heizmöglichkeit.

Das Restaurant bei Alpin_hut einzeln zu taggen, gefällt mir inzwischen. Und zwar weil Hütten sich möglicherweise als Tagesausflugsziel mit Einkehr am Ziel eignen, ohne dass da die Übernachtungsmöglichkeit interessiert. Also kann es mglw. Karte geben mit Restaurant eingezeichnet, aber Übernachtungsmöglichkeit nicht eingezeichnet.

Basic_hut werde ich unabhängig von irgendwelchen Votings sicher wo passend weiter verwenden.

Lean_to habe ich doch schon einmal gefunden, im Schwarzwald am Westweg: eine "normale" Regenschutzhütte mit einer zweiten flachen Etage unter dem Dach. Die gibt es bei uns möglicherweise so selten, weil sie (in der Nähe von Siedlungen) Saufgelage anziehen.

Gruß Wolf

Netzwolf wrote:

Nahmd,

toc-rox wrote:

http://i.imgur.com/EBh0G.png

Es wurde angeregt für einige der folgenden POIs auch deutsche Begriffe anzugeben.
Wie wären die deutschen Begriffe oder sind das "feststehende" Bezeichnungen die man nicht "eindeutschen" sollte ?

Ein Versuch:

Alpin Hut (mit Bewirtung) → Berghütte (impliziert eigentlich mit Bewirtung, könnte man aber dennoch in der Legende hinzufügen)

Alpin Hut (ohne Bewirtung) → Selbstversorgerhütte (impliziert das "ohne Bewirtung")
↓
(fließender Übergang)
↓
Wilderness Hut → Einfache Selbstversorgerhütte / komfortable Biwakhütte (ich bevorzuge #1)
↓
(fließender Übergang)
↓
Basic Hut → Biwakhütte

Lean To → kenne ich nicht aus DE/AT. Habe ich zum ersten Mal gesehen in einer TV-Doku über den Apalachien Trail in den USA. Übersetzung vielleicht: “Offene Hütte mit Übernachtungsmöglichkeit”?

Gruß Wolf

Ich habe das mal so unverändert übernommen:

Gruß Klaus

Nachtrag: Hier gibt's gleich 5x Lean-To auf kurzer Strecke - aber ob das so beabsichtigt war ?

Insgesamt gibt es in den Alpen aber recht wenige Lean-To.

Gruß Klaus

Die Freizeitkarte wird immer besser- toll! Dennoch möchte ich einige Optimierungsvorschläge benennen:
Ich fände es gut, wenn bei den tracks die Wegecharakteristik von grade 1 bis 5 ausdifferenziert und möglichst klar unterscheidbar dargestellt würde. Dies ist vor allem für Trekkingrad- und Mountainbiker wichtig und der große Vorteil der OSM gegenüber den offiziellen Karten. Dies wird m.E. bislang noch am Besten umgesetzt von Nop's Wanderreitkarte und von Kleineisel (weniger gut z.B. im Mapnik-Stil). Wünschen würde ich mir noch eine optimiertere bzw. kontraststärkere Darstellung für Garmin-Geräte. Die Freizeitkarte kommt zumindest im Edge 800 vergleichsweise blass rüber, weshab man die Display-Helligkeit sehr hoch setzen muss und so den Akku schnell leergesaugt hat. Für Ganztagestouren mit dem Fahrrad deshalb kaum zu gebrauchen.

trelgne wrote:

Wünschen würde ich mir noch eine optimiertere bzw. kontraststärkere Darstellung für Garmin-Geräte. Die Freizeitkarte kommt zumindest im Edge 800 vergleichsweise blass rüber, weshab man die Display-Helligkeit sehr hoch setzen muss und so den Akku schnell leergesaugt hat. Für Ganztagestouren mit dem Fahrrad deshalb kaum zu gebrauchen.

Das ist wohl mehr ein Problem der Touchscreen gegenüber einfacheren Displays.
Man vergleiche mal Edge 700 gegenüber Edge 800 oder eTrex gegenüber Oregon/Dakota.

Wenn der Kontrast für Touchscreens optimiert ist, wäre er für einfachere Displays viel zu hoch.
Ebenso würde das wahrscheinlich in Basecamp auf einem PC-Monitor ziemlich daneben aussehen.

PS: Manchmal hilft es auch, die Sonnenbrille abzusetzen.

Edbert (EvanE)

...übrigens auch der Grund, warum die RadReiseKarte so quitschbunt ist. 😉 Die Darstellung auf dem Monitor geht egtl. Ist halt etwas kräftiger, aber ist halt wie alles optische Geschmackssache.

Die Darstellung kann man aber auch recht simpel über das TYP-File ändern.

Weitere Fragen an die "Alpenexperten":

Speziell für die Alpenkarte wurde der Wunsch geäußert "Trinkwasserstellen" auszuweisen.

Fragen:
- Als wie wichtig ist das Feature "Trinkwasserstellen" einzustufen ?
- Wenn sinnvoll: Sollte das Feature eine eigene Signatur bekommen ?

Gruß Klaus

Du Klaus,

was ich z.B. vermisse:

Das sind Sitzbänke und Hochsitze. Wäre das möglich diese anzeigen zu lassen?

Gruß Jürgen und Danke für deine gute Karte

trelgne wrote:

Die Freizeitkarte kommt zumindest im Edge 800 vergleichsweise blass rüber, weshab man die Display-Helligkeit sehr hoch setzen muss und so den Akku schnell leergesaugt hat. Für Ganztagestouren mit dem Fahrrad deshalb kaum zu gebrauchen.

Trelgne,

das ist einer der großen Pluspunkte der Freizeitkarte! Die Pastellfarben sind perfekt um darauf die Geocaches erkennen zu können. Das war bei der Kleineisel immer etwas schwierig und soll bitte bloß nicht geändert werden.

LG,

-moenk

toc-rox wrote:

Speziell für die Alpenkarte wurde der Wunsch geäußert, "Trinkwasserstellen" auszuweisen.

Fragen:
- Als wie wichtig ist das Feature "Trinkwasserstellen" einzustufen ?
- Wenn sinnvoll: Sollte das Feature eine eigene Signatur bekommen ?

Wäre praktisch, aber nicht zwingend notwendig.
(In Italien/Südtirol deutlich praktischer, weil es da im Gebirge wesentlich weniger Quellen/Brunnen gibt als z.B. in den bayrischen und österreichischen Alpen)

In der Garmin TransAlpin sieht es so aus:

Wobei ich das Zeichen nicht wirklich gelungen finde.

Ich denke wenn es eingebaut wird, sollte das irgendwie über die Kommandozeile beim Bauen in der Entwicklungsumgebung abschaltbar sein.
So kann man vermeiden dass zu viele Sachen angezeigt werden.

Nahmd,

toc-rox wrote:

- Als wie wichtig ist das Feature "Trinkwasserstellen" einzustufen?

Für Bergregionen: sehr wichtig.

In die Alpenvereinskarten sind eine große Menge von Quellen eingetragen, die aber häufig nur sehr schwer zu finden sind. Die Auflösung der 1:25k und das Druckraster setzen da der Präzision eine Grenze.

Hat man die einmal per GPS eingemessen, sind die mit einer Onlinekarte deutlich einfacher zu finden. Ein Eintrag ist also wirklich hilfreich.

- Wenn sinnvoll: Sollte das Feature eine eigene Signatur bekommen ?

Die Alpenvereinskarte verwendet einen blauen Kringel mit einer blauen Schlangenlinie, ähnlich dem Buchstaben "Q". Die Schlangenlinie zeigt in Fließrichtung des Wassers.

Um das nachzuahmen, muss man natürlich die Fließrichtung des Gewässers kennen. Die sollte man aber ohnehin erfassen, alldieweil es das Auffinden der Quelle sehr erleichtert.

Gruß Wolf

toc-rox wrote:

Speziell für die Alpenkarte wurde der Wunsch geäußert "Trinkwasserstellen" auszuweisen.

Fragen:
- Als wie wichtig ist das Feature "Trinkwasserstellen" einzustufen ?
- Wenn sinnvoll: Sollte das Feature eine eigene Signatur bekommen ?

Bin zwar kein Alpenexperte, wandere aber regelmäßig im Sommer im Ausland. Von daher kann ich nur sagen: Wasser ist schwer und auf langen Strecken braucht man viel davon, von daher sind Stellen, wo man das Trinkwasser auffüllen kann, sehr wichtig.

Den 2. Teil der Frage verstehe ich nicht, was meinst Du mit "eigene Signatur bekommen"?

Thorsten

Ich habe mal ein Bild erstellt, das eine Ähnlichkeit mit dem Topo-Quellen-Symbol hat. Wer es mag, darf es gerne nutzen.

Allgemein gibt es natürlich auch noch amenity=drinking_water. Keine Ahnung, ob es sowas auch in den Alpen gibt.

btw: auch wenn es hier recht OT ist: Gibt es bereits eine Sammlung von garmintauglichen, freien Bilderchen (bzw. die typ-files, da kann man sich diese ja auch raus kopieren) im wiki oder sonstwo? Bzw. bestünde daran ein Interesse?

Moins,

Netzwolf wrote:

Um das nachzuahmen, muss man natürlich die Fließrichtung des Gewässers kennen. Die sollte man aber ohnehin erfassen, alldieweil es das Auffinden der Quelle sehr erleichtert.

Feststellung: ich hab die Fließrichtungen natürlich nicht eingegeben.
Schwätze ist einfacher als schaffe. 🙁
Hmpf!

Bevor ich das aber nachhole eine Frage zum diesbezüglichen Tagging: manche Punktfeatures wie hier die Quellen haben eine Orientierung. Das hatten wir bereits bei den Scharten festgestellt, gilt aber auch (und gerade) für Verkehrsschilder.

Ich verwende seit einiger Zeit zur Angabe einer (groben) Orientierung “dir=N/NE/E/SE/S/SW/W/NW”.

→ ist sehr robust, funktioniert bei Verkehrsschildern (Ortseingang z.B.) auf der Straße oder links oder rechts davon.
→ beim Rendern leicht auszuwerten, indem man z.B. das Symbol in 8 gedrehten Versionen vorhält.
→ liegt das Punktfeature auf oder neben einem Way, kann man mit einer trivialen Berechnung (Skalarprodukt positiv/negativ) feststellen, ob es in oder gegen die Orientierung des Ways zeigt.

Hat jemand eine bessere Lösung für die Aufgabenstellung?

Gruß Wolf

Nö...keine Lösung. Ist bei den Garminkarten auch nur recht komplex umsetzbar. Man bräuchte für jede Richtung eine eigene ID und ein Bild dafür.

Für mich kann ein punktförmiges Objekt wie ein Node auch keine Richtung haben. Die Quelle ist halt an dem Punkt wo der Node ist und die Richtung gibt dann der waterway=*stream an, der dann dort losgehen sollte 😉

kukuk wrote:

... Den 2. Teil der Frage verstehe ich nicht, was meinst Du mit "eigene Signatur bekommen"? ...

In der FZK werden viele POIs lediglich durch kleine Quadrate dargestellt. Hierdurch wird verhindert, daß z.B. Innenstädte mit Signaturen "zugepflastert" werden. "Wichtige" POIs (z.B. Kirche, Krankenhaus, Polizeistation, ...) haben aber eigene Signaturen. Die Frage war so gemeint: Ist das Objekt "Trinkwasserstelle" (in der Alpenkarte) so wichtig, daß es über eine eigene Signatur (und nicht durch ein kleines Quadrat) dargestellt werden sollte?

Gruß Klaus

toc-rox wrote:

Weitere Fragen an die "Alpenexperten":

Speziell für die Alpenkarte wurde der Wunsch geäußert "Trinkwasserstellen" auszuweisen.

Fragen:
- Als wie wichtig ist das Feature "Trinkwasserstellen" einzustufen ?
- Wenn sinnvoll: Sollte das Feature eine eigene Signatur bekommen ?

Gruß Klaus

Leider war meine Frage nicht exakt genug - sorry dafür. Quellen sind in der FZK ja bereits enthalten - sie werden mit einem blauen "Q" dargestellt. Mit "Trinkwasserstellen" waren von mir zusätzliche Objekte vom Typ "amenity=drinking_water" gemeint. Denn nicht jede Quelle dürfte auch eine (ungefährliche) Trinkwasserstelle sein (so meine Vermutung). Die Diskussion wirft aber noch eine andere Frage auf: Wie erkennt man bei einer Quelle, ob diese auch eine Trinkwasserstelle ist ?

Gruß Klaus

aighes wrote:

... btw: auch wenn es hier recht OT ist: Gibt es bereits eine Sammlung von garmintauglichen, freien Bilderchen (bzw. die typ-files, da kann man sich diese ja auch raus kopieren) im wiki oder sonstwo? Bzw. bestünde daran ein Interesse?

Eine diesbezügliche Sammlung ist mir nicht bekannt. Die Signaturen der FZK stelle ich gerne zur Verfügung - dies sind aber ja nicht sehr viele.

Gruß Klaus

derjürgen wrote:

... was ich z.B. vermisse: Das sind Sitzbänke und Hochsitze. ....

Picknick-Plätze werden z.B. ausgewiesen ... sind ja auch potentielle Ziele.
Sitzbänke "überfrachten" m.E. die Karte aber.
Und Hochsitze wären eher etwas für eine Spezialkarte.
Oder werden Hochsitze oft als Orientierungspunkte im Wald verwendet?

Gruß Klaus

PS: Siehe auch Post #179 zum Thema "Sitzbänke und Hochsitze".

Ja Hochsitze werden schon als Orientierungshilfen genommen. Auch z.B. für Geocaching und diese Suchralley Spiele. Könnte ja auch als Punkte ohne fettes Symbol sein.

Gruß Jürgen

Nahmd,

aighes wrote:

Ist bei den Garminkarten auch nur recht komplex umsetzbar. Man bräuchte für jede Richtung eine eigene ID und ein Bild dafür.

Gut zu wissen. Mit Kartenrenderern kenne ich micht nicht aus.

Für mich kann ein punktförmiges Objekt wie ein Node auch keine Richtung haben.

Vieles, was als Punktfeature abstrahiert erfasst wird, hat eine Orientierung.
Und hey! Selbst ein Elektron hat einen Spin! 😉

Die Quelle ist halt an dem Punkt wo der Node ist und die Richtung gibt dann der waterway=*stream an, der dann dort losgehen sollte 😉

Du kennst Karst? Rinnsal kommt aus einem Felsen, um unmittelbar davor wieder im Boden zu verschwinden. Ein Linie in Originallänge wäre in der Karte unsichtbar. Und zeichnete ich die "für den Renderer" so lang, dass sie auch dargestellt wird, bildet das die Wirklichkeit nicht ab. Lasse ich die Line ganz weg, weiss ich nicht, auf welcher Seite eines Felsens oder einer Mulde ich suchen muss.

Deshalb halte ich die Angabe einer Quellrichtung für hilfreich.

Gruß Wolf

Nahmd,

toc-rox wrote:

Leider war meine Frage nicht exakt genug - sorry dafür. Quellen sind in der FZK ja bereits enthalten - sie werden mit einem blauen "Q" dargestellt. Mit "Trinkwasserstellen" waren von mir zusätzliche Objekte vom Typ "amenity=drinking_water" gemeint. Denn nicht jede Quelle dürfte auch eine (ungefährliche) Trinkwasserstelle sein (so meine Vermutung). Die Diskussion wirft aber noch eine andere Frage auf: Wie erkennt man bei einer Quelle, ob diese auch eine Trinkwasserstelle ist ?

Überhaupt nicht. Nach der deutschen Trinkwasserverordnung kann ich Wasser nur dann als Trinkwasser bezeichnen, wenn es regelmäßig im Labor überprüft wird. Es ist als weniger eine Frage der Hygiene als eine der Juristerei. Auch aus diesem Grund würde ich niemals Aussagen über Wasserqualität in der OSM-DB geschweige denn in einer Karte machen.

Brilliant ausgedrückt hat das mal eine Hüttenwirtin auf meine Frage: “Ist das Wasser aus dem Brunnen Trinkwasser?” mit der Antwort: “Wir trinken es.”

Man wird zwar Wasser aus gefassten Quellen und Brunnen vorziehen; wenn aber das Wasser ausgeht, ist man über die Angabe jeder Quelle dankbar.

Gruß Wolf

Nahmd,

toc-rox wrote:

Ist das Objekt "Trinkwasserstelle" (in der Alpenkarte) so wichtig, daß es über eine eigene Signatur (und nicht durch ein kleines Quadrat) dargestellt werden sollte?

Gefasster Brunnen / Wasserzapfstelle = kleiner blauer Kreis.

Quelle = kleiner dünnerer Kreis mit Schlangenlinie raus.

Die erscheinen mir selbsterklärend.

Gruß Wolf

Hallo Wolf,
Karst kenne ich nicht vom sehen her, kann es mir aber vorstellen. Auch eine Linie zeichnen, damit eine da ist halte ich für falsch.

Aber ist der Ort der Quelle nicht hinreichend über die Koordinaten beschrieben? Eine Quelle ist ja ein Ort, wo Wasser zu Tage tritt. Wenn an einem Ort eine Bushaltestelle steht und man diesen Ort entsprechend als Node taggt findet man diese doch auch. Ich verstehe daher nicht so ganz, wo das Problem bei der Quelle ist.

Evtl. hast du ein Bild mit so einer undurchsichtigen Situation, wo die Koordinate nicht ausreichend ist, um die Quelle zu finden.

Netzwolf wrote:

Die erscheinen mir selbsterklärend.

Das sagst du als jemand der mehr mit Topo-Karten zu tun hat, mir war bis gestern das Symbol völlig unbekannt 😉

aighes wrote:

Netzwolf wrote:

Die erscheinen mir selbsterklärend.

Das sagst du als jemand der mehr mit Topo-Karten zu tun hat, mir war bis gestern das Symbol völlig unbekannt 😉

Hmm…
also folgender Kompromissvorschlag:

“Die sind selbsterklärend, wenn man sie kennt.”

Akzeptabel?

Gruß Wolf

Klar...wenn man weiß (Legende), dass eine Quelle ein blaues "Q" ist, dann muss in der Karte nicht noch fett "Quelle" dran stehen.

@Netzwolf:
Für die Richtungsangabe von Nodes gibt es folgende, mir bekannte, Vorschläge:
https://wiki.openstreetmap.org/wiki/Pro … /direction
https://wiki.openstreetmap.org/wiki/Rel … ional_node

Nahmd,

Fabi2 wrote:

Für die Richtungsangabe von Nodes gibt es folgende, mir bekannte, Vorschläge:
https://wiki.openstreetmap.org/wiki/Pro … /direction
https://wiki.openstreetmap.org/wiki/Rel … ional_node

Mit #1 stimme ich bis auf den Key überein.

Die #2 ist schrott. Völlig überdimensioniert und anfällig gegen versehentliche Zerstörung (Lagekorrektur eines der beiden Punkte).

Ich werde also nach und nach von “dir=” auf “direction=” umtaggen. Und weiterhin nur einen Subset, also Kompassangaben, aber kein Zahlen benutzen.

Das ist doch mal ein schnelles Ergebnis. Danke für die Hinweise! 🙂

Gruß Wolf

Kartenpate für Belgien, Luxemburg und Niederlande gesucht:

Derzeit plane ich (noch vor dem Sommerurlaub) auch eine FZK für die vorgenannten Länder zu veröffentlichen.
Könnte jemand mit sehr guten Ortskenntnissen bei der Qualitätssicherung der Karten unterstützen?

Danke und Gruß - Klaus

Vielen Dank für die Erstellung dieser hervorragenden Karte.

Eine Anmerkungung hierzu: Die Radwege werden in der Farbe Blau angezeigt. Sie sind dadurch leicht mit kleinen Bächen zu verwechseln. Ich würde sie daher lieber in einer anderen Farbe sehen.

Wie seht ihr anderen Nutzer dies?

Leider ist die Anzeige der FZK auf dem GPS-Gerät Garmin 60csx sehr blass. Wälder sind z. B. blass grau (statt grün). Wege sind ähnlich grau. Insgesamt fehlen Kontraste. Gerade im Sonnenlicht ist daher draußen wenig zu erkennen.

Hat das Problem auf dem GPS-Gerät etwas gerade mit dem 60csx zu tun?

Was kann ich machen, um ein bessere Darstellung auf dem 60csx zu erreichen?

Zu Hause am Computer ist die Darstellung übrigens gut.

Ja, die alten Geräte haben nur eine begrenzte Anzahl an Farben (Garmin-Palette).

Ich habe jetzt auch seit einigen Tagen mal die Freizeitkarte auf meinem Nüvi255t.

Folgende Sachen stören mich an der Karte:

Die blassen Farben. Ist draußen schwer zu erkennen. Die AIO hatte schöne satte Farben (aber die routet momentan falsch http://forum.openstreetmap.org/viewtopic.php?id=16592).

Beim Fahren mit der Karte werden nur Namen bei Querstraßen nur bei Nebenstraßen angezeigt. Bei den wichtigen großen Straßen steht nichts. War bei der AIO aber auch so auf meinem Nüvi 255t.

Ich fahre in 2 Wochen ins Elbsandsteingebirge und hab mal probiert ob man mit der Freizeitkarte dort wandern könnte. Leider nicht so gut! Testgebiet waren die Affensteine. Z.B. hier: http://www.openstreetmap.org/?lat=50.91 … 7&layers=M
Die Namen der Wanderwege z.B. obere Affensteinpromenade werden gar nicht angezeigt. Wenn ich jetzt über die Zwillingsstiege, obere Affensteinpromenade zum Carolafelsen will. Oder alternativ über die Wilde Hölle. Probiert das mal über die Freizeitkarte zu finden. Die Wege und der Carolafelsen werden in keiner Zoomstufe angezeigt. Man muss direkt draufklicken auf den richtigen Weg oder Carolafelsen, um den Namen angezeigt zu bekommen.
Schade.

Was mir gut gefällt ist in Berlin die Anzeige der Stadtbezirke beim Fahren.

Moin Peter.

die Pastellfarben sind ein USP der Freizeitkarte! Keine andere Karte hat das so, dass man die Geocaches und eigenen POI sauber erkennen kann. Weshalb ja auch sogar ein Mirror im Geoclub liegt: http://osm.geoclub.de/

LG,

-moenk

Also ich habe auch Probleme mit dem Kontrast bei der Freizeitkarte auf meinem Vista. Draußen fast nur mit viel Hintergrundbeleuchtung möglich.

Gruß Jürgen

derjürgen wrote:

Also ich habe auch Probleme mit dem Kontrast bei der Freizeitkarte auf meinem Vista. Draußen fast nur mit viel Hintergrundbeleuchtung möglich.

Hallo,
die Freizeitkarte ist noch die beste, die man ohne Hintergrundbeleuchtung im Freien ablesen kann. Also bitte so lassen. Wenn ich draußen bin und im Wald stehe, weiß ich das. Da brauche ich nicht dunkelgrünen Hintergrund mit Tannenbaumsymbolen auf dem kleinen GPS-Display.
Franz

So unterschiedlich sind die Ansichten... Aber in Ordnung.

Deshalb wichtig das man das hier besprechen kann.

Gruß Jürgen

Nicht ohne Grund gibt es viele Karten 😉

Wenn eine Karte alle glücklich machen würde, wäre das überflüssig.

Ich verweise mal hierauf: http://www.freizeitkarte-osm.de/dies-und-das.html

Hilf mit!
...
Optisches Darstellung:
Das optische Erscheinungsbild der Karte wird durch ein sogenanntes Typfile definiert. Du kannst, mit etwas technischem Hintergrundwissen, das Erscheinungsbild der Karte grundlegend verändern. Sei es, weil dir "dein" Design besser gefällt, oder du für ein spezielles GPS-Gerät Anpassungen vorgenommen hast. Stelle deine Arbeiten doch allen Nutzern zur Verfügung.
...

Gruß Klaus

Peter Maiwald wrote:

... Ich habe jetzt auch seit einigen Tagen mal die Freizeitkarte auf meinem Nüvi255t. ...

Die "FZK und das Nüvi" war, ist und wird (wohl) keine Erfolgsstory.
Ich rate deshalb von der Nutzung der FZK auf dem Nüvi eher ab ...

Gruß Klaus

Peter Maiwald wrote:

Die AIO hatte schöne satte Farben (aber die routet momentan falsch http://forum.openstreetmap.org/viewtopic.php?id=16592).

Du kannst mal meine Karte ausprobieren. Die Farben sind größtenteils identisch zu der AIO, ansonsten hat sie aber nichts damit gemeinsam.

Thorsten

Hallo Thorsten.

Interessante Seite. Dank dir, werd ich mir mal ansehen.

Gruß Jürgen

Routingfehler
Mit dem Auto soll ich über 2 Poller und Fuß- und Radwege fahren.

Ich wurde von der Straße 52 gerade durch zur Bundesstr. 2 geroutet.
http://www.openstreetmap.org/?lat=52.59 … 5&layers=M
Von oben nach unten der Weg über die Wiese.

In meinem nüvi 255t war "Auto"-Routing eingestellt. Also nicht etwa Fahrrad oder Fußgänger.

Wie kann das sein, die Daten sind in osm korrekt eingetragen?

Hallo Peter,

könntest du einen Screenshot (vom GPSr) mit dem "fehlerhaften" Routing einstellen ?
Und welche Routingeinstellungen (toll, carpool, ...) hast du benutzt ?

Gruß Klaus

toc-rox wrote:

Hallo Peter,

könntest du einen Screenshot (vom GPSr) mit dem "fehlerhaften" Routing einstellen ?
Und welche Routingeinstellungen (toll, carpool, ...) hast du benutzt ?

Gruß Klaus

toll, carpool? So etwas finde ich hier nicht zum Einstellen.
Routing ist fürs Auto, kürzere Zeit eingestellt.

Einstellungen - > Route - > Ausschlüsse Maut und Fahrgemeinschaft.

chris66 wrote:

Einstellungen - > Route - > Ausschlüsse Maut und Fahrgemeinschaft.

Gefunden. Bei mir heißt das Einstellungen/Navigation/Vermeidungen
Aktiviert ist Verkehrsfunk, Fahrgemeinschaftsspuren.

Hallo Peter,

dann stelle die Vermeidungen einmal so ein wie hier beschrieben: http://www.freizeitkarte-osm.de/routing.html

Für "Auto" also "Mautstraßen + Fahrgemeinschaftsspuren" vermeiden.

Gruß Klaus

PS: Nur mit der Einstellung "Fahrgemeinschaftsspuren vermeiden" warst du als Radfahrer unterwegs.

toc-rox wrote:

Hallo Peter,

dann stelle die Vermeidungen einmal so ein wie hier beschrieben: http://www.freizeitkarte-osm.de/routing.html

Für "Auto" also "Mautstraßen + Fahrgemeinschaftsspuren" vermeiden.

Gruß Klaus

PS: Nur mit der Einstellung "Fahrgemeinschaftsspuren vermeiden" warst du als Radfahrer unterwegs.

Ja, jetzt routet er außen herum. Ist das denn ein Fehler in der Karte? Wieso bin ich als Radfahrer unterwegs, wenn ich Auto eingestellt habe und Mautstraßen nicht vermeide?
Wenn ich auf Radfahrer umstelle, dann bin ich Radfahrer, nicht wenn ich Auto eingestellt habe und Mautstraßen vermeide. Was hat denn eine Mautstraße mit Radfahrern zu tun?
Also die Mautstraßen Option nehme ich aber wieder heraus. Schließlich möchte ich ja vielleicht über eine Mautstraße fahren. Warnowtunnel in Rostock z.B. Spätestens wenn ich in Österreich unterwegs bin komm ich ohne Mautstraßen wohl nicht an.

Peter Maiwald wrote:

toc-rox wrote:

Hallo Peter,

dann stelle die Vermeidungen einmal so ein wie hier beschrieben: http://www.freizeitkarte-osm.de/routing.html

Für "Auto" also "Mautstraßen + Fahrgemeinschaftsspuren" vermeiden.

Gruß Klaus

PS: Nur mit der Einstellung "Fahrgemeinschaftsspuren vermeiden" warst du als Radfahrer unterwegs.

Ja, jetzt routet er außen herum. Ist das denn ein Fehler in der Karte? Wieso bin ich als Radfahrer unterwegs, wenn ich Auto eingestellt habe und Mautstraßen nicht vermeide?
Wenn ich auf Radfahrer umstelle, dann bin ich Radfahrer, nicht wenn ich Auto eingestellt habe und Mautstraßen vermeide. Was hat denn eine Mautstraße mit Radfahrern zu tun?
Also die Mautstraßen Option nehme ich aber wieder heraus. Schließlich möchte ich ja vielleicht über eine Mautstraße fahren. Warnowtunnel in Rostock z.B. Spätestens wenn ich in Österreich unterwegs bin komm ich ohne Mautstraßen wohl nicht an.

wie einfach es doch wäre, wenn ihr euch die seite zur karte mal durchlest, die ihr verwendet... spätestens wenn probleme auftreten könnte das helfen.
http://freizeitkarte-osm.de/routing.html

und auch wenn du einstellst: Mautstraßen vermeiden (was du tun musst!!! wenn du die fzk verwendest und ein gescheites autorouting möchtest) wird er dich über Mautstraßen schicken. dies liegt daran, dass nur eingeschränkte Möglichkeiten auf den Garmin Geräten zur Verfügung stehen.

Das bedeutet also, dass wenn ich das Navi aus dem Auto nehme und ans Fahrrad klemme muss ich nur folgendes tun:
1. Extras/Einstellungen/System von Auto auf Fahrrad umstellen
2. Zurück/Navigation auf kürzere Strecke stellen
3. Vermeidungen Mautstraßen Haken rausnehmen
4. Vermeidungen Fernstraßen/Autobahnen Haken rein
5. Vermeidungen unbefestigte Straße Haken raus

Ist ja super einfach kann man sich ja gut merken... Ist ein Witz oder?
Wofür ist denn die Unterscheidung Auto, Fahrrad, Fußgänger da, wenn ich doch alle Einzelheiten per Hand umstellen muss? Liegt das am noch unzureichend entschlüsselten Garminformat? Oder wo ist der Fehler?

Außerdem nutze ich das nüvi auch zum Wandern und mit dem Motorrad.

Und warum werde ich trotzdem über Mautstraßen geschickt, obwohl Vermeidung angeklickt ist? Weil das Garminformat noch nicht so weit entschlüsselt ist? Oder Warum.
Es scheint aber zu funktionieren. Ich hab mich gerade mal per GPS-Simulation durch den mautpflichtigen Warnowtunnel in Rostock routen lassen. Funktioniert trotz Vermeidung der Mautstraßen. Sehr merkwürdig.

Peter Maiwald wrote:

Das bedeutet also, dass wenn ich das Navi aus dem Auto nehme und ans Fahrrad klemme muss ich nur folgendes tun:
1. Extras/Einstellungen/System von Auto auf Fahrrad umstellen
2. Zurück/Navigation auf kürzere Strecke stellen
3. Vermeidungen Mautstraßen Haken rausnehmen
4. Vermeidungen Fernstraßen/Autobahnen Haken rein
5. Vermeidungen unbefestigte Straße Haken raus

Kennt das Nüvi keine Profile ?

Gruß Klaus

Hi Peter,
wie Klaus schon selber schrieb ist die FZK nicht für das Nüvi optimiert. Garmin hat das Routing bei
den neuen Modellen (eTrex x0) und bei Basecamp ab V3.2 geändert, deshalb die Klimmzüge mit den
Avoid-Flags.
Chris

Peter Maiwald wrote:

Das bedeutet also, dass wenn ich das Navi aus dem Auto nehme und ans Fahrrad klemme muss ich nur folgendes tun:
1. Extras/Einstellungen/System von Auto auf Fahrrad umstellen
2. Zurück/Navigation auf kürzere Strecke stellen
3. Vermeidungen Mautstraßen Haken rausnehmen
4. Vermeidungen Fernstraßen/Autobahnen Haken rein
5. Vermeidungen unbefestigte Straße Haken raus

Ist ja super einfach kann man sich ja gut merken... Ist ein Witz oder?
Wofür ist denn die Unterscheidung Auto, Fahrrad, Fußgänger da, wenn ich doch alle Einzelheiten per Hand umstellen muss? Liegt das am noch unzureichend entschlüsselten Garminformat? Oder wo ist der Fehler?

Außerdem nutze ich das nüvi auch zum Wandern und mit dem Motorrad.

Und warum werde ich trotzdem über Mautstraßen geschickt, obwohl Vermeidung angeklickt ist? Weil das Garminformat noch nicht so weit entschlüsselt ist? Oder Warum.
Es scheint aber zu funktionieren. Ich hab mich gerade mal per GPS-Simulation durch den mautpflichtigen Warnowtunnel in Rostock routen lassen. Funktioniert trotz Vermeidung der Mautstraßen. Sehr merkwürdig.

es steht jedem frei sich eine garminkarte zu kaufen. ob man damit aber dann zufriedener ist, wer weiß.

wenn das nüvi keine profile kennen sollte, ist die verwendung der fzk allerdings in der tat etwas aufwändig.

Jayjay01 wrote:

wenn das nüvi keine profile kennen sollte, ist die verwendung der fzk allerdings in der tat etwas aufwändig.

Ich kann unter System einen Verwend.-Modus einstellen, in dem ich Auto, Fahrrad, Fußgänger auswählen kann.
Weiterhin gibt es unter Navigation die Vermeidungen (Mautstraßen, Fahrgemeinschaftsstraßen, Verkehrsfunk, Fähren, ungeteerte Straßen, Kehrtwenden, Fernstraßen/Autobahnen und die Routenpräferenz (kürzere Zeit, kürzere Strecke, weniger Treibstoff, Luftlinie)

kukuk wrote:

Peter Maiwald wrote:

Die AIO hatte schöne satte Farben (aber die routet momentan falsch http://forum.openstreetmap.org/viewtopic.php?id=16592).

Du kannst mal meine Karte ausprobieren. Die Farben sind größtenteils identisch zu der AIO, ansonsten hat sie aber nichts damit gemeinsam.

Thorsten

Habe gerade deine Karte Dach mit gmaptool zusammengefügt und auf mein nüvi kopiert.
Leider die selben Routingfehler wie bei der AIO hier: http://forum.openstreetmap.org/viewtopi … =16592&p=1
Ursache und Behebung werden auf Seite 2 beschrieben.

Zum Ausprobieren route mit gps-Simulation Berlin:
von 52.51617 13.41811 Alexanderstraße
nach 52.51318 13.41753 Brückenstraße
Nur ca. 300m geradeaus über die Jannowitzbrücke wäre korrekt und wird von den Onlineroutern auch so angezeigt.
Die die kukuk-Karte will nicht über die Jannowitzbrücke!

Entweder es wir drumherum gerouted oder die Berechnung bleibt bei 80% stehen.

Peter Maiwald wrote:

Habe gerade deine Karte Dach mit gmaptool zusammengefügt und auf mein nüvi kopiert.
Leider die selben Routingfehler wie bei der AIO hier: http://forum.openstreetmap.org/viewtopi … =16592&p=1
Ursache und Behebung werden auf Seite 2 beschrieben.

OK, damit wäre dann beweisen, das sie dortige Analyse mit Ursache und Behebung falsch ist. Die entsprechende Option verwende ich nicht.

Auf meinem GPSmap 62s mit Firmware 3.90 sowie mit MapSource kann ich das Problem auch nicht nachvollziehen. Was verwendest Du?

Thorsten

kukuk wrote:

Peter Maiwald wrote:

Habe gerade deine Karte Dach mit gmaptool zusammengefügt und auf mein nüvi kopiert.
Leider die selben Routingfehler wie bei der AIO hier: http://forum.openstreetmap.org/viewtopi … =16592&p=1
Ursache und Behebung werden auf Seite 2 beschrieben.

OK, damit wäre dann beweisen, das sie dortige Analyse mit Ursache und Behebung falsch ist. Die entsprechende Option verwende ich nicht.

Auf meinem GPSmap 62s mit Firmware 3.90 sowie mit MapSource kann ich das Problem auch nicht nachvollziehen. Was verwendest Du?

Thorsten

Ich verwende Nüvi 255t Software Version 6.60.
Dann liegt der Fehler wohl noch woanders. Auf der aktuellen AIO ist der Fehler auch immer noch vorhanden. Hab ich gestern ausprobiert.
Auf der Jannowitzbrücke in Berlin verläuft aber mitten drauf eine Kachelgrenze. Zumindest bei der AIO.

Peter Maiwald wrote:

Dann liegt der Fehler wohl noch woanders. Auf der aktuellen AIO ist der Fehler auch immer noch vorhanden. Hab ich gestern ausprobiert.
Auf der Jannowitzbrücke in Berlin verläuft aber mitten drauf eine Kachelgrenze. Zumindest bei der AIO.

Jetzt wäre das Log File von mkgmap nützlich, ob vielleicht in einer der beiden Kacheln Fehler wie "Area too small to split at ..." oder "way too long to split" auftauchen. Die führen auch zu Routingfehler.

Thorsten

kukuk wrote:

Peter Maiwald wrote:

Habe gerade deine Karte Dach mit gmaptool zusammengefügt und auf mein nüvi kopiert.
Leider die selben Routingfehler wie bei der AIO hier: http://forum.openstreetmap.org/viewtopi … =16592&p=1
Ursache und Behebung werden auf Seite 2 beschrieben.

OK, damit wäre dann beweisen, das sie dortige Analyse mit Ursache und Behebung falsch ist. Die entsprechende Option verwende ich nicht.

Nicht unbedingt, im gleichen Thread auf der mkgmap-dev Liste, auf den sich der Post oben bezieht, wird als weiterer Fix vorgeschlagen, den Legacy-Mode-Parameter beim Splitter zu setzen, siehe hier. Verwendest Du den zufällig in deiner Toolchain?

Gruß,
mmd

mmd wrote:

kukuk wrote:

Peter Maiwald wrote:

Habe gerade deine Karte Dach mit gmaptool zusammengefügt und auf mein nüvi kopiert.
Leider die selben Routingfehler wie bei der AIO hier: http://forum.openstreetmap.org/viewtopi … =16592&p=1
Ursache und Behebung werden auf Seite 2 beschrieben.

OK, damit wäre dann beweisen, das sie dortige Analyse mit Ursache und Behebung falsch ist. Die entsprechende Option verwende ich nicht.

Nicht unbedingt, im gleichen Thread auf der mkgmap-dev Liste, auf den sich der Post oben bezieht, wird als weiterer Fix vorgeschlagen, den Legacy-Mode-Parameter beim Splitter zu setzen, siehe hier. Verwendest Du den zufällig in deiner Toolchain?

Damit das eine Wirkung hat, müßte bei meiner Karte eine Kachelgrenze dort oder in der Nähe sein. Ist aber nicht. Der Weg wird nicht gesplittet.
Der --make-all-cycleway Parameter erzeugt aber auch Probleme, wenn keine Kachelgrenze in der Nähe ist. Deswegen verwende ich die Option schon lange nicht mehr.

Zumal man den gleichen Effekt über das Style-File erzeugen kann 😉

kukuk wrote:

mmd wrote:

kukuk wrote:

OK, damit wäre dann beweisen, das sie dortige Analyse mit Ursache und Behebung falsch ist. Die entsprechende Option verwende ich nicht.

Nicht unbedingt, im gleichen Thread auf der mkgmap-dev Liste, auf den sich der Post oben bezieht, wird als weiterer Fix vorgeschlagen, den Legacy-Mode-Parameter beim Splitter zu setzen, siehe hier. Verwendest Du den zufällig in deiner Toolchain?

Damit das eine Wirkung hat, müßte bei meiner Karte eine Kachelgrenze dort oder in der Nähe sein. Ist aber nicht. Der Weg wird nicht gesplittet.
Der --make-all-cycleway Parameter erzeugt aber auch Probleme, wenn keine Kachelgrenze in der Nähe ist. Deswegen verwende ich die Option schon lange nicht mehr.

Ok, dann teste ich mal, ob mein Oregon mit deiner Karte auch ohne Probleme routet. Die Routingprobleme mit der AIO konnte ich ja mit dem Oregon schon mal reproduzieren.

Ist die Karte hier die richtige? D/A/CH/FL Basiskarte TK-DACH-Basemap.7z 2012-06-15, 9:44

Ich würde die dann für Mapsource bzw. BaseCamp installieren und nur den Bereich um Berlin auf das Gerät übertragen.

Gruß,
mmd

mmd wrote:

Ok, dann teste ich mal, ob mein Oregon mit deiner Karte auch ohne Probleme routet. Die Routingprobleme mit der AIO konnte ich ja mit dem Oregon schon mal reproduzieren.

Ist die Karte hier die richtige? D/A/CH/FL Basiskarte TK-DACH-Basemap.7z 2012-06-15, 9:44

Ja. Die funktioniert bei mir.

kukuk wrote:

mmd wrote:

Ok, dann teste ich mal, ob mein Oregon mit deiner Karte auch ohne Probleme routet. Die Routingprobleme mit der AIO konnte ich ja mit dem Oregon schon mal reproduzieren.

Ist die Karte hier die richtige? D/A/CH/FL Basiskarte TK-DACH-Basemap.7z 2012-06-15, 9:44

Ja. Die funktioniert bei mir.

Kann ich bestätigen, keine Kachelgrenze auf der Brücke, keine Probleme beim Routen von 52.51617 13.41811 Alexanderstraße nach 52.51318 13.41753 Brückenstraße.

Lassen sich beim Nüvi (ähnlich wie beim Oregon) auch mehrere Karten als aktiv kennzeichnen? Wenn ja, könnte eine ebenfalls aktive AIO Routingfehler produzieren?
Dazu müsste Peter mal genau sein Setup beschreiben.

mmd wrote:

kukuk wrote:

mmd wrote:

Ok, dann teste ich mal, ob mein Oregon mit deiner Karte auch ohne Probleme routet. Die Routingprobleme mit der AIO konnte ich ja mit dem Oregon schon mal reproduzieren.

Ist die Karte hier die richtige? D/A/CH/FL Basiskarte TK-DACH-Basemap.7z 2012-06-15, 9:44

Ja. Die funktioniert bei mir.

Kann ich bestätigen, keine Kachelgrenze auf der Brücke, keine Probleme beim Routen von 52.51617 13.41811 Alexanderstraße nach 52.51318 13.41753 Brückenstraße.

Lassen sich beim Nüvi (ähnlich wie beim Oregon) auch mehrere Karten als aktiv kennzeichnen? Wenn ja, könnte eine ebenfalls aktive AIO Routingfehler produzieren?
Dazu müsste Peter mal genau sein Setup beschreiben.

Also mein nüvi kann immer nur mit einer gmapsupp.img auf dem Gerät sowie auf der micro-SD umgehen. Auf dem Gerät ist die originale gmapsupp.img von Garmin. Diese ist im Gerät aber nicht aktiv geschaltet.
Auf der Micro-SD ist die gmapsupp.img von kukuk. Diese ist aktiv geschaltet im Gerät.

Ich habe aber kein mkgmap oder Basecamp oder MapSource verwendet! Ich habe die verschiedenen Kartenlayer mit gmaptool zusammengefügt mit folgendem Befehl:

gmt␣-jo␣gmapsupp.img␣TK-DACH-Basemap.img␣TK-DACH-SRTM.img␣TK-DACH-Wanderwege.img␣TK-DACH-Bicycling.img␣TK-DACH-Oepnv.img␣TK-DACH-Marine.img␣TK-DACH-KeepRight.img␣TK-DACH-OSB.img

Dabei kam es zu keiner Fehlermeldung. Die .exe Dateien die dabei waren hab ich nicht angefasst.
Danach die fertige gmapsupp.img auf das Nüvi auf die Micro-SD kopiert, fertig.

kukuk wrote:

Jetzt wäre das Log File von mkgmap nützlich, ob vielleicht in einer der beiden Kacheln Fehler wie "Area too small to split at ..." oder "way too long to split" auftauchen. Die führen auch zu Routingfehler.

Na dann guck doch mal rein. Ich dachte du erzeugst die gmapsupp.img mit mkgmap?

Ich habe hier sowas ähnliches. Wenn ich diesen Weg http://www.openrouteservice.org/index.p … ways=false mit BaseCamp und der FZK plane, so wird eine Route "rechts rum" (Ostseite) des Sonntagshorn berechnet:

Irgendwas ist da in der Mitte des Weges nicht in Ordnung.

Der Weg südlich der Schutzhütte ist mit sac_scale=mountain_hiking getaggt. Da würde ich bei einer allgemeinen Freizeitkarte auch keinen Fußgänger drüber routen. 😉

Bei dem Weg nördlich der Schutzhütte finde ich die access-Taggs merkwürdig. access=unknown beißt sich irgendwie mit motorcar=no und motorvehicle=no. 😉

shammat wrote:

Irgendwas ist da in der Mitte des Weges nicht in Ordnung.

Der "lila" Feldweg wird als "Privatweg" angesehen - deshalb wird da nicht drüber geroutet.

Aber wie Henning schon sagte, der Weg ist "merkwürdig getaggt":
Weg 74041984
access: unknown
highway: track
motorcar: no
motorcycle: no
surface: sand
tracktype: grade2

Gruß Klaus

Peter Maiwald wrote:

Ich habe aber kein mkgmap oder Basecamp oder MapSource verwendet! Ich habe die verschiedenen Kartenlayer mit gmaptool zusammengefügt mit folgendem Befehl:

gmt␣-jo␣gmapsupp.img␣TK-DACH-Basemap.img␣TK-DACH-SRTM.img␣TK-DACH-Wanderwege.img␣TK-DACH-Bicycling.img␣TK-DACH-Oepnv.img␣TK-DACH-Marine.img␣TK-DACH-KeepRight.img␣TK-DACH-OSB.img

Dabei kam es zu keiner Fehlermeldung. Die .exe Dateien die dabei waren hab ich nicht angefasst.
Danach die fertige gmapsupp.img auf das Nüvi auf die Micro-SD kopiert, fertig.

Da damit mehrere Routingfähige Karten zusammengefügt werden, kann es sein dass das Nüvi damit nicht klar kommt? Probier mal nur die Basemap bzw. eventuell noch die SRTM, ob das ein Unterschied macht.

kukuk wrote:

Jetzt wäre das Log File von mkgmap nützlich, ob vielleicht in einer der beiden Kacheln Fehler wie "Area too small to split at ..." oder "way too long to split" auftauchen. Die führen auch zu Routingfehler.

Na dann guck doch mal rein. Ich dachte du erzeugst die gmapsupp.img mit mkgmap?

Der Kommentar bezog sich auf die AiO, die dort ja auch einen Kachelgrenze hat. Ich habe für Berlin keine Fehlermeldungen im Log, nur für Rügen.

Thorsten

aighes wrote:

Der Weg südlich der Schutzhütte ist mit sac_scale=mountain_hiking getaggt. Da würde ich bei einer allgemeinen Freizeitkarte auch keinen Fußgänger drüber routen. 😉

Bis zu der Hütte ist es ein recht schmaler aber gut ausgebauter und gesicherter Weg (da gehen auch ältere Herrschaften spazieren). Nach der Hütte ist ein ganz normaler Forstweg, breit genug für ein Auto. Ich sehe keinen Grund Fußgänger davon abzuhalten dort zu gehen.

Ausserdem habe ich explizit, folgende Einstellungen in meiner lines-master:

highway␣=␣path␣&␣(sac_scale␣=␣hiking␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣sac_scale␣=␣mountain_hiking)␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg12}
highway␣=␣path␣&␣(sac_scale␣=␣demanding_mountain_hiking␣|␣sac_scale␣=␣alpine_hiking)␣␣␣␣␣␣␣␣␣␣␣{set␣highway␣=␣bergweg34;␣set␣access␣=␣no;␣set␣motorcar␣=␣no;␣set␣bicycle␣=␣no;␣set␣foot␣=␣no}
highway␣=␣path␣&␣(sac_scale␣=␣demanding_alpine_hiking␣␣␣|␣sac_scale␣=␣difficult_alpine_hiking)␣{set␣highway␣=␣bergweg56;␣set␣access␣=␣no;␣set␣motorcar␣=␣no;␣set␣bicycle␣=␣no;␣set␣foot␣=␣no}

Da sollte doch eigentlich über solche Wege geroutet werden, oder?

toc-rox wrote:

Der "lila" Feldweg wird als "Privatweg" angesehen - deshalb wird da nicht drüber geroutet.

Ist definitiv kein Privatweg.

Bei dem Weg nördlich der Schutzhütte finde ich die access-Taggs merkwürdig. access=unknown beißt sich irgendwie mit motorcar=no und motorvehicle=no. 😉

Wie kann man das ändern?

shammat wrote:

Wie kann man das ändern?

OK, ich habe mal das Tagging für diesen Abschnitt geändert.
http://www.openstreetmap.org/browse/changeset/11940565

Ich hoffe das ist richtig so.

(warum wird mir eigentlich in der Übersicht als "(still editing)" angezeigt obwohl ich das schon gespeichert habe?)

Wie kommst du denn auf bicycle=no? Ist dort wirklich Radfahren verboten?

kukuk wrote:

Peter Maiwald wrote:

Ich habe aber kein mkgmap oder Basecamp oder MapSource verwendet! Ich habe die verschiedenen Kartenlayer mit gmaptool zusammengefügt mit folgendem Befehl:

gmt␣-jo␣gmapsupp.img␣TK-DACH-Basemap.img␣TK-DACH-SRTM.img␣TK-DACH-Wanderwege.img␣TK-DACH-Bicycling.img␣TK-DACH-Oepnv.img␣TK-DACH-Marine.img␣TK-DACH-KeepRight.img␣TK-DACH-OSB.img

Dabei kam es zu keiner Fehlermeldung. Die .exe Dateien die dabei waren hab ich nicht angefasst.
Danach die fertige gmapsupp.img auf das Nüvi auf die Micro-SD kopiert, fertig.

Da damit mehrere Routingfähige Karten zusammengefügt werden, kann es sein dass das Nüvi damit nicht klar kommt? Probier mal nur die Basemap bzw. eventuell noch die SRTM, ob das ein Unterschied macht.

Thorsten

Ich habe gerade nur die TK-DACH-Basemap.img auf das Nüvi kopiert und umbenannt in gmapsupp.img und der Fehler an der Jannowitzbrücke ist weg. Der Fehler scheint also beim zusammenfügen der Layer oder durch einen anderen defekten Layer zu entstehen.
Grundsätzlich kann das Nüvi aber mit mehreren schaltbaren Layern umgehen. Als die AIO noch andere Layer hatte (OSB/Maxspeed/Keepright/Höhenlinie - schön war die Zeit) funktionierte das Routing gut.

Test 2: gmt -jo gmapsupp.img TK-DACH-Basemap.img TK-DACH-SRTM.img
Routing funktioniert, auch über die Jannowitzbrücke.

aighes wrote:

Wie kommst du denn auf bicycle=no? Ist dort wirklich Radfahren verboten?

Im südlichen Teil schon, ja.

Die Freizeitkarten sind in der Ausgabe 12.6 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 19.6.2012.

Link: http://www.freizeitkarte-osm.de

Neu in Ausgabe 12.6:
- Anleger/Pier auch als Fläche
- Darstellung von Deichen
- Darstellung von Böschungen
- Darstellung von trigonometrischen Markierungen (mit Höhenangabe)
- Freizeitkarte Polen
- Freizeitkarte Luxemburg
- Freizeitkarte Schweden

Kartendarstellung in BaseCamp: Wangerooge

Viel Freude an den Karten ... und viele interessante Touren damit.

Gruß Klaus

PS: Hast du Interesse "Karten-Pate" zu werden und bei unserem Projekt mitzuhelfen ?

Ich lade gerade runter und probiere einmal.
Schön wäre, wenn Norwegen noch mit aufgenommen werden könnte.

Beiri22 wrote:

Schön wäre, wenn Norwegen noch mit aufgenommen werden könnte.

Schön wäre, wenn sich ein Pate für Norwegen fände ...

Ansonsten empfehle ich dir, mal in "weitere Länder" nach unten zu scrollen und dem Link auf den Download-Bereich zu folgen.

Gruss Christian

Weiß ja nicht, eventuell habe ich es überlesen.

Ist geplant in der Freizeitkarte Hausnummern anzuzeigen? Häuser sind ja drin falls gemappt. Aber da steht dann nur Gebäude statt der Hausnummer wenn getaggt.

Gruß Jürgen

Nach den automatischen Datenlöschungen (BOT) im Zuge der Lizenzumstellung:

Für den Zeitraum des erforderlichen Remappens besteht die Möglichkeit, die "Freizeitkarte_Deutschland" deutlich häufiger (z.B. 2x pro Woche oder auch täglich) zu aktualisieren. Dies wäre ein Service speziell für die Mapper, die (auch) ihr Garmin-GPS-Gerät für das Remapping zuhilfe nehmen.

Fragen:
- Würde der Service für das Remappen helfen ?
- Welcher Aktualisierungszyklus wäre sinnvoll ?

Gruß Klaus

PS: Die Karte würde dann "Remappingkarte_Deutschland" heißen und eine eigene ID bekommen. Dies hätte den Vorteil, daß sie (in den meisten GPS-Geräten) alternativ zur letzten "Freizeitkarte_Deutschland" (vor der Datenlöschung) genutzt werden könnte.

Die Freizeitkarten für Deutschland, Österreich, Schweiz, Alpen und Frankreich sind in der Ausgabe 12.7 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 15.7.2012.

Vielen Dank an alle Mapper die Daten hierzu beigetragen haben.

Link: http://www.freizeitkarte-osm.de/de/index.html

Ergänzungen/Veränderungen in der Ausgabe 12.7:
- Darstellung von Deichen verbessert
- Darstellung von Böschungen entfernt
- allgemeine Verbesserung der Adresssuche

Kartendarstellung in BaseCamp: Der südlichste Landpunkt Deutschlands - markiert durch das Staatsgrenzzeichen Nr. 147 auf 1883m Höhe.

Viel Freude an den Karten ... und viele interessante Touren damit.

Gruß Christian und Klaus

PS: Hast du Interesse "Karten-Pate" zu werden und bei unserem Projekt mitzuhelfen ?

Vielen Dank für die ständige Pflege dieser schönen Karte.

In der 12.07 sind zwei TYP Files vorhanden: "freizeit.typ" und "1-freizeit.typ"
Ach bei den Styles sind einige mit dem Präfix "1-" zusätzlich vorhanden "1-lines-master","1-options-master" usw.

Was hat das mit den "einsern" auf sich? (Ich passe mir die immer nach meinen eigenen Vorstellungen an, deswegen wüsste ich gerne ob ich beide Versionen ändern muss oder nur eine letztendlich verwendet wird)

shammat wrote:

Was hat das mit den "einsern" auf sich?

Also die Dateien die mit "1-", "2-" usw. beginnen können ignoriert werden.
Das sind Sicherheitskopien die vor der Veröffentlichung nicht bereinigt wurden.

Gruß Klaus

toc-rox wrote:

Also die Dateien die mit "1-", "2-" usw. beginnen können ignoriert werden.
Das sind Sicherheitskopien die vor der Veröffentlichung nicht bereinigt wurden.

Danke. Schon gelöscht 😉

Die Freizeitkarten sind in der Ausgabe 12.9 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 24.9.2012.

Vielen Dank an alle Mapper die Daten hierzu beigetragen haben.

Link: http://freizeitkarte-osm.de/de/index.html

Neu in der Ausgabe 12.9:
- Darstellung von Nationalparks
- Darstellung von Auffahrten auf Kreisstraßen
- Berücksichtigung von Restaurants in Hotels
- Darstellung von (Gebirgs-)Pässen
- Darstellung von (Seilbahn-)Pylonen
- Darstellung von (Barriere-)Blöcken
- Freizeitkarte Italien
- Freizeitkarte Tschechien
- Freizeitkarte Spanien
- Freizeitkarte Kanarische Inseln

Kartendarstellung in BaseCamp: Der "Mittelpunkt" Deutschlands - die "Wartburg" im Thüringer Wald.

Viel Freude an den Karten ... und viele interessante Touren damit.

Gruß Christian und Klaus

PS: Hast du Interesse "Karten-Pate" zu werden und bei unserem Projekt mitzuhelfen ?

Edit: Link korrigiert.

derjürgen wrote:

... was ich z.B. vermisse: Das sind Sitzbänke und Hochsitze. Wäre das möglich diese anzeigen zu lassen? ...

Hier hatte ich (am Beispiel von Sitzbänken) einige Info zusammengestellt wie man eigene POIs in einer Garmin-Karte "nachrüstet":

POIs aus OpenStreetMap (OSM) in Garminkarten nachrüsten
http://forum.geoclub.de/viewtopic.php?f=7&t=66508

Viel Erfolg ...

Gruß Klaus

So etwas ähnliches habe ich für Rettungspunkte immer auf meinem Garmin dabei. Praktisch für: wo ist der nächste Rettungspunkt und wie komme ich dorthin. Anleitung dazu gibt es irgendwo hier im Forum, habe gerade den link nicht parat.

hi !

dieses Posting ist schon sehr lang und deshalb kann es sich mit vorherigen Dingen überschneiden. Sorry in diesem Falle.

Mein Anliegen: unterstützt die Freizeitkarte schon die Darstellung von Gebirgen, Regionen und Buchten (siehe hierzu auch http://forum.openstreetmap.org/viewtopic.php?id=16094) ??

Gruß Jan :-)

Die Freizeitkarten sind in der Ausgabe 12.10 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 22.10.2012.

Vielen Dank an alle Mapper die Daten hierzu beigetragen haben.

Link: http://freizeitkarte-osm.de/de/index.html

Ergänzungen / Veränderungen in der Ausgabe 12.10:
- allgemeine Verbesserung der Darstellung
- allgemeine Verbesserung des Routings
- Symbolfarbe für Gräber, Denkmale und Kapellen geändert (schwarz)
- kein Symbol mehr für Miniparkflächen (<10 Stellplätze)
- Alpenkarte: Routing auch über Bergwanderwege T3-T6
- Darstellung von bedeutenden Grabstätten

Kartendarstellung im Garmin Montana: Die drei beliebtesten Sehenswürdigkeiten Deutschlands (aus der Sicht ausländischer Touristen):
1. Schloss Heidelberg, 2. Schloss Neuschwanstein, 3. Kölner Dom

Viel Freude an den Karten ... und viele interessante Touren damit.

Gruß Christian und Klaus

toc-rox wrote:

- Alpenkarte: Routing auch über Bergwanderwege T3-T6

hmmm... da hätte ich Angst, dass sich die Wanderer beschweren. Ein korrekt eingetragener T5 oder T6 hat mit "Weg" ungefähr so viel Gemeinsamkeit wie die Route der Rallye Dakar mit einer Straße.

Grüße, Max

maxbe wrote:

toc-rox wrote:

- Alpenkarte: Routing auch über Bergwanderwege T3-T6

hmmm... da hätte ich Angst, dass sich die Wanderer beschweren. Ein korrekt eingetragener T5 oder T6 hat mit "Weg" ungefähr so viel Gemeinsamkeit wie die Route der Rallye Dakar mit einer Straße.

Grüße, Max

Man kann es nicht jedem Recht machen, wurde implementiert weil es Beschwerden gab, dass nicht drüber geroutet wurde 🙂
und es besteht ja immer noch die Möglichkeit, selbst die Karten zu erstellen und sie wieder unroutbar zu machen

Jayjay01 wrote:

Man kann es nicht jedem Recht machen, wurde implementiert weil es Beschwerden gab, dass nicht drüber geroutet wurde 🙂
und es besteht ja immer noch die Möglichkeit, selbst die Karten zu erstellen und sie wieder unroutbar zu machen

Ich beschwere mich nicht. Im Gegenteil, ich bin jedem dankbar, der sich um Karten abseits der Straßen kümmert.

Nur interessehalber: Hat der Beschwerer einen konkreten Weg als Beispiel genannt, über den er gerne Wanderer geführt haben möchte?

maxbe wrote:

toc-rox wrote:

- Alpenkarte: Routing auch über Bergwanderwege T3-T6

hmmm... da hätte ich Angst, dass sich die Wanderer beschweren. Ein korrekt eingetragener T5 oder T6 hat mit "Weg" ungefähr so viel Gemeinsamkeit wie die Route der Rallye Dakar mit einer Straße.

Grüße, Max

Ich kann das nur begrüssen. Ich habe bis jetzt immer die Entwicklungs-Version genommen, damit ich das Routing zu Fuß über alle Wege aktivieren kann. Aus meiner Sicht sind T5 oder T6 "normale" allerdings schmale und evtl. ausgesetzte (Berg)Wanderwege.

Wer in die Berge geht sollte auch darüber nachdenken, wo er da geht. Eine Papierkarte verhindert ja auch nicht, dass man auf den kleinen Wegen entlanggeht.

maxbe wrote:

Nur interessehalber: Hat der Beschwerer einen konkreten Weg als Beispiel genannt, über den er gerne Wanderer geführt haben möchte?

Ich glaube ich habe das hier als erster Mal angesprochen: http://forum.openstreetmap.org/viewtopi … 12#p231412

Nach der Erklärung wie ich das ändern kann, habe ich halt die Einstellungen für das Routing geändert. War ja eigentlich recht einfach.

Also wenn ich mir das wiki zu T5 und T6 anschaue, würde ich nicht erwarten, dass eine allgemeine Freizeitkarte nicht über solche Wege routet. Das ist schließlich eine Karte, die von normalen Fußgängern verwendet wird und nicht ausschließlich von Wanderern.

@shammat:
Ziel eines Routings ist es der Zielgruppe einen Weg anzuzeigen, den sie nutzen können. Bei einer Karte für Bergwanderer würde ich T5 und T6 routingfähig machen. Natürlich muss man als Nutzer vor Ort entscheiden, ob man den Weg gehen kann und darf nicht blind auf das Navi vertrauen. Nur wenn ich dann eine Route geplant hab und dann regelmäßig doch einen anderen Weg gehen muss, dann frag ich mich irgendwann, was ich mit der Karte soll, wenn ich ohnehin selber Routen muss.

Aber das ist nur meine Meinung.

Ich glaube, die entscheidung, für OSM die SAC-Skala zu nehmen war einfach falsch. Die Begriffe "wandern", "Weg", "meist weglos" und "Kletterstellen im II. Schwierigkeitsgrad" sind einfach zu weit interpretierbar.
Was mich beruhigt ist, dass das auch beim taggen oft weit nach oben interpretiert wird, das hebt sich dann auf 😉

Grüße, Max

Bislang war es eigentlich unmöglich irgendwie über eine T3-T6-Weg zu routen. Das hat zur Folge, daß für die Strecke auch kein Höhenprofil möglich ist. Das ist der Punkt den die meisten Nutzer bemängelt haben ...

Ein Wanderführer hat es m.E. mal auf den Punkt gebracht:
"Auch erfahrene Bergwanderer würden gerne ihre Route zu Hause planen und dabei wird das Routing wiederum gebraucht. Also sollte man es auch zulassen, denn Turnschuh-Touristen gehen einen Pfad unabhängig davon ob der geroutet wurde oder nicht. Denn die Gefahr geht vor Allem von der Fehleinschätzung der eigenen Möglichkeiten aus."

BTW - Um das Routing zu aktivieren ist beim Builden der Karte explizit der Schalter "DT36ROUTING" zu setzen.
Also z.B. so: perl mt.pl -cores=3 -ram=6000 build ALP DT36ROUTING

Gruß Klaus

PS: Über "Via Ferrata" wird übrigens damit auch geroutet ...

Moin Henning,

aighes wrote:

Also wenn ich mir das wiki zu T5 und T6 anschaue, würde ich nicht erwarten, dass eine allgemeine Freizeitkarte nicht über solche Wege routet. Das ist schließlich eine Karte, die von normalen Fußgängern verwendet wird und nicht ausschließlich von Wanderern.

ob sich der sprichwoertliche "Turnschuhtourist" angesichts des Smartphone-Booms noch ein separates Garmin zulegt (und dann vom Routing auf zu anspruchsvolle Strecken geschickt wird)?

"Hier" ist es flach, deshalb traue ich mir da nicht wirklich ein Urteil zu. Vielleicht aeussert sich zu dem Thema ja noch der Eine oder die Andere mit konkreten Erfahrungen?!

Gruss Christian

aighes wrote:

@shammat:
Ziel eines Routings ist es der Zielgruppe einen Weg anzuzeigen, den sie nutzen können. Bei einer Karte für Bergwanderer würde ich T5 und T6 routingfähig machen

Die Frage ist halt was bedeutet "Freizeitkarte"? Für mich sind auch solche Wege noch "Freizeitwandern" - die "richtigen" Bertouren gehen dort los wo es keine markierten Wege mehr gibt.

toc-rox wrote:

Über "Via Ferrata" wird übrigens damit auch geroutet ...

Das ist zum Planen einer Tour auch sehr hilfreich - allerdings sind leider nicht alle Klettersteige als "Via Ferrata" ge-tagged. Ich habe das bei einigen nachgeholt und ein paar der Tags wurden dann leider wieder entfernt mit der Begründung das "aber highway / via_ferrata wird weder in Mapnik noch Hikebikemap dargestellt". Nachdem ich kein erfahrener Mapper bin habe ich das so hingenommen, auch wenn das für mich ein Fehler in der Kartensoftware ist (dabei ging es um einen Klettersteig der definitiv nicht ohne Klettersteigausrüstung begangen werden sollte).

chkr wrote:

ob sich der sprichwoertliche "Turnschuhtourist" angesichts des Smartphone-Booms noch ein separates Garmin zulegt

Meiner Erfahrung nach, haben die "Turnschutouristen" im Regelfall überhaupt keine Karten dabei ("Ist doch alles markiert...")

Im Grunde kann ich die Bedenken verstehen, so ist es ja nicht. Allerdings nehme ich an, dass jemand der sich explizit die Karte für die Alpen runterlädt, was anderes damit vorhat, als jemand der die "normale" Karte runterlädt.

Ich persönlich war mit der Lösung, dass ich mir die Karte selber erstellen kann ganz zufrieden. Ich habe allerdings ein paar Freunde die nicht so erfahren mit Computern sind und sowas nicht selber können. Da ist es schon ganz praktisch, wenn die eine Karte die sie zum Wandern geeignet ist, einfach runterladen können.