OSMonitor (raporty z danych OSM)

Paweł Paprota · 2012-08-28 13:17:15

Po wielu przygodach udało się w końcu ponownie odpalić raporty. Wszystko oczywiście dzięki uprzejmości SunCobalta, który zaprosił mnie na swój serwer

W tej chwili raporty dla Polski są generowane co 2 godziny od 8:00 do 24:00.

W najbliższej przyszłości mam w planie rozwiązać porządnie wszelkie problemy związane z dziwnymi "końcówkami" dróg (lub z ich brakiem - rondo w relacji etc). Na razie jest trochę dróg, które mają niepoprawny raport np.:

http://suncobalt.dyndns.org:8080/browse/road/RS/M1

Na to chwilowo nie ma lekarstwa, tzn. nie należy próbować zmieniać danych aby raport był zielony. Będzie zielony w kolejnej wersji

tomith · 2012-08-28 19:23:14

Ways: all (194), with ref tag (177), in relation (194)

Czy wszystkie odcinki należące do relacji powinny mieć ref czy wystarczy, że są w relacji?
Jeśli jest ważne aby jedno z drugim było zgodne, to przydatna by była warstwa z odcinkami w relacji ale bez ref.

Paweł Paprota · 2012-08-31 12:05:35

tomith wrote:

Ways: all (194), with ref tag (177), in relation (194)
Czy wszystkie odcinki należące do relacji powinny mieć ref czy wystarczy, że są w relacji?
Jeśli jest ważne aby jedno z drugim było zgodne, to przydatna by była warstwa z odcinkami w relacji ale bez ref.

W raporcie wyświetlane jest to tylko informacyjnie. Czy powinno być tak jak piszesz? Nie wiem... W przypadku, który podajesz prawie 20 segmentów nie ma "ref". Co z tego wynika? Właściwie chyba tylko (albo aż?) tyle, że niektóre renderery nie domyślą się po relacji, że trzeba te segmenty oznaczyć numerem drogi.

Przy okazji: raporty dla Polski się nie odświeżają, bo jest bug, będzie poprawiony jakoś w weekend.

wajak · 2012-09-03 13:26:22

Ponownie jest jakaś awaria odświeżania raportów?

Paweł Paprota · 2012-09-03 14:43:01

Thomas (SunCobalt) wyłączył raporty na jakiś czas, bo robi jakąś konserwację baz danych.

Paweł Paprota · 2012-09-04 15:36:46

Raporty znowu ruszyły. Replikacja jest teraz co minutę, raporty co 2 godziny (8:00-24:00). Dodałem też guzik "refresh report" na widoku drogi - można w ten sposób wygenerować świeży raport dla konkretnej drogi (całościowy raport na wiki nie jest aktualizowany po naciśnięciu tego przycisku).

marek kleciak · 2012-09-04 16:16:11

Pawle tak nawiasem raz jeszcze: Swietna i pomocna praca, wielkie dzieki!!
Marek

wajak · 2012-09-06 10:45:46

Można prosić o pomoc, jak poprawić drogę:
http://suncobalt.dyndns.org:8080/browse … ache=false

Zbigniew Czernik · 2012-09-06 10:50:00

Tam chyba jest wszystko dobrze, podejrzewam, że OSMonitor ma opóźnienie.

Paweł Paprota · 2012-09-06 11:22:02

Dziś mam zamiar odpalić kolejną wersję ze zmienionym trochę sposobem obliczania długości i przejezdności. Powinno to rozwiązać trochę dziwnych problemów z niektórymi raportami. Co ciekawe, DW786 nie jest jest poprawnie raportowana nawet w tej nowej wersji, ale poprawię to zanim zrobię aktualizację - nie musisz edytować tej drogi, wręcz przeciwnie - dla mnie to ciekawy test case

wajak · 2012-09-06 11:33:52

To podeślę jeszcze kolejny przypadek do testów. Dla mnie to WTF, ale może to nie błąd OSMonitora, a rzeczywiście jest coś nie tak z tą drogą
http://suncobalt.dyndns.org:8080/browse … ache=false

Paweł Paprota · 2012-09-06 12:10:02

Ta droga (DW768) jest zielona.

marco406 · 2012-09-06 12:13:55

DW768 poprawiałem wczoraj tj. 05.09.2012 i jest juz OK.

Paweł Paprota · 2012-09-08 16:09:09

Przez następne kilka(naście) godzin będzie przerwa w dostawie raportów - na serwerze importuje się cała Europa.

Poza tym w ramach przygotowania OSMonitora na wieloraportowość pracuję nad raportem tras rowerowych (bo jest "tylko" wariantem raportu drogowego). Czesi mają ładną stronę:

http://wiki.openstreetmap.org/wiki/Cyklotrasy_v_%C4%8CR

Na początek odpalę więc raport dla czeskich tras, a później to będzie tylko kwestia przygotowania danych dla Polski (i innych krajów), chociaż widziałem, że u nas nie ma raczej spójnego i powszechnego systemu numeracji dróg rowerowych...

Paweł Paprota · 2012-09-09 21:16:43

Wyłączyłem właśnie web aplikację OSMonitor. Raporty (na wiki i web aplikacja) powrócą kiedy zaimportuje się Europa. Z nowości będą:

* Nowy interfejs użytkownika dla web aplikacji - miejmy nadzieję bardziej przyjazny...
* Raport dróg rowerowych (na razie tylko Czechy)

W najbliższej przyszłości (4-6 tygodni) mam zamiar zrobić następujące rzeczy:

* Bardziej przyjazna dokumentacja - w szczególności żeby ludzie mogli odpalać własne raporty bez mojego udziału.
* Raport regresji (czyli powiadomienia na forum/ML/IRC/whatever, że ktoś coś popsuł).
* Raport administracyjny (na razie dla Polski - na podstawie TERYT i może częściowo Wikipedii).

Paweł Paprota · 2012-09-14 16:18:46

Raporty wróciły do życia. Raporty drogowe będą odświeżane co 2 godziny.

Nowy raport administracyjny co godzinę (wpół do każdej godziny):

https://wiki.openstreetmap.org/wiki/OSM … nistrative

rogal · 2012-09-14 17:19:57

super . Mam tylko uwagę - przy miastach na prawach powiatu raportuje błędny admin_level (że jest 8 a powinno być 6). Finalnie przyjęliśmy że taka granica ma 2 relacje - i 8 i 6 - czy tego typu komunikat oznacza, że brakuje relacji z level 6 czy jest to błąd w logice oprogramowania? Jeżeli jest to po prostu brak relacji to można by zmienić komunikat, żeby przypadkiem ktoś admin_level=8 nie zamienił na admin_level=6 tylko wiedział, że trzeba stworzyć nową relację .

Mam jeszcze prośbę o sprawdzanie czy linie typu boundary=administrative nie mają czasem tagu admin_level, albo name - wszystko powinno być jedynie w relacjach, a w bazie różne kwiatki się trafiają i mapnik pokazuje głupoty.

Last edited by rogal (2012-09-14 17:24:42)

Paweł Paprota · 2012-09-14 17:29:04

rogal wrote:

super . Mam tylko uwagę - przy miastach na prawach powiatu raportuje błędny admin_level (że jest 8 a powinno być 6). Finalnie przyjęliśmy że taka granica ma 2 relacje - i 8 i 6 - czy tego typu komunikat oznacza, że brakuje relacji z level 6 czy jest to błąd w logice oprogramowania? Jeżeli jest to po prostu brak relacji to można by zmienić komunikat, żeby przypadkiem ktoś admin_level=8 nie zamienił na admin_level=6 tylko wiedział, że trzeba stworzyć nową relację .

Zależy od przypadku, ale na pewno jest błąd w OSMonitor. W tej chwili szukam albo po teryt:terc albo nazwa musi się zgadzać. Tam gdzie relacje z 6 i 8 mają tę samą nazwę, obie relacje są znajdowane i źle wyświetla. Poprawię to.

rogal wrote:

Mam jeszcze prośbę o sprawdzanie czy linie typu boundary=administrative nie mają czasem tagu admin_level, albo name - wszystko powinno być jedynie w relacjach, a w bazie różne kwiatki się trafiają i mapnik pokazuje głupoty.

OK, dodam do TODO.

Dotevo · 2012-09-14 17:33:31

Wydaje mi się, że akurat tag name nie jest błędem.

Paweł Paprota · 2012-09-14 17:39:53

rogal wrote:

super . Mam tylko uwagę - przy miastach na prawach powiatu raportuje błędny admin_level (że jest 8 a powinno być 6). Finalnie przyjęliśmy że taka granica ma 2 relacje - i 8 i 6 - czy tego typu komunikat oznacza, że brakuje relacji z level 6 czy jest to błąd w logice oprogramowania? Jeżeli jest to po prostu brak relacji to można by zmienić komunikat, żeby przypadkiem ktoś admin_level=8 nie zamienił na admin_level=6 tylko wiedział, że trzeba stworzyć nową relację .

Poprawiłem - niektóre pozycje się zazieleniły a niektóre zaczerwieniły. Jeśli możesz to sprawdź czy jest OK i krzycz jeśli ciągle coś nie tak.

rogal · 2012-09-14 21:01:14

Super - wielkie dzięki

Dotevo - tutaj można akurat się spierać . Jeżeli jakiś fragment jest jednocześnie granicą powiatu i gminy, to jaki tag name= powinien mieć? . Zwłaszcza, że u nas w większości była niezła samowolka - np. województwa miały na swoim styku tag name="Województwo 1/Województwo 2" (do teraz jakieś szczątki tam są). O ile pamiętam wyświetlane nazwy są automatycznie generowane z relacji i rozdzielane slashem.

Paweł Paprota · 2012-09-14 21:43:34

Siłą rozpędu chciałbym niedługo dodać powiadomienia o zmianach w raportach, a później trochę zwolnić z rozwojem nowej funkcjonalności w OSMonitor i skupić się na drobniejszych ulepszeniach, bugfixach, dokumentacji i innych tematach w OSM...

Kilka pytań do Was co do powiadomień:

* Jakie zmiany w raporcie powinny powodować wysłanie powiadomienia? Coś poza przejściem z zielonego na nie-zielony (i z powrotem)?
* W jakiej formie wysyłane powinny być powiadomienia? Lista mailingowa/forum/IRC?
* Jak często? Dla każdej zmiany czy zbiorczo?

Takie powiadomienia się chyba przydadzą, bo np. przed chwilą ktoś z Francji popsuł relację "Polska", przypadkiem to zauważyłem odświeżając raport

Zbigniew Czernik · 2012-09-14 21:47:48

Paweł Paprota wrote:

1. Jakie zmiany w raporcie powinny powodować wysłanie powiadomienia? Coś poza przejściem z zielonego na nie-zielony (i z powrotem)?
2. W jakiej formie wysyłane powinny być powiadomienia? Lista mailingowa/forum/IRC?
3. Jak często? Dla każdej zmiany czy zbiorczo?

1. Przejście z zielonego na niezielony. W drugą stronę niekoniecznie.
2. Na listę.
3. Zbiorczo, raz na dobę, w nocy. Dlaczego nie po każdym odświeżeniu? Bo może się zdarzyć, że ktoś popsuje, ale zaraz naprawi - szkoda się angażować daremnie (i generować konflikty edycyjne).

Paweł Paprota · 2012-09-14 22:41:07

rogal wrote:

Mam jeszcze prośbę o sprawdzanie czy linie typu boundary=administrative nie mają czasem tagu admin_level, albo name - wszystko powinno być jedynie w relacjach, a w bazie różne kwiatki się trafiają i mapnik pokazuje głupoty.

Dodałem to i wychodzi na to, że tych dróg jest cała masa...

https://wiki.openstreetmap.org/wiki/Use … estOutput2

Jajcuś · 2012-09-14 23:01:44

rogal wrote:

Mam jeszcze prośbę o sprawdzanie czy linie typu boundary=administrative nie mają czasem tagu admin_level, albo name - wszystko powinno być jedynie w relacjach, a w bazie różne kwiatki się trafiają i mapnik pokazuje głupoty.

Name IMHO rzeczywiście jest złe (co, wymieniać wszystkie województwa, powiaty i gminy których fragment dotyczy?), ale boundary=administrative plus _odpowiedni_ admin_level bym zostawił, jak już argumentowałem w tym, czy innym wątku.

boundary=administrative bez odpowiedniego admin_level może być źle renderowane jeśli będzie renderowane, a linia bez żadnego tagu związanego z jej przeznaczeniem jest zbyt podatna na przypadkowe usunięcie.

Announcement

#226 2012-08-28 13:17:15

Re: OSMonitor (raporty z danych OSM)

#227 2012-08-28 19:23:14

Re: OSMonitor (raporty z danych OSM)

#228 2012-08-31 12:05:35

Re: OSMonitor (raporty z danych OSM)

#229 2012-09-03 13:26:22

Re: OSMonitor (raporty z danych OSM)

#230 2012-09-03 14:43:01

Re: OSMonitor (raporty z danych OSM)

#231 2012-09-04 15:36:46

Re: OSMonitor (raporty z danych OSM)

#232 2012-09-04 16:16:11

Re: OSMonitor (raporty z danych OSM)

#233 2012-09-06 10:45:46

Re: OSMonitor (raporty z danych OSM)

#234 2012-09-06 10:50:00

Re: OSMonitor (raporty z danych OSM)

#235 2012-09-06 11:22:02

Re: OSMonitor (raporty z danych OSM)

#236 2012-09-06 11:33:52

Re: OSMonitor (raporty z danych OSM)

#237 2012-09-06 12:10:02

Re: OSMonitor (raporty z danych OSM)

#238 2012-09-06 12:13:55

Re: OSMonitor (raporty z danych OSM)

#239 2012-09-08 16:09:09

Re: OSMonitor (raporty z danych OSM)

#240 2012-09-09 21:16:43

Re: OSMonitor (raporty z danych OSM)

#241 2012-09-14 16:18:46

Re: OSMonitor (raporty z danych OSM)

#242 2012-09-14 17:19:57

Re: OSMonitor (raporty z danych OSM)

#243 2012-09-14 17:29:04

Re: OSMonitor (raporty z danych OSM)

#244 2012-09-14 17:33:31

Re: OSMonitor (raporty z danych OSM)

#245 2012-09-14 17:39:53

Re: OSMonitor (raporty z danych OSM)

#246 2012-09-14 21:01:14

Re: OSMonitor (raporty z danych OSM)

#247 2012-09-14 21:43:34

Re: OSMonitor (raporty z danych OSM)

#248 2012-09-14 21:47:48

Re: OSMonitor (raporty z danych OSM)

#249 2012-09-14 22:41:07

Re: OSMonitor (raporty z danych OSM)

#250 2012-09-14 23:01:44

Re: OSMonitor (raporty z danych OSM)

Board footer