czy takie użycie landuse:grass jest dopuszczalne przy mapowaniu trawników czy wysepek trawiastych w osiedlach?
https://www.openstreetmap.org/#map=19/50.03612/22.03123
Tak, ale nie powinno się przyklejać do budynków
Ok.
Ostatnio stwierdziłem, że będę unikał łączenia czegokolwiek z czymkolwiek, po tym jak przypadkiem zepsulem landuae za pomocą “q” w JOSM, a połapałem się po długim czasie, a już sporo edycji było zrobionych w kolejnych paczkach danych.
Teraz landuse robię małe (nie na duże regiony), dzięki czemu łatwiej później zmiany wprowadzić (no. Gdy landuse się zmienia na inny), oraz gdy coś przypadkiem źle zrobię to mniejsze straty.
Można, nie jest zabronione mapowanie tego co widać na zdjęciach lotniczych.
Mapując prywatne baseny też się opłaca, bo wtedy widać na mapie czy to bogata dzielnica 
https://www.osm.org/#map=17/34.11098/-118.30718
Odnośnie mapowania osiedli zamkniętych: czy chodniki powinny mieć access=private? Wydaje mi się, że o ile w przypadku dróg wewnętrznych ma to sens (wjazd tylko dla mieszkańców) o tyle chodniki - mimo ogrodzenia i furtek - są bardziej dostępne dla osób z zewnątrz. Skutkiem ubocznym takiego tagowania jest też wadliwy routing, jak w linku https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=52.20826%2C21.06448%3B52.20643%2C21.06616
Jeżeli obiekty obiektywnie istnieją, to mogą być na mapie, z tagiem access=private. Basen na prywatnej działce to świetny punkt orientacyjny np. z powietrza, a w sytuacji ekstremalnego zagrożenia pożarem może zostać użyty. Właścicielowi może się to nie podobać, zwłaszcza jak nie wykazał obiektu, powiedzmy w oświadczeniu majątkowym. Jeżeli mapujesz w terenie sytuacja może być groźna, jak poszczują Cię psem. Ortofotomapowicze w najgorszym wypadku mogą dostać nieprzyjemnego e-maila.
Jeśli nie można tam wejść, to access=private.
Jest jeszcze access=permissive, co pasuje w takich dwuznacznych sytuacjach, gdy bramki są stale otwarte.
Czy macie pomysł jak można oznaczyć kasę automatyczną, gdzie płaci się za parking? Nie chodzi mi bynajmniej o parkomat, tylko o system typu: pobieramy bilecik na szlabanie wjazdowym, a przed opuszczeniem parkingu idziemy najpierw do budki, gdzie można opłacić bilet zależnie od czasu parkowania i dopiero taki opłacony bilet “skanujemy” na szlabanie przy wyjeździe, żeby się otworzył. I właśnie o tę “budkę” mi chodzi. Mimo, że gabarytowo i funkcjonalnie podobne, to vending_machine to nie jest, bo taka kasa służy tylko uiszczeniu opłaty, a więc nie wydaje nam biletu, tak jak w typowym parkomacie.
Stosowałem amenity=payment_terminal.
Tego właśnie szukałem, dzięki!
Dodałem do Wiki polskie nazwy: terminal płatniczy, kasa automatyczna, kasa samoobsługowa, automat parkingowy, teraz będzie łatwiej wyszukać.
Z opisu wygląda to na magazyn sklepu internetowego. Jeżeli zajmuje cały budynek, oznaczyłbym go jako building=warehouse (lub building:use=warehouse). Oprócz tego dodałbym punkt ze znacznikiem office=logistics. Na pewno nie shop=delivery, ponieważ nie ma tam miejsce sprzedaż towarów/usług.
Bankomat i paczkomat w jednej maszynie, z jednym ekranem. Czy oznaczyć go zgodnie z rzeczywistością jako amenity=atm;parcel_locker, co nie będzie wspierane przez większość programów/usług? Czy nagiąć trochę rzeczywistość i „otagować pod renderer” jako dwa osobne punkty?
Właśnie nie zajmuje całego budynku, tylko zwykły lokal usługowy. Jak Żabka, tylko wstęp wyłącznie dla dostawców. shop=delivery wydaje się nawet stworzone dla takich miejsc, ale zgadzam się, że jest w złym namespace’ie, to nie powinien być *shop=**. office=logistics jednak słabo mi pasuje, żadne to biuro, gdzie następuje planowanie i organizacja.
Na szybko dla tego “wirtualnego marketu” głównie z produktami spożywczymi (internetowy sklep z żywnością) może pasowałaby kombinacja:
- shop=outpost
- delivery=only
- website:orders=*
Osobiście nie jestem pewien, czy ten rodzaj sklepu powinien mieć jako główny tag shop=* ponieważ w terenie jest to często zwykły magazyn, do którego potencjalni klienci nie mają wstępu, zakupy są robione jedynie online z dostawą, ewentualnie odbiór osobisty.
Przykłady firm z Wielkiej Brytanii, gdzie tego typu usługa się narodziła to: Whole Foods (Amazon), Bolt, Gorillas, Dija, Zapp, Weezy, Jiffy, Getir. W Polsce Carrefour, Lisek, Jokr, Biedronka Express BIEK. Maja powstać: Bolt Food, Glovo Express, Wolt Market.
Cortilla (Włochy) - przywozi w ciągu 24h świeże produkty od rolników.
Bother (Wielka Brytania) - specjalizuje się w chemii gospodarczej.
W sensie że ten sam ekran? Otagowałbym jako osobne.
amenity=warehouse?
man_made=warehouse?
amenity=pickup_point?
na pewno nie shop=*
shop=catalogue [lub inna wartość; shop=delivery też jest dobre, skoro już zaczyna być używane]
access=delivery lub access=private
Kurierzy pracujący dla tego sklepu to też użytkownicy mapy. A liczba osób mająca dostęp do jakiegoś obiektu, który jest widoczny w terenie i nie jest dostępny publicznie, nie ma wpływu na mapowalność.
W domyslnych ustawieniach JOSM są warstwy jak “granice działek” i “budynki wms”, ale coś te podkłady nie działają. Czy można ich używać ogólnie i ma ktoś aktualnie działające adresy WMS?
Ale kurierzy nie robią w tym magazynie wysyłkowym zakupów w sposób bezpośredni, fizyczny. Kurierzy pewnie nawet nie mają wstępu do tego magazyn, być może odbierają przekonfekcjonowaną przez magazyniera paczkę i jadą z nią do klienta.
Tag shop=* z tego co się orientuję jest skojarzony w całym ekosystemie OSM z fizycznym sklepem, który w aplikacjach wyszukuje się po tagu shop=* idzie się do niego i fizycznie robi zakupy. Coraz bardziej utwierdzam się w przekonaniu, że stosowanie tagu shop=* dla siedziby sklepu internetowego, który jest prywatnym magazynem gdzieś w strefie przemysłowej, jest błędne.
Ja bym proponował jakiś tag z grupy amenity=, ewentualnie office=.