Prośby o zmapowanie/poprawę

jeśli coś ma być budowane to prawdopodobnie jest że tam gdzie będzie droga będzie jeszcze pole …

A, bo to chodzi o drogę planowaną… nie doczytałem. Mnie nie bawi wprowadzanie planowanych dróg. Ja lubię wprowadzać drogi, które są przynajmniej budowane.

Też uważam że planowane drogi to bezsens. Nie odzwierciedlają stanu faktycznego, są nanoszone na oko, przez jakieś błędy mogą stanowić elementy routingu czy renderu. Często w miejscu gdzie jest planowana droga są obecne jeszcze budynki, pola, inne drogi które kiedyś ulegną usunięciu, ale obecnie są czynne.
Co innego jak są już budowane, bo można je przejść, przejechać rowerem czy zrobić zdjęcie lotnicze, nanieść przyzwoicie i odzwierciedlają stan faktyczny “budowy”.

+1
Sens ma nanoszenie gdy wiemy juz cos konkretnie, jak serekmedia pisze…

Dzięki chłopaki. Niech ciemny lud pozostanie ciemny. Po co zaczynać dyskusję przed zatwierdzeniem planów. Przecież można zastawiać kopary jak już jest “po ptokach” Highway=proposed to bardzo potrzebny tag, chyba, że nie interesuje was społeczeństwo obywatelskie. Prędzej czy później ludzie zaczną korzystać z osm i czerpać stąd wiedzę choćby o hajłeju za miedzą.

Hejki tjabek,
dla mnie problem polega na tym, ze wiekszosc ludzi “wierzy” w dokladnosc map rysowanych wektorowo wiec nie majac w miare dokladnych informacji wprowadzamy “ciemny lud” w blad.
Moze byc to o tyle niebezpieczne jesli rysujemy cos zgrubnie nie majac dokladnej informacji, ze np. ktos uzywajacy map OSM uwierzy w zamieszczona informacje o przebiegu drogi co moze np. wplynac na jego decyzje o kupnie/sprzedazy jakiejs nieruchomosci. Nie pisze tu o zawodowych deweloperach lecz wlasnie o “ludzie ciemnym”.
Wprowadzal bym wiec na mape nie informacje o hipotetcznych planach bedacych w dyskusji lecz o zatwierdzonych planach o dobrze znanym przebiegu. Taka informacja jest jak najbardziej potrzeba i po to ten tagging wprowadzono.

Nikt nie mówi tutaj o nienanoszeniu planowanych dróg, tylko raczej chodzi o dokładność. Naniesienie drogi z dokładnością “ona będzie biegła gdzieś między Kozią Wólką a Wygwizdowem” niesie żadne korzyści dla zwykłego kowalskiego, bo zwykly kowalski chciałby wiedzieć najczęściej czy droga będzie biegła przez jego działkę lub w jej pobliżu, a taka mapa rysowana na oko mu tej informacji nie da. Mało tego, taki Kowalski może zobaczyć jakąś drogę planowaną narysowaną przez swoje podwórko, narobi krzyku i OSM okaże się mało wiarygodne. Zwykły kowalski nie wie jak działa OSM.

Reasumując - możemy nanosić wszystko, byle na podstawie sprawdzonych źródeł, dokładnie i dobrze otagowane.
(a nie jak np. kolega wczoraj: http://www.openstreetmap.org/way/250475506/history)

http://umapa.pl/KjBA5
Most w Toruniu do korekty

Hmm,
czy to nie jest mapa przyjaciól z UMP?

Zwróć uwagę na pojazd, to “samochód OSM” czyli routing po danych OSM wyświetlony akurat na podkładzie UMP. Trochę mylące.

Ok, dzieki.

Niestety nie bylem od roku w tym miejscu. Musi ktos miejscowy sprawdzic jak to jest w rzeczywistosci…

Hej!

Jest problem z Node: Wyźrał (31899913). Jego wartość is_in nie odpowiada rzeczywistości
jest gmina Brzeźnica, powiat wadowicki,
ma być gmina Liszki, powiat Kraków ziemski (czy jak on tam się nazywa).

Teoretycznie może być takich kwiatków więcej. Można by jakiegoś skrypta puścić do sprawdzenia,
czy is_in jest wewnątrz dobrego boundary?
Czy ten konkretny przypadek mogę sobie sam wklepać?

Tomek

tagi is_in* są przestarzałe, w związku z czym po prostu je usuń i problem z głowy.

Co do sprawdzania automatem czy te tagi są poprawne - wątpię czy jest sens tworzenia takowego. Ja bym je po prostu wywalił, bo takich błędów też już spotkałem kilka.

Co można zrobić z zestawem zmian 19232936 (widok w History Viewer)?

Wprowadzone błędy to co najmniej przesunięcie ul. Lotniczej, którą jakiś czas temu poprawiałem - zestaw 18834619, oraz “rykoszetem” zepsucie geometrii DK16 na skrzyżowaniu Lotniczej z Sielską (DK16).

Wysłałem 7-go grudnia prośbę do autora (wiadomość via openstreetmap.org) o używanie skalibrowanego podkładu (Geoportalu lub skalibrowanego Binga), oraz dodawanie komentarzy do własnych edycji - pokazując jako przykład przesunięcie ul. Lotniczej wprowadzone w tym changesecie. Dotychczas bez odpowiedzi ani poprawki, natomiast dwóch innych edycji od tego czasu dokonał - jest to bardzo aktywny użytkownik w okolicach Olsztyna. Nie spotkałem w tej okolicy nikogo innego wykonującego tyle pracy dla OSM, szkoda gdy trochę się ona marnuje ze względu na wprowadzane błędy.

Problem z mojego punktu widzenia jest taki, że changeset ten wprowadza znacznie więcej zmian, które mogą nawet być poprawne (choć zapewne również przesunięte - spodziewam się, że ich geometria pochodzi z tego samego nieskalibrowanego Binga). Czyli ewentualne cofanie całego changesetu raczej nie ma sensu i lepiej ręcznie poprawić to, co na pewno zostało w nim zepsute?

Za samo używanie Potlacza bym zrewertował. I za niedodanie opisu zmian.

A na poważnie - można zrobić w ten sposób, że ładujesz ten obszar do JOSM, wyłapujesz szukałką węzły zmodyfikowane przez usera truszek (type:node user:truszek) i przeciągasz je we właściwe miejsce.
Jeśli naprawienie tego wymagałoby więcej pracy niż sposób przedstawiony wyżej to ja bym zrewertował bez rozczulania się - niech się user uczy na błędach.

Prosiłbym o poprawienie tych dwóch relacji.

http://www.openstreetmap.org/relation/1757750
http://www.openstreetmap.org/relation/1757620

A ja proszę o poprawę turn restriction w Krakowie
Taka nawrotka jest możliwa tylko na rondzie.

http://osrm.at/62C
Tomek

To lepiej w osrm poprawić - patrz https://github.com/DennisOSRM/Project-OSRM/issues/859 i https://github.com/DennisOSRM/Project-OSRM/issues/860

Najprościej to dociągnąć te kilkaset metrów dwiema nitkami w pobliże ronda Grunwaldzkiego. Wiem wiem, nie mapujemy pod render :-). Tak naprawdę moim zdaniem most powinien mieć z definicji wbudowaną restrykcję zawracania. Efekt jest taki, że ten żenujący bug jest na dość newralgicznej trasie z lotniska w okolice Rynku.

A tak właściwie - czemu na południe od skrzyżowania są dwie nitki przez te kilka metrów? Z tego co pamiętam nie ma tam fizycznego rozdzielenia pasów. Zmiana na poprawną jedną nitkę też by to rozwiązała.