Podmiana obiektów - "typ"
     Możliwość własnego definiowania obiektów to "wynalazek" ogłoszony przez Staszka gpsmappera pod koniec maja 2006r.  W ślad za tym, Staszek opublikował specjalną wersję  cgpsmappera kompilującą plik z definicjami obiektów.
    Mając do dyspozycji tak świetne narzędzie oraz opublikowane przez Staszka wytyczne (po angielsku) w postaci pliku custom.txt można było pokusić się o przygotowanie własnych obiektów.
    Idea w zasadzie jest prosta:
  • przygotowujemy odpowiedni plik tekstowy z definicjami obiektów np: "obiekt.txt"
  • z poziomu wiersza poleceń wykonujemy polecenie: cgpsmapper typ obiekt.txt i w efekcie otrzymujemy plik z rozszerzeniem "TYP", który wysyłamy do odbiornika razem z mapkami
    Jak wspomniałem wyżej, w pliku custom.txt podane są wyczerpujące przykłady definiowania własnych obiektów. Tu tylko kilka moich dodatkowych uwag i spostrzeżeń. Czy słusznych ? Nie wiem, na razie zbyt krótko i zbyt słabo zgłębiłem zagadnienie.
     Mój projekt składa się z dwóch niezależnych zestawów map: Topo_PL_100 i Topo_PL_Szlaki. Każdy z tych zestawów posiada niezależny plik definiujący obiekty. Tu pierwsza uwaga. Każdy plik definiujący obiekty, wpinany do MapSource musi mieć swoją indywidualną nazwę o długości do 8 znaków. Umieszczenie w MapSource dwóch plików o identycznych nazwach spowoduje, że podczas wysyłania do odbiornika map z dwóch zestawów  zostanie wysłany tylko jeden plik definiujący i obiekty zostaną podmienione tylko w jednym zestawie.

Plik definiujący:  obiekt.txt
     W przypadku wysyłania map MapSourcem przygotowanie pliku tekstowego musimy rozpocząć od sekcji ID:
[_ID]
ProductCode=1
FID=4807
[End]
w której podajemy parametry ProductCode i FID zgodne z parametrami MapSetu zastosowanymi do przygotowania pliku pv.txt ( zobacz ). Jeżeli mapki wysyłamy SendMapem przygotowanie sekcji ID nie jest konieczne.
    Drugą sekcją, którą tworzymy to sekcja dotycząca kolejności wyświetlania poligonów [_drawOrder]. Tę sekcję można przekopiować w całości z pliku custom.txt bądź z mojego pliku !inne.txt Brak tej sekcji spowoduje, że nie będą się wyświetlały poligony !!!
    Teraz definicja obiektów. Oto mój nowy parking (0x2f0b)
[_point]
Type=0x2F
SubType=0x0B
String1=4,PARKING
String2=0x15,PARKING
DAYXPM="11 13 3 1"
"      c None"
"$    c #0000AA"
"#    c #FFFFFF"
"$$$$$$$$$$$"
"$$$$$$$$$$$"
"$$######$$$"
"$$#######$$"
"$$##$$$##$$"
"$$##$$$##$$"
"$$#######$$"
"$$######$$$"
"$$##$$$$$$$"
"$$##$$$$$$$"
"$$##$$$$$$$"
"$$$$$$$$$$$"
"$$$$$$$$$$$"
[end]
1. Pierwsze dwie linie nie wymagają wyjaśnienia. To definicja typu: 2f 0b
2. Następnie podajemy nazwę obiektu (m.in. wyświetla się po naprowadzeniu kursora, gdy dany obiekt nie posiada nazwy własnej) w wersji angielskiej (4) i w wersji polskiej (0x15). Domyślam się, że chodzi tu o podanie nazwy dla różnych wersji językowych wybranych w Menu odbiornika.
3. Teraz defincja paremetrów wyświetlania w trybie dziennym (DAYXPM):
  • 11 - szerokość zdefiniowanego POI
  • 13 - wysokość jw.
  • 3 ilość zdefiniowanych kolorów (uwaga: w tym POI zastosowałem tylko dwa kolory, ale defincję "pustego" kopiowałem z innych i tak pozostało, jak widać w niczym to nie przeszkadza)
  • 1 Działanie tego parametru na dzień dzisiejszy nie jest dla mnie jasne.
4. Defnicja kolorów RGB w systemie szesnastkowym. Pierwsze dwie wartości podają nasycenie piksela dla koloru czerwonego, następne dwie zielonego, ostatnie niebieskiego. W moim parkingu wygląda to tak:
  • spacja - punkt "przezroczysty"
  • $ - punkt ciemno niebieski (niebieski=0000FF)
  • # - punkt biały
5. Mapa bitowa dla ikony.

      Dokładnie w taki sam sposób możemy zdefiniować inne ikony POI oraz linie i poligony. O ile dobrze zrozumiałem, w przypadku linii mamy dwa sposoby definiowania obiektu. Bądź jako linię z "borderem", bądź - tak jak w przypadku POI jako mapę bitową. W przypadku mapy bitowej można zdefiniować tylko 2 kolory dla wersji dziennej i dwa dla wersji nocnej. W przypadku bitmapy powinniśmy zadeklarować odcinek o długości 32 pkt, tak jak w tym przykładzie:
[_line]
Type=0x16
Xpm="32 1 2 1"
"# c #000000"
" c none"
"## ## ## ## ## ## ## ## "
string1=4,SCIEZKA
string2=0x15,SCIEZKA
[end]
a w przypadku bitowej deficji obiektu o szerokosci większej niż 1 linia wskazane jest zastosowanie parametru: UseOrientation, tak jak w tym przykładzie:
[_line]
Type=0x19
UseOrientation=Y
Xpm="32 4 2 1"
"# c #000000"
" c none"
"################################"
" ####    ####    ####    ####     "
" ####    ####    ####    ####     "
"################################"
string1=4,KOLEJ
string2=0x15,KOLEJ
[end]
     Parametr UseOrientation dodałem zgodnie z zaleceniami autora cgpsmappera, ale muszę przyznać, że jego działanie nie do końca mnie przekonuje. Odnoszę wrażenie, że w samym odbiorniku lepsze efekty można czasem uzyskać stosując: UseOrientation=N.
    Następnie plik "obiekt.txt" kompilujemy do postaci TYP (przypominam: cgpsmapper TYP obiekt.txt i ...... wraz z mapą wysyłamy do odbiornika np. SendMapem.
     W przypadku MapSource przyjmujemy jakąś specyficzną - unikatową nazwę (u mnie: obiekt.typ dla szlaków i obiekt1.typ dla topo_100) i dodajemy do rejestru wpis określający lokalizację pliku:

Nowy-021.jpg (59001 bytes)

Polecam analizę przykładów podanych przez Staszka i .... życzę sukcesów.
-------------------------------
Lech Ratajczak   VI 2006