Automatyczna numeracja

Z UMP

Wersja z dnia 16:36, 19 gru 2016

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.

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 sugeruje rysować ciut gęściej, szczególnie w okolicach zabudowań.

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 > ...). Sugeruje jednak częste zapisywanie.

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

w pliku Numbers_PL.7z:

• Numbers_PL.mp - do popatrzenia jak sobie radzi program
• 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).

osobno:

• 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)

FAQ

• Co z numeracją liniową, już wprowadzoną ręcznie?

Przewiduje 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 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 nie mał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.

Jak poprawić jasno-zielone?

do uzupełnienia

Jasno zielone 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, zdarzają się 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łownie 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. Klikajc na punkcie prawym 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", po przez 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 wstawianie wejść są wsie które mają domki rozrzucone gdzie bądź i do tych domków prowadza już drogi prywatne (których raczej nie ma sensu rysować), a algorytm albo z powodu ograniczenia (500m) całkowicie 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