OSMonitor (raporty z danych OSM)

przemas75 · 2012-08-06 20:56:37

Ja myślałem o czymś takim jak Niemcy mają:
droga A-H via C-E to jedna relacja
droga A-H via D-G to następna relacja

Razem dwie, czy widzisz jeszcze inne? C-E i D-G to oneway, więc nie można inaczej pojechać.
Czy Ty dla jednej drogi typu A-H widziałbyś jedną relację po prostu?

Last edited by przemas75 (2012-08-06 20:57:18)

Paweł Paprota · 2012-08-06 21:01:26

Owszem, to co piszesz działa, ale takich miejsc są setki albo i tysiące. Czy dla drogi, która w 99% jest jednojezdniowa a gdzieśtam się rozdwaja na pewno chcemy robić dwie relacje?

Ja bym się zastanowił czy nie chcemy po prostu zostać przy obecnym rozwiązaniu. Można by nawet próbować zostawić role backward/forward tak jak są, bo chyba nie są używane dla relacji "route=road".

przemas75 · 2012-08-06 21:07:32

Paweł Paprota wrote:

Ja bym się zastanowił czy nie chcemy po prostu zostać przy obecnym rozwiązaniu. Można by nawet próbować zostawić role backward/forward tak jak są, bo chyba nie są używane dla relacji "route=road".

ha!
Właśnie, w związku z wprowadzeniem nowego typu opisu komunikacji publicznej, to gdzie ma zastosowanie forward/backward?
Przypomnienie tych ról:
if a route should only be followed in one direction for some or all of its length, the "role" can indicate this for some or all of the constituent ways. "forward" means the route follows this way only in the direction of the way and "backward" means the route runs only against the direction of the way. Rendered on the cycle map

Jeśli traktujemy drogę A-H jako jedną logikę, wtedy według mnie forward/backward ma tutaj jak najbardziej zastosowanie. To jakby spojrzenie na forward/backward stosowany w osm kiedyś w transporcie publicznym, ale ze strony zwykłego ruchu samochodowego przecież.

Jednak pisałeś, że chciałbyś również stworzyć tool znajdujący zastosowanie nie tylko w Polsce. Namów Niemców do przeroobienia ich relacji na "naszą modłę".

marek kleciak · 2012-08-06 21:13:56

Namów Niemców do przerobienia ich relacji na "naszą modłę".

Jesli beda rzeczowe argumenty, czemu nie. Projekt ciagle sie rozwija.
Jednakze podyskutowal bym z nimi czemu przyjelo sie tam takie rozwiazanie a nie inne.
Byc moze jest to po prostu zwyczajowe a byc moze sa ku temu jakies inne argumenty.

Paweł Paprota · 2012-08-06 21:18:54

Te dwa rozwiązania się nie wykluczają. Jeśli są osobne relacje dla nitek to jest jeszcze łatwiej, bo można przyjąć, że np. wszystkie segmenty z relacji positive mają rolę forward, wszystkie z relacji negative mają backward i sprowadzamy sytuację do naszego schematu. Z punktu widzenia technicznego nie ma problemu z obsługą obu schematów. Oczywiście fajnie by to było ujednolicić, ale może nie rzucajmy się z motyką na słońce...

Dobra, to jeśli nikt nie ma nic przeciwko (kendzi?) to ja na razie zostawiam implementację raportów tak jak jest, czyli w oparciu o role backward/forward. Plus jest taki, że łatwo to zaimplementować i są duże korzyści - weryfikacja długości sporo daje, a to byłoby trudno zrobić bez ról...

kendzi · 2012-08-06 21:25:04

Naprawdę nie rozumiem co jest złego w wykorzystywaniu kolejności segmentów w relacji. Jeśli walidator będzie narzekać ze coś z nią jest nie tak to na pewno ktoś kiedyś poprawi.

Obecnie jest bałagan z kolejnością bo po prostu nie było takiego fajnego walidatora jak OSMonitor

Paweł Paprota wrote:

Myślę o takiej sytuacji:
/C------E\
A---B G----------H
\D------F/

To prosty przypadek odcinek AB jest dwukierunkowy odcinki CE i DE jedno więc prosto wykryć ze jest to punk rozdzielenia drogi. Teraz przemieszczając się od punktu B dowolna drogą jednokierunkową trzeba tylko znaleźć najbliższy punkt połączenia G (wchodzą do niego 2 jednokierunkowe drogi wychodzi jedna dwukierunkowa) i dopasować nitki jednokierunkowe pomiędzy tymi punktami B i G.

marek kleciak · 2012-08-06 21:26:23

Oczywiście fajnie by to było ujednolicić, ale może nie rzucajmy się z motyką na słońce...

Pawle,
koledzy zza miedzy chetnie sluchaja rzeczowej argumentacji. juz wielokrotnie ich przekonywalem do róznych rozwiazan a prace np. Kendziego, Marimila i paru innych kolegów (sorry do wszystkich których nie wymieniam!) spowodowala, ze jestesmy postrzegani jako równorzedni partnerzy którzy maja jedynie problem z utrata danych.
Namawiam Cie do podjecia dyskusji na forum niemieckim. Gdyby co bedzie na mnie

Last edited by marek kleciak (2012-08-06 21:26:49)

Dotevo · 2012-08-06 21:35:46

Paweł Paprota wrote:

Najlepsze rozwiązanie to by było wprowadzenie ról np. positive/negative żeby nie nadużywać backward/forward, reszta zostaje tak samo i tyle....

Popieram. Jedyny problem to możliwość podpięcia tylko jednej roli. Jak dla mnie obecne forward/backward z wiki ma malo sensu. Jeszcze do głowy przychodzi mi jeden problem. Załóżmy, że autobus ma trasę drogami dwukierunkowymi, a w każdą stronę jednak inną trasę. Pytanie. Jak w relacji opisać, który kierunek jest który.

Paweł Paprota · 2012-08-06 21:41:36

Jutro spróbuję powalczyć jeszcze z implementacją bez ról i bez kolejności (kolejność de facto niewiele ułatwia implementację).

Dotevo wrote:

Paweł Paprota wrote:
Najlepsze rozwiązanie to by było wprowadzenie ról np. positive/negative żeby nie nadużywać backward/forward, reszta zostaje tak samo i tyle....
Popieram. Jedyny problem to możliwość podpięcia tylko jednej roli. Jak dla mnie obecne forward/backward z wiki ma malo sensu. Jeszcze do głowy przychodzi mi jeden problem. Załóżmy, że autobus ma trasę drogami dwukierunkowymi, a w każdą stronę jednak inną trasę. Pytanie. Jak w relacji opisać, który kierunek jest który.

Z tego co zrozumiałem z wiki public transport to dla każdego kierunku mają osobną relację.

serekmedia · 2012-08-06 23:38:16

Dla potrzeb osmonitora to ja bym w relacji każdą drogę dwukierunkową liczył podwójnie, jednokierunkową pojedynczo, a dwukierunkową z forward albo backward też pojedynczo - dostajemy sumę przejazdu w tą i nazad - dzielimy na pół i mamy długość drogi, średnią - wystarczającą do monitorowania. Dotyczy to autostrad również - są jednokierunkowe. Ustawianie f/b na jednokierunkowej to pomyłka i nadmiar informacji - nie da się jechać pod prąd. Kolejność w relacji to dla mnie nadmiar informacji poukładanie kolejności to zadanie dla narzędzia, nie edytora, który ma po prostu określić z jakich odcinków się składa droga. Wspólne nody układanki w końcu wskazują jak relacja wygląda.

Dotevo · 2012-08-07 06:30:45

serekmedia wrote:

Kolejność w relacji to dla mnie nadmiar informacji poukładanie kolejności to zadanie dla narzędzia, nie edytora, który ma po prostu określić z jakich odcinków się składa droga.

W JOSM jest sortowanie relacji i zazwyczaj działa.

przemas75 · 2012-08-07 08:16:00

Poszukałem jakie są relacje dla dróg zwykłych w Niemczech, autostrady to jednak zupełnie inny przypadek.
http://www.openstreetmap.org/browse/relation/60421
Stosują tam kolejność segmentów, nie ma ról.

Mi osobiście chyba najbardziej podoba się rozwiązanie dotychczasowe z rolami backward/forward. Oczywiście póki co, trochę sprzeczne jest to z opisem na wiki.
Ale myślę, że nie ma jakiegoś problemu, żeby zrobić proposal i zmienić lub poszerzyć ten opis. Zwłaszcza w kontekście innego opisu komunikacji publicznej.
Napisałem o tym przekonywaniu Niemców do zmian relacji, myślę że dobrym argumentem byłoby to, że z rolami (tak jak teraz my mamy) jest dużo łatwiej diagnozować i tworzyć relacje dróg.

Wprowadzenie positive/negative to właściwie dublowanie forward/backward...

marek kleciak · 2012-08-07 08:24:07

Napisałem o tym przekonywaniu Niemców do zmian relacji

Czesc Przemas75,
gdzie napisales? Na ich forum?

przemas75 · 2012-08-07 08:54:39

Powyżej, we wcześniejszym poście

przemas75 wrote:

Namów Niemców do przeroobienia ich relacji na "naszą modłę".

marek kleciak · 2012-08-07 09:15:38

przemas75,
móglbys w takim razie zrobic taki "alternatywny" proposal po angielsku rozszerzajac istniejacy opis tak,
by na przykladach pokazac dlaczego to rozwiazanie jest lepsze w stosunku do istniejacego?

przemas75 · 2012-08-07 09:25:08

Dojdźmy może najpierw na własnym podwórku do jakiegoś konsensusu.
Póki co, zdania są lekko podzielone.

Dotevo · 2012-08-07 09:47:12

Domyślam się, że łatwiej będzie przeforsować pomysł typu główna relacja z dwoma członkami relacjami (z rolą positive/negative). Wtedy każda nitka leci osobno w osobnej relacji. Dlaczego łatwiej? Ponieważ nie narusza obecnej struktury mapowania przez Niemców. Wtedy aby policzyć długość trzeba wziąć członków wspólnych z tych dwóch relacji oraz unikalnych podzielonych przez 2.

Paweł Paprota · 2012-08-07 10:06:01

Dodawanie ról to żmudna praca, która de facto ma ułatwić rzeczy techniczne (rozpoznanie nitek, wyliczanie długości). O ile mi się to podoba, bo bardzo ułatwia implementację to w tym przypadku rozumiem argumenty typu "nie mapujmy pod narzędzia". Bo w sumie jaką wartość dodają te role? Lepiej może spędzić czas na konkretnym mapowaniu / sprawdzaniu dróg niż dodawaniu ról. Takie argumenty mają sens i dlatego sprawdzę dzisiaj kilka różnych heurystyk (np. tę co opisał Dotevo wyżej - prosta, ale może wystarczająca?) żeby zobaczyć na ile raporty się "popsują" (szczególnie weryfikacja długości) bez brania pod uwagę ról.

serekmedia · 2012-08-07 11:07:03

Ale jak to nie mapować pod narzędzia? To po co nam ta mapa? Mamy za dużo HDD
Wizualizacja, geodekodowanie, nawigacja itd to chyba cel. Relacja daje optymalny dostęp do drogi i zachowanie jej spójności - a sieć drogowa na poziomie DK, DW i podział adm to naturalny "szkielet" mapy.
Bez relacji da się żyć, w końcu można wybrać z roads wszystkie kawałki ref=447 i sobie je poskładać - ale to niestety jest zasobochłonne - lepiej ten szkielet mieć na wyciągnięcie ręki.

marek kleciak · 2012-08-07 11:14:08

Mnie jest zawsze trudno dyskutowac nic nie mówiac bo pracuje zawodowo w systemach nawigacji, jednak moge b. ogólnie powiedziec ze tam prawie nic sie bez relacji nie robi.
Mysle ze dla OSM trzeba jakis zloty srodek znalezc.

Dotevo · 2012-08-07 11:19:46

serekmedia wrote:

Relacja daje optymalny dostęp do drogi i zachowanie jej spójności - a sieć drogowa na poziomie DK, DW i podział adm to naturalny "szkielet" mapy.

Raczej kiepski argument, ponieważ to może zrobić automat, a nie człowiek. Myślę, że relacje mają pomagać nam, a nie narzędziom np. zmienia się numer drogi to zmieniamy tylko jedną rzecz.

Zbigniew Czernik · 2012-08-07 15:48:04

Dotevo wrote:

Raczej kiepski argument, ponieważ to może zrobić automat, a nie człowiek.

A nie wydaje Ci się, że automatowi będzie łatwiej operować na relacjach zamiast zgadywać na podstawie czegośtam?

rogal · 2012-08-07 15:52:55

nie zapominajmy, że za automatem i tak stoją ludzie którzy muszą go w rozsądny sposób zaprogramować

Paweł Paprota · 2012-08-07 19:42:24

Nie wygląda to nawet tak źle bez ról... Jeśli przyjmiemy założenie, że droga jest z A do B, czyli może mieć co najwyżej 4 końcówki (bo dwujezdniowa) to jest OK. Z drugiej strony jest taki potwór jak DK81:

http://www.openstreetmap.org/browse/relation/418927

To jest z kolei droga z A do A... kończy się zawracaniem. To powinien być chyba błąd w mapowaniu... A w ogóle najlepiej to jakby były jakieś tagi na oznaczenie początku i końca drogi (czyli pierwszy i ostatni segment dostają jakiś tag). Pomysły?

Paweł Paprota · 2012-08-07 22:01:08

Już zaczyna wychodzić mi, że to była dobra decyzja żeby nie polegać na rolach. "Przy okazji" dopisałem sprawdzanie przejezdności drogi, bo mi było "po drodze" i wyszedł ciekawy kwiatek na pierwszej lepszej drodze z brzegu:

http://www.openstreetmap.org/?lat=49.80 … 8&layers=M

Taki sobie mostek "pod prąd"... nawigacje na tym pewnie padają.

Jako, że mostek już poprawiony, link do drogi, która była zepsuta: http://www.openstreetmap.org/browse/way/172028438

Announcement

#126 2012-08-06 20:56:37

Re: OSMonitor (raporty z danych OSM)

#127 2012-08-06 21:01:26

Re: OSMonitor (raporty z danych OSM)

#128 2012-08-06 21:07:32

Re: OSMonitor (raporty z danych OSM)

#129 2012-08-06 21:13:56

Re: OSMonitor (raporty z danych OSM)

#130 2012-08-06 21:18:54

Re: OSMonitor (raporty z danych OSM)

#131 2012-08-06 21:25:04

Re: OSMonitor (raporty z danych OSM)

#132 2012-08-06 21:26:23

Re: OSMonitor (raporty z danych OSM)

#133 2012-08-06 21:35:46

Re: OSMonitor (raporty z danych OSM)

#134 2012-08-06 21:41:36

Re: OSMonitor (raporty z danych OSM)

#135 2012-08-06 23:38:16

Re: OSMonitor (raporty z danych OSM)

#136 2012-08-07 06:30:45

Re: OSMonitor (raporty z danych OSM)

#137 2012-08-07 08:16:00

Re: OSMonitor (raporty z danych OSM)

#138 2012-08-07 08:24:07

Re: OSMonitor (raporty z danych OSM)

#139 2012-08-07 08:54:39

Re: OSMonitor (raporty z danych OSM)

#140 2012-08-07 09:15:38

Re: OSMonitor (raporty z danych OSM)

#141 2012-08-07 09:25:08

Re: OSMonitor (raporty z danych OSM)

#142 2012-08-07 09:47:12

Re: OSMonitor (raporty z danych OSM)

#143 2012-08-07 10:06:01

Re: OSMonitor (raporty z danych OSM)

#144 2012-08-07 11:07:03

Re: OSMonitor (raporty z danych OSM)

#145 2012-08-07 11:14:08

Re: OSMonitor (raporty z danych OSM)

#146 2012-08-07 11:19:46

Re: OSMonitor (raporty z danych OSM)

#147 2012-08-07 15:48:04

Re: OSMonitor (raporty z danych OSM)

#148 2012-08-07 15:52:55

Re: OSMonitor (raporty z danych OSM)

#149 2012-08-07 19:42:24

Re: OSMonitor (raporty z danych OSM)

#150 2012-08-07 22:01:08

Re: OSMonitor (raporty z danych OSM)

Board footer