Chciałbym poznać waszą opinię na temat automatycznego przyłączania node adresowych do budynków. Zdaję sobie sprawę że takie automatyczne przyłączanie na ślepo nie jest wskazane i dlatego proponuję następujące zasady (zasady których trzyma się większość(?) osób edytujących niebędących lokalnymi):
Adres zostanie złączony do obrysu budynku tylko jeśli:
Punkt zawiera jedynie informacje adresowe (addr:) oraz source (source lub source:addr)
Wartość source lub source:addr zawiera stronę internetową np. www.geoportal.gov.pl.
Punkt adresu jest wewnątrz obrysu lub minimalnie obok (<1m) (trzeba skupić się na poprawnej analizie relacji)
Punkt nie został nigdy edytowany (bezpośrednio po imporcie)
Punkt nie znajduje się wewnątrz kilku budynków (nakładające się obrysy)
Punkt nie jest złączony do krawędzi budynku
Budynek nie posiada aktualnie żadnego adresu
Wewnątrz obszaru budynku znajduje się tylko 1 punkt adresowy
Budynek nie posiadał wcześniej tego adresu (addr: oraz old_addr:)
Budynek nie jest w stanie demolished, abandoned, itp.
Obszar jaki zajmuje budynek ma mniej niż X m^2.
Podczas złączania nastąpi edycja:
Zamiana source na source:addr w celu uniknięcia konfliktów.
Założenie jest takie, że program będzie na bieżąco monitorował nowe i historyczne importy i wprowadzał zmiany w całej Polsce. Celem takiego działania jest optymalizacja pracy edytujących którzy nie będą już na “taką skalę” musieli złączać nodeów adresowych do budynków. Sam wykonałem tego typu pracę niezliczoną ilość razy i postanawiam coś z tym zrobić.
To chyba nie przejdzie. Są osoby, które lubią adres w węźle, nawet gdy jest to jedyny adres dla budynku.
Czyli wystarczy zrobić duplikat adresu z obrysu budynku na węźle, by takie osoby były częściowo zadowolone. Częściowo, bo to jednak dodatkowa robota dla nich.
W węźle - w sensie wewnątrz obrysu? No to kwestia czasu wg. mnie aż ktoś przypadkiem tego nie złączy. A jeśli ktoś rzeczywiście to zweryfikuje ręcznie to wystarczy proste rozłączenie. Częścią procedury sprawdzania jest sprawdzanie danych historycznych obrysu budynku. Jeśli kiedyś był tutaj ten adres to nie zostanie on ponownie przyłączony.
Uważam że ilość dobrze uzasadnionych przypadków gdzie node nie powinien być przyłączany do budynku jest znikoma w porównaniu do ogółu. O wiele prościej jest naprawić kilka przypadków niż ręcznie przyłączać tysiące adresów. Dodam krok sprawdzający pole obszaru budynku (złącz tylko jeśli obszar ma poniżej X m^2).
Jestem zwolennikiem danych adresowych w budynku. W związku z tym popieram tę propozycję łączenia przy tych warunkach.
Wiem, że jednym argumentem za osobnymi punktami adresowymi jest wskazanie nawigacji, gdzie ma kierować do adresu. W takim wypadku lepiej zmapować główne wejście. Jest to jednak dużo trudniejsze na dużą skalę.
source:addr jest nowszym i bardziej precyzyjnym tagiem, więc warto to uwzględnić. Niektórzy dodają/dodawali również ref:addr, ale do tego to akurat nie jestem przekonany, bo jest to trudne w utrzymaniu i weryfikacji i nie wiem, czy ktokolwiek to dodawał ręcznie poza masowym importem. Nie wiem, czy jest coś jeszcze.
EDIT. Oczywiście jeszcze old_addr.
To by było ok, gdyby nie było tak, że bywają 2 sklejone budynki z 1 adresem i dlatego często wtedy wisi jako węzeł.
Co do tego nie jestem przekonany, żeby działało to w pełni automatycznie, bardziej widziałbym to jako np. narzędzie, które wygeneruje plik zmiany i można wczytać do JOSMa i przejrzeć lub/i wizualizuje na mapce potencjalne punkty do złączenia.
Jest trochę edytujących, którzy nie chcą tego łączyć i mają ku temu powody. Jak sam zobaczysz musisz tworzyć określone kryteria, kiedy łączysz, a kiedy nie łączysz – jest to komplikacja. Niektórzy adresy wrzucają nawet w relacje…
Dodatkowo trudniej się edytuje obiekty, które są połączone z innymi, choć oczywiście standardowy domek z adresem nie powinien mocno utrudniać sprawy. Tu problem jest taki, że w Polsce nie zostało to po prostu ustalone.
Zobacz np. na Czechy, oni mają nieco inne podejście do adresów, u nich adresy nie będące węzłami to dość mały procent.
Oczywiście oba podejścia mają swoje wady i zalety.
Druga kwestia jest taka, że do JOSMa jest chyba plugin, który je łączy stąd trochę nie widzę potrzeby dodatkowego narzędzia, które zrobi to za nas (polecam się jednak przekonać )
Oprócz tych bliźniaków, to moim zdaniem nie warto ich łączyć, gdy adres jest dość stary tj. ze starego importu. Wtedy zwykle ich aktualizacja, bądź po prostu pozbywanie się ich bywa zdecydowanie prostsze jak są na węzłach szczególnie, że np. występuje konflikt tagu source.
Inne przypadki:
Co z multipolygonami?
Co adresami na wejściach/klatkach?
Pewnie coś by się jeszcze znalazło, ale to tak na szybko.
to mi bardziej odpowiada od JOSM ale nie jestem pewien czy chcę w tą stronę brnąć, adresów jest masa i prościej to zautomatyzować z jakąś fancy logiką.
Tak, ale w znacznym stopniu łączysz. Nie mówię że takie działanie będzie idealne, tylko ilość poprawek będzie bardzo mała w stosunku do potencjalnego zaoszczędzenia czasu. Jeśli adres został rozłączony to nie będzie on przyłączony 2-gi raz.
Pomysł dotyczy jedynie nietkniętych node po imporcie. Dodam regułę, musi być to node w wersji #1. Bez żadnych dodatkowych edycji.
Można dodać automatyczną zamianę source na source:addr.
Multipolygon jako budynek? No to traktowany jako budynek tylko że zaawansowany obrys.
Adresy na wejściach klatkach mają inne tagi niż addr: + source: więc ich nie ruszy.
Chodziło mi o to, że takie tagi również są na węzłach adresów. Rozdzielanie ich oczywiście nie ma sensu.
To może się wcale nie okazać prostsze. Choćby patrząc na przykład wyżej z bliźniakami.
Po 1 odpaleniu bota może pójść mnóstwo revertów, a w przypadku bliźniaków rozumiem, że mogą być i nawet 2, jeśli najbliższy budynek zostanie wykluczony?
Mimo wszystko jak to by to miało być robione, to zacząłbym od zwizualizowania potencjalnych punktów na wybranym obszarze przed jakąkolwiek automatyczną zmianą w celu ich oceny przez społeczność.
Może wyjść w ten sposób więcej przypadków, które warto/trzeba uwzględnić. Najlepiej, żeby były zróżnicowane tj. zawierały one większe miasto/a jak i mniejsze wsie.
Sprawdzane mają być tylko nowe adresy czy też nowe budynki?
Przed czym ma to zabezpieczać?
Skoro punkt ma być po imporcie, to może od razu ograniczyć się do węzłów z source=www.geoportal.gov.pl? Odpadnie problem z ludźmi samodzielnie dodającymi węzły adresowe.
Ogólnie nie protestuje - choć bym chciał zobaczyć listę proponowanych zmian. Ale myślę że jest wiele mniej kontrowersyjnych botoedycji co można by najpierw zrobić.
Naprawdę? Nie ma już czego mapować? Nie ma już czego poprawiać?
Ja rozumiem, że jest zima, i wszyscy się nudzą w domach. Ale po co łączyć z budynkiem? Budynek to nic trwałego… Za 10,20, 50 lat go nie będzie. Jeszcze mniej trwałym jest adres związany z… no właśnie, z czym? Z działką? budynkiem? Adresy się zmieniają, dziś jest to Przemysłowa, jutro Pstrowskiego a pojutrze Fabryczna…
Po połączeniu z budynkiem adres będzie wskazywał na centroid tego budynku. Co nie do końca ma sens…
To pisałem ja, który x lat temu zaimportował N+1 punktów adresowych i był zwolennikiem łączenia. Przeszło mi. Teraz jestem zwolennikiem prostoty.
To nie działa. Proszę mi wierzyć. Za rok, dwa, czy dziesięć — oprogramowanie sprawdzające/sprawdzający/sposób tagowania odejdą do lamusa. Mieliśmy, jako OSM w .pl, setki walidatorów. Na różne okoliczności. Większości z nich już nie ma. Nikt za nimi specjalnie nie płacze.
Dodałem warunek żeby punk nie był na krawędzi budynku. W połączeniu z tym że będą edytowane jedynie node w wersji #1 (oryginalnej) nie będzie to problemem.
Trochę off-topic, ale czy mógłbyś coś więcej napisać o tych walidatorach? Czy jest dostępny ich kod źródłowy? Z czego wynika ich zniknięcie?
Być może jakieś wątki na starym forum dobrze to obrazują?
Moim założeniem jest optymalizacja pracy edytujących a jednym z głównych zjadaczy czasu jest przyłączanie adresów.
Adres też nie jest stały. Z twojej wypowiedzi odnoszę wrażenie że nie tyle jesteś przeciwny mojemu pomysłowi co po prostu przyłączania adresów do budynków w ogóle.
Nie widzę przeciwskazań aby tak zaimplementować wersję pierwszą a potem ją rozszerzyć o on-the-fly analizowanie nowych changesetów. Jeśli logika jest już napisana to większy problem z głowy.
)