Adresówki
Z UMP
Spis treści |
Pliki ADR
W katalogach źródłowych src możesz spotkać pliki z rozszerzeniem .adr, format wewnątrz jest bliźniaczo podobny do formatu PNT. To są adresy pozyskane z urzędów miast i gmin, z ich rejestrów emuia (ewidencja miast, ulic i adresów), która jest od kilku lat umocowana prawnie.
Ponieważ są to dane zewnętrzne, to edycje ograniczamy do niezbędnego minimum by wyeliminować istotne błędy, a same pliki mają status "prawie tylko do odczytu". Po prostu, podczas aktualizacji plik jest kasowany, i wgrywany jest nowy, bez zachowania dotychczasowych zmian (jedynie nasza pisownia nazw ulic, ale to się dzieje automatycznie bazując na innym mechanizmie). Przesuwanie tych punktów czy inne poprawki są słabe, gdyż poprawki powinny być nanoszone przez dany urząd, a nie przez nas.
Proszę nie dzielić tych plików na granicy obszarów, one mają "wystawać".
Jeśli chcesz działać w tej materii (pozyskiwanie, zmiany, uwagi, itp) skontaktuj się najpierw z Ar't-em bądź z Alf-em (a najlepiej mailować do nas zbiorczo). Mamy dość dopracowany mechanizm przetwarzania danych z różnych źródeł, i dokumentujemy wszystkie aktywności (tylko dla uprawnionych, zarządza tym WojtekN i chyba Alf, Ar't też może).
Od listopada 2022 mamy na mapie adresówki ze wszystkich polskich gmin.
Zmienne nazwy ulic?
Jako że mamy zmieniające się zasady nazewnictwa to w adresówkach można spotkać różne zapisy, nie "zsynchronizowane" z nazwą w ulicy. Tu mały poradnik co gdzie warto przenieść. przynajmniej w plikach z 2016+
- jeśli w adresówce jest nazwisko z "pseudonimem" to warto przenieść taką do linii
- podobnie z zapisami z małej litery tj: droga, szosa, zaułek, park, wyspa przenosimy do linii
- Batalionu "coś tam" też przenosimy do linii, kiedy w linii brakuje ciapek
Inne zapisy wymagają już dalszego badania co jest poprawne a co nie. Błędy zdarzają się i w adresówkach jak i w liniach.
W przypadku gdy to adresówka ma stary zapis, warto się zastanowić jak to poprawić:
- dla starych plików lepszym rozwiązaniem było by "odświeżyć" dane.
- dla nowych gdzie mamy "_PRG16.adr" i "_2016i.adr" lepiej zgłosić do nas, gdyż następne uaktualnienie też będzie miało złą nazwę, nam też łatwiej poprawić taki plik (w tym przypadku).
- dla pozostałych warto poprawić adresówkę i zgłosić do nas.
Przy okazji warto pamiętać że punkt adresowy ma tylko jednoznaczną i pojedynczą nazwę miasta i ulicy (nie działa zapis z @).
Dekomunizacja okazała się być masowa i wymagała dorobienia mechanizmu poprawy ulic w adresówkach. Interesujemy się plikiem narzedzia/dekomunizacja.ini (utf-8!) jest tam opisane co i jak, mechanizm poprawiania nazw w adr, działa prawie automatycznie dla plików 201Xi (impa), dla pozostałych już nie (czytaj dla impów zwykle wystarczy wpis w deko, a pozostałe wypadało by niestety ręcznie poprawić). Jeśli poprawisz tylko adr (impa/prg) a nie będzie wpisu w deko to jest szansa cofnięcia takich poprawek! Mimo że mechanizm działa praktycznie tylko dla impów to prosił bym jednak uzupełnić i dla wszystkich adresówek (z wyjątkiem ADR-Obszar.adr).
Skąd bierzemy
- pytamy urząd miasta / gminy
- żeby sprawdzić, czy i jak urząd używa ePUAP, i nauczyć urzędy tej drogi
- żeby dostać najświeższe dane
- żeby mieć możliwość zgłoszenia błędu czy mieć osobę kontaktową do dopytania o jakieś lokalne niuanse
- sprawdzamy, czy urząd używa iMPA albo nawet z góry jawnie udostępnił tam swoje dane
- sprawdzamy co jest w PRG.
Mamy następujące główne skrypty:
- przetworzenie danych xml z systemu emuia
- przetworzenie danych gml z systemu iMPA
- przetworzenie danych z innych systemów (formaty gml, shp)
- dzielenie wielgachnych PRG na mniejsze, gminne pliki.
- pobranie danych z iMPA
oraz mechanizm budowania słownika poprawnych (ujednoliconych) nazw ulic, i wykazywania typowych błędów (podwójne adresy, adresy z niekompletnymi danymi, itp.)
Nazewnictwo
Pewnie spotkałeś się z plikami gNazwaGminy-data.adr albo gNazwaGminy-PRG16.adr, te nazwy, jak się domyślasz, mają jakieś znaczenie :)
W wyniku przemyśleń doszliśmy do pewnego schematu nazewniczego, ponieważ proces ten przebiegał w długim okresie to nadal można spotkać pełne spektrum "na wolności".
schemat podstawowy wygląda tak:
mgNazwaGminy_data.adr
na początku umieszczamy wyróżnik rodzaju gminy
- g - gmina wiejska
- mg - gmina miejsko-wiejska
- m - gmina miejska lub miasto na prawach powiatu (czyli po prostu miasto)
Potem nazwa gminy (a w paru miejscach dodajemy też nazwę powiatu) pisaną bez spacji.
Zwykle za nazwą gminy umieszczamy datę w formie rok-miesiąc (o np tak 2016-01), jednak w tym członie zachodziły największe zmiany.
Dla danych pozyskiwanych bezpośrednio od gmin wpisujemy rok-miesiąc.
Dla kilku miast gdzie można pobrać dane samodzielnie, używamy pełnej daty tj (2016-01-01)
Dla danych udostępnianych przez codgik używaliśmy kolejno: PRG1, PRG2 potem zmieniliśmy na PRG14C gdzie 14 to końcówka roku a C to kolejna literka nadawana przy pobraniu danych (doszliśmy do 15U). Ten schemat uchował się do końca roku 2015. Od początku 2016 r. używamy 2 zapisów: PRG16A gdzie literka oznacza kolejny miesiąc (dla danych wymagających dużej pracy ręcznej) oraz PRG16 bez literki dla czystych danych które można często uaktualniać.
Od niedawna (IX 2016) używamy również zapisu 2016i dla danych udostępnionych przez gminy w iMPA (literka "i" jest stała). Te same dane, ale starsze, powinny być też w PRG - ale wolimy świeże.
Można też spotkać pliki ADR-Obszar.adr to jest miejsce na własnoręcznie wstawione punkty. Acz lepiej postarać się o te gminne, niźli wstawiać je tu seryjnie. I ten jako jedyny można edytować do woli (proszę o nie mikro-przesuwanie).
EntryPoint
Ciekawa funkcja umożliwiająca wskazanie właściwego miejsca zjazdu z ulicy do danego punktu adresowego, bez konieczności zmiany oryginalnej lokalizacji punktu. Korzystamy z niej przełączając ME w tryb Navitel (File -> map properties > zakładka Header > Type set). Następnie klikając na punkcie prawym klawiszem myszy (w trybie select) > add entrypoint i wskazujemy punkt wejścia, przez ponowne kliknięcie. Opcja ma zastosowanie w kilku sytuacjach:
- gdy działki są pod kątem do drogi i najkrótsza droga do budynków dalej położonych wypada nie tam gdzie trzeba (prostopadle do drogi zamiast skośnie), dodanie EP w ok. początku drogi dojazdowej rozwiązuje problem
- na wioskach, które mają domki rozrzucone gdzie bądź i do tych domków prowadzą już drogi prywatne (których raczej nie ma sensu rysować)
- pomieszanie numerów dla kilku budynków, które można by ewentualnie rozwiązać narysowaniem małej alejki bocznej ale EP również bardzo dobrze się sprawdzi
- w pobliżu punktu są dwie drogi i algorytm kończy trasę na tej niewłaściwej.
Ten ostatni powód dobrze obrazuje przykład z Chwałkówka. Kilka punktów adresowych leży tam między S5 a alejką. Algorytm routingowy pierwotnie kończył trasę na S5 co nie powinno mieć miejsca. Wstawienie EP w pobliżu alejki zmieniło sytuację o 180°.
Historia
Na początku 2014 r. wpadliśmy (Ar't i Wojtek) na pomysł by pozyskiwać z urzędów punkty adresowe, po małych perturbacjach dorobiliśmy się dość uniwersalnego konwertera danych (o ile dane dają się w jakiś sposób parsować i nie są tajnymi blobami binarnymi) używanego do dziś.
Do zespołu "adresowego" dość aktywnie włączył się jeszcze Alf. Parę osób nam pomaga od czasu do czasu.
Pewnego dnia (2014-07-10) codgik zrobił niespodziankę, udostępnił dane z własnych zasobów (acz warto wspomnieć że był zmuszony do tego wyrokiem sądu). I wszystko było by fajnie gdyby nie jakość tych danych, która wahała się od dobrej do bardzo złej (z przewagą tych ostatnich). Ale to nie koniec, dane te są udostępnione wg podziału administracyjnego na poziomie województw, a to oznacza plik XML dla mazowieckiego wielkości powyżej 2GB inne mniej ale w granicach 1GB, dodatkowo struktura wewnętrzna potrzebuje skakać po całym pliku by go jakość sensownie przetworzyć. Stąd decyzja podziału na gminy pozwalająca to powoli ogarniać. Pomimo dostępnych danych, sporo gmin warto nadal odpytywać, gdyż zwykle dostajemy wtedy dane lepsze/poprawione (zdarzają się być poprawiane na nasze wskazanie).
I tak to się kręci.
