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

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