Teraz 2 domy mają taki sam adres, czy jesteś w stanie powiedzieć, który powinien mieć, który?
Wg danych urzędowych ten po lewej (way/629022599) powinien mieć 76B, a ten po prawej 76A.

Dzięki za edycje, wkradł się drobny
błąd w tagowaniu, ale poprawiłem:

changeset/118664972

Kolejne duplikaty szkół.
Wycofałem.
changeset/118596084
---

Published using OSMCha: https://osmcha.org/changesets/118547173

Duplikat szkoły. Wycofane. changeset/118595957
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/118547009

Wejścia powinno się odpowiednio otagować jeśli już łączymy je z budynkami. Jest do tego tag entrance
entrance=*
---

Published using OSMCha: https://osmcha.org/changesets/118546169

Nazwa znajduje się już na obszarze. Wycofane.
changeset/118595376

Jest to duplikat amenity z obszaru. Usunąłem tagi z budynku i przeniosłem na obszar. changeset/118595054
---

Published using OSMCha: https://osmcha.org/changesets/118545538

> Wydaje mi się, że jak jakiś obiekt przestaje istnieć, to zdecydowana większość mapowiczów po prostu taki obiekt wykasuje, bez żadnych prefiksów :/

Część wykasuje, część nie wykasuje od razu, a tymczasowo zostawi przetagowane, a część nie wykasuje w ogóle. Wszystko zależy od obiektu i danej sytuacji. Np. adresy lepiej wrzucać w old_addr jeśli były "przypisane" do danego domu, tak, żeby zachować informacje o poprzednim adresie.

> Czy budynek z demolished:building będzie renderowany?

Na tę chwilę nie będzie (na domyślnej warstwie). Tak samo jak disused:amenity i inne tego typu obiekty.
Przykład: way/185586808

> W ogóle to jest bardzo demotywujące, kiedy coś zmieniasz, aktualizujesz, a później twoja edycja jest automatycznie (czy półautomatycznie) kasowana i np budynek wraca z powrotem na mapę (

Zgadza się, choć na pewno większość w tym charl3s nie robią tego specjalnie.

> Czy istnieje możliwość podczas importu obiektów sprawdzać, czy on już był wcześniej importowany i kasowany? To by (chyba) rozwiązało problem.

W teorii tak, w praktyce raczej małe szanse na to, bo trzeba by było ładować usunięte obiekty z bazy danych OSMa, a nie wiadomo jaki przedział czasu by nas interesował oraz jaki obszar. Przy masowych importach, pewnie byłoby ciężko. Nie wiadomo również dlaczego został np. usunięty, może w miejscu starej chatki wybudowali nowy blok, a może ktoś po prostu usunął przypadkiem.
Trzeba by do tego analizować komentarze zmian dla każdego budynku.
Overpass posiada możliwość robienia Query na daną datę, ale jest to bardzo wolne no i trzeba znać tę datę, więc raczej byłoby z tym ciężko. To wszystko powyższe brzmi na mocną komplikacje importowania i na takie dość można by się pewnie decydować tylko w szczególnych przypadkach. Tylko skąd ktoś miałby wiedzieć, że akurat w tym miejscu jest ten szczególny przypadek? :)

Dlatego pozostałbym na (prawdopodobnie najprostszym) rozwiązaniu dodawania tagów cyklu-życia obiektu podesłanych wyżej, aż do usunięcia z orto/ewidencji.

https://github.com/valhalla/valhalla/issues/1434
Tutaj widzę jakieś issue z tym związane. Jak jesteś w stanie "odtworzyć błąd", to warto im to zgłosić i pokazać jak takie ograniczenie powoduje konkretne problemy.

> ograniczoną precyzję w bibliotekach do routingu punkty te zlewają się w jeden.

Jakich? OSM używa 7 miejsc po przecinku do współrzędnych, jeśli ktoś chce wykorzystywać dane OSM musi się z tym liczyć, że może trafić na takie dane z taką precyzją i nie powinno się zmieniać danych, bo zewnętrzna aplikacja czegoś nie obsługuje. To powinno być realizowane w drugą stronę.

W tabelce jest ładnie opisane jak dane są przechowywane i wskazówka, żeby nie używać typu "float", bo gubiona jest precyzja, która jak zauważyłeś może być kluczowa, choć nie do wszystkiego jest to aż tak istotne :).

osm.wiki/Node#Structure

Nie chce się powtarzać, bo już Dawid odpowiedział + w sumie pod inną zmianą (118459062) maciek-szn, również wyjaśnił, że takie decyzje podjęli w edytorze iD.

Zrobienie zaawansowanego walidatora, który obejmie wiele przypadków i nie wygeneruje nieprawdziwych błędów może nie być wcale takie proste – zależnie od przypadku, dlatego niektóre edytory, go mają inne nie.

Tutaj mamy do czynienia z mikromapowaniem, do którego iD no niestety niezbyt się nadaje, więc możliwe, że nie wszystko może się tutaj iD podobać.

Prawdopodobnie ten walidator został napisany dla takiego przypadku jak na zdjęciu:
https://github.com/openstreetmap/iD/issues/6241
Może można go ulepszyć i np. sprawdzać, czy ten bliski węzeł czegoś nie przecina przy okazji.

Co do łączenia area:highway, to ogólnie wiem, że jest "trend", aby ze zlepianiem wszystkiego do siebie nie przesadzać, w szczególności unikać łączenia obszarów z budynkami (które mogły by rozwiązać problem id).

Takie niepotrzebne, a przy okazji ścieżki zostały rozłączone i powstał teleport...
Wycofane
changeset/118465980

To nie są niepotrzebne punkty. area:highway powinny się przecinać z daną ścieżką. Wycofałem...
changeset/118465898

@Volodymyr D-k
Nie sposób weryfikować każdy 1 budynek tak szczegółowo przy importowaniu i wyszukiwać w mediach, czy akurat ten konkretny nie został zniszczony. Akurat w tym przypadku np. Wrońskiej 5b blok jest i na ortofotomapie i na egib, nie ma landusa, który by wskazywał, że nie ma tam budynku. Nie ma nic co by wskazywało, że spłonął.

Jeśli masz wiedzę lokalną na temat zburzonego/spalonego/itp. budynku, to super, ale warto to dodać np. w postaci "lifecycle prefix" demolished:building, albo inny odpowiednik
osm.wiki/Lifecycle_prefix
I najlepiej do tego note z opisem sytuacji i podtrzymać przynajmniej aż do nowej orto/zniknięcia z ewidencji, ewentualnie wybudowania nowego obiektu w tym miejscu.

Rzeczywiście, Osmose by pewnie wykryło jutro. Byłeś szybszy :D

Poprawione:
changeset/118404782

Co to znaczy private property i dlaczego usunąłeś te ścieżki?
Dostępne podkłady nie sugerują, żeby tam było cokolwiek, co by blokowało przejście, a orto sugeruje ścieżki.
Jakie jest źródło tych zmian?

Cześć,
niestety w tej edycji pojawiło się sporo zbędnych i niepoprawnych zmian.

Zmiany na drogach ekspresowych w dodawaniu access=no i innych pieszych/rowerowych są zbędne i podatne na błędy i ograniczanie w routingu, bo wynika to m.in. np. z tej tabeli domyślnych dostępów.

osm.wiki/OSM_tags_for_routing/Access_restrictions#Poland

Dodawanie w drugą stronę bicycle=yes dla dróg typu service jest również zbędne.

Zmiany dróg service->residential, również wyglądają na niepoprawne np. ta: way/340239188

Wycofałem zestaw zmian w całości:
changeset/118324395

Cześć, dzięki za edycję!

Domyślam się, że w tym miejscu powstają piwa, więc poza samą nazwą budynku, przydałby się jeszcze odpowiedni tag.

Na wiki można znaleźć jak to poprawnie otagować:
W tym przypadku prawdopodobnie craft=brewery

osm.wiki/Pl:Tag:craft%3Dbrewery

It's already there.

way/368946236

Jakie jest źródło tych danych? "Knowledge" w tym przypadku nie wygląda wiarygodnie.