W toku dyskusji trochę nieoczekiwanie skrystalizował mi się pomysł na reformę tagowania i nawet wygląda na to, że można ją podzielić na różne stopnie trudności i pracochłonności (trochę tłumaczę to, co opisałem na https://lists.openstreetmap.org/pipermail/talk/2015-March/072375.html).
Docelowo myślę o załatwieniu szerszych problemów związanych z tym, że na początku był to lokalny brytyjski projekt złożony z prostych, zdroworozsądkowych obiektów w średniej skali, ułożonych w wygodny system:
- Nasze schematy tagowania coraz bardziej się komplikują i zamieniają powoli w nieskończoną listę szczególnych przypadków, a duże systemy powinny mieć swoją logikę, dzięki czemu nawet nie znając szczegółów można po nich skutecznie nawigować - nawet bez ciągłego szukania na wiki.
- Niektóre “proste” obiekty okazują się złożone - na przykład trzeba oddzielać formę od funkcji (2a. np. “building=church + tourism=museum”) albo mają więcej równorzędnych funkcji (2b. sklepy typu mydło&powidło, np. “shop=fashion + shop=jewelry”?..).
- Drogi są u nas reprezentowane jako bezwymiarowe linie (lub o stałej, predefiniowanej grubości na mapie w zależności od od typu) - ale w większym zbliżeniu, które już mamy, widać że to fałszywe założenie (więc to nie tylko kwestia tagów w mikromapowaniu).
- Świat jest dużo bardziej różnorodny, niż to, co widać na ulicach Londynu (więc i w dużej skali nie jest lekko, a w dodatku kojarzy się to z kolonializmem).
Co można zrobić:
4. Jako Europejczyk nie wiem za bardzo co z tym zrobić, bo Warszawa aż tak się nie różni (choć nie zawsze wiadomo jak tłumaczyć obiekty) - pewnie trzeba nadal powoli rozszerzać i uogólniać.
3. Prosta sprawa - wystarczy wdrażać propozycję Marka (http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area ).
2. Tu już zaczynają się schody (2a. to w rzeczywistości pewne oszustwo, czyli ukryta zmiana znaczenia tagu, bo building=church zapewne długo nie był traktowany jako sama tylko forma budynku, tylko typowy kościół, który nie wymaga dokładniejszego określania - przecież “koń jaki jest każdy widzi”; 2b. z kolei to techniczny problem związany z przyjęciem płaskiego modelu klucz=wartość).
- Trzeba przynajmniej częściowo reformować sam system (nie ma lekko!).
Najprostsze, co można zrobić, to uporządkować bałagan z obszarami na wzór tego, co mamy z budynkami. W skrócie mówiąc nie mamy ogólnego schematu oznaczania obszarów, o których nie wiemy za dużo - nieznany budynek możemy zawsze opisać jako building=yes, a dopiero potem uszczegóławiać, natomiast jeśli mamy teren zadrzewiony i nie wiemy, czy to ma być landuse=forest, natural=wood, landuse=orchard itp., to trzeba zgadywać, bo nie ma nic bardziej ogólnego. Tymczasem moim zdaniem można by użyć area=trees. Co więcej - area w zasadzie poza yes/no nie jest w ogóle używane i można by to wykorzystać do oznaczania także innych ogólnych obszarów - np. area=grass, gdy nie wiemy, czy to ma być landuse/landcover=grass/grassland/meadow itp.
Oczywiście to nie jest zupełnie proste, bo area=* zapewne nie występuje samodzielnie, a to, że nie jest zajęte przez inne wartości, ma też swój duży minus, bo nie można się powołać na żaden uzus, a to automatycznie bardzo osłabia taką propozycję. Traktuję to jednak jako eksperyment w kwestii metody opracowywania tagów - do tej pory jest to ruch oddolny plus propozycja, natomiast uważam, że po 10 latach potrzeba też porządków robionych z szerszej perspektywy i od góry.
Przyjęcie area=* jako samodzielnej, ogólnej przestrzeni nazw dla obszarów to pikuś wobec pomysłu, żeby odejść od obecnego modelu i zacząć się szerzej bawić w “cegiełki” pojęciowe. Nie jest istotny zapis, tylko zbitki - przykłady rozjaśniające istotę tej koncepcji:
education + children_facility → obecna “szkoła” (amenity=school)
police + education → akademia policyjna
education + transport → szkoła jazdy
children_facility + daycare → placówka opieki dziennej nad dziećmi
adult_facility + daycare → placówka opieki dziennej nad osobami dorosłymi
adult_facility + gaming → kasyno
transport + police → jakieś (bliżej nieokreślone) miejsce stacjonowania pojazdów policyjnych
service + food → jakiś punkt żywienia (nie wiemy, czy to fast food, bar czy restauracja)
service + police - > posterunek policji
itp. itd. (wcale nie musi to być zbitka dwuelementowa - można dokładać kolejne, byle z sensem)
To system, który z kolei mi przyszedł do głowy w związku z przypadkiem 2a., czyli rozbiciem dotychczas rozumianego kościoła na typ budynku i funkcję. Dzięki temu mamy bardziej ogólne narzędzie i jeśli powstanie przybytek jakiejś nowej grupy religijnej, to wystarczy dodać amenity=place_of_worship, żeby od razu wiedzieć do czego służy, a zarazem jeśli do budynku kościoła dodamy np. tag amenity=warehouse, to też wiadomo, że to budowla obecnie zdesakralizowana i nawet do czego teraz służy.
Uważam, że z takich standardowych obiektów (typu amenity=school) należałoby odtworzyć katalog bardziej podstawowych pojęć i przede wszystkim stworzyć mapowanie 1:1 popularnych obiektów starego typu na nowe zbitki, a potem pozwolić ludziom na swobodne mieszanie tych cegiełek.
Pozwoliłoby to zachować stabilność systemu w etapie przejściowym (arbitralnie uznajemy, że pewne zbitki są zarezerwowane dla dotychczas używanych pojęć), a jednocześnie znacznie poprawiłaby się czytelność schematu. Bez zaglądania na wiki (choć oczywiście warto to robić dla osiągnięcia jednoznaczności) można podejrzewać, że np. area + trees (teraz już jako zbitka, a nie ścisła para klucz=wartość) to skupisko drzew, work + trees to zapewne tartak, work + furniture to fabryka mebli, a shop + furniture to sklep meblowy.
Dalej to już kwestia kierunku rozwoju takiego systemu, ale mamy elastyczność i jednoznaczność (przyszpilamy niektóre zbitki dla konkretnych celów), a dodatkowo można lepiej wyławiać nowe uzusy korzystając z taginfo, bo kombinacje składają się z prostszych, powtarzalnych elementów, gdy obecnie jakiś złożony obiekt można opisać różnymi nazwami. Tu jeszcze przydałoby się uwzględnienie hierarchiczności, czyli żeby można było od takich płaskich zbitek dochodzić do rzeczy bardziej ustrukturalizowanych i szczegółowych gdy zajdzie taka potrzeba, czyli coś na wzór obecnego kaskadowego stylu: highway=construction + construction=service + service=parking_aisle .
Jestem bardzo ciekaw, co o tym sądzicie - zarówno o diagnozie problemów po dekadzie działania OSM, proponowanych rozwiązaniach, szansach na wykonanie i sensie czy metodach ich ewentualnego wprowadzania tudzież o dostrzeżonych dużych i małych błędach w myśleniu. Generalnie czekam na komentarze. =}