Edytor iD

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

https://www.onosm.org/

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?

Tekst “połącz obiekty” jest wspólny dla wszystkich rodzajów przecinających się dróg. Kliknięcie na “połącz obiekty” jedynie tworzy wspólny węzeł dla dwóch przecinających się linii i ewentualnie dodaje tagi dla tego węzła, np. dla połączenia drogi z torami stworzy węzeł railway=level_crossing, dla ścieżki i drogi doda highway=crossing itd. A w przypadku ścieżki i strumienia otaguje jako ford=yes. To mapujący powinien wiedzieć co robi i jak to jest w terenie. Jeśli strumień przepływa pod drogą, to wiadomo że nie można ich łączyć, bo leżą na różnych warstwach. Niestety mostu nie można stworzyć jednym kliknięciem i trzeba to zrobić ręcznie.

Jeśli funkcja opisana jako łącząca obiekty tworzy także bród, to są dwie możliwości:
-funkcja robi coś, czego nie powinna
-funkcja jest źle opisana

Moim zdaniem funkcja działa dobrze i jest dobrze opisana. “połącz obiekty” znaczy tutaj tyle, że te dwie drogi znajdują się na tym samym poziomie (warstwie) i żadna z nich nie przebiega pod lub nad drugą. Trudno żeby “połącz” znaczyło “narysuj tu most, strumień biegnie tunelem pod drogą”. Bród wynika z tego, że ciek i droga są połączone, więc jeśli mają wspólny węzeł, to znaczy to, że jest tam bród.
Po kliknięciu na “i” można przeczytać “Drogi przecinające cieki powinny być oznakowane jako most, tunel lub bród.” - można do tego komunikatu coś dopisać, ale nie sądzę żeby to pomogło, bo jeśli ktoś bez pomyślenia klika “połącz obiekty” i tworzy bród tam gdzie go nie ma, to i nie kliknie na “i”.

Fakty temu przeczą:

  1. Znam przynajmniej trzech mapujących, którzy takie brody nieświadomie utworzyli.
  2. Funkcja wykonuje dwie operacje, a jej opis informuje tylko o pierwszej z nich.

Nie mają wspólnego węzła - w danych OSM nie było połączenia. Węzeł zrobił iD po skołowaniu mapujących - zasugerował im, by dokonali połączenia, bez informowania o znaczeniu tej operacji. A dodanie znacznika brodu zrobił potajemnie.

Nie pomoże, zbyt ogólne. Poza tym ludzie nie sięgają do dokumentacji, nawet jeśli dzieli ją od nich jeden klik.
Dlatego nazwy/opisy, które są widoczne dla użytkowników, powinny być jak najbardziej jednoznaczne i kompletne.

Faktycznie! Opcje "Oznacz jako most lub tunel " oraz “Przemieść obiekty” są nieaktywne, przypuszczalnie niezaimplementowane.
Czyli mapujący ma tylko dwie możliwości: zignorować lub połączyć obiekty.
Jako że to wszystko jest opisane słowem “Problemy”, to oczywiste, że mapujący nie ma wyboru - i robi połączenie.

Dla mnie jest już jasne - ta funkcja w iD jest niedokończona, to taka zajawka, które powinna być w preview, a nie w finalnym produkcie.

https://github.com/openstreetmap/iD/issues/6734

Tak będzie lepiej?

Moim zdaniem to nie jest rozwiązanie problemu, bo myślę że bród będzie w 1 na 100 przypadków, a w pozostałych 99 to będzie rów przechodzący pod drogą. A ludzie dalej będą klikać i łączyć.

https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions

Wie ktoś jak rozdzielić w iD taki obszar? Na południu już nie ma żwirowni, jest łąka czy pole (patrz zdjęcia Bing).

https://www.openstreetmap.org/way/285986050

W JOSM-ie to jest Alt-X.

Nie ma odpowiednika w iD - https://github.com/openstreetmap/iD/issues/969

Kolejny dowód na wyższość JOSM-a. W ogóle rozdzielanie obszarów w iD graniczy z cudem. A dla kogoś kto robi więcej niż dodanie paru budynków na krzyż taki przypadek użycia to jeden z podstawowych…