Sorry ale ja to widzę tak. Typowe dla kolegi marafa bicie piany o nic i na siłę zmienianie byle tylko komuś pokazać, że należało by lepiej inaczej etc. Co to za różnica czy tag będzie zwał się ref czy unsigned_ref dla kompletności czy poprawności danych? No ale jednak musi być po marafowemu. Chłop może i dobrą robotę w wielu miejscach robi, ale uderzyła mu władza do głowy co nawet nie boi się powiedzieć http://imgur.com/a/suAGY. Ta przytoczona przez Ciebie dyskusja jak i wiele innych wątków, choćby o ochronie przyrody gdzie fakt pomógł, ale później na siłę wymyślał i upierał się przy jakiś dziwacznych tagach pokazuje że jak już ma jakąś wizję to żadna inna się nie liczy, gdyż musi być błędna.
Czy w takiej sytuacji się dziwicie, że są ludzie których to denerwuje? W przypadku rowersa akurat trafił na gościa, który jak on ma własną wizję i swoje argumenty i mamy gotową kłótnię dwóch gości z których żaden nie ustąpi 
Osobiście zmęczony jestem czytaniem tego do niczego nie prowadzącego wątku. Wejdę na niego ponownie jak w temacie zobaczę zmianę tytułu z przedrostkiem [rozwiązany].
Peace
Miałem napisać złośliwie, że:
… ale powstrzymałem się i po prostu życzę trochę dystansu do tego, co się czyta na forach i czatach. Z dalsza łatwiej dostrzec kontekst 
Nie wiem, na jakiej podstawie wysnułeś tak dziwny wniosek. Ja wypowiedź marafa zrozumiałem tak: “To my rządzimy OSM, a nie OSMF.”
No ale gdy się chce kogoś uderzyć, kij zawsze pod ręką.
Proponuję powrót do meritum, odjechaliśmy.
Wrócę do #55:
Z tego co rozumiem, to mamy tendencję by ten istniejący schemat rozszerzyć w tym sensie że:
-
Gdy ścieżka biegnie wzdłuż drogi, to rysujemy je osobno. Mamy coraz częstszy w użyciu kerb=yes a ten implikuje prawidłowe geometryczne położenie ścieżki rowerowej.
-
Jak najbardziej
-
Jak pokazuje praktyka w Niemczech używany jest schemat:
highway=cycleway (zamiast path)
bicycle=designated
foot=designated
segregated=yes
Jednak z powodu zastosowania a:h tam, gdzie a:h jest narysowane, dopuszczalne jest rysowanie dwóch równoległych nitek -
Może zostać jakkolwiek ten path jest bardzo niefortunny.
Proszę rozmawiajmy tylko i wyłącznie o punktach 1 do 4.
A to jest błędny przykład. https://wiki.openstreetmap.org/wiki/Proposed_features/shared_lane jest jeśli nie ma drogi dla rowerów a droga ma znak drogowy poziomy przypominający że może też być wykorzystana przez rowerzystów.
Jeśli ktoś chce używać tagu cycleway zamiast mapować drogę dla rowerów biegnącą wzdłuż drogi powinien użyć tagów według zasad opisanych na https://wiki.openstreetmap.org/wiki/Key:cycleway (tu chyba byłby cycleway=track)
Czasami proste zwrócenie uwagi na popełniane błędy w tagowaniu może zaskutkować odpowiedzią na 3 ekrany: http://www.openstreetmap.org/changeset/51968276
A błędnie otagowana linia od 2 miesiecy nadal jest niepoprawiona. Widać lepiej poświęcić czas na pisanie pustego tekstu, niż poprawienie błędu. Co kto lubi.
Chciałem sprawę załatwić “po bożemu”, najpierw zwracając uwagę personalnie - wysyłając prywatną wiadomość (21.07.2017). Niestety nie ma żadnej reakcji ze strony rowers2. Więc ponawiam swoją prośbę, tym razem publicznie. Cyt.
"Cześć.
Mogę Cię prosić o “posprzątanie” po imporcie obrysów budynków w Lesznie w w. wielkopolskim? Były tam wcześniej obrysy zrobione wg geoportalu, jednak one “zniknęły” i pojawiły się Twoje. Nie ma sprawy, jeśli są dokładniejsze, ale wraz z importem zostały one rozłączone, lub połączone tylko jednym punktem, mimo że powinny być scalone.
Tu jest przykład dwóch budynków, z których oprócz braku poprawnego połączenia kształt jednego również się nie zgadza.
Droga: 220044666 Zestaw danych: 532a3545 Edytowane: 2016-12-28T06:49:33Z Edytowane przez: rowers2 (2445224) Wersja: 6 W zestawie zmian: 44723147 Tagi: “addr:postcode”=“64-100” “building”=“residential” “source”=“geoportal2” “addr:country”=“PL” “addr:street”=“Bolesława Prusa” “addr:city”=“Leszno” “source:geometry”=“geoportal.gov.pl:BDOT” “addr:housenumber”=“2” Bounding box: 16.5915901, 51.833006, 16.5918046, 51.8331366 Bounding box (projected): 1846967.3613827191, 6769986.935974927, 1846991.239413494, 6770010.4624982355 Center of bounding box: 51.8330713, 16.5916974 Środek: 51.8330685, 16.5916956 10 węzłów: 4574470541 4574470540 4574470532 4574470533 4574470534 4574470525 4574470545 4574470546 4574470550 4574470541
Droga: 462021931 Zestaw danych: 532a3545 Edytowane: 2016-12-28T06:50:02Z Edytowane przez: rowers2 (2445224) Wersja: 3 W zestawie zmian: 44723147 Tagi: “building”=“residential” “source:geometry”=“geoportal.gov.pl:BDOT” Bounding box: 16.5916941, 51.8330873, 16.5918405, 51.8331655 Bounding box (projected): 1846978.9386097617, 6770001.581497881, 1846995.2357832133, 6770015.668606409 Center of bounding box: 51.8331264, 16.5917673 Środek: 51.8331269, 16.5917684 7 węzłów: 4574499937 4574499949 4574499936 4574470546 4574499928 4574499938 4574499937
W tej okolicy jest więcej takich budynków po imporcie, które nakładają się na siebie. Z tym narzędziem szybko wyłapiesz je w Lesznie→ http://osmose.openstreetmap.fr/pl/map/#zoom=15&lat=51.83703&lon=16.60313&layer=Mapnik&overlays=FFFFFFFFFFFFFFFFFFFFT&item=&level=1%2C2%2C3&tags=&fixable=
Liczę na wyrozumiałość i doprowadzenie importu do końca. Tym bardziej zależy mi na tym, bo zajęło mi dużo czasu wcześniejsze obrysowanie tych budynków.
Dziękuję i pozdrawiam. ntat"
Możemy różnić się w różnych kwestiach ale wszyscy pracujemy na wspólne dobro. Można popełniać błędy i pomyłki ale nawet początkujący maperzy, gdy zwróci im się uwagę, to poprawią/uzupełnią braki. W tym przypadku nie widzę żadnej reakcji. Zrobienie bałaganu i pozostawienie tego jest po prostu dewastacją.
A to nowa edycja? Podlinkujesz ją? Bo jeśli zgłaszano problemy, a wykonujący wadliwe importy nie reaguje na zgłoszenia to warto takie wadliwe edycje wycofać póki nie ma konfliktów
Mam na myśli posprzątanie po sobie, m.in. takich “baboli” → https://imgur.com/a/tgKeq - poszczególne części rozsunąłem, żeby pokazać w czym jest problem.
To jest generalnie częsty problem danych importowanych z innych systemów.
Przydała by się funkcja łącząca takie obrysy. Spotkaliście się z czymś takim w jakimś programie?
Co do takich importów: mam z tym naprawdę ogromny zgryz: Z jednej strony często są precyzyjniejsze i dzielą dłuższe budynki na segmenty a tego w przyszłości potrzebować będziemy do mappingu indoor. Z drugiej strony dane często potrafią nie odpowiadać rzeczywistości a podział jednego bloku mieszkalnego na segmenty straszliwie utrudnia mapowanie w 3D. Do tego dochodzi fakt, że nikt nie będzie chciał by plan jego mieszkania był ogólnodostępny w internecie więc indoor ograniczy się najprawdopodobniej do budynków publicznych gdzie to ma sens (znalezienie odpowiedniego pomieszczenia na uczelni, szpitalu, w urzędzie itd itp.
Dlatego uważam że takie importy można robić tylko wtedy, gdy się potem posprząta. I tego należy oczekiwać od każdej osoby która importu dokona.
Problem leży po stronie WMS’ów.
Nie ma standardu w Polsce w jaki sposób wykonać WMS z Geoportalu.
Każdy WMS, w zależności od regionu/miasta/powiaty jest inny.
Jedne są bardzo szczegółowe, cienkie linia obrysu i budynki podzielone.
Nawet widać obrys schodów lub balkonów.
Inne, mają bardzo grube linie, co powoduje, że po skopiowaniu obrys jest mniejszy niż stan rzeczywisty.
Inne znowu, mają obrys zewnętrzny kompleksu budynków połączonych.
Aplikacje takie jak Tracer2, po kliknięciu wewnątrz obrysu, kopiują obrys wewnętrzny.
Firmy tworzące WMS’y często zmieniają serwery na których te WMS’y są, lub linki do nich.
Albo zmieniają wygląd budynków na tych WMS’ach.
Pomijając budynki nowe/wyburzone, często budynki z z WMS’u nie pokrywają się z budynkami na zdjęciach lotniczych w Bing lub Geoportal2.
Może to być niechlujstwo osób tworzących WMS, złe pomiary lub przesunięcie obrazu na zdjęciach lotniczych.
Co jest bardziej prawdziwe? WMS czy obraz ze zdjęć lotniczych i jego rezolucja?
Jedynym, orientacyjnym, kryterium jest relacja obrysu budynku do drogi lub płotu.
Pozostaje jeszcze ręczne, jak to właśnie robię w Nepalu, orientacyjne, odrysowanie zarysu budynku ze zdjęć lotniczych.
Która z tych metod przedstawi dokładniejszy obrys budynku przy ziemi?
A co jak budynek jest na pochyłym terenie?
Jakie to ma konsekwencje jeśli róg budynku na OSM jest przesunięty 20 cm w stosunku do widoku ze zdjęć lotniczych?
Jak ma być dokładność w nanoszeniu punktów na OSM?
Stąd właśnie wynikają konflikty co do położenia lub kształtu budynku na OSM.
Czy ktoś z krytykujących zmierzył dokładnie położenie punktów należących do budynku w terenie i na podstawie tych pomiarów ma argument, że obrys na OSM jest zły?
OpenStreetMap informuje, że położenie punktów jest orientacyjne.
Dlatego, zanim zacznie się wylewać kubeł pomyj na czyjąś głowę, należy zastanowić się, czy warto przykładać tak dużą wagę do położenia obrysu budynku.
PS. Co do odwzorowanie w 3D, to i tak, praktycznie, tworzymy obrys od nowa, bazując na zdjęciach lotniczych i zdjęciach osobistych.
Podobnie niezgodności z węzłami z adresem. Obrys budynku sobie a węzeł poza budynkiem.
Władysławie, sugerujesz że niedoskonałości zewnętrznych źródeł (tutaj - błędy topologii) zwalniają z dążenia do dobrej jakości edycji.
Tak nie jest. Ciężar upewnienia się że wprowadzane dane są prawidłowe należy do osoby wykonującej edycje. Jeśli chcesz, może Ci to powiedzieć DWG. Naturalnie, że każdy robi błędy, ale jeśli robi masowe edycje i nie trzyma standardu, to będzie robił masowe błędy.
Tu siedzi też problem dotyczący filozofii mapowania. Znaleźliście sobie niszę w postaci masowego trasowania z BDOT. Wszystkie (przecież przyjazne lub co najmniej neutralne!) uwagi, które pokazują negatywne aspekty takiego mapowania są ignorowane lub redukowane do ataku. Nie przechodzi wam przez głowę, że coś mogłoby spowodować - dla dobra mapy - zaprzestanie przez was lub spowolnienie tej roboty
Załaduj sobie Starogard Gdański do edytora. Trasowałem tam 2 lata temu budynki z powiatowej ewidencji (WMS WebEWID). Nie jestem pewien ile mi to zajęło, bo robiłem kilkutygodniową przerwę, w sumie byłby to pewnie tydzień wieczornych sesji mapowania. Dla tylko 11 tysięcy budynków. Ale ja każdy budynek prostowałem, w razie niezgodności weryfikowałem na różnych ortofoto lub dorysowywałem z nich. Znalazłem też parę nieścisłości w adresach, pouzupełniałem landuse i drogi zakładowe.
Tym się różni nasze podejście. Osoby masowo trasujące z BDOT-u chcą byle najwięcej, najszybciej. A gdzie prostowanie obrysów, walidacja topologii i aktualności? Z racji tego, że skaczecie od miejsca do miejsca, nie macie nawet czasu wyrysować landuse (sprawdzałem w PostGIS-ie, kilkudziesięciokilometrowa smuga takich budynków na płd. Polski była wytrasowana przez Ciebie)
Oczekiwanym zachowaniem wobec wszystkich maperów jest, że po wskazaniu błędu wstrzymają się z mapowaniem, poprawią go i wyciągną wnioski, a nie zignorują tak jak to robił i robi rowers2.
Żadnego spisku nie ma, jest tylko buta rowersa. Gdyby sobie trasował, ale wolniej i poprawiał błędy, pewnie nie byłoby wobec niego obiekcji.
Konflikty rozlały się na całą Polskę. Może z tematu usunąć “we Wrocławiu”?
Jeśli jest zgoda, to nie ma problemu.
To bardziej ogólny temat więc nie widzę problemu.
Jak już zmieniamy to zmieńmy z “konflikty edycyjne we Wrocławiu” na “różnice zdań wynikłe z odmiennej interpretacji oraz konfliktowe edycje w kraju”. Wypowiedzi jak ta nie wyczerpują znamion konfliktów edycyjnych. Jak dla mnie ta sytuacja ma miejsce dopiero wówczas gdy jedna osoba zmieniła wartości drugiej (jak przykład od ntata). A w tym przypadku jedna coś edytowała, a druga wyraziła na ten temat jedynie opinie.
Jestem bardziej za skracaniem nazw tematów. Co sądzicie o nazwie “Konflikty” albo “Spory”? 
Wiadomo, że forum dotyczy wszystkiego, co jest związane z OSM i mapowaniem, wiec może nie trzeba uszczegóławiać.
PS
Wow, setny post! Jutro przyniosę cukierki 
Co masz zrobić jutro zrób dziś… 
Spory edycyjne powinno być ok, bo pozostałe pewnie należą do wątku o moderacji.
Nie ma znaczenia, co sobie postawił za punkt honoru, ważne co robi:
-
wywalenie tagów source:* bo “nikomu to niepotrzebne, a lista tagów na niektórych obiektach była tak długa, że trzeba ją przewijać, a to spowalnia edytowanie” - o ile mi wiadomo, dane te nie wróciły na miejsce.
-
Przesunięcie lasu o 100km i zostawienie tego tak, mimo uwagi do changesetu i dyskusji na forum - Cz ja naprawił OIDP
-
Programowe olewanie uwag do changesetów, podczas gdy to właśnie jest najlepsze miejsce do dyskutowania zmian w konkretnym changesecie.
Ja jestem jak najbardziej za używaniem wszelkich narzędzi do całkowitej lub częściowej automatyzacji poprawiania mapy i rozumiem, że przy tym pojawią się błędy - nie to mnie wzburza. Wzburza mnie niereagowanie na informację, że coś się zepsuło.
Tak że szacun dla rowersa za przemiał, ale jak się coś zepsuło, to trzeba to poprawić i zadbać, żeby błędu nie powtarzać, a nie ignorować wszelkie uwagi, lub uznawać je za ataki.
Chętnie zobaczył bym statystyki ilość błędów vs poprawne edycje. Idę o zakład że błędy są primo nie zamierzone, a po drugie primo nie stanowią nawet 0,1 promila tych poprawnych.
No i właśnie szacun ma, ale nagrody nigdy nie zobaczy.
Zaproponował ciekawe rozwiązanie które następnie rozwinąłem. Nawet się nikt nie zająknął nad tego typu rozwiązaniem. A można by go rozwinąć jeszcze dalej, ale będzie że to nie ten wątek mimo że odpowiednim do dyskusji chętnych również zabrakło.
Jak patrzę po forum to tak np. na 99% jego postów nie chce nikt odpowiedzieć z tego czy innego powodu. Działa to obustronnie
Jedyny rzetelny przykład błędu jaki widziałem na forum to ten od ntata. Wszystko inne to jakieś głupoty o pojedyncze rzeczy, które każdy przypadkiem zrobi i się obraża jak się mu zwróci uwagę na takowe. Nie mówiąc już o tym, że poprawienie ich zajęło by często mniej niż pisanie na ten temat. Dla przykładu dopiero co wczoraj czy przedwczoraj poprawiłem jakieś kilka pustych linii które miały być highway=track jednego poważnego kandydata do mapowicza miesiąca. Owszem można by pisać za każdym razem gdy takie coś się zobaczy, ale ja nie mam czasu na pierdoły.
A potrzebne? O ile mnie pamięć nie myli to DWG mówi od dłuższego czasu by z source nie korzystać, a umieszczać go w opisie do changesetu.