Zgadzam się, zwłaszcza, że rzadkością są edycje “wszystkiego i wszędzie”. Wydaje mi się bez sensu wyświetlanie ostrzeżeń o budynkach osobie, która edytuje tylko drogi.
Proszę uważać na te propozycje napraw narzucane przez iD.
Właśnie odkryłem, że przestarzałe office=administrative na budynku jest, owszem, zmieniane na office=government, ale przy okazji znika tag budynku.
https://github.com/openstreetmap/iD/issues/6466 - zgłoszone godzinę temu i naprawione pół godziny temu. Nie wiem kiedy iD wypuści poprawioną wersję.
Cieszę się.
Tyle że to objaw większego zjawiska w iD - dodawania lub usuwania tagu building przy aplikacji różnych presetów. Stara sprawa i ciągle jakieś presety są właśnie z tego powodu naprawiane (lub jest odmowa naprawy).
Np. aktualnie zastosowanie presetu Śmietnika do budynku tez powoduje zniknięcie tagu building. Z kolei Ogrodnik(craft) lub Centrum Ogrodnicze(shop) jako obszar ma zawsze dodany tag building.
W zasadzie to chyba ma sens, żeby nie łączyć budynku i innej funkcji na jednym obiekcie. Tu się ujawnił ten problem co do wyświetlania nazw, bo jak są razem, to nie wiadomo czego ta nazwa dotyczy:
https://github.com/gravitystorm/openstreetmap-carto/issues/3780
Prawdopodobnie należy po prostu zrobić inny obiekt o tej samej geometrii (te same punkty i linie), chodzi tylko o to, żeby to przedyskutować gdzieś najpierw, a nie żeby to był efekt uboczny.
Kiedyś przy mostach takie konflikty rozwiązywało się poprzez bridge:name. Tutaj mogłoby to być building:name.
Dlatego jestem za tym, żeby amenity rozdzielać od budynku i dawać jako węzeł, nawet jeśli zajmuje cały budynek.
Co jeśli do kamienicy, która ma nazwę wprowadziła się biblioteka i zajmuje cały budynek? To mamy dwie nazwy, kamienicy i biblioteki. A jeśli chcę dodać start_date to czego będzie dotyczyć, budynku czy biblioteki?
Kamienica mogła być wybudowana kilkaset lat temu i chcemy zaznaczyć to w tagach, a instytucja zajmująca budynek będzie się zmieniać częściej niż sam budynek. Więc moim zdaniem na te dwie rzeczy warto mieć dwa obiekty.
Potem powstają takie kwiatki jak ten, że nie wiadomo które tagi czego dotyczą:
WroclawGIS:addr:date 2011-03-13
WroclawGIS:addr:id 26777
WroclawGIS:addr:layer search/0
WroclawGIS:addr:postcode:id 28145
WroclawGIS:addr:postcode:layer odniesienie_k_lite/1
WroclawGIS:building:ID 2360
WroclawGIS:building:date 2011-02-25
addr:city Wrocław
addr:country PL
addr:housenumber 5
addr:postcode 51-301
addr:street Aleja Jana III Sobieskiego
addr:street:sym_ul 20428
building yes
contact:phone +48 666 737 555
motorcycle:clothes yes
motorcycle:parts yes
motorcycle:sales no
name I'M Inter Motors
old_name Meble Bodzio
opening_hours Mo-Fr 10:00-20:00; Sa 10:00-17:00
shop motorcycle
source WroclawGIS
source:addr WroclawGIS
source:building WroclawGIS
website https://www.imready.eu/pl/intermotors-wroclaw-sobieskiego
A gdyby tu jeszcze były tagi budynku 3D to już zupełnie byłoby zamieszanie.
Takie łączenie nie ułatwia też przeglądania POI na mapach, bo jak ktoś szuka bibliotek czy sklepów motocyklowych to nie obchodzą go tagi budynku, których tu może być bardzo dużo.
A dlaczego proponujesz akurat węzeł, jeśli wiadomo że zajmuje obszar (taki sam jak budynek)?
Umieszczanie tagów POI na budynku jest tak powszechne, że nie warto próbować tego zmieniać.
Metoda dodatkowego obrysu po budynku dla POI jest poprawna, choć niespotykana. Sam ją stosują tylko gdy POI obejmuje kilka sąsiadujących budynków.
Jeśli na budynku jest amenity/shop/office, to przyjmuję że tagi name, start_date, website odnoszą się właśnie do POI, a nie budynku. Może nie jest to nigdzie ustalone, ale najczęściej poprawne.
Atrybuty budynku można umieszczać w building:xxxx… Wg taginfo np. tagi building:name i building:start_date są rzadkie, ale w użyciu.
Kolejny głupi fix iD: amenity=public_building zmienia w building=public, nawet w takich sytuacjach: https://www.openstreetmap.org/node/1669030252
Edit:
Inny problem: https://www.openstreetmap.org/way/545510058
Przejście dla pieszych dostało barrier=kerb z powodu kerb=lowered. To może być problem w routerze poprzestającym tylko na kluczu barrier, bez wnikania w jego wartość.
Może to jest też błąd w tagowaniu - czy kerb=lowered nie powinnien być w węźle w miejscu krawężnika, a nie na całej linii?
Edit2:
barrier=entrance zmienia w entrance=yes. Pierwsze oznacza fizyczny brak wejścia (otwór), drugie zwykle jakieś drzwi, bramę itp.
Edit3:
https://www.openstreetmap.org/way/409779391 - service=driveway wystarczyło, by powołać do życia nieistniejącą drogę
Jest to jednakże przykład złego tagowania, po tam powinno być highway=proposed. W takiej sytuacji iD nie tworzy drogi.
Moim zdaniem stawianie węzła w miejscu POI wydaje się bardziej poprawnym sposobem oznaczania, czy to pokoju, budynku lub obszaru rezydowania danego POI Analogicznie jak w przypadku miejscowości, pomimo że miejscowość zajmuje obszar, który można z całkiem dużą dokładnością oznaczyć tagiem na obszarze + nazwa, dane miejscowości są zapisane z jakiegoś powodu w węźle nie obszarze. Z drugiej strony nazwane obszary lepiej wypełniają mapę i często w przypadku dużych obszarów atrakcyjniej wyglądają na niej.
Myślę, że dla POI powinno być coś w rodzaju automatu (specjalnej strony), w którym zainteresowany (podobnie jak w przypadku Googla) wypełniłby stosowne kluczowe pola: 1. Rodzaj i/lub podrodzaj POI, 2. nazwa, 3. adres (kod, nazwa miejscowości, ulicy, numer lokalu), 4.numer telefonu, 5. strona WWW 6. Ograniczony opis POI w description itd… Gdyby kluczowe pola zostały pominięte np. rodzaj poi, nazwa, opis, dane do weryfikacji nie mógłby dodać poi i musiał skorzystać z uwagi. Jako że takie zgłoszenie byłoby anonimowe zainteresowany mógłby zostawić adres do korespondencji. Dane jeszcze nie byłyby widoczne na mapie ani obecne w bazie danych.
Następnie dane mogłyby być dodane do mapy, po wcześniejszej akceptacji, lub odrzucane, ewentualnie poprawione przez zaawansowanego użytkownika. Jednym kliknięciem Tak dodaj lub Odrzuć. Jednak w razie wątpliwości jeśli obecny byłby adres do korespondencji doświadczony mapowicz mógłby zadać szczegółowe pytania zgłaszającemu np. o położenie punktu POI. Po akceptacji POI powinny być dostępne i widoczne w bazie danych i mapie, bo to zachęca do aktywności konsumentów mapy.
Obecnie traci się czas na weryfikację dodawanych danych czy w POI, czy w uwadze zwykle użytkownicy dodają niepełne dane przeważnie samą nazwę (nawet z jakiegoś powodu są zalecenia na wiki, aby dodawać niepełne dane). Uwagi wiszą latami. Zainteresowani, którzy nie chcą marnować swojego prywatnego czasu, albo nie mają go wcale na zgłębianie niuansów dodawania danych do mapy dodają najwyżej uwagę.
Odnośnie POI mam na myśli sytuację w Europie, konkretnie w Polsce.
Zgałszałem, zostało olane - https://github.com/openstreetmap/iD/issues/5951
Poprawione po https://github.com/openstreetmap/iD/issues/6506
Otworzyłem tę stronę. Jak mam zrobić, aby po kliknięciu na wybrane miejsce na mapie pojawił się formularz pozwalając dodać POI do bazy danych?
Chętnie widziałbym na https://www.openstreetmap.org po kliknięciu prawym klawiszem myszki na mapę poza standardowego “Dodaj uwagę tutaj” także … prosto z mostu “Dodaj POI tutaj”
Przesuwasz znacznik na wybrane miejsce, a potem pod mapą klikasz “add more details”.
Od tego jest edytor iD :). Jedynie musisz raz kliknąć “edytuj” przed tym. OnOSM to tylko proste narzędzie.
W nowej wersji 2.15.2, która weszła dzisiaj, nie ma już autonapraw jednym kliknięciem.
Francuski fork iD: http://id.openstreetmap.fr
M.in. stosuje crossing_ref=zebra zamiast crossing=marked dla oznaczania przejść dla pieszych.
Widziałem ostatnio wiele nowo utworzonych brodów w miejscach, gdzie są mosty i przepusty.
Wszystkie edycje z iD. Jak się okazuje, to sprawka edytora:
Kliknięcie na “Połącz obiekty” tworzy bród.
Chyba zmiana tłumaczenia na “Oznacz jako bród” by pomogła?