Automatyczna numeracja
Z UMP
Z adresówek potrafimy generować numeracje dla garminków. Na razie w formie osobnej nakładki. Jednak program jest dość wymagający, by zechciał się pochylić nad naszymi danymi. :D
Dlatego też wypluwa dość dużo błędów, potocznie zwanymi grzebykami czy też wachlarzykami, a sam program dorobił się miana grzebienica.
Spis treści |
Istotne uwagi
Bardzo proszę nie kopiować wyniku działania tego programu do naszych danych, na ten czas przewiduję że będzie to generowane przy każdej kompilacji.
- Wsie i wachlarzyki najlepiej poprawić poprzez wstawienie wpisu Miasto, ale bez Label, do najbliższej drogi przy wskazywanych poi.
- Czasem w adresach dostajemy punkty planowane, można albo zignorować, można też zrobić odcinek planowany z Miasto i nazwą ulicy (jak zwykle).
- Nie przesadzać z dzieleniem dróg wyższego rzędu
- Najlepiej dzielić drogi tylko na istniejących skrzyżowaniach, chyba że nie da się inaczej.
- Autostrady i eSki najlepiej nie ruszać i zostawić je bez miasta.
- Przyjąć do wiadomości że czasem adresówki mają błędy.
- Nowe drogi na wsi sugeruję rysować ciut gęściej, szczególnie w okolicach zabudowań.
- Unikać (jeśli się da, zwykle niestety nie) zapisów Miasto=pierwsze@drugie, dla dróg na granicach wsi, ale też lepiej wpisać Miasto=wieś1@wieś2, niż zrobić nakładkę dwóch linii!
Generalnie nic na siłę.
Warto też wpisywać Miasto dla dróg we wsi. Tu przypomnę ułatwienie, jakie ma ostatni ME2 można nim ustawiać extrasy dla selekcji obiektów (zaznaczasz kilka z altem, potem prawy myszy > Modify> extras > ...). Sugeruję jednak częste zapisywanie. Można też zaznaczyć kilka obiektów, a potem prawy myszy > Modify > Postal Address > City i wybrać z listy.
Aktualizacja raz na tydzień (po kompilacji 7ways), linki bez zmian.
Nie ma możliwości (w tej chwili) na podział na obszary.
By były te błędy widoczne, to muszą być wyświetlane bookmarki (view > show bookmark and notes).
Na liście dev będą publikowane statystyki, wraz z przypomnieniem do linków (te się raczej nie zmieniają).
Znaczenie plików
w pliku EntryPoints_PL.7z:
- bad_entrypoint_all.mp - poi i adr powyżej 500m
- mid_entrypoint_all.mp - poi i adr pomiędzy 200-500m
- bad_entrypoint_poi.mp - tylko poi powyżej 200m
- POI-ADR-dist.mp - brudno-zielone linie dla poi, które są dalej niż 200m od najbliższego punktu adresowego z tym adresem (proszę o dokładne sprawdzenie, gdyż tu zdarzają się dziwności)
- ADR-samotne.mp - czerwone kółeczka, wskazujące zasięg punktów bezpańskich (tj brakuje linii z takimi danymi adresowymi, zwykle wsie). Uwaga sposób wyznaczania tych pętelek jest na mocno uproszczonej zasadzie z punktów tworzących coś w rodzaju litery C zrobi O; a kształty podobne literom Z,N,M zamieni na prostokąty.
- Numbers_PL_ignored.mp - zielone wskazują segmenty drogi oraz adresy z których nie udało się wyliczyć jakieś sensownej regularności (sposoby poprawy «jeszcze nie» opisane poniżej).
- Numbers_PL_lost.mp - grube zielone wskazują punkty adresowe pominięte (np jeden nr w grupie kilkunastu, przeszkadza utworzyć normalną numeracje)
w pliku Numbers_PL.7z:
- Numbers_PL.mp - do popatrzenia jak sobie radzi program
osobno dla wygody, acz to te same dane co wyżej:
FAQ
- Co z numeracją liniową, już wprowadzoną ręcznie?
Przewiduję dla trybu "wzbogacania", że linie mające już numerację liniową nie będą w żaden sposób poprawiane. Natomiast w trybie generowania podkładki program korzysta tylko z danych punktowych (by pokazać jak sobie radzi).
- Czy kolory cyan/magenta mają jakieś znaczenie? Inne kolory?
- Te 2 kolory wskazują stronę drogi dla adresówek pominiętych w generacji adresów liniowych, ale mających choć jeden wpis miasto/ulica w liniach.
- Zielony to adresy, z których nie można przetworzyć na adresy liniowe
- Brudno-zielony używany jest dla POI, które są daleko (200m) od punktu adresowego.
- Czemu nie wpisywać label dla wsi?
>> IMHO jednak z Label=, jeśli po zamontowaniu mapy z danymi ADR widać, że wzdłuż ulicy/drogi jest numeracja typu "Wieś 1", "Wieś 15a" itd.,
> na www i w innych navi to słabo wygląda, dla garmina będzie się generować samo wg potrzeb, wystarczy wpis Miasto
tu dodatkowe wyjaśnienie
koledzy zauważają, że może lepiej by dawać wpisy w Label dla wsi (jak to kiedyś tam ustaliliśmy) ja się tu z nimi nie zgadzam, gdyż traci się niepotrzebnie czas na wprowadzanie tego labela, a i tak program sobie to miasto dorobi jak mu będzie potrzebne. W dodatku taki gąszcz takich samych labeli wprowadza zbędny szum (na www).
- False positives w poi, czyli alarmuje, a jest dobrze. Co z tym?
No niestety, też takie się zdarzają (200m albo 500m to czasem za mało). Czasami dalekie przypisanie jest prawidłowe, nawet w mieście (przykład z realu: kampus uczelni, mamy punkt wydziału X który jest w głębi, jest alarm).
Częściowym rozwiązaniem może być wskazanie wejścia tzw. EntryPoint, przez wstawienie w komentarzu
;EntryPoint: (52.00000,20.00000)
(w plikach pnt/adr to będzie ";;EntryPoint: (...)")
Jednak nie zawsze się to sprawdza (bywają POI, gdzie wejście jest od innej ulicy niż sam adres).
Uwaga, kilka naszych nawigacji korzysta z tych danych i tam będzie kierować przy wybraniu takiego punktu docelowego.
Pozostaje jeszcze dość oczywisty sposób, czyli nazwany chodniczek, ale bardzo proszę nie nadużywać tego, bo cierpi na tym czytelność mapy.
Na inne pomysły i formy uciszania jestem otwarty.
- Pomijanie po przekroczeniu 200m. Nie za dużo to? Nie za mało?
Nie ma jednej dobrej uniwersalnej granicy. Zdarzają się budynki powyżej tej odległości od drogi, i wcale niemało, jednak zaczyna być coraz więcej błędów z powodu braku dokładniejszego wyrysowania odnóżek. Z wstępnych prób wyszło że te 200m jest dość dobre, by przy nim zostać. Myślałem też nad adaptacyjnym ustawieniem tej granicy dla każdego segmentu, jednak są 2 dość spore ograniczenia, tj. czas przetwarzania oraz pewna niestabilność wyników, nie wspominając o pewnej trudności z raportowaniem błędów. Możliwe, że wrócę do tego pomysłu.
- Z czym nie "walczyć"? Ewentualnie jak to poprawić?
- Drogi na granicy: nie nazwane ulice wsi i nazwane ulice miejskie - w tej sytuacji wygrywa miasto - zazwyczaj.
- Budynki z adresami na "czubku" ulicy. Czasem pomaga lekkie przesuniecie skrzyżowania, albo dodanie noda przed by złapał jak najwięcej a resztę zignorował.
- Pojedyncze budynki daleko od drogi, szczególnie wiejskie. Jedyne sensowne rozwiązanie to dodanie EntryPoint, jeśli to za trudne to lepiej zignorować niż dorysowywać cokolwiek.
- Zabudowa łanowa (pacz 100-lat planowania na ssc) gdy działki są pod kątem do drogi, dla budynków dalej położonych najkrótsza "droga do drogi" wypada nie tam gdzie trzeba, zaburzając liniowość, chyba najczęstszy przypadek poddawania się programu (po za tym wiejskim random). Raczej dodawać EntryPoints-y, niźli coś innego. Czasem dla większej grupy budynków (o ile nie jest to przypadek, że każdy sobie ma dróżkę własną) warto coś narysować.
- Pomieszanie numerów dla kilku (zazwyczaj 3-5) budynków którą można by opędzić narysowaniem małej alejki bocznej (obecnej zresztą w rzeczywistości). Jeśli już to użyj adrLabel=Nazwa_ulicy bez niczego w Label. Lepiej jednak załatwić to (o znowu) EntryPoints-ami wskazując im to samo miejsce wjazdu (tj na tej drodze).
Jak poprawić jasno-zielone?
do uzupełnienia
Jasnozielone linie wskazują, że na danym odcinku ulicy (segmencie) program nie dał rady znaleźć żadnej regularności i się poddał. Najczęściej można mu pomóc dorysowując brakujące odnóżki dróg, przy nieregularnej numeracji wystarcza często dodanie pojedynczego punktu w środku (np. po lewej było 15, 16, potem 17 po prawej, a potem znów po lewej 18 i 19 - nie da się tego zaadresować jednym odcinkiem, ale po wstawnieniu punktu gdieś między 16/17 albo 17/18 już tak). Zdarzają się też błędnie zaadresowane (czy też umieszczone) POI, albo brak ulicy (i punkt załapał się błędnie gdzie indziej, a jeszcze nie wyleciał z powodu granicy 200m).
Warto przejrzeć artykuł o tworzeniu adresacji dla garmina gdyż wiele porad tam zawartych (odnośnie jak rysować i umieszczać węzły) jest przydatnych, by pomóc programowi w obróbce danych.
Przyjmując że drogi są poprawnie narysowane, to zostają praktycznie 2 opcje:
- dodanie nodów pomiędzy niezależnymi grupami nr (pamiętając że program potrzebuje pewnej regularności przyrostu, z wyjątkami [1])
- dodanie EntryPoints dla punktów, by wskazać prawidłowe wejście dla takich (dotyczy to głównie adr, gdyż większość POI mamy blisko danej ulicy)
[1] tu warto wspomnieć, że program potrafi sobie w pewnych przypadkach poradzić z dziwactwami, jednak jest w większości bardzo zachowawczy.
EntryPoints w adr
W tej chwili entrypoiny obsługuje monter pythonowy, wystarczy wtedy przełączyć się na tryb uniwersal/navitel (menu File / map properties > zakładka Header > Type set), by dość łatwo skorzystać z tej wbudowanej w ME funkcji. Klikając na punkcie prawym klawiszem myszy (w trybie select) > add entrypoint i wskazać punkt wejścia, przez ponowne klikniecie. W przypadku mont-demont.bat (beta) są pewne przymiarki, by nie trzeba się było przełączać, i będzie się to działo trochę "magicznie", poprzez przesunięcie punktu adresowego w miejsce wyjścia, a po demontażu ten punkt "wróci" na swoje pierwotne miejsce z dopisanym punktem wejścia.
Co i jak
Proszę pamiętać by entrypointów nie stawiać na drodze, ale obok niej (tak 5-10m, czasem można więcej).
Dobrym miejscem dla wstawiania wejść są wsie, które mają domki rozrzucone gdzie bądź i do tych domków prowadzą już drogi prywatne (których raczej nie ma sensu rysować), a algorytm albo z powodu ograniczenia (500m) całkowicie je zignorował, albo z powodu innej drogi przyciąga w złe miejsce.
Podobnie można działać w miastach dla pojedynczych przypadków przyciągnięcia do niewłaściwej drogi. EP sprawdzają się dla dalej odsuniętych domków, które z powodu drogi pod kątem do linii zabudowy źle się wpasowują i tworzą zakresy z zaburzoną kolejnością.
WiP
