Masowo przesunięte budynki. Import niszczy mozolną ręczną...

Taki jest bieg rzeczy przy programach społecznościowych. Musisz się z tym pogodzić i nie zniechęcać się - znaleźć jakąś niszę dla siebie. Cel nadrzędny jest ważniejszy i chyba się sprawdza (czego doświadczyłem podróżując za granicą z pomocą map OSM).
Troche zapachniało komunizmem :(. Może autor tych autozmian przynajmniej przeprosi?

Np. tak http://overpass-api.de/achavi/?changeset=34193494 (trzeba trochę poczekać, długo się ładuje)

Różnie wygląda jakość obrysów z Geoportalu, zwykle bez trudu się da jednak dostrzec, gdy się rozmijają z rzeczywistością.
W podanych przez ciebie lokalizacjach tego nie widzę, dane z Geoportalu są dobrej jakości.
Różnice są dostrzegalne, bo te obrysy są robione dla podstawy budynku (poziom gruntu lub 1 metr - tego nie wiem), a mapując ze zdjęć robiłeś to pewnie wg pozycji dachów.

Na pewno wg dachów:) Rzeczywiście - bardzo staranna robota. Rozumiem twoje rozgoryczenie.

Patrząc na ten “import” był on robiony najprawdopodobniej wtyczką Tracer2 do JOSM-a. Autor wziął podkład mapowy WMS z obrysami budynków, odpalił wtyczkę Tracer2 i na każdym budynku klikał aby zwektoryzować go z podkładu. Także to nie było tak że Twoja ciężka praca została “magicznie” jednym przyciskiem wykasowana. Dla każdego budynku autor musiał kliknąć, i patrząc po metadanych zestawu zmian, użył także Geoportalu do sprawdzania na bieżąco poprawności.
Wiele razy w anglojęzycznych dyskusjach był wałkowany temat “społeczność kontra importy” tj. opinii jakoby importy negatywnie wpływały na rozwój społeczności poprzez dawanie na tacy gotowych danych które ponadto nie zawsze są dobrej jakości. Prawda jest taka, że na świecie występowało wiele masowych (o wiele większych niż jakikolwiek w Polsce) importów średniej jakości wymagających poprawek (np. TIGER w USA) lub zwyczajnie śmieciowych (Yahoo w Japonii który Mapbox wraz z Japończykami teraz poprawia).

Tutaj jednak sytuacja jest zgoła inna, bo mamy przesłanki iż autor dołożył należytej staranności, aby nie wprowadzać śmieci, bo każdy budynek wektoryzował z osobna i patrząc na ortofotomapę.

Dam Ci też kontrprzykład. W okolicach Trójmiasta (np. gmina Puck) pewien użytkownik już parę lat temu rysował budynki (choć nie była to super jakość) i dodawał do nich adresy z pewnej mapy którą przemilczę. Z tym, że nawet kopiować nie potrafił i często wprowadzał przesunięcia o jeden budynek, mylił nazwy ulic czy dodawał adresy z numerem “0”. Koleś musiał się nieźle napracować, bo mapował w takim tempie jakby był robotem. Czy jego pracy też nie powinno się zaorać importem, bo włożył w nią dużo wysiłku?

Mnie akurat ucieszyła sytuacja z importem budynków w moim mieście - mimo tego, że wcześniej włożyłem w to ogrom pracy i wszystko poszło do “kosza”…
Ale teraz przynajmniej jest wszystko. Po imporcie jedynie trzeba było troszkę “posprzątać” i nanieść jakieś korekty.
Także kolego Randal4 podejdź do tego z bardziej optymistycznym nastawieniem :slight_smile:

najbardziej to krew człowiek zalewa jak sobie rysuje na podkładzie Geoportalu i mu schodzi miesiąc wyrysowanie całej gminy. Później odkrywa osmtools i w tydzień robi to samo. Po czym odkrywa tracera i się zastanawia po kiego się marnowało tyle czasu :confused: Dawno nie sprawdzałem porad dla początkujących ale powinno być tam jasno napisane by jeden z drugim wiedział, że są sposoby wyrysowania budynków, które pozwalają oszczędzić sporo czasu.

PS wiem, że podobnie jest z polami uprawnymi, ale za nic nie mogę znaleźć stosownego wątku na forum który by to pisywał

Tak przy okazji się zapytam w tym temacie: jaki jest obecnie wms dla BDOTa geoportalu? Kiedyś miałem i gdzieś mi się link zapodział a te z forum starsze chyba nie działają.

Jesli jak mowi Randal w importowanych danych sa bledy to niekoniecznie jest to zblizenie do celu, chociaz z komentarzy innych wnioskuje, ze nowe dane nie sa o wiele lub wcale gorsze. Oczywiscie lepiej takie importy koncentrowac na miejscach gdzie nie ma danych.

Wiec w tym wypadku nie warto chyba wycofywac zmian importujacego, ale chce przypomniec, ze jest taka mozliwosc - czesciowego lub calosciowego wycofywania zmian - jesli oryginalna wersja byla lepsza to mozna ja zawsze przywrocic, nic nie zostalo utracone.

Co do tracera, to jesli ktos ma zamiar to masowo robic to powinien moze zainwestowac czas w porzadne narzedzie pod konkretne zrodlo, takie jak czasem byly uzywane do wektoryzowania innych warstw dostepnych w Polsce. Tracer2 nie bierze poprawki na grubosc linii (prawdziwy brzeg budynku biegnie srodkiem linii a nie wewnetrzna albo zewnetrzna krawedzia) ani nie pobiera z BDOT dodatkowych atrybutow budynkow, a domyslam sie, ze jakies atrybuty da sie wyciagnac w tak samo zautomatyzowany sposob, jak ksztalty. Chociazby styl graficzny budynku juz niesie jakas informacje, ktora jest tracona przy korzystaniu z narzedzia ogolnego uzytku.

2 posty niżej rozbieżność została wyjaśniona - Randal rysował po dachu (bo inaczej jest trudno z orto). Zazwyczaj dążymy albo do odwzorowania przyziemia, albo poziomego rzutu budynku tj. włączywszy znajdujące się wyżej wystające, lecz otoczone ścianą elementy (czyli nie balkony).

Nie bierze, ale wydaje mi się, że ściąga dane przy takim przybliżeniu (da się to ustawić), że to nie ma znaczenia. Zwektoryzowałem cały Starogard Gdański i nie zaobserowałem znacznych odchyłów nawet gdy pasek skali pokazywal centymetry. A przypomnę, że szczegóły terenowe I grupy są mierzone z dokładnością 10 cm.

Wydaje mi się, że jeśli budynki z importu są łatwe do odfiltrowania po źródle (lub niewielkiej ilości zestawów zmian), to można by było post-factum dodać do nich opisy i liczbę kondygnacji. Geoportal bardzo wspiera różne standardy i GetFeatureInfo pozwala dobrać się do tych samych danych które webaplikacja Geoportalu pokazuje narzędziem (i), a nawet więcej. Myślę że nawet łatwiej by było otagować import “w postprodukcji”. Zazwyczaj kwerenda zwraca kilka rekordów, trzeba wybrać ten ze Stan=Aktualny.
O, i pole “informacja dodatkowa” może bardzo pomóc w mapowaniu, bo często zawiera nazwy POI znajdujących się w danym budynku.

JOSM ma możliwość skryptowania w JS i to chyba najłatwiejsza droga do implementacji importera metadanych.

To ja zaimportuję i pozamieniam budynki w całej Polsce, bo obecne nie podobają mi się. Potem pozamieniam inne obiekty, bo też jakieś takie… Musicie się z tym pogodzić, bo to program społecznościowy przecież i taki jest bieg rzeczy.

Teraz to już sobie dopowiadasz. Nie wiem czy jesteś na czasie, ale GUGIK udostępnił zbiór punktów adresowych które posiada dla całej Polski, ale nikt go nie importował, bo ci którzy tym się zajmują wiedzą że jakość danych bardzo się różni od gminy do gminy (bo to one zajmują się ewidencją ulic i adresów). Nasze importy są naprawdę na małą skalę, co pisałem wcześniej. Importów budynków (takich typowych, automatycznych) dokonano dla paru miast (np. Szczecin, Wrocław) i może kilku mniejszych powiatów na południu Polski.

@Randal4

W pełni rozumiem Twoje rozgoryczenie. Również trafiłby mnie szlak gdyby coś podobnego zrobione zostało na “moim” terenie.
Bardzo ważną uwagę napisał moim zdaniem balrog-kun: lepiej takie importy koncentrować na miejscach gdzie nie ma danych. Podpisuję się pod tym w 100%. Jest jeszcze tyle roboty do zrobienia, że nie ma chyba sensu dublowania czyjejś pracy, zwłaszcza jak jest ona jakościowo gorsza. Jest jeszcze jeden ważny aspekt takiego importu - demotywująco działa na mapera, przynajmniej tak zadziałałoby to na mnie.

Ponieważ nie wgłębiałem się Tracera mam przy okazji pytanie. Czy w przypadku kiedy budynek posiada segmenty z różną ilość kondygnacji, to wtyczka ta uwzględni taką ewentualność?

Nikt tu chyba nie czyta ze zrozumieniem. Autor rzucił że gorsza, bo rysował po dachach, a nie według przyziemia. Wszedłem sobie na to miejsce w JOSM-ie i ortofoto i tak jest niskiej rozdzielczości, niemniej widać że importowane budynki są dociągnięte do ściany i nie ma błędu perspektywy który zazwyczaj dokonuje się trasując po dachu z orto. Dla mnie to wszystko jest zgodnie ze sztuką.

Co do Tracer2 to wektoryzuje on tak jak jest w materiale źródłowym - więc wszystko zależy od autora czy będzie chciał dodatkowo podzielić. W ewidencjach budynków wyróżnia się chyba części z różną liczbą kondygnacji, a na BDOT teoretycznie agreguje się budynki z tą tamą funkcją ogólną - choć praktyka wskazuje że nie zawsze.

Nie zrozumiałeś moich intencji. Popatrz na parę moich mapowań (nie podam linków przez wrodzoną skromność).

Ten import przy użyciu Tracera nie dotyczył tylko poprawiania budynków Randala, ale też wyrysowania całej reszty pominiętych przez niego - głównie gospodarczych. Na oko to drugie tyle budynków.
I nie polegał on na skasowaniu starych, ale na zmianie ich kształtów. Randal jest wciąż ich pierwszym autorem.

Nie, ale za to często pokazuje połączone budynki mające wspólny dach, więc nieodróżnialne na zdjęciu.

Przydałaby się w OSM możliwość oznaczania elementów jako zweryfikowane (np. gm-verified-by, gm-verified-date …itd), aby np. zmiana geometryczna danego wierzchołka czy elementu oznaczonego w ten sposób była możliwa przy akceptacji osoby, która zmieniała geometrię ostatnio i ustawiła flagę verified. Wtedy otrzymujesz info, że użytkownik X chce zmienić to co rysowałeś i wtedy konsultuje się z Tobą i ustala, czy ma dane, które są bardziej precyzyjne - jeśli tak, pozwalasz mu zmienić i przekazujesz flagę dla danego elementu i może on ustawić gm-verified na siebie…itd

Do tego czasu musiałbyś mieć jakąś wewnętrzną bazę, która przechowuje zmapowane przez Ciebie elementy i co jakiś czas sprawdza, czy ktoś czasem nie zepsuł Twojej pracy (a wtedy reakcja, cofanie nowych zmian…itd).

Moderacji w takiej formie mówię stanowcze nie. Po pierwsze to wypaczenie idei projektu społecznościowego, a po drugie koncept “własności” danych jest niedorzeczny. Są wśród nas użytkownicy, którzy patrzą na OSM tylko przez pryzmat swojego użytku. Przykładowo kilku ludzi związanych ze strażą (oczywiście nie generalizuję - duża część odwala dobrą robotę). Danie im takiej możliwości utworzyłoby mieszankę wybuchową, niemal pewny punkt niezgody.
Obecnie jest tak: zmiana → revert → opcjonalnie: wojna edycyjna → opcjonalnie: rozwiązanie sporu przez DWG. Punkty od 3 prawie wcale nie występują. Przez lata model ten udowodnił, że działa całkiem dobrze.

Zbędne, bo cała historia edycji jest już zapisana w OSM.
Niepraktyczne, bo nie dasz rady przeanalizować większej ilości zmian, a cofanie może zadziałać tylko przy natychmiastowej reakcji (konflikty), a przy niektórych zmianach nawet szybka reakcja nie wystarcza.

Element może być zapisany jako referencja zawierająca nr elementu oraz nr changsetu.

Przecież cofnąć zmianę można w każdym czasie - bierzemy wektor i przesuwamy do wcześniejszej postaci i zapisujemy jako nowy changeset.

A co w przypadku jego podziału?

Nie tak szybko. Jeśli spowoduje konflikty, zostanie on odrzucony przez serwery osm.

Dobra uwaga. Tutaj sprawa jest bardziej złożona, bo faktycznie trzeba by nadzorować przesunięcie elementów opartych o przesuwane węzły i poświęcić temu większą uwagę (automat może coś zaproponować, ale i tak finalnie użytkownik musi to zweryfikować, bo automat może nie wyłapać elementów, które nie są bezpośrednio powiązane z badanym elementem). Ale i tak jest to możliwe do wykonania.