Automatyczna numeracja

Z UMP

(Różnice między wersjami)
d (→FAQ)
(jak poprawić)
Linia 78: Linia 78:
Na inne pomysły i formy uciszania jestem otwarty.
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 sposobu.
== Jak poprawić jasno-zielone? ==
== Jak poprawić jasno-zielone? ==
do uzupełnienia
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 [[Adresacja|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*)
 +
* 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)
 +
 +
 +
* tu warto wspomnieć że program potrafi sobie w pewnych przypadkach poradzić z dziwactwami, jednak jest w większości bardzo zachowawczy.

Wersja z dnia 21:17, 8 paź 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.

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

  • 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 sposobu.

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


* tu warto wspomnieć że program potrafi sobie w pewnych przypadkach poradzić z dziwactwami, jednak jest w większości bardzo zachowawczy.
Źródło: "http://ump.fuw.edu.pl/wiki/Automatyczna_numeracja"