Dyskusja:Format PNT

Z UMP

(Różnice między wersjami)
(→Głosy ZA)
Aktualna wersja (07:50, 17 maj 2010) (edytuj) (anuluj zmianę)
(→implementacja: inne pomysły)
 
(Nie pokazano 8 wersji pośrednich.)
Linia 3: Linia 3:
* miszka - Jestem za - dokumentacja, testy
* miszka - Jestem za - dokumentacja, testy
* piti - pomysł jak najbardziej akceptuję i mi się podoba - beta-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 ==
== Głosy PRZECIW ==
== Zakres niezbędnych zmian w narzędziach ==
== 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) 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 bankomatów , rozkładów jazdy itp
 +
kol[2]="Highway"
 +
kol[3]="lvl"
 +
kol[4]="Miasto"
 +
kol[5]="ul"
 +
kol[6]="nr"
 +
kol[7]="zip"
 +
kol[8]="tel"
 +
kol[9]="www"
 +
Proszę o podesłanie własnej :) jeżeli ktoś ma inny pomysł :)
 +
 +
*nazwy pól mogą być dowolne (poza CityName,CityIdx,Plik,Zip)
 +
 +
==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
 +
 +
 +
==Inne pomysły:==
 +
(-) nie przyjęty
 +
 +
(+) przyjęty
 +
 +
* (-)lvl jako stałe pole na 2 pozycji (z przyzwyczajenia)
 +
** lvl inny niż 0 występuję w małej ilości poi (mniej niż 1-2%)
 +
** zrywamy ze starym zapisem
 +
* (+)usuniecie nawiasów z latlon
 +
** łatwiejsze przetwarzanie dla innych skryptów
 +
* (-) nazwy pól pisane małymi lub Kapitalikami
 +
** nieczytelność, trudniejsza edycja "notatnikiem"

Aktualna wersja

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) 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 bankomatów , rozkładów jazdy itp
      kol[2]="Highway"
      kol[3]="lvl"
      kol[4]="Miasto"
      kol[5]="ul"
      kol[6]="nr"
      kol[7]="zip"
      kol[8]="tel"
      kol[9]="www"

Proszę o podesłanie własnej :) jeżeli ktoś ma inny pomysł :)

  • nazwy pól mogą być dowolne (poza CityName,CityIdx,Plik,Zip)

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


Inne pomysły:

(-) nie przyjęty

(+) przyjęty

  • (-)lvl jako stałe pole na 2 pozycji (z przyzwyczajenia)
    • lvl inny niż 0 występuję w małej ilości poi (mniej niż 1-2%)
    • zrywamy ze starym zapisem
  • (+)usuniecie nawiasów z latlon
    • łatwiejsze przetwarzanie dla innych skryptów
  • (-) nazwy pól pisane małymi lub Kapitalikami
    • nieczytelność, trudniejsza edycja "notatnikiem"
Źródło: "http://ump.fuw.edu.pl/wiki/Dyskusja:Format_PNT"