Dyskusja:Format PNT

Z UMP

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: /Alf/? poprawienie perlowego mdm2: ?