Siedzę właśnie i łamię sobie głowę jak otagować jeden sklep w którym sprzedaje się:
Obuwie
odzież
zabawki
Wszystko jest równorzędne.
Czyli wg wiki:
shop=shoes
shop=clothes
shop=toys
Brak nam specyfikacji dla sklepów multifunkcyjnych, tak częstych w Polsce.
Macie jakiś pomysł na proposal?
Edit:
Koledzy z zagranicy sugeruja: **shop=shoes;clothes;toys **
Sprytne wyszukiwarki obsłużą to, jedynie rendering będzie głupiał (lub brał pierwszą wartość do renerowania na mapie).
Propozycja podoba mi się.
Mnie sie nie podoba. W takim razie powinnismy dodac wszedzie shop=supermarket;alcohol;…
Osobiscie preferuje cos w stylu alcohol=yes toys=yes itp. poniewaz rendering zachowuje sie normalnie oraz latwiej wyciagnac interesujace nas dane.
A mnie się podoba. Nie chodzi o sklep typu supermarket bo tam rzeczywiście zależnie od sieci jest różny asortyment towarów.
Tak jaki pisałeś prowadziło by to do do powstawania strasznych dziwolągów.
Chodzi tylko i wyłącznie o małe sklepy, gdzie sprzedawca ma dwa, trzy kompletnie różne rodzaje towarów do zaoferowania jak w podanym przykładzie.
Nie można często zdecydować czym on naprawdę handluje. Widziałem np. sklep spożywczy gdzie sprzedawano też… meble ogrodowe.
To zdaje się specjalność mniejszych miejscowości. Na zachodzie praktycznie czegoś takiego nie ma, w Azji już dużo częściej.
Ważne jest by dobrze to rozgraniczyć na wiki by ludzie nie wpadali na tego typu pomysły tagowania zbędnych szczegółów
bo inaczej pojawi nam sie rzeczywiście coś typu shop=supermarket; wóda; kiełbasa; znaczki na listy
Wydaje mi się, że tagowanie obiektu “shop” określa jego ogólne przeznaczenie.
Aby podać grupy towarów, powinien być dodatkowy tag uzupełniający. Na przykład: shop:brand
Coś podobnego jak ze szpitalami lub lekarzami, gdzie dodajemy bardziej dokładne podgrupy.
Wtedy Dotevo bardzo łatwo wyłapie wszystkie podgrupy i może je podać w dymku.
Obecny podział jest całkiem niezły, okazuje się kiepski tylko czasem (np. mamy zegarmistrza, który sprzedaje zegary oraz dewocjonalia - połączenie zegarów z dewocjonaliami jest chyba zresztą dość popularne…). Możnaby oczywiście zmienić tagowanie, dając shop=yes (ewentualnie shop=small/normal/market/supermarket czy coś w tym stylu) oraz shop:alcohol=yes/no, shop:bakery=yes/no etc. w zależności od asortymentu (domyślnie oczywiście no), ale moim zdaniem wprowadziłoby to więcej zamieszania i problemów, niż to warte… (bo czy kiosk, w którym można kupić wodę brzozową to już byłby shop:alcohol=yes? - to raczej byłoby bardzo subiektywne ). Oczywiście tego typu zmiana wymagałaby akceptacji nie tylko na forum users:Poland.
Dodałem całkiem sporo POI i bardzo często miałem ten problem co tak naprawdę wybrać dla niewielkiego osiedlowego sklepu posiadającego kilka całkiem odmiennych towarów. Warte ustandaryzowania.
Generalnie mnie się to podoba gdyż jest to stosunkowo proste i wydaje się naturalne.
Zastanowił bym się jednak nad wykorzystaniem wskazania konkretnych asortymentów gdyż można by do JOSM wtedy dodać szablon jak dla stacji benzynowych, gdzie mamy wybór konkretnych rodzajów paliwa. Odklikanie konkretnych pozycji powinno być jeszcze prostsze niż wprowadzanie ich po kolei
shop:stock:typ_produktu=yes - wyobrażam sobie że będzie tam dokładnie to samo, co dzieje się obecnie z tagiem shop - czyli wolna amerykanka.
Istotą danych jest to, żeby dało się je zrozumieć (przez maszynę). Różne nieustandaryzowane wynalazki (bo proces głosowania pozostawia wiele do życzenia) oraz brak świadomości, że nie tagujemy dla własnej przyjemności, a - jak wyżej wspomniałem - po to, aby ktoś mógł z tych danych zrobić użytek.
Dodajmy jeszcze do tego politykę OSMF, że OSM nie dostarcza usług, a zajmuje się danymi, które inni mogą wykorzystać w swoich usługach. Jest mnóstwo programów-konsumentów OSM, których programiści są dość leniwi i opieszali we wprowadzaniu poprawek do interpretacji danych OSM (por. komercyjne projekty mapowe, gdzie klient i dane są utrzymywane przez tę samą firmę). Jeśli nie zrobimy porządku z POI, to OSM będzie zawsze o krok do tyłu względem komercyjnych map, na czele z Google Maps.
Bardzo fajne rozwiązanie. Zakładając, że po shop:stock: może się pojawić w zasadzie tylko to co może być wartością dla klucza shop oprócz convenience, department_store, general, kiosk, mall, supermarket uzyskujemy bardzo zgrabne rozwiązanie.
Czyli zakazujemy w shop:stock: tego co nie określa branży a określa rozmiar, czy charakter.
Pojawia się pytanie czy dla danego obiektu wolno powtórzyć w shop:stock: to co pojawiło się jako wartość dla klucza shop, ale raczej chyba nie powinno.
Dla mnie tag shop nie jest userdefined i dzięki temu jest możliwość łatwej analizy np. ile mamy sklepów danego typu w PL. Jeśli użyjemy tam separatora dla róznych typów to będziemy mieć sieczkę. Odradzam. Bardzo podoba mi się shop:stock:* sam używałem często nieco uproszczonej wersji np. alcohol=yes zamiast shop:stock:alcohol. Możemy z automatu wprowadzić taką zmianę.
Przemyśl którą wersję:
shop:stock:alkohol=no
shop:stock=alkohol
Pierwsza wersja pozwala dać wartość yes/no
Czyli można zrobić listę towarów standardowych i zaznaczyć, że właśnie danego towaru nie prowadzą.
W drugiem wersji wiemy, że jakiegoś standardowego towaru nie ma, dlatego że nie został umieszczony, chociaż to nie musi być prawda.
Pomyśl również nad wprowadzeniem tego schematu dla innych tagów jako “nasz” standard, gdyż mamy duży bałagan z wyszczególnianiem podkategorii danego tagu.
Na przykład: szpitale, przychodnie lekarskie, place zabaw, gabinety kosmetyczne, itd.
Byłaby długa lista.
Władku, zrób krótkie podsumowanie, bo ja nie rozumiem następujących spraw:
Jakim cudem chcesz ustawić np. shop:stock=alkohol oraz shop:stock=newspaper na jednym sklepie (czyli jednym punkcie lub jednej linii/obszarze). Gdyby dało się tak zrobić, to nie byłoby pytania Marka na początku tego wątku (bo dałoby się również ustawić na jednym punkcie/linii shop=clothes i shop=shoes, a jak wiemy się nie da).
Czy tagi shop:stock:*=yes/no traktujemy niezależnie od wartości tagu shop (wtedy da się ustawić shop:stock:clothes=yes i shop:stock:shoes=yes na sklepie z zabawkami i wiadomo, że sprzedaje on poza tym ubrania i buty), czy jednak mają to być tagi zależne od wartości tagu dla klucza shop (czyli jeśli jest shop=toys, to shop:stock:shoes=yes i shop:stock:clothes=yes dotyczą zabawkowych butów i ubrań, np. dla lalek - to wynikałoby z Twojej sugestii w wątku pytania początkujących dla sklepu z akcesoriami dla koni (choć i tam jesteś niekonsekwentny, bo żarcie dla psów i kotów nie jest “podkategorią” asortymentu dla koni).
Pierwsza Twoja informacja (shop:stock:*=yes/no) zapowiadała się na być może dość sensowne rozwiązanie dla problemu Marka, ale im bardziej wchodzisz w szczegóły, tym bardziej jest to zagmatwane i nielogiczne. Dlatego proszę o podsumowanie/doprecyzowanie :).
Ja napiszę dlacze wg mnie to rozwiązanie (shop:stock:*=yes/no) jest dobre. Po pierwsze teraz mowimy o wartościach yes/no, ale przecież mogą się tam pojawić też inne wartości jak np. limited. Nie chce tutaj sztucznie wymyślać wartości ale na pewno coś się znajdzie. Po drugie jeśli będziemy mieć shop=supermarket i damy tam shop:stock:alcohol=no będzie wiadomo, że tam alkoholu nie ma. Niewszystkie sklepy prowadzą sprzedaż alkoholu.
Po trzecie jestem przeciwny średnikom (w tagach głównych) bo gdy będziemy mieć nagle 10 wartości pod tagiem shop - co nie jest chyba rzadkie w Polsce - to parsowanie nie będzie przyjemne dla programów oraz co ważniejsze dla mapowiczów.
Po czwarte teraz łatwo możemy znaleźć dziwne tagi shop za pomocą taginfo szukając najrzadszych, gdy średniki staną się normą stracimy taką możliwość i będą potrzebne jakieś specjalne narzędzia.
Pamiętajmy, że schemat: shop/craft=<coś tam> "shop:stock:<nazwa towary lub usług>=yes/no/limited", jest podkategorią danego tagu ( w tym przypadku “shop”) i z nim związanym, a nie jako coś niezależnego.
“shop:stock:”, niezależnie, nic nie znaczy.
Jako “nazwę” powinno się wstawiać coś rozsądnego, co może być upowszechnione, a nie cokolwiek.
Czyli dodajemy dodatkowo do tagu opisującego obiekt, znacznik asortymentu:
Obiekt (jego nazwa)
Znacznik asortymentu usług (stock)
Nazwa towaru/usług
Dostępność (yes/no/limited/free/recommended)
