Hallo.
Zu MOBAC läuft im OSM-Forum z.Zt. eine recht negativer Thread, der bis "Sperrung" des OSM-Kartendownloads geht:
Mobile Atlas Creator - Lizenz- und Policyverstöße.
Ich hoffe die kommen nicht auf dumme Gedanken. 
Man fragt sich schon, wofür die Karten eigentlich erstellt werden - wobei MOBAC-Nutzer ja auch für OSM loggen.
Gruß
W.
Ja das ist recht unerfreulich!
Ich hoffe das die dort nicht das Augenmaß verlieren!
Ein gewisser Download sollte man zulassen - nicht jeder ist ein Crack und kann sich die Karte selber Rendern!!!!
Natürlich gibt es immer welche die übertreiben - aber grad bei den OSM-Karten ist es doch garnicht sinnvoll große Bereiche zu holen.
Wenn es wirklich Probleme bei den Servern gibt (bei dem Thread war das eher theoretischer Natur!) sollten die dort irgendwelche Bremsen einbauen aber nicht in einen Krieg verfallen.
Und eigentlich reduziert der MOABC richtig angewand den Traffic!!
Ich schau mir vorher meist das Gebiet schon im MOBAC an - das hab ich dann schon in Cache anstatt das in nem Viewer anzusehen.
Und ich lösche wenn ich neue Karten will expilzit nur die entsprechenden Cache-Ordner (bei der von Nop angebotenen Reit und Wanderkarte lösch ich nie den Relief-Cache-Ordner somit muß ich das nur 1mal laden und kann das immerwieder für alle Karten verwenden) die ich auch neu haben will.
Schauen mir mal was die Zeit bringt.
Gruß
Silver
Ich sehe das auch kritisch. Die Prozessor- und Netzwerklast kann schon sehr groß dabei werden, vor allem wenn es mehrere gleichzeitig machen. Man darf nie vergessen, dass hinter OSM kein millidardenschweres Großunternehmen wie Google steht, um die Server zu finanzieren.
Könnte man das nicht eleganter lösen? Beispielsweise wenn MOBAC einzelne Bereiche als Vektordaten holt und das Rendering selbst durchführt. Die Rendering-Software ist doch selbst Open Source. Das müsste schon irgendwie integrierbar sein. Der Vorteil ist besonders groß, wenn mehrere Zoomstufen generiert werden. Dann reicht ein einzelner Vektordatensatz. Ansonsten müsste man jedesmal neu die Pixeldaten übertragen.
Ich nutze die OSM-Rasterdaten überhaupt nicht in Glopus. Dafür habe ich die Topo-CDs gekauft. OSM habe ich nur als Vektor-Overlay in Glopus, weil da mittlerweile manches korrekter und umfangreicher ist als in den Topokarten (Waldwege, Fußwege).
Könnte man das nicht eleganter lösen? Beispielsweise wenn MOBAC einzelne Bereiche als Vektordaten holt und das Rendering selbst durchführt. Die Rendering-Software ist doch selbst Open Source. Das müsste schon irgendwie integrierbar sein. Der Vorteil ist besonders groß, wenn mehrere Zoomstufen generiert werden. Dann reicht ein einzelner Vektordatensatz. Ansonsten müsste man jedesmal neu die Pixeldaten übertragen.
Mach doch einen Feature Request. Ich halte es allerdings für sehr unwahrscheinlich, dass ein OSM Renderer eingebaut wird...
Grüße
Helge
Ich sehe das auch so das wohl das nix mit dem Renderer wird.
Nicht das ich das auch wünschen würd!
Aber wenn ich sehe wie oft ich mkgmap wechseln muß damit lauffähige Karten rauskommen (weil irgendwo sich was in den Rohdaten geändert hat)...
Und dann müsste er auch noch Relief - bzw. Hillshadingkarten errechnen können - das ist für mich eigentlich das wichtigste das ich die Karten damit kombinieren kann - ist grad für die Planung von Touren viel besser als reine Höhenlinien.
Da kommen leider optisch auch meine halbtransparenten IMG-Karten mit Rliefkarten als Hintergund nicht mit!
Wohl ein bischen viel!!! als wunsch für MOBAC wohl auch weil eigentlich nur eine Person dahintersteckt trotz OpenSource!
Vielleicht ist das aber in Etappen zu schaffen!!!!
Ein einfaches Programm das Karten rendert und analog in Netz das im z/x/y Ordnerformat auf die Festplatte legt.
Ein Programm das ganauso Relief bzw. Hillshadingkarten anlegt
und
MOBAC der direkt was nicht im Cache liegt statt vom Netz von der Festplatte holt!!!!
Das Ergebnis sollte an die Wanderkarte von Nop bzw. Hikebike+Relief herankommen!
Naja Träumen darf mann ja noch!!!
Gruß
SIlver
Hallo
leider wird derzeit Front im OSM-Forum gegen MOBAC gemacht.
MOBAC in Verbindung mit MAPERATIVE als Renderer das wäre ne feine Sache....aber auch nur ein weiterer Traum...
MfG
Achim
Alles anzeigenHallo
leider wird derzeit Front im OSM-Forum gegen MOBAC gemacht.
MOBAC in Verbindung mit MAPERATIVE als Renderer das wäre ne feine Sache....aber auch nur ein weiterer Traum...
MfG
Achim
Na nur nicht so Träumen !!!
Mit dem teil kann man auch Tiles erstellen und diese kann man dann direkt mit dem Tintenbrot laden und zumindest für Glopus aufbereiten!!
Dürfte doch ein kleines sein den MOBAC dazu zu bringen statt im Netz auf der festplatte zu suchen oder !
Man muß nur vorher halt das Gebiet rendern lassen und dann darauf zugreifen!!!!
Leider bin ich noch gescheitert mehr als ca. 1000 Kacheln auf einmal Rendern zu lassen (hatte bein Test nur 5 Zoomstufen gerendert 10-14 bzw. 12-16)
wenn das noch mehr Rendert ist das genau das Teil das ich gesucht hat da auch Relief und Shading sich in die Karte mischen lassen !!!!!!
Gruß
Silver
Hallo AZERTY
...wozu braucht man Tintenbrot? Wenn man einen lokalen Webserver am Laufen hat und den in MOBAC als SOURCE konfiguriert kann man diese "lokalen" Tiles in ALLE Zielformate von MOBAC generieren... 
MfG
Achim
Ps: Für NaviComputer habe ich da das Plugin für MOBAC erstellt. Derzeit bin ich dabei das Ausgabeformat (sqlite DB) anzuzeigen, dass man weiß welches Kartengebiet man hat. Sinngemäß mache ich das eventuell für Glopus um die GMF's anzuzeigen. Ferner kann ich damit Tracks anzeigen...
@womisa,
Danke für den Hinweis!
Allerdings hab ich mit localen Webservern noch nichts zu tun gehabt, geschweige denn wie ich damit Maperative dazu bewege mir die tiles zu liefern!
Nee Anleitung für Dummys währe da nicht schlecht!!
Gruß
Silver
Hallo AZERTY
Nee Anleitung für Dummys währe da nicht schlecht!!
...na,na das ist aber hart....
Also ich habe einen lokalen Webserver am laufen, bei dem schon einiger Aufwand erforderlich ist, da ich den auch für andere Zwecke nutze.
..aber ein Kollege hat mir berichtet dass er mit dem "USB WEBSERVER" der nahezu null Aufwand bzw. leicht zu konfigurieren ist und diesen in Verbindung mit MOBAC erfolgreich einsetzt. Dieser muß auch nicht installiert werden (Portable Version)
In MAPERATIEV kannst du die lokalen Tiles mit dem Comand:
generate-tiles [parameters]
generieren. Das Habe ich schon mal gemacht. Derzeit nutze ich aber ausschließlich MOBAC zum Karten generieren.
Falls du das konfigurieren möchtest und Probleme hast, dann melde dich..
MfG
Achim
Ps: MAPERATIVE hat jetzt unter Tools ein "Generate Tiles! ...aber irgendwie stürzt der ab bei hohen Zoomlevel....
Hallo @womisa
"USB WEBSERVER" ist ja wirklich leicht einzurichten mußte nur den Port von 8080 auf 9050 (Auch deshalb nur weil mein localer Proxy darauf liegt) und das Root anpassen und schon lief das Teil.
Der Zugriff mit MOBAC auf die Tiles funktioniert auch super!
Jetzt muß isch nur noch mit dem splitter entsprechenden Auschnitt aus der germany.osm rausschneiden weil mit meim 32Bit-System der Speicher vorne wie hinten nicht reicht!
@All
weis jemand wie man aus z.B 9.123245 E 51.4556 N in Garminkoodinaten umrechnen kann - Brauch das um das in die areas.list des Splitter's reinzuschreiben um entsprechenden Ausschnitt zu bekommen!
Gruß
Silver
Mach doch einen Feature Request. Ich halte es allerdings für sehr unwahrscheinlich, dass ein OSM Renderer eingebaut wird...
Naja, das wird dem Programmierer schon selbst einfallen. Spätestens wenn MOBAC ausgesperrt wird ist das die logische Konsequenz. Ich kenne die Sources nicht, um den Aufwand abschätzen zu können. Problematisch wären u.U. auch verschiedene Programmiersprachen. Andererseits wäre es auch schön, eine Art von embedded OSM Renderer als Library (DLL/.so) so zu errichten, das Anwendungsprogramme leicht die OSM-Karten einbetten können. Sozusagen den OSM-Webrenderer so frisiert, dass er die Tiles nicht über HTTP ausliefert sondern über einen Funktionsaufruf. Wäre mal eine schöne Übungsaufgabe für angehende Geoinformatiker ...
Ansonsten, lokaler Webserver geht immer ... dank OpenSource Renderingengine
Ansonsten, lokaler Webserver geht immer ... dank OpenSource Renderingengine
Wo ist dann das Problem?
Grüße
Helge
@All
weis jemand wie man aus z.B 9.123245 E 51.4556 N in Garminkoodinaten umrechnen kann - Brauch das um das in die areas.list des Splitter's reinzuschreiben um entsprechenden Ausschnitt zu bekommen!
Sollte so funktionieren:
#define UNIT_TO_DEG .00002145767211914062L // 360/(2^24)
#define tomap(x) ((INT32)((x) / UNIT_TO_DEG + .5))
Wo ist dann das Problem?
Nur ein Komfortproblem. Eine Integration in MOBAC wäre komfortabler. Und dort gäbe es nicht das Problem, wenn Kiddies damit ganz D-Land runterladen. Gut, sollte man irgendwie drosseln wie schon angekündigt.
