Nein, natürlich sind in den Höhendaten keine Index Infos enthalten. Will man aber Höhenlinien zu den normalen Karten in eine einzige Karte zusammenfügen (wird auf allen GPS, sowie Basecamp, sowie ziemlich sicher Mapsource 6.16.2 korrekt angzeigt und unterstützt inkl. Höhendiagramme für Routen), dann bleibt einem nur mkgmap.
Das ist schon mal beruhigend. Nur solltest Du dann mit Deinem Post nicht den Anschein erwecken wollen, img2ms würde schlechter arbeiten, weil es Indexe verlieren läßt.
Ansonsten unterscheiden sich wohl unsere Kartenphilosopien. Ich kann nachvollziehen, dass Du Du bei der openmtb die Höhendaten nicht integrierst, weil das mit jeden Update neu eingebaut werden müßte und nur zusätzliche Arbeit macht. Deshalb halte ich es durchaus für legitim, die Höhendaten generell als separate Karte zu verwenden. Freeclimber, und wenn ich die Gastbeiträge auf Deiner Hompage lese, wohl auch andere, scheitern an der Komplexität der Karteninstallation. Du verlangst mit Deinen Batfiles den usern zu viel ab. Ich unterstelle jetzt mal, dass die batfiles prinzipiell funkitionieren könnten (hab es nicht selbst getestet), aber wer die Gesamtübersicht nicht hat, wird auf Deiner Homepage auch nicht schlau. Es gibt keine idiotensichere stepbystep-Anleitung. Du schmeist dort mit Fachbegriffen umher, die der Dau eh nicht versteht. Und daraus resultieren dann die Problemfälle , die hier diskutiert werden. Ich denke, wir sind uns einig, daß Deine Karten, auch inclusive SRTM-Höhen schon in MS laufen könnten, wenn man es richtig einbindet. Aber ganau dazu sind die Anfänger nicht in der Lage. Und Deine Beschreibungen benutzen oft die Terminologie des Experten. Folge: Der Dau versteht nur 'Bahnhof'.
Nicht zustimmen kann ich betreffs mkgmap. Das ist halt Ansichtssache und Erfahrungssache. Soll jeder das verwenden , was er für richtig hält.
Verbinde ich mehrere Karten zu einer neuen Karte mit Img2ms oder egal was und cgpsmapper (nicht Pro Version), verliere ich zwangsläufig den Addressindex. Dieser ist zugegebener Maße, mit mkgmap nicht 100% korrekt, aber ob er bei cgpsmapper 100% korrekt ist, glaube ich auch nicht. Würde gerne mal eine Karte in Größe der City Navigator mit cgpsmapper erstellt sehen, ob da der Addressindex funktionieren würde. Ich schätze nämlich mal ganz dreist, dass die Fehler im Addressindex von mkgmap großteils an Fehlern von cgpsmapper liegen,
Nur bitte keine Spekulationen, was cgpsmapper kann oder nicht kann, sondern Tatsachen. Das kann ich jetzt nicht nachvollziehen, wieso die Fehler von mkgmap an cgpsmapper liegen sollen. Das ist absurd. Und da ist es eben Tatsache , daß weder gmaptool noch mkgmap (welche Version ist eigentlich die aktuelle, es gibt ja laufend neue ? und das ist auch ein Zeichen, dass mkgmap nicht ausgereift ist ) mdr -files erzeugen kann, die MS akzeptiert. Du schreibst ja selbst, daß man die ggf. deinstallieren soll. Wo also ist da die Überlegenheit von mkgmap über cgpsmapper?.
Anders Thema: Deine Terminologie ist ungenau. Was meinst Du mit ' Will man aber Höhenlinien zu den normalen Karten in eine einzige Karte zusammenfügen?'. Eine Karte kann sowohl ein Kachel bedeuten als auch einen Kartensatz(aus mehreren Kacheln). Ich halte es so, dass die Höhenlinien integraler Bestandteil jeder Kachel sind. Siehe meine Toskanakarte. Das ist schlicht und einfach und man kann nichts falsch machen. Die Kachel wird eingebunden, will heißen ein TDB- file und preview mit cgpsmapper erzeugt, und die Höhenlinien sind automatisch da. Sicher geht es auch anders. z.B hat Peter Mapdekode in seiner Griechenlandkarte die Höhenlinien in Extrakacheln ausgelagert und trotzdem im Kartensatz drin, aber einfacher ? Vielleicht läßt Du Dich doch überzeugen, für die openmtp betreffs der Höhenlinien eine bessere Technologie einzubauen. A la Mapdekode. : nur einmal kompilieren und nur die TDB neuschreiben, wenn sich die Anzahl /name usw. der mtp-Kacheln bei Updates ändert. Dazu müssen halt die SRTM-Kacheln entsprechend eingestellt werden (FID, PID, Levls, transparenz, polygone drin ?) Sollten eigentlich nur Lines sein, aber bei dir weis man ja nie...
morgen1