Dzięki za edycję!
Format godzin otwarcia jest w OSMie dość skomplikowany i bardzo łatwo w nim się pomylić, więc poprawiłem (zmiana: 118757694). Zabrakło średnika oddzielającego dni i sobota/niedziela miały niewłaściwy skrót :).

Powstał duplikat adresów w tych 2 zmianach, bo zarówno budynek i jak punkt mają dane adres Polna 18. Wystarczy 1 z tych (oddzielny punkt, lub tagi na budynku).

Reszta wygląda w porządku pomijając to, że nie powinno być tutaj highway=track a residential, ale nie ty je utworzyłeś :P

Poprawiłem te 2 rzeczy (118757639).

Poprawili na e-mapie.

Jeśli drogi, które dodajesz wymagają weryfikacji, dodawaj proszę do nich np. tag:

fixme=Wymaga weryfikacji z GPS/zdjęć lotniczych.

Wtedy będzie łatwiej to zobaczyć w za pomocą walidatorów, że jest coś do poprawienia.

Jeśli jeszcze nie istnieją to nie dodawaj ich jako istniejące (jest to mocno szkodliwe), a np. proponowane (highway=proposed) highway=proposed – o ile będzie w ogóle budowana.

Chyba, że widzisz, że jest już w trakcie budowy wtedy jak najbardziej highway=construction (highway=construction).

Dlaczego obszar highway=residential, został zamieniony na multipolygon?

Co do wejścia do szkoły, to jedno powinno być połączone do budynku
node/9582620371

Ok, dzięki za odpowiedź, w takim razie ten drugi adres 76A jest zbędny, bo się duplikuje (jeden wystarczy, więc usunąłem :))
A błąd zgłosiłem na e-mapie, żeby poprawili dane urzędowe.
https://kowala.e-mapa.net/
changeset/118668229

Ok, to w takim razie zgłosiłem do e-mapy.
Ale aktualnie ten adres duplikuje się z tym.
way/247624138
Wiesz może jaki tam jest adres?

E-mapa wskazuje Polną 3, czy na pewno jest to ul. Wiejska?
https://toszek.e-mapa.net/

Tam był nadany jedynie adres. Na e-mapie/gugiku nadal występuje. Jeśli uważasz, że niesłusznie, możesz zgłosić go przez e-mapę/e-maila do UG.
Na ten moment przywróciłem.
changeset/118665305

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).