Na wie gesagt, ich finde immer dass man derartige Entscheidungen (sinnvoll oder sinnlos) gerne auch dem Nutzer überlassen kann. Ausser dass es für dich keinen Sinn ergibt und, dass bei Benutzung die Karte unübersichtlicher wird sehe ich keinen Grund die Karte nicht routable zu Erstellen. Denn dann kann der Nutzer selber sehen ob die Funktion für ihn sinnvoll ist und wenn dem nicht so ist, dann routet er halt nicht und alles ist gut.
Aber ist ja deine Sache. Für mich für meinen Teil kommt OSM-C genau aus dem Grund nicht in Frage. Ich mag es einfach den Weg zum nächsten Geocache in einer Stadt auf dem kürzesten Weg zu finden und nicht nur als Luftlinie.
Deswegen hatte ich halt bisher immer Lambertus oder OpenMtbMap genutzt. Nun würde ich mir halt gerne eine “tagesaktuelle” Version von OpenMtbMap mit eventuell noch leicht abgewandelten routingEigenschaften und leicht verändertem Aussehen erstellen.
Mal schaun wie lange das dauern wird bis ichs geschafft hab oder aufgegeben habe.
Die Funktionsweise von OSM-C finde ich nichts desto trotz den “wichtigen” Schritt in die richtige Richtung zu einer für Anfänger, NichtEnglischProfis und WindowsNutzer nutzbaren GUI. Dafür auf jeden Fall großen Respekt!
Sehe Ich es richtig, dass im Grunde genommen OSM-C nur andere schon vorhandene Programme/Routinen aufruft?
Wie schneidet der OSM-C denn aus eine Planet Datei einen Bereich heraus?
Ich finde nur den Splitter der die osm-Datei in Kacheln zerlegt.
Nochmal: Das funktioniert so nicht, das erfordert deutlich mehr Arbeit. Du kannst es auch gerne selber ausprobieren: Composer legt eine Datei ab, welche Kommandozeilenbefehle er verwendet hat. Da kannst Du einfach ein --route hinzufügen, es nochmal aufrufen und Dich davon überzeugen, daß die Karte nicht funktioniert.
Für das Ausschneiden der Planetfiles wird osmosis verwendet. Für die Zerlegung in Kacheln hat Composer einen eigenen Splitter, der derzeit z.B. mit Multipolygonen besser zurechtkommt als der von mkgmap und in der nächsten Version auch die Dichte der Höhenlinien berücksichtigen wird.
So sehr ich mir natürlich ein Routing für meine Karten wünsche würde, aber Nop hat hier meiner Meinung nach recht. Warum etwas vorgaukeln, was hinterher eh nur bescheiden funktioniert. Die Höhendaten in der Karte sind auf jeden Fall viel wichtiger als das Routing.
Warum kannst du den mkgmap-splitter nicht auf die Hoehenlinien anwenden? Dem ist es doch eigentlich egal, was fuer OSM-Daten er in Kacheln teilen soll.
Ich weiss nun ja nicht, wie der Composer die Hoehnlienien integriert. Bei meinen eigenen Karten sind sie einfach in einem eigenen, transparenten Layer abgelegt. Da muessen die Kachelgrenzen nicht identisch sein mit den Kachelgrenzen der anderen Layer.
Eine andere Loesung waere auch, erst die OSM-Daten mit dem mkgmap-splitter in Kacheln zu zerschneiden. Dabei liefert der splitter ja auch die Schnittgrenzen als Ausgabe. Mit diesen Grenzen kann man dann sich ja die passenden Hoehenlineinkacheln erzeugen.
Und als drittes ist ja auch vom mkgmap-splitter der Quelcode offen. Es waere vielelicht einfacher, da einen Blick rein zu werfen als in mkgmap selber.
Erstens sind deine Karten ja nicht nur fuer die Berge gedacht. Nur weil es nicht absolut perfekt ist, ueberhaupt kein Routing anbieten zu wollen, sehe ich als falsch an. Letztendlich wird der Nutzer schon entscheiden, ob er die Funktion bruahcbar findet oder nicht, er ist ja nicht gezwungen, sie zu verwenden.
Zweitens kannst du in das Routing ja auch die Parameter sac_scale, smoothness und incline mit aufnehmen, so dass schwierige Wege trotz der kuerzeren Strecke als schlechter bewertet werden. (Das geht dann aber nur ueber den Umweg des verbogenen Auto-Routings.) Alleine durch die Anwendung erzeugst du letztendlich den Druck, dass die Leute die entsprechenden Tags auch setzten. Dann sehen die Nutzer, an welchen Stellen die Daten noch Luecken haben, und sie merken auch direkt, welche positiven Effekte das Schliessen dieser Luecken mit sich bringt.
Das kenne ich ja von mir selber: Wenn mich beim Autorouting oder beim Rennradrouting das Navi eine eher unegwoehnliche Strecke langschicken will, dann gehe ich der Sache nach und suche nach der Ursache. Sehr haeufig sind das dann solche Sachen wie fehlenden max_speed oder surface Tags. Ohne aktive Nutzung des Routings faellt einem das gar nicht erst auf.
Dank auch von mir an Torsten für die hilfreiche Erklärung bezüglich Styles und Typ-Files. Am Anfang ist allein die Fülle der verschiedenen Anleitungen, Tools, Vorgehensweisen verwirrend (trotzdem natürlich toll, dass es sie gibt).
Ich nutze auch größtenteils die fertigen openmtb-Karten, aber für manche Situationen nehme ich lieber selbstgemachte. Zuerst war ich auf Höhenlinien ganz wild, habe allerdings dann doch realisiert, dass die mir in Brandenburg irgendwie nichts bringen. Aber im Urlaub in bergigen Regionen eben schon.
Dann sollte man, wenn ich richtig verstehe, am besten immer eigene IDs vergeben, um Kollisionen zu vermeiden, und die eines transparenten Layers (Höhenlinien) muss kleiner sein als die anderen. Frage insbesondere an Chris: Wäre es möglich, die Meerespolygone auch in eine separate OSM-Datei und eigenes Layer auszulagern statt sie mittels Osmosis mit der Grundkarte zu mergen?
Zur Family-ID und deren sinnvoller Vergabe habe ich bisher noch recht wenig gefunden. Was genau ist denn deren Aufgabe?
Für’s erste brauche ich zwar Routing gar nicht unbedingt, finde aber die Möglichkeit, über Styles die Bevorzugung von Wegtypen im Routing zu beeinflussen, richtig spannend.
ich habe zwar nicht Alles genau durchgelesen, aber die Fragew wie eine ROUTING-Fähige Karte ensteht war mehrfach ein Thema. Zufällig bin ich über diesen Link gestolpert ==>http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map#Technik dort ist die Vorgehensweise erläutert.
