Wizja lepszej mapy - dyskusje

Dla mnie lepsza mapa to bardziej kompletna w POI niż w adresy. Adresy są ważne, ale raczej dla nawigacji, a POI sa bardziej uniwersalne.

Ja też w tym kierunku poszedłem i dlatego np. coraz bardziej mnie interesuje serwis OSM24.eu . I w tym kontekście wyświetlanie jest słabe i laguje za wprowadzaniem danych, bo panuje rodzaj lęku przed wyświetlaniem np. shop=yes, ale nie tylko takie szerokie - wciąż wielu znanych i niekontrowersyjnych punktów nie widać na głównej mapie (taksówki, fontanny, różne warsztaty…).

Ale skoro na chwilę oderwaliśmy się od technikaliów, które przeważają w naszych dyskusjach, to wróćmy jeszcze do spraw ogólnych - Richard Fairhurst (ten od iD) napisał maila o swoich 10 latach w projekcie (niezły kawałek historii!) i co sądzi o obecnej sytuacji OSM:

https://lists.openstreetmap.org/pipermail/talk/2014-October/071237.html

Moim zdaniem obecnie osm jest lepsze dla turysty niż google maps - które wygrywa pod względem tagowania firm ale nie miejsc ogółem.

Przyszłość osm to ciągłe dodawanie danych i poprawia dokladności oraz tego co nas otacza, jeśli to będzie wysokie to mapa będzie (być może już jest) najlepsza.

Nie wiem, czy lepsze, ale na pewno dużo lżejsze - jak ostatnio wszedłem na GMaps, to się zdziwiłem, że komputer ledwo mi zipie! Już nie mówiąc, że aż przyjemnie było mi popatrzeć na nasze bogate renderingi w porównaniu z którymi Google jest na poziomie podstawowym. Oczywiście w usługach dodanych jest dużo lepsze, ale samą mapkę to sobie odpuścili.

A tak w temacie wizji - trafiła się okazja, to wywnętrzyłem się na anglojęzycznej liście talk ze swoimi pomysłami na świetlaną przyszłość OSM:

https://lists.openstreetmap.org/pipermail/talk/2015-March/072331.html

zatrudnienie ludzi - jestem zdecydowanie za, bo jak nie ma osób odpowiedzialnych za cokolwiek to jest byle jak, co kto łaskawie zrobi, a już największy bałagan to jest z tymi bilecikami do Mapnika i tutaj przydał by się ktoś kto by zaczął to ogarniać zawodowo a nie “w wolnym czasie”

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:

  1. 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.
  2. 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”?..).
  3. 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).
  4. Ś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ść).

  1. 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. =}

One word: don’t ;). Mam niedobre doświadczenia z taką właśnie nieustrukturyzowaną taksonomią. W praktyce, i tak ludzie widzieli w tym hierarchię z typami głównymi i podtypami. A gdy już jakiś automat chciał te dane podejść w poprzek, uznawał, że kino samochodowe i McDonald’s to właściwie to samo - bo oba miały na sobie tag drive-in. Podobnie Italian może być i na restauracji i na ambasadzie. Dla mnie tagi powinny jednak mieć jakąś semantykę, a czymże właściwie jest takie adult_facility? A im bardziej abstrakcyjne pojęcia opisujesz, tym trudniej w ogóle użyć takiej płaskiej chmury tagów; w gruncie rzeczy nadaje się ona tylko do kategoryzowania obiektu, nie do opisywania jego atrybutów.

Sejm jest adult_facility bo przecież nieletni głosu nie mają. :slight_smile: Tak jak murzynka nazywają afromanem pomimo, że mieszka w Londynie od kilku pokoleń. Zwykła poprawność polityczna u Anglików, wynajdują problemy gdzie ich nie ma.
Zgadzam się, że cały system tagów powinien być przede wszystkim czytelny dla oprogramowania a zaraz potem dla ludzi. Ludzie przede wszystkim oczekują od mapy że będą ikonki a nie jakieś tagi.

Dzięki za komentarze! =}

Skoro jednak mielibyśmy nadal sztywny katalog pewnych zestawów (np. service + food + drive-in → McDonald’s, road + drive-in - > dróżka typu drive-in), to zupełnie nie obawiam się pomyłki. Jazda w poprzek to zawsze może się okazać jazda po krawędzi, choć wcale nie musi - np. po building albo po police raczej da coś sensownego, ale możesz też spróbować wybierać obiekty po colour i twój biznes co z tym chciałbyś zrobić. =} Nic więc nowego co do zasady.

Być może przydałby się podział na (płasko zdefiniowaną) kategorię obiektu i (hierarchiczne) atrybuty? Przy czym prawdziwą hierarchiczność, drzewiastą, a nie taką byle jaką, jaka jest teraz, czyli zamiast kombinacji typu “elementy=element1;element2 + atrybuty=atrybut1;atrybut2;atrybut3;atrybut4” mieć:

element1
atrybut1
atrybut2
atrybut3
element2
atrybut4

Nie mam pojęcia co to może być “adult_facility” - ba, nawet mnie to nie obchodzi (sic!), bo cierpimy na zbytnie przywiązanie do gotowych, złożonych obiektów. Dlatego właśnie zaproponowałem podejście pragmatyczne i ewolucyjne: najpierw należałoby zebrać powszechnie używane tagi i dopiero z nich wyekstrahować użyteczne cegiełki, a nie najpierw wymyślanie z powietrza (tak jak ja do tych przykładów). W dodatku nie mamy z góry żadnej gwarancji, że wszystkie cegiełki będą coś użytecznego znaczyły samodzielnie (tak jak np. colour).

Ten system ma pozwolić na większą elastyczność, żeby załapało się więcej sensownych kombinacji, a nie żeby za wszelką cenę unikać bezsensownych. I tak przecież filtrujemy tylko wybrane elementy przygotowując prezentację (np. wyświetlanie zawiera tylko część porządnych tagów, a resztę ignoruje) i również dziś mamy takie powszechnie używane dziwności jak building=no, gdzie dopiero musimy się zastanawiać co to może ewentualnie znaczyć.

I w żadnym razie nie sprowadzałbym OSM do roli ikonek, bo z tym wozimy się także w tej chwili - na osm-carto trwa właśnie wielka kampania, w której nebulon42 nareszcie opracowuje nowe ikonki (bo wiele sensownych elementów nie ma na razie reprezentacji i typ tagowania nie ma tu nic do rzeczy), a w dodatku aż się prosi o uwzględnianie już dziś kombinacji, żeby np. dla historic=memorial wcześniej zacząć wyświetlać pomniki, a tablice pamiątkowe później.

Ta moja propozycja to tylko pewne techniczne rozwiązanie do rozważenia/poprawienia/odrzucenia, ale ciekaw jestem nie tylko czysto technicznych uwag, bo może tylko mnie się zdaje, że pewna formuła się wyczerpuje i trzeba szukać jej poszerzania (nowa typologia), a nie tylko pogłębiania (nowe podtypy)?

  1. Czy nowa typologia oparta na cegiełkach miałaby co najmniej tak samo dobre możliwości wyszukiwania błędów we wprowadzonych danych? Wydaje mi się, że nie, bo każdy (nawet bezsensowny!) zestaw cegiełek coś by oznaczał. A wiemy bardzo dobrze, ile błędów potrafią zrobić użytkownicy w projekcie opartym na wolontariacie takim jak osm.
    Standaryzacja jest potrzebna.

  2. Nadal będziemy potrzebować par klucz=wartość, choćby po to, aby oznaczyć wysokość, nazwę, kolor (a przy okazji sama cegiełka colour zupełnie nic nie znaczy :wink: ).

To ma sens, jeśli rozumieć to jako przyporządkowanie kolejnych tagów do już dodanych tagów dla jednego obiektu. Np. teraz jest problem, jeśli w jednym obiekcie jest hotel z restauracją i chcemy dodać godziny otwarcia, które są inne dla hotelu (nie zawsze 24h/dobę) i inne dla restauracji. Można już oczywiście napisać opening_hours:hotel=… lub hotel:opening_hours=… (bo lista używanych tagów nie jest zamknięta), ale nie jest to takie oczywiste i jednoznacznie określone (i wobec tego prawie na pewno nie będzie wspierane przez aplikacje).

“Więcej możliwości” nie znaczy “żadnych reguł”. Bezsensowny zestaw cegiełek z definicji nic by nie znaczył - bo jak zobaczymy w nim sens, to już nie jest bezsensowny i coś oznacza. O standaryzacji przecież też mówię: pewne zestawy cegiełek oznaczałyby pewne konkretne rzeczy, czyli tak samo jak obecnie pewne zestawy k=v. Wbrew pozorom przecież obecnie też można nadawać dowolne tagi, jakie sobie wymyślisz i możliwe są wszelkie (np. bzdurne natural=man_made też ktoś może nadać i będzie to prawidłowe w ramach systemu k=v), więc nie na tym polega nowość, tylko na większej spójności.

A co do błędów - to trudno powiedzieć, bo przecież błędy to bardzo szeroka sprawa. Nie bez kozery w JOSM są różne typy walidacji (i można dodawać nowe) zamiast jednego czujnika “to jest dobrze/źle”. Musiałbyś sprecyzować o jakie błędy ci chodzi najbardziej.

Hm, to może rzeczywiście w atrybutach obiektu byłoby potrzebne, czyli może należałoby zcegiełkować tylko typologię.

A cegiełka colour oczywiście, że nic by sama nie znaczyła, o tym pisałem, natomiast może w zestawie z jakąś inną już coś - kto wie? Ale to akurat mało ważne - nie fiksowałbym się na wymyślaniu teraz jakie cegiełki by wyszły.

Wspomniałem o tym wczoraj (http://forum.openstreetmap.org/viewtopic.php?pid=491945#p491945), ale wygląda na to, że nie doceniłem skali dyskusji - na liście Tagging toczą się ze 3 (sic!) równoległe, żywe wątki na temat reformy Wiki OSM:

https://lists.openstreetmap.org/pipermail/tagging/2015-March/thread.html

Jeszcze dużo może się zdarzyć, ale zasadniczo wyłania się z nich wizja odejścia od praktyki uznawania Wiki za wyrocznię i postawienie raczej na rolę informacyjną i dobre miejsce do dyskusji nad schematami tagowania. Są nawet propozycje, żeby to wyglądało bardziej jak StackExchange (https://pl.wikipedia.org/wiki/Stack_Exchange_Network), a w każdym razie raczej zostanie porzucone tradycyjne głosowanie w celu przyjęcia/odrzucenia - natomiast będzie można głosować w celu zobrazowania proporcji osób wspierających w stosunku do nie zgadzających się z danym schematem.

Wracając do Twojej propozycji cegiełek: po przemyśleniu stwierdzam, że jest to… zubożenie istniejącego schematu. Zrealizuję proponowane przez Ciebie oznaczenia (realizacje Twoich przykładów kombinacji cegiełek w istniejącym systemie tagowania są po “=>”):

  1. education + children_facility → obecna “szkoła” (amenity=school) => education=yes; children_facility=yes
  2. police + education → akademia policyjna => police=yes;education=yes
  3. education + transport → szkoła jazdy => education=yes;transport=yes
  4. children_facility + daycare → placówka opieki dziennej nad dziećmi => children_facility=yes;daycare=yes
    i dalej w ten deseń. Czy coś zyskujemy? Nic (poza tym, że w systemie cegiełek wartości “yes” nie są do niczego potrzebne, bo nie niosą żadnej informacji). Tracimy jednak możliwość ustawiania wartości (wyliczalnych jak kolor i co gorzej niewyliczalnych numerycznych takich jak wysokość, pierśnica (drzewa) itp.).

Niezależnie od sposobu tagowania wiki jako wyrocznia jest potrzebne, bo jeśli każdy będzie wymyślał własne kombinacje tagów na oznaczenie tego samego, to przy okazji te same oznaczenia stosowane przez różne osoby będą oznaczały co innego…

Starałem się abstrahować od zapisu oraz nazw cegiełek, ale widzę, że mi nie wyszło i wszyscy się trzymają bieżącego zapisu i tagów. :slight_smile: Zapis " education + transport" to tylko najprostszy sposób oddania zupełnie przykładowego zestawu - bo może po analizie istniejących tagów wyszłoby że szkołę jazdy najlepiej oddaje “cars=yes + school=yes”, a może jeszcze inaczej. Więc trudno mówić o zubożeniu, raczej o celowo uproszczonym zapisie przykładów.

Teoretycznie więc to nawet lepiej, że da się zapisać nowy schemat w starych ramach (byłoby tylko więcej nowych kluczy), ale k=v mnie uwiera swoją płaskością, więc na razie próbuję go pomijać w ogólnych rozważaniach i nadal się zastanawiam nad zapisem, który pozwoliłby na hierarchiczność drzewiastą.

A co do wiki - jest pospolite ruszenie, więc w tym wypadku to nie ze mną należy dyskutować. Nikt zresztą nie mówi o likwidacji (ani ja nic takiego nie napisałem!), tylko o przywrócenie zdrowszych proporcji między propozycjami społeczności a duchem twórczego poszukiwania - nawet jest o tym strona na wiki :slight_smile: :

http://wiki.openstreetmap.org/wiki/Any_tags_you_like

Wiki nie musi być żadną wyrocznią, żeby było użyteczne - wystarczy, że opisuje dobre praktyki.

Osobiście wolałbym, żeby było wyrocznią w jeszcze większym stopniu niż dziś :confused:

Zdecydowanie popieram.

Wiki powinna być podręcznikiem! Napisana w jasny i czytelny sposób, najlepiej tłumaczona na bieżąco - jeśli projekt ma się rozwijać.

Przychylam się obecnie wiki to pole minowe i zasieki. Cięzko tam znaleść szybko przydatne dane. OSM.pl powinnien się tym chyba zająć.

Moim zdaniem Wiki jest obecnie niedoinwestowana i dobrze byłoby gdyby się poprawiła, ale takiej roli, jakiej chyba od niej oczekujecie, chyba po prostu nie jest w stanie unieść.

Jako mapowicz oczekuję, że 1) mogę łatwo zgadnąć jak powinien się nazywać potrzebny tag, 2) będzie to gdzieś dokładnie udokumentowane, gdybym chciał/musiał sprawdzić. I to jest rozsądne i zrozumiałe, tylko niestety nierealne. Projekt jest już zbyt szeroki, ma zbyt wiele wyjątków i sytuacji granicznych i w dodatku dźwiga zbyt duży bagaż starych decyzji (lepszych dla budynków, ale gorszych dla obszarów), żeby dało się to załatwić kazuistyką - bo do tego się sprowadza idea “Wiki jako książka telefoniczna”, gdzie każdy numer jest opisany z osobna i żeby z niej skorzystać trzeba ściśle trzymać się zapisu, bo inaczej - klapa.

Ja w wizji reformy systemu tagowania stawiam bardziej na 1), czyli lepszą wewnętrzną logikę systemu, żeby 2) było mniej istotne (choć rzeczywiście nadal przydatne). Dyskusja na Tagging (“Wiki 2.0”) skupia się na samym Wiki i jeszcze nie wiem jakie będą końcowe wnioski, bo póki co - co symptomatyczne - kombinują nad zmianą systemu głosowania, ale w samej dyskusji nie bardzo wiedzą, jak głosować nad wnioskami w sprawie głosowań (sic! =} )…

I trochę to jest zabawne, ale dobrze ilustruje problem z wiki - jak coś jest trudniejsze i dyskusyjne, to jest za “ciężkie” jako narzędzie. Dlatego wydaje mi się, że ważne jest odchudzenie i model bardziej w stylu StackExchange - bo w dyskusji okazało się, że także forum ma swoje ograniczenia w tym względzie, tak samo jak lista dyskusyjna, więc to nie jest tylko problem z wiki, tylko skala decyzji i dyskusji jest zbyt wielka jak na te narzędzia. Już samo to, że dyskusja nad Wiki 2.0 zdominowała całą listę, świadczy o tym, że przekroczona została masa krytyczna problemów i już się nie da “tak jak dotąd”.

Oczywiście, można oczekiwać, że będzie więcej tłumaczeń, ale zobaczcie, ile jest jeszcze do zrobienia (po polsku jeszcze nie jest źle, pewnie dzięki wielkiej pracy Władka), żeby tylko mieć z grubsza komplet języków. A dochodzi jeszcze aktualizacja (nawet u nas widzę duże dziury) oraz wciągnięcie większej ilości uczestników do głosowań, żeby to było bardziej reprezentatywne w skali globalnej. W zasadzie właśnie od tego problemu rozpętała się cała dyskusja - bo do tego trzeba by tłumaczyć na bieżąco dyskusję w wielu językach, żeby nie było wykluczenia, skoro potem ma to obowiązywać bezwzględnie…

Nie zapominajmy, że i tak mamy potem kolejne “filtrowanie” w postaci stylów renderowania, zwłaszcza na domyślnej warstwie, więc to też ma wpływ na standardy tagowania - czy tego chcemy, czy nie, do pewnego stopnia to też jest ważne w kwestii tagowania, a jakoś Andy Allan i tak nie wdraża wszystkiego, co zostało udokumentowane i nie budzi wątpliwości.

Dlatego uważam, że Wiki dopiero po odchudzeniu i odpuszczeniu części pretensji do jej roli jako wyroczni ma szansę rzeczywiście działać. Maksymalistyczne oczekiwania rozumiem, ale wobec nich rzucam “sprawdzam” - czyli powiedzcie jak da się ten stan osiągnąć i dlaczego ogólny wydźwięk dyskusji nad Wiki 2.0 jest właśnie w kierunku odchudzenia i prezentacji różnych poglądów (czyli przerzucenie ostatecznej decyzji na użytkownika) zamiast dotychczasowego odgórnego systemu przyjęte/odrzucone?

Udało mi się w końcu wymyślić schemat drzewiastej hierarchizacji!

Zasadniczo powiedzmy, że jest ten hotel z restauracją otwarte w różnych godzinach (problem podrzucony przez Domissa) - wyrażone w obecnych tagach, ale hierarchicznie, wygląda to mniej więcej tak:

tourism=hotel
opening_hours=24/7
amenity=restaurant
opening_hours=10:00-22:00

czyli w uproszczeniu:

A
A1
B
B1

Na płasko można to przedstawić tak:

(A (A1) B (B1))

a jeśli się skomplikuje przez nowy tag A3, podrzędny wobec A2, to np. tak:

(A (A1 A2 (A3)) B (B1))

To oznacza, że ważna jest kolejność, przynajmniej w tym sensie, że rodzic (tag nadrzędny) musi stać bezpośrednio przed nawiasem z potomkami (czyli tagami podrzędnymi), bo przecież jak zamienimy całe człony:

(B (B1) A (A1 A2 (A3)))

to w sensie znaczenia tagowania jest to samo.

Ok, ale jak to zapisać w obecnym schemacie? To już zależy - każde rozwiązanie będzie miało swoje wady i zalety. Najlepiej chyba po prostu:

nested_objects=(tourism=hotel (opening_hours=24/7) amenity=restaurant (opening_hours=10:00-22:00))

(zewnętrzny nawias może załatwiać sprawę czytelności przy wielu znaków równości, ale technicznie jest zbyteczny, bo wystarczy zauważyć, że nazwa klucza to ciąg do pierwszej równaśki licząc od lewej). Wtedy tracimy czytelny podział na klucze i wartości, ale łatwo się to ręcznie modyfikuje. Można też odwrotnie - najpierw ustalamy kolejność alfabetycznie (to ważne):

amenity=restaurant
opening_hours=10:00-22:00
opening_hours=24/7
tourism=hotel

i dodajemy tylko tag z opisem struktury:

nesting=(1 (2) 4 (3))

Wówczas jest wszystko tak jak dotąd (plus jeden dodatkowy, dziwny tag), ale za to zmiana nazwy lub wartości, a nawet dodanie nowego tagu zwykle będzie wymagać zmiany elementów struktury.

Być może do tego najlepsza byłaby relacja (type=nested_objects), bo tam elementy chyba mają znaną kolejność. Choć w zasadzie można wówczas obejść się bez dodatkowego tagu i załatwić wszystko odpowiednią rolą dla tagów podrzędnych (np. “child” na pojedynczy element podrzędny, “child_start” w znaczeniu otwarcia nawiasu/grupy podrzędnej do poprzedniego elementu, “child_end” jako zamknięcie nawiasu/grupy podrzędnej). Minus jest niestety taki, że relacja dotyczy obiektów (węzłów, linii, relacji), a nie gołych tagów…

Oczywiście można też przeprowadzić rewolucję i z k=v przejść na inny zapis danych, np. jakiś rodzaj XML. :slight_smile: Bo te wszystkie zapisy są skomplikowane tylko dlatego, że nie były wymyślone jako takie od początku i to kolejne sztukowanie. Ale z drugiej strony nie wydaje mi się, żeby to był duży problem, bo wydaje mi się, że tylko mała część obiektów wymaga zagnieżdżania drzewiastego. Nawet z równorzędnymi funkcjami:

nested_objects=(shop=clothes) (shop=jewelry)

(to jest to samo co “shop=clothes;jewelry”, ale bez średnika) będzie to mniejszość. Ale dobry system polega na tym, żeby łatwe rzeczy robić łatwo (czyli jak dotąd), a trudne żeby też były możliwe - i to by było rozszerzenie właśnie do takich przypadków.

Na pewno bardzo pomogłoby, gdyby nasze narzędzia oferowały wygodną reprezentację drzewek (taką z wcięciami na przykład), ale i bez graficznej reprezentacji dałoby się tego schematu używać w tych specjalnych przypadkach, kiedy nie chcemy oszukiwać przyjmując nadmierne uproszczenia.