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
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? 
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.
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 -_-
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
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/viewtopic.php?pid=208081#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.
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
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.