Nie wiem co masz na myśli pisząc o optymalnych zbliżeniach. Dla mnie to takie zbliżenie, które odpowiada mniej więcej skali oryginalnej mapy. Przykładowo dla mapy w skali 1:50000 takim zbliżeniem będzie zoom w granicach 500-300m. Przy takim zoomie prawidłowo przygotowany JNX, oglądany w odbiorniku (przynajmniej w Oregonie 600) powinien być - pod względem ostrości - nie do odróżnienia od KMZu. Problemy zaczynają się przy większych, ponadnormatywnych zbliżeniach na co zapewne ma wpływ zarówno sposób renderowania obrazka przez odbiornik jak też fakt, że JNX bazuje na jpgach. No i właśnie. Nie znam programu mobat2jnx, ale może tam właśnie tkwi problem? Może program stosuje zbyt dużą kompresję jpgów podczas generowania JNXa?igrek pisze:nie udało mi się uzyskać optymalnej ostrości na optymalnych zbliżeniach
Niestety z tego nie wynika o jakim zoomie dla jakiej skali mapy mówimy. Wspominasz coś o zoomie 80m. W przypadku JNXa, jeżeli jest to np. mapa w skali np. 1:50.000 lub mniejszej, o ostrym obrazie możesz zapomnieć. Ba! Nawet mapa 1:25.000 nie będzie "błyszczała". Natomiast mapa w skali 1:10.000 powinna wyglądać bardzo dobrze.igrek pisze:Od razu wyjaśnię, że mając na myśli optymalne zbliżenie, mam na myśli takie zbliżenie na odbiorniku w którym detal na mapie jest najbardziej powiększony
ale nie ma jeszcze efektu "schodkowania"
Kod: Zaznacz cały
<?xml version="1.0" encoding="UTF-8"?>
<customMapSource>
<name>German Maps</name>
<minZoom>8</minZoom>
<maxZoom>15</maxZoom>
<tileType>jpg</tileType>
<tileUpdate>IfNoneMatch</tileUpdate>
<url>http://gmaps.zamki.pl/{$z}/{$y}/{$x}.jpg</url>
<backgroundColor>#000000</backgroundColor>
</customMapSource>
). 
Nie wykluczone, że gdy wyjdziesz z odbiornikiem w teren, gdzie wyświetlacz sam z siebie straci nieco wigoru tzn. przyblednie, różnice - jeżeli chodzi o kontrast, nasycenie - mogą być niezauważalne. Może też być odwrotnieigrek pisze:Ja różnicę w jakości na korzyść KMZ lekką widzę KMZ jest jakby bardziej nasycony ? Kontrast jest większy ?
Pomysł super ale mi MOBAC wywala hasło że plik nieprawidłowy...musi mieć JAR, czyli jak zrobić JARa nie mając JKD?igrek pisze:To moje wyniki zabawy KMZ kontra JNX na tym samym źródle danych
Źródło to MOBAC z plikiem sourceKod: Zaznacz cały
<?xml version="1.0" encoding="UTF-8"?> <customMapSource> <name>German Maps</name> <minZoom>8</minZoom> <maxZoom>15</maxZoom> <tileType>jpg</tileType> <tileUpdate>IfNoneMatch</tileUpdate> <url>http://gmaps.zamki.pl/{$z}/{$y}/{$x}.jpg</url> <backgroundColor>#000000</backgroundColor> </customMapSource>
Jeśli przyjrzeć się bliżej to widać, że Messtischblaty w http://gmaps.zamki.pl są skalibrowane i pocięte dokładnie tak, jak kafle map googla. Więc generalnie EPSG:3857 - WGS84, projekcja Mercatora, numery kafli w standardzie googla, współrzędne narożników jak w kaflach googla.Norick pisze:Pytanie brzmi: Jakie przyjąć parametry by Messtischblaty gryzło prawidłowo w Mapc2mapc ?
Czasem trzeba je transformować do innych formatów i tu the dhupa
.
Noric, jeśli chcesz ręcznie kalibrować oryginalne Messtischblatty na siatkę z mapy, to musisz wybrać datum Potsdam, a jeśli go nie ma w programie - wcześniej zdefiniować. Obszar mapy podzielony jest na 6 stref, więc dodatkowo powinieneś wiedzieć, w której strefie się znajdujesz. Współrzędne BL w narożnikach mapy są na elipsoidze Bessela - jeśli zadeklarujesz je jako WGS84, to będzie przesunięcie. Najprościej jest pobrać dla arkusza i wykorzystać do kalibracji plik kalibracyjny Oziego. Możesz sobie z jego pomocą zrobić np. jnx-y jnxerem. Jeśli chciałbyś mieć Messtischblatty jednym kliknięciem i akceptujesz nieco gorszą jakość, to możesz się w nie zaopatrywać pobierając i sklejając kafle pocięte w standardzie googla ze wspomnianego WMTS http://www.zamki.pl .Norick pisze:No cóż, "po wielu bólach ("bulach") trudach i mękach" poddałem się i niestety tu...
