OSMonitor (raporty z danych OSM)

rogal · 2012-08-17 14:55:01

hmm...a nie prościej tworzyć na początku i końcu problematycznych dróg punktu z jakimś custom tagiem?

Paweł Paprota · 2012-08-17 15:12:40

Dodawanie takich tagów to by był kolejny narzut na mappera tylko po to żeby raport naprawić - raczej unikałbym. Mam kilka pomysłów jak to zwalczyć, najlepiej by było uświadomić topologicznie/geograficznie OSMonitor, ale nie mam czasu chwilowo nad tym siedzieć.

Najważniejsze, żeby ludzie sprawdzali te drogi, bo naprawdę większość ma inne/większe problemy niż kończenie się na rondzie.

przemas75 · 2012-08-17 15:22:40

jak często będzie bot sprawdzał?

przemas75 · 2012-08-17 15:25:26

acha, co w końcu z maxspeed? bo mignęła mi dyskusja, ustaliliście?

serekmedia · 2012-08-17 15:28:29

Tak, mapa jest zasadniczo za wysoka, powinna być pozycjonowana względem top: bottom: lesf: right: IMO w tego typu stronie. Po za tym jest ekstra, następny poziom analizy - to co Panowie i Panie? Zazieleniamy?

Paweł Paprota · 2012-08-17 15:31:02

przemas75 wrote:

jak często będzie bot sprawdzał?

Na wiki jak do tej pory - co 30 minut. Planuję dodać guzik "odśwież raport" (taki jak w Relation Analyzer jest) na ekranie mapy, który na żądanie odświeży raport dla wybranej drogi.

marimil · 2012-08-17 15:31:15

przemas75 wrote:

acha, co w końcu z maxspeed? bo mignęła mi dyskusja, ustaliliście?

Dyskusja była na IRC Biorę się za tłumaczenie wiki.

Dla wyjaśnienia - w raporcie występuje taka pozycja. Chcąc uniknąć nadmiarowej pracy staramy się ustalić pewne wytyczne.

Paweł Paprota · 2012-08-17 15:35:15

marimil wrote:

przemas75 wrote:
acha, co w końcu z maxspeed? bo mignęła mi dyskusja, ustaliliście?
Dyskusja była na IRC Biorę się za tłumaczenie wiki.
Dla wyjaśnienia - w raporcie występuje taka pozycja. Chcąc uniknąć nadmiarowej pracy staramy się ustalić pewne wytyczne.

Myślę, że dobrze by było stworzyć osobny wątek na ten temat (analogicznie do granic administracyjnych) z dyskusją. Jak będą już wnioski to odpowiednio zmodyfikuję bota.

serekmedia wrote:

Tak, mapa jest zasadniczo za wysoka, powinna być pozycjonowana względem top: bottom: lesf: right: IMO w tego typu stronie. Po za tym jest ekstra, następny poziom analizy - to co Panowie i Panie? Zazieleniamy?

Mapa jest "za wysoka"? Masz na myśli CSS?

serekmedia · 2012-08-17 16:07:59

Tak style css, okno wymaga przewijania góra dół, a w nim mapa góra dół, trochę nie wygodne. Ja mam 900px w pionie i tak niestety mam. Pewnie na fullhd się mieści

Paweł Paprota · 2012-08-17 16:18:34

Trochę pomieszałem w CSS - może teraz jest lepiej.

tomith · 2012-08-18 18:51:28

Proszę o podpowiedź jak naprawić DW925 - relacja wygląda w porządku, OSMonitor pokazuje że droga nie nawigowalna tutaj:
http://osm.org/go/0Lc9Pxr9H--

Last edited by tomith (2012-08-18 18:59:38)

ajank · 2012-08-18 20:40:04

tomith wrote:

Proszę o podpowiedź jak naprawić DW925 - relacja wygląda w porządku, OSMonitor pokazuje że droga nie nawigowalna tutaj:
http://osm.org/go/0Lc9Pxr9H--

Krótki dwukierunkowy kawałek miał ustawione oneway=yes: http://www.openstreetmap.org/browse/way … 91/history -- już poprawiłem.

Ja mam natomiast inny kłopot. OSMonitor zgłasza problem z DK30, ponieważ... gdzieś w lesie w Katowicach-Murckach znajduje się droga leśna z ref=30: http://www.openstreetmap.org/browse/way/36243005. Ta droga leśna oczywiście nie należy do relacji DK30, no ale ma ten sam ref... Pytanie, co z tym zrobić? Z jednej strony mamy drogi wojewódzkie highway=track, z drugiej zaś drogi leśne miewają oficjalne numery (np. droga pożarowa nr ...), które warto gromadzić. Jakieś pomysły?

Paweł Paprota · 2012-08-18 21:00:29

Moim zdaniem jeśli ten tag "ref=30" jest uzasadniony (np. tym, że to jest droga pożarowa) to powinno to być jakoś ujęte w danych - nie wiem czy jest coś takiego jak fireway albo relacje dla dróg pożarowych, ale w tej chwili nie ma możliwości rozpoznania, że to nie jest DK30.

Wszystkich segmentów highway=track nie mogę zignorować, bo tak jak zauważyłeś są one czasem częścią oficjalnych dróg (chociaż wg mnie to powinno chyba być highway=secondary/tertiary i surface=cośtam a nie highway=track, bo track to dla mnie jakaś niezidentyfikowana ścieżka w lesie).

Paul167 · 2012-08-19 10:36:01

Paweł Paprota wrote:

Moim zdaniem jeśli ten tag "ref=30" jest uzasadniony (np. tym, że to jest droga pożarowa) to powinno to być jakoś ujęte w danych - nie wiem czy jest coś takiego jak fireway albo relacje dla dróg pożarowych, ale w tej chwili nie ma możliwości rozpoznania, że to nie jest DK30.

To jest numer oznakowanej drogi pożarowej. Informacja moim zdaniem przydatna, szczególnie jeśli ktoś zgubi się w lesie . Nie jestem tylko pewien w jaki sposób tagować te informacje, nie znalazłem żadnych oficjalnych wytycznych na ten temat.

marek kleciak · 2012-08-19 11:37:32

Skoro nie ma wytycznach na ten temat, trzeba spytac strazaków i na tej podstawi wymyslic oznaczanie bo wydaje sie byc pomocne - w ogóle przydala by sie pewna kompatybilnosc z tym, jak strazacy oznaczaja. Po drugie spytac na formach miedzynarodowych. Byc moze koledzy zza miedzy cos maja na ten temat- mozna by wtedy spolonizowac schemat ( jesli istnieje).

Polimerek · 2012-08-19 13:15:49

Można by pewnie zagadać do ludzi z zespołu ds. Leśnej Mapy Numerycznej.... Może nawet jakaś współpraca by się nawiązała w zakresie mapowania lasów? Może np. chociaż by się zgodzili zaimportować do OSM obrysy granic lasów państwowych?

http://www.lmn.lasy.gov.pl/55

ajank · 2012-08-19 15:06:50

Koło Koszalina znalazłem tagowanie w rodzaju name=Droga pożarowa 06 + ref=P-06: http://www.openstreetmap.org/browse/way/37689277. Myślę, że warto dorzucić jeszcze emergency=designated, wtedy mamy już w miarę kompletny opis sytuacji. Te drogi pożarowe w Katowicach tak właśnie przerobię.

wajak · 2012-08-19 17:21:49

Znalazłem mały problem/błąd na przykładzie DW703. Pokazuje, że relacja ma dwa kawałki. W rzeczywistości nie ma, ale jeden odcinek jest w remoncie (highway=construction). ten odcinek jest dołączony do relacji co czyni ją kompletną. OSMonitor właśnie robi problem z powodu tej drogi.

Przy okazji może to być pomysł na udoskonalenie raportu i dodanie informacji, czy jakieś odcinki mają highway=construction, pozwoli to wychwytywać niepozakańczane remonty w OSM.

Paweł Paprota · 2012-08-19 17:34:04

wajak wrote:

Znalazłem mały problem/błąd na przykładzie DW703. Pokazuje, że relacja ma dwa kawałki. W rzeczywistości nie ma, ale jeden odcinek jest w remoncie (highway=construction). ten odcinek jest dołączony do relacji co czyni ją kompletną. OSMonitor właśnie robi problem z powodu tej drogi.
Przy okazji może to być pomysł na udoskonalenie raportu i dodanie informacji, czy jakieś odcinki mają highway=construction, pozwoli to wychwytywać niepozakańczane remonty w OSM.

Ignorowanie highway=construction jest celowe - jeśli globalnie brać je pod uwagę to wychodzą cuda na kiju z autostradami/DK. Jeśli to jest remont a nie budowa to myslę, że powinno być to jakoś inaczej tagowane może, żeby rozróżnić.

wajak · 2012-08-19 17:50:19

Paweł Paprota wrote:

wajak wrote:
Znalazłem mały problem/błąd na przykładzie DW703. Pokazuje, że relacja ma dwa kawałki. W rzeczywistości nie ma, ale jeden odcinek jest w remoncie (highway=construction). ten odcinek jest dołączony do relacji co czyni ją kompletną. OSMonitor właśnie robi problem z powodu tej drogi.
Przy okazji może to być pomysł na udoskonalenie raportu i dodanie informacji, czy jakieś odcinki mają highway=construction, pozwoli to wychwytywać niepozakańczane remonty w OSM.
Ignorowanie highway=construction jest celowe - jeśli globalnie brać je pod uwagę to wychodzą cuda na kiju z autostradami/DK. Jeśli to jest remont a nie budowa to myslę, że powinno być to jakoś inaczej tagowane może, żeby rozróżnić.

Hmm, ale taka jest przyjęta konwencja, że drogi zamknięte z powodu remontu oznaczamy jako construction. Taka zmiana nie przejdzie, za powszechnie to już jest stosowane.

Paweł Paprota · 2012-08-19 18:23:34

Jasne, nie ma sensu tego zmieniać, ale coś trzeba ustalić. Sytuacja jest taka:

1. W tej chwili segmenty z highway=construction i construction=cokolwiek są ignorowane.
2. W poprzedniej wersji były brane pod uwagę, ale moim zdaniem powoduje to więcej zamieszania niż pożytku + informacje o długości są średnio dokładne dla dróg w budowie.
3. Jak zauważył wajak - (1) powoduje, że raporty zgłaszają błąd dla remontowanych segmentów.

Ja widzę dwa rozwiązania:

a. Zostaje tak jak jest i na czas remontu należy ustawić osmonitor:road_components=2 żeby zazielenić raport - po zakończeniu remontu ten raport się zaczerwieni jeśli ktoś zapomni skorygować osmonitor:road_components a tylko zmieni tag highway.

b. Przywracamy ignorowanie, ale są jakieś założenia, np. jeśli highway=construction to remont to musi być jakiś dodatkowy tag (from/to). Ewentualnie można by rozpoznawać po tym, że jest tylko highway=construction a nie ma tagu construction - tylko nie wiem czy wszystkie drogi w budowie mają construction=cośtam.

Opinie?

ajank · 2012-08-19 18:30:21

A może OSMonitor powinien działać następująco: segmenty z highway=construction i construction=cokolwiek są ignorowane, chyba że znajdują się w odpowiedniej relacji?

Last edited by ajank (2012-08-19 19:50:53)

serekmedia · 2012-08-19 18:31:00

Sądzę - było to wygodne, to taka droga musi widnieć jako uszkodzona, nie ważne czy przez nieciągłość czy przez cokolwiek innego. Ktoś kto się nią opiekuje wpisze sobie w note: rozpięta z powodu remontu mostu w Ostrowie - remont się skończy droga się zazieleni.
Co do opieki nad drogami - tak myślę aby 10 osób się wzięło i podzieliło DW po 2 osoby na 200 dróg do obecnego rekonstruowania i późniejszego monitorowania ich stanu. Ja obecnie robiłem 4xx - są już albo na zielono, albo wyjaśnione w note w większości, zamierzam zrobić 5xx w ten sam sposób. Kto bierze resztę?
Podobnie, ale myślę że ze 3-4 osoby do A,S,DK tego jest mniej ale tu raczej doświadczonych mapowiczów bym widział.
Dzięki temu ten stan dróg będzie można szybko ustalić, naprawić, a te 200 dróg po paru tygodniach to się będzie znało na pamięć.
Co Wy na to?

Paweł Paprota · 2012-08-19 18:55:44

serekmedia wrote:

Co do opieki nad drogami - tak myślę aby 10 osób się wzięło i podzieliło DW po 2 osoby na 200 dróg do obecnego rekonstruowania i późniejszego monitorowania ich stanu. Ja obecnie robiłem 4xx - są już albo na zielono, albo wyjaśnione w note w większości, zamierzam zrobić 5xx w ten sam sposób. Kto bierze resztę?
Podobnie, ale myślę że ze 3-4 osoby do A,S,DK tego jest mniej ale tu raczej doświadczonych mapowiczów bym widział.
Dzięki temu ten stan dróg będzie można szybko ustalić, naprawić, a te 200 dróg po paru tygodniach to się będzie znało na pamięć.
Co Wy na to?

Myślę, że to jest super pomysł - najlepiej zrobić na wiki stronę z przydziałem. Jak tylko uda się na nowym serwerze zaimportować Europę/świat to planuję odpalić kilka nowych krajów (większych i mniejszych - jak ktoś ma życzenia dotyczące konkretnych krajów to piszcie), zrobić im strony na wiki tak jak my mamy i opisać/pokazać jak to w Polsce funkcjonuje. Taka strona z opiekunami dróg byłaby wskazówką dla innych i pokazaniem, jak można efektywnie wykorzystywać raporty. Można tę stronę nawet dodać do tego paska nawigacji między osmonitorowymi stronami żeby było widoczne i łatwo dostępne.

Czy się przyjmie to nie wiem, wydaje mi się, że Polska ma najbardziej aktywnych mapperów - ale może któryś kraj będzie zainteresowany raportami tak jak my/Wy

wajak · 2012-08-19 19:00:58

serekmedia wrote:

Sądzę - było to wygodne, to taka droga musi widnieć jako uszkodzona, nie ważne czy przez nieciągłość czy przez cokolwiek innego. Ktoś kto się nią opiekuje wpisze sobie w note: rozpięta z powodu remontu mostu w Ostrowie - remont się skończy droga się zazieleni.

Remont drogi może wprowadzić ktoś inny niż opiekujący się drogą. Tak jak pisałem uważam, że remont powinien być widoczny, ale w taki sposób, żeby było jasne, że problemem jest tylko construction.

serekmedia wrote:

Co do opieki nad drogami - tak myślę aby 10 osób się wzięło i podzieliło DW po 2 osoby na 200 dróg do obecnego rekonstruowania i późniejszego monitorowania ich stanu. Ja obecnie robiłem 4xx - są już albo na zielono, albo wyjaśnione w note w większości, zamierzam zrobić 5xx w ten sam sposób. Kto bierze resztę?
Podobnie, ale myślę że ze 3-4 osoby do A,S,DK tego jest mniej ale tu raczej doświadczonych mapowiczów bym widział.
Dzięki temu ten stan dróg będzie można szybko ustalić, naprawić, a te 200 dróg po paru tygodniach to się będzie znało na pamięć.
Co Wy na to?

Pomysł jest dobry. Ja się bardziej przyglądam DW7xx, ale ostatnio brak mi czasu na mapowanie i regularną kontrolę, więc nie mam takich wyników jak Ty

Announcement

#176 2012-08-17 14:55:01

Re: OSMonitor (raporty z danych OSM)

#177 2012-08-17 15:12:40

Re: OSMonitor (raporty z danych OSM)

#178 2012-08-17 15:22:40

Re: OSMonitor (raporty z danych OSM)

#179 2012-08-17 15:25:26

Re: OSMonitor (raporty z danych OSM)

#180 2012-08-17 15:28:29

Re: OSMonitor (raporty z danych OSM)

#181 2012-08-17 15:31:02

Re: OSMonitor (raporty z danych OSM)

#182 2012-08-17 15:31:15

Re: OSMonitor (raporty z danych OSM)

#183 2012-08-17 15:35:15

Re: OSMonitor (raporty z danych OSM)

#184 2012-08-17 16:07:59

Re: OSMonitor (raporty z danych OSM)

#185 2012-08-17 16:18:34

Re: OSMonitor (raporty z danych OSM)

#186 2012-08-18 18:51:28

Re: OSMonitor (raporty z danych OSM)

#187 2012-08-18 20:40:04

Re: OSMonitor (raporty z danych OSM)

#188 2012-08-18 21:00:29

Re: OSMonitor (raporty z danych OSM)

#189 2012-08-19 10:36:01

Re: OSMonitor (raporty z danych OSM)

#190 2012-08-19 11:37:32

Re: OSMonitor (raporty z danych OSM)

#191 2012-08-19 13:15:49

Re: OSMonitor (raporty z danych OSM)

#192 2012-08-19 15:06:50

Re: OSMonitor (raporty z danych OSM)

#193 2012-08-19 17:21:49

Re: OSMonitor (raporty z danych OSM)

#194 2012-08-19 17:34:04

Re: OSMonitor (raporty z danych OSM)

#195 2012-08-19 17:50:19

Re: OSMonitor (raporty z danych OSM)

#196 2012-08-19 18:23:34

Re: OSMonitor (raporty z danych OSM)

#197 2012-08-19 18:30:21

Re: OSMonitor (raporty z danych OSM)

#198 2012-08-19 18:31:00

Re: OSMonitor (raporty z danych OSM)

#199 2012-08-19 18:55:44

Re: OSMonitor (raporty z danych OSM)

#200 2012-08-19 19:00:58

Re: OSMonitor (raporty z danych OSM)

Board footer