Dyskusja:Format PNT
Z UMP
(→Zakres niezbędnych zmian w narzędziach) |
(z maila) |
||
Linia 54: | Linia 54: | ||
napisanie konwertera w awk: (w trakcie) Ar't | napisanie konwertera w awk: (w trakcie) Ar't | ||
- | implementacja w kompilatorze: /Alf/? | + | implementacja w kompilatorze (okres przejściowy 2 formaty poi i pnt): /Alf/? |
poprawienie perlowego mdm2: ? | poprawienie perlowego mdm2: ? | ||
+ | |||
+ | |||
+ | = implementacja = | ||
+ | wersja mont-demont-bat | ||
+ | |||
+ | |||
+ | Przykład linijki: | ||
+ | |||
+ | (52.16525,21.09042); MUZEUM ; Pałac w Wilanowie; UL=Kostki-Potockiego; NR=10/16; MIASTO=Warszawa; TEL=+48228428101; | ||
+ | |||
+ | aby zobaczyć jak to wygląda na całej warszawie zapraszam tu: | ||
+ | http://chomikuj.pl/artiip/UMP/poi-warszawa.zip | ||
+ | miasta też się tam zaplatały | ||
+ | |||
+ | *Rozdzielenie lat i lon w zasadzie nie ma sensu :) wiec jest | ||
+ | (52.16525,21.09042) tak jak w mp | ||
+ | |||
+ | UL NR MIASTO TEL są pisane właśnie TAK, ponieważ poprawia to | ||
+ | czytelność, ale wpisanie ręcznie ul,nr,itp też jest przyjmowane (i | ||
+ | poprawiane w następnym przejściu skryptu | ||
+ | |||
+ | *Dodatkowo kolejność tych pól jest ustalana odgórnie tu lista: | ||
+ | kol[1]="id" # dla bankomatow , rozkladow jazdy itp | ||
+ | kol[2]="Highway" | ||
+ | kol[3]="lvl" | ||
+ | kol[4]="ul" | ||
+ | kol[5]="nr" | ||
+ | kol[6]="zip" | ||
+ | kol[7]="Miasto" | ||
+ | kol[8]="tel" | ||
+ | kol[9]="www" | ||
+ | Proszę o podesłanie własnej :) jeżeli ktoś ma inny pomysł :) | ||
+ | |||
+ | Do zrobienia zostały | ||
+ | * góry i ich wysokości | ||
+ | właśnie na czas edycji i kompilacji należało by te wysokości trzymać w labelu. | ||
+ | Warto to rozdzielać? | ||
+ | * znaki specjalne ";" i "=" | ||
+ | * przypisanie typ dla nowych poi (z 0x0???) | ||
+ | * dzielenie na pliki | ||
+ | I będzie można to wdrożyć | ||
+ | |||
+ | |||
+ | A wiec veto dla nagłówków , przede-wszystkim nie ma tego jak trzymać | ||
+ | dobrze w mp podczas edycji , trzeba stosować sztuczki typu trzymanie | ||
+ | danych w plikach lub w pamięci (perl) , wszystkie te globalne | ||
+ | wartości mogą spokojnie być trzymane w samym poi. | ||
+ | |||
+ | Kodowanie powinno być trzymane globalnie dla całego obszaru/kraju | ||
+ | zresztą i tak nie mamy dobrego wsparcia w ME dla mieszanych charsetów | ||
+ | |||
+ | Dla pseudo XML mówię zdecydowanie raczej nie :) już wole mp |
Wersja z dnia 18:05, 16 maj 2010
Spis treści |
Dyskusja n.t. nowego formatu POI
Głosy ZA
- miszka - Jestem za - dokumentacja, testy
- piti - pomysł jak najbardziej akceptuję i mi się podoba - beta-testy
- Ar't - W tym momencie, nie mam czasu żeby poprawiać awka.
- całkowite odstępstwo od plików pnt. - bez nagłówka. - koniecznie nowe rozszerzenie np poi. - sugerowany format: lat;lon;typ;nazwa;mix_xml - dodatkowe podtypy TYP-PODTYP (np ATM-24H itp) jeżeli nie rozumie podtypu to ignoruje podtyp stosuje tylko TYP. - TYPY tylko wielkie, narzędzia jednak nie czułe na to (poprawiające). - mapowania tekstowy na cyfrowy trzymane w jednym pliku! bez tego nie ma sensu wogóle tego ruszać. format proponowany to pnt2poi.txt - fajnie by było zmusić narzędzia do automatycznego rozkładania poi na właściwe pliki. - za TS: trim na lat,lon,typ. - za TS: kolejność w mix_xml ustalona. - jestem przeciw endLevel (w stałej części) 400zdefiniowanych vs 18000=0 (w wawa, duza czesc to city), za to może być na początku mix_xml. - może być wiele tagów comment. - średnik jako rozdzielacz między tagami.
- Wojtek Zientara - tak
a EndLevel wyrzucamy, czy nadajemy automatycznie?
- Tomek R. Surmacz - ja z pewnością - skrypty/testowanie.
- ulica, dom, miasto oraz EndLevel (którego zabrakło) to na tyle często występujące parametry POI-a, że warto je umieścić jako "obowiązkowe" na ustalonych pozycjach, tak jak lat, lon i nazwę. Przy czym "obowiązkowe" w tym sensie, że mogą być puste (nazwy też nie wymagamy dla wszystkich, np. parkingów czy słupków) - ponadto zezwoliłbym na spacje po polach numerycznych/o ustalonej wartości, takich jak lan/lon/endlevel/typ. Pozwoli to poprawić czytelność pliku przy ręcznej edycji. - koniecznie nowe rozszerzenie dla plików (*.poi na przykład) i współistnienie z plikami *.pnt (przynajmniej przez jakiś czas) - nagłówek pliku - niby niepotrzebny, ale jednak... Powinna być możliwość zapisania pewnych defaultów związanmych z całym plikiem, np. kodowania znaków, być może domyślnego miasta itp. a także komentarzy dotyczących całego pliku (np. zawierających meta-info, że plik pochodzi z danych zewnątrznych, jak stacje BP, albo źródeł weryfikacji danych) - kolejność tagów (tych opcjonalnych) - jakaś ustalona. Wysnikająca z mapedita albo alfabetyczna. Cokolwiek, byle uniknąć "migotania" danych przy montowaniu/demontowaniu/edycji różnymi narzędziami. - koniecznie możliwość dodawania komentarzy do pojedynczych rekordów. Może na zasadzie specjalnego taga comment="...", a może na zasadzie specjalnego znacznika (np. "//" po którym już wszystko do końca linii jest traktowane jako komentarz. (co daje też możliwość łatwego "zakomentowania" czyli wyłączenia części/wszystkich tagów w razie problemów
Głosy PRZECIW
Zakres niezbędnych zmian w narzędziach
napisanie konwertera w awk: (w trakcie) Ar't
implementacja w kompilatorze (okres przejściowy 2 formaty poi i pnt): /Alf/?
poprawienie perlowego mdm2: ?
implementacja
wersja mont-demont-bat
Przykład linijki:
(52.16525,21.09042); MUZEUM ; Pałac w Wilanowie; UL=Kostki-Potockiego; NR=10/16; MIASTO=Warszawa; TEL=+48228428101;
aby zobaczyć jak to wygląda na całej warszawie zapraszam tu: http://chomikuj.pl/artiip/UMP/poi-warszawa.zip miasta też się tam zaplatały
- Rozdzielenie lat i lon w zasadzie nie ma sensu :) wiec jest
(52.16525,21.09042) tak jak w mp
UL NR MIASTO TEL są pisane właśnie TAK, ponieważ poprawia to czytelność, ale wpisanie ręcznie ul,nr,itp też jest przyjmowane (i poprawiane w następnym przejściu skryptu
- Dodatkowo kolejność tych pól jest ustalana odgórnie tu lista:
kol[1]="id" # dla bankomatow , rozkladow jazdy itp kol[2]="Highway" kol[3]="lvl" kol[4]="ul" kol[5]="nr" kol[6]="zip" kol[7]="Miasto" kol[8]="tel" kol[9]="www"
Proszę o podesłanie własnej :) jeżeli ktoś ma inny pomysł :)
Do zrobienia zostały
- góry i ich wysokości
właśnie na czas edycji i kompilacji należało by te wysokości trzymać w labelu. Warto to rozdzielać?
- znaki specjalne ";" i "="
- przypisanie typ dla nowych poi (z 0x0???)
- dzielenie na pliki
I będzie można to wdrożyć
A wiec veto dla nagłówków , przede-wszystkim nie ma tego jak trzymać
dobrze w mp podczas edycji , trzeba stosować sztuczki typu trzymanie
danych w plikach lub w pamięci (perl) , wszystkie te globalne
wartości mogą spokojnie być trzymane w samym poi.
Kodowanie powinno być trzymane globalnie dla całego obszaru/kraju zresztą i tak nie mamy dobrego wsparcia w ME dla mieszanych charsetów
Dla pseudo XML mówię zdecydowanie raczej nie :) już wole mp