Zasada niemapowania pod render

Brak spisanych przykładów niedozwolonego tagowania tzw. “pod render” (TPR) jest powodem i podstawą do czynienia złośliwości.
Gdy jedni maperzy nie chcą czekać kolejnych 14 lat na to aby wszystkie ważne zaakceptowane tagi się renderowały na stylu podstawowym lub polskiej osmapie, to wykorzystują te tagi które już się renderują (oczywiście bliskoznacznych i jednoznacznych).
Od wielu lat maperzy są zachęcani do dodawania obiektów które na mapach głównych się nie renderują poprzez zapewnienia że jest grupa osób, która zgłasza największe potrzeby poprawiania renderingu oraz zgłasza kilka propozycji do wyboru a pod dyskusji jest poprawiany kod stylu i serwery kafelkujące zapuszczane w ruch aby w 1-3 dni przerobić cały świat pod nowe wyświetlanie.
Choć nie każdy potrafi w programach graficznych przygotować nowe wersje wyglądu to każdy może braki w renderze zgłaszać np tak jak tu https://github.com/gravitystorm/openstreetmap-carto/issues/339

Jest jednak pewien problem gdyż kilka dni temu jeden z programistów zasugerował że być może autor stylu carto czyli mapy podstawowej generowanej oprogramowaniem pod nazwą Mapnik, nie chce aby pewne obiekty na mapie podstawowej sie pojawiały.
Sądzę, ze po tej informacji wielu maperów jest w szoku bo mogą sie poczuć że byli oszukiwani obietnicami na ktorych spełnienie czekają wiele lat intensywnie mapując czyli być może tracąc czas na coś co nigdy na mapie podstawowej się nie ukaże.
Często padają rady aby w takim przypadku każdy wygenerował sobie własną mapę jeśli ma zastrzeżenia do tempa rozwoju carto.

Te propozycje ocierają się raczej o prowokacje i kpinę, bo skoro w grupie 3,5 mln społeczności grupie programistów zabiera tyle lat aby wyświetlić choćby podstawowe obiekty znane z legendy map papierowych, to trudno aby maperzy bez przygotowania programistycznego i bez silnego sprzętu sobie mapę skompilowali. Zresztą ci kpiarze sami nigdy się nie splamili wygenerowaniem własnej mapy więc ich propozycje traktowane są jako podyktowane złą wolą a nie chęcią pomocy.
Na polskim forum nie było wątku jak mapy kompilować.Był tylko jeden kolega który zadeklarował się że kiedyś napisze poradnik jak wygenerować mapę do druku ze swoimi ikonami.
W tej sytuacji należy rozumieć że są osoby które na wiele sposobów podkładają nogę aby nie dało się zagwarantować lub obiecać ze pewne obiekty z pewnością na mapach sie pojawią podając np horyzont czasowy 1-3 lat.
Myślę tu np o podaniu listy obiektów nad którymi prace będą trwać w pierwszej kolejności.
Jednak jeśli linkowany wyżej liścik dla ikony wieży nadawczej czeka 3 lata choć ikona już gotowa, to może zakładanie liścików nie ma sensu a ktoś celowo przeciąga zanim się wyda, że maperzy są tu murzynami i trzyma się ich przy mapowaniu fałszywymi obietnicami.Sądzę, że wielu już straciło wiarę że jest podział pracy i z tego powodu odeszło bo nie będą dodawać latami obiektów które trafiają do bazy zamiast na mapę co przypomina wrzucanie do kosza (bez opróżniania go).

Ta niejasna sytuacja powoduje wiele kłótni oraz pozwala co poniektórym nadgorliwcom którzy urodzili sie za późno aby wstąpić do ORMO, psuć dane kolegów którzy cieszyli się, że znaleźli sposoby tagowana czy rysowania pozwalające wyświetlić ciekawe i istotne obiekty.
Aby nie wracać do starych dyskusji powiem że najczęstszym sposobem pomagania renderowi na wyświetlenie obiektów dla których dotąd (a może nigdy w przyszłości) nie udało się opracować kreski czy ikony jest opisanie literowe obiektu poprzez nadanie mu nazwy np.Spichlerz z XVII. Pomnik przyrody, Lipa z XVIII w. itd . Tak czyniono przez setki i tysiące lat aby mapa nie zawierała setek ikon bo nikt by ich nie spamiętał a legenda mapy byłaby większa niż mapa, zaś w mapach elektronicznych trzeba by wychodzić z mapy w tryb legendy.

Wobec braku wyjaśnień co jest pożądane a co szkodliwe i dlaczego, należy uznać, że ci co dane psują zdejmując obiekty z mapy i chowając do bazy lub kasując całkowicie, po prostu tych obiektów na mapie nie potrzebują. W rozmowach z wieloma maperami uznaliśmy że takie psucie danych wypełnia z pewnością znamiona wandalizmu i jest dużo bardziej szkodliwe gdy hurtowo kasuje doświadczony maper niż narobi bałaganu początkujący gdy robi to nie złośliwie a z niewiedzy. Wojenki edycyjne dotyczą głównie subiektywnych danych jak np kategorie dróg ale można się zabezpieczyć przed wandalizmami przy kwestiach oczywistych bo tagi są precyzyjne i logiczne więc da się spisać np niedozwolone zestawieni tagów dla typowych często występujących w realu obiektów.

Tu kluczowe znaczenie ma wiki, która jeśli czegoś zakazuje to i u nas musimy się do niej stosować.
Wiki podaje 2 przykłady TPR
http://wiki.openstreetmap.org/wiki/Pl:Tagging_for_the_renderer

Pierwszy przykład dotyczy rysowania 3D na mapie podstawowej która jest mapą 2D, przy wykorzystaniu rozmaitych kresek i kolorków pobieranych z tagów landuse. W Polsce nie zdarza się takie tagowanie pod 3D ale często budynki gospodarcze rysowane są kolorowo np. bez building a jako landuse=farmyard zaś pojedyncze budynki szklarni na seledynowo jako landuse=greenhouse. Pomijając kwestię czy to z niewiedzy (najczęściej) czy dla kolorków, wypełnia to definicje TPR.

Drugi przypadek z wiki jest trochę niefortunnie opisany.Tam pokazano przykład rysownia tunelu akcelelatora LHC za pomocą tagu drogi krajowej czyli głównej.Niefortunny, bo wielu maperów mogło się bać rysować podziemne drogi a to przecież dozwolone z tym, że takie drogi są najczęściej wąskie np licznie występują w kopalniach czy sztolniach jako piesze lub co najwyzej track lub w wyjątkowych sytuacjach jako service.te dwa przykłady są tak oczywiste że rozciąganie TPR na mapowanie z wykorzystaniem dopasowanych do obiektów tagów świadczy albo o głupocie albo o złej woli.
Takie sytuacje psucia czy obrażania maperów były tak częste, że wiki przed tym przestrzega.Zresztą ta przestroga to gro treści w opisie TPR więc niezrozumiale dlaczego wandale i psuje się do wiki nie stosują.

Cytuję: "Wyrażenie “Tagowanie pod renderer” a zwłaszcza “Nie taguj pod renderer” ma długą historię w OSM i jest często źle rozumiane. Sens tego wyrażenia jest przypuszczalnie znacznie bliższy następującemu:
Nie wprowadzaj celowo nieprawidłowych danych ze względu na sposób ich renderowania.

ale musimy pogodzić się z tym, że w powszechnym użyciu jest tamto wyrażenie. Podstawowym dobrym zwyczajem jest unikanie stosowania niewłaściwych tagów lub w inny sposób przekłamywania wprowadzanych danych tylko po to, by zostały one wyświetlone w określony sposób na mapie.
Wyjaśnienie:
Często spotykanym nieporozumieniem jest, kiedy ludzie mówią, żeby nie “tagować pod renderer” chociaż użyte tagi są precyzyjne i klarowne. Dla przykładu, jeśli specjalistyczna mapa wyświetla pewien specjalistyczny znacznik (np. miejsce gniazdowania rzadkich ptaków) wówczas używanie tagów, które ten renderer rozumie jest całkowicie uzasadnione i to nawet jeśli nie zostały one oficjalnie zaakceptowane.

Zatem jeśli ktoś użyje do opisu masztu nadawczego tagów man_made=mast lub man-made=tower +tower:type=communication to używa tagów “precyzyjnych i klarownych”, bo granica między wieżą nadawczą a masztem nadawczym jest minimalna a oznacza wysoki wąski obiekt ponad zabudową czy lasem służący do łączności.Nikt tu nie używa do wyrenderowania masztów tagów przeznaczonych np. do renderowania dróg czy zagospodarowania terenu.Oczywiscie ogrodzony teren wokół masztu można otagować jako landuse=commercial czy nawet nadać name=GSM czy, TV z tym że dodawanie do name operatora jest raczej sporym błędem choć społeczność może zadecydować czy taką informacje można dublować, bo n.p jest bardzo istotna z punktu bezpieczeństwa bo zwykle właściciel tel.komórkowego ma niemożliwy roaming krajowy.
Podaję ten przykład bo wczoraj na naszym forum padły sugestie że użycie głównych tagów czy też stosownie ich zamiennie bo łącznie się nie da (ten sam klucz man_made) byłoby jakoby psuciem mapy czyli TPR.
Przykład jest tak oczywisty, że dobrze służy wykazaniu niezrozumienia zasady TPR.
Jak pisał kolega wmyrda wiele energii wkładamy w rozbudowywanie opisów na wiki ale brak podstawowych opisów co jest psuciem mapy a co jej służy
Dziwne, że tyle czasu tolerowano kłótnie i wojny edycyjne zamiast zebrać z nich wnioski i jasno napisać czego nie wolno robić (a co nie jest zabronione jest dozwolone). Na koniec przypomnę to co często koledzy podnoszą, że wiki jest dość elastyczna i pozwala odstępować od jedynego zestawu tagów, zresztą dzięki temu OSM się rozwija bo gdy jakiś niezatwierdzony tag jest często stosowany to i render się na niego nastawia jak i wiki nie tylko nie zabrania ale wskazuje jako nowy typ tagowania. Nawet wskazuje stare tagowanie jako przestarzałe co daje przyzwolenie na przerabianie starych tagów na nowe.

Zarezerwuję po tym obszerny wyjaśnieniem okienko na post gdzie bez dyskusji, alfabetyczne spiszemy niedozwolone kombinacje i sądzę że będzie ich na tyle mało że każdy spamięta.Zatem w 3-cim poście możemy w tym wątku dyskutować jeśli zasada TPR budzi w kimś wątpliwości. Sądzę, że we wstępie opisałem wszystkie motywacje i nieporozumienia jakie zbierały się latami dlatego musiał być długi.

Tu jest zarezerwowane miejsce na bezdyskusyjne przykłady Tagowania Pod Render, które każdy maper ma prawo przerobić na dozwolone.

Lista:

“nie mapowania” → “niemapowania” (rzeczownik odczasownikowy).
Proszę o poprawienie, a ten post można skasować.

PS: Tytuł wątku może poprawić jego autor, nie potrzeba do tego moderatora…

Ale zwróciłeś uwagę, że artykuł, na który się powołujesz, zaraz po “precyzyjnych i klarownych” tagach objaśnia:

Czyli istotą jest tu, że użycie tagów, których widok domyślny (ani żaden popularny) nie wyświetla, żeby oznaczony obiekt wyświetlił się w określony sposób na specjalnej mapie jest OK. Inaczej: dowalenie jakichś dodatkowych tagów, interpretowanych tylko przez jakieś specyficzne narzędzie nie jest tagowaniem pod renderer. Tyle i tylko tyle wynika z artykułu na wiki.

Natomiast użycie tagów jednego obiektu dla oznaczenia innego obiektu, mającego zdefiniowany własny, specyficzny zestaw tagów pozostaje tagowaniem pod renderer i będę się upierać, że oznaczanie masztów jako wież (czy odwrotnie) jest nieprawidłowe.

OSM, to jest przede wszystkim baza danych, to w tej bazie odwzorowujemy, co jest w terenie. Tam mają być dane możliwie dobrze odwzorowujące rzeczywistość, bo potem na podstawie tych danych można rysować różne mapy. Jeśli zafałszujesz dane, nawet “tylko troszeczkę”, po to żeby popularny renderer pokazywał obiekty, których normalnie nie pokazuje, to inny, specjalistyczny renderer (który może już istnieje, albo w przyszłości ktoś go zrobi) będzie pokazywać fałszywe dane komuś, komu może zależeć na odrożnieniu obiektów, którym zmieniłeś tag, od obiektów, które normalnie oznacza się tagami, które zafałszowałeś.

Rendererów już jest mnóstwo, może je sobie pooglądaj, moze któryś Ci podpasuje? Styl domyślny nie jest jedynym, który można sobie wydrukować, jeśli akurat to chcesz zrobić. Na upartego, możesz nawet wyciągnąć overpassem obiekty, które uważasz za istotne, przypisać im ikony, jakie sobie wymyślisz i to wydrukować…

Pojadę z praktycznym przykładem: zmapowałem (naprawdę dokładnie) POI w Galerii Metropolii w Gdańsku, po czym kolega kukułka przesunął kilka, argumentując tym że zasłaniają napis Galeria Metropolia. Potem dostałem takie PW:

Co robić?

Podawałem kilka dni temu podobny przykład kościoła na skalę europejską, który po odremontowaniu trafi zapewne na europejską(światową) listę dziedzictwa.Tam też był konflikt między tagami na obrysie z ikoną.
W moim przypadku ważniejsza informacja czyli name mówiące, że nie jest to zwykły kościołek wiejski, przegrała z ikoną i nie chciało mi się robić śledztwa dlaczego. Prawdopodobnie tagi na ikonie i obrysie tak się różniły, że render zgłupiał.

Mój przypadek jest łatwy i można zrobić regułkę do takich konfliktów.
Do Twojego przydałoby się w końcu uruchomienie tagów label czyli zamiast przesuwać POI spróbować przesunąć name.Też nie lubiłem np. indoor przewidując kłopoty.
Potrzeba myśleć kategorią jakich danych ludzie szukają. Oczywiste że priorytet ma Galeria. Wydawałoby się to proste, że do pewnego zooma renderujemy name, bo POI i tak by na siebie właziły. Może POI za wcześnie się wyświetla a nie że MPK używa złego zooma.

Już o tym wcześniej pisałem, że na OSM maperów traktuje się jak durniów wierząc, że automat da sobie radę wszystko porozsuwać i dopasować lepeij niż ludzie.
Potem jest tłumaczenie, że co jest proste u nas komplikuje się np. w Chinach gdzie napisy większe. Zamiast dać ludziom mozliwość (tagi) do decydowania w specyficznych sytuacjach o tym na jakim zoomie POI ma się wyświetlić, pozostawia się im jedyną mozliwość robienia roszad w geolokalizacji. Jeśli jeden render słuchałby się wskazówek label czy ukosowania napisów, inny render mógłby sobie to olać.

Musimy mieć świadomość, że im gęstsze będą dane tym częściej rozmaite interesy będą naruszane i tym częściej ludzie będą kombinować.
Zatem jeśli globalnie nie podamy rozwiązań, każdy będzie starał się wymyślać swoją metodę i większość będzie zła.

Ikony wymyślono po to aby ominąć konflikt wielu wielu długich name. Zatem ikona to informacja drugorzędna a raczej sposób na zmniejszenie problemu. Czyli metoda/narzędzie ratunkowe nie może zabijać danych głównych.
Samym ikonom i name też można nadać tagi podobne do layer aby to maper decydował, które POI powinno się wyświetlać pierwsze bo w kazdym kraju może być inna hierarchia POI.
Ale właśnie nadawanie maperom praw do decydowania o wyglądzie renderu niebezpiecznie koresponduje z szafowaniem zasadą TPR co może tłumaczyć blokadę bardzo potrzebnej funkcji label.

Mało wierzę w rozmaite tłumaczenia wad renderu.Ostatnio coraz częściej wskazuje się na główny powód tzn że co da się zrobić w Europie nie zadziała w innych miejscach.

Wiele takich barier zaczyna do siebie pasować .Można je sprowadzić do tego ze o stylu decydują programiści czyli osoby wierzące w “sztuczna inteligencję” czyli ze regułki można tak rozbudowywać ze będą zawierać wszystkie możliwe przypadki.
Nie przeszkadzają im białe plamy i nawet nie starają sie podać horyzontu czasowego rozwiązania pewnych problemów.
To jest jak z krzyżówką, że im bliżej końca tym idzie wolniej. A my ciągle tworzymy nowe tagi i skoro już dziś render dostaje pata to co będzie za kilka lat.
Nawet w tej dyskusji informatycy podbijają aspekt teoretycznych konfliktów na mapach, których jeszcze nie ma i nie słychać aby powstawały.W imię tych konfliktów lepiej (ponoć) spowolnić rozwój renderu czy krytykować stosowanie tagów bliskoznacznych.
Dla mnie to zabetonowywanie OSM czyli obrona tego co już się udało zrobić.

OSM to baza danych na podstawie której m.in. można stworzyć mapę. Programiści tworzący styl osm-carto (przypomnę że są wolontariuszami tak jak i zwykli maperzy) stoją przed najstarszym problemem kartografów, czyli co jest na tyle ważne by wyświetlić na mapie, a co nie jest. I robią to na skale globalną, próbując pogodzić wymagania niezliczonych kultur użytkowników.
Jedną z możliwości na przezwyciężenie tego problemu byłoby rzeczywiście wymaganie tagu label i nie przejmowanie się innymi rzeczami. Ma to jednak szereg wad.

1. Należałoby się zgodzić we wszystkich regionalnych centrach OSM nad hierarchią tagów.
2. Mapa w każdym miejscu globu wyglądałaby inaczej. Pewnie w niektórych miejscach mogła by być nieczytelna dla osób przyzwyczajonych do czytania mapy z innych części świata.
3. W przypadku gdyby wewnątrz danej społeczności nie doszłoby do ugody, wewnątrz danego państwa wygląd OSM byłby nie spójny.
4. Należałoby szkolić nowych maperów do używania nowych tagów, w momencie gdy staramy się zmniejszyć trudność zaczęcia przygody z OSM.
5. Mogłoby dojść do swoistej “inflacji” wyświetlanych nazw na miejsce. “Moja wioska jest dużo ważniejsza od wioski obok”.
6. Dopuścilibyśmy do bazy kolejną grupę tagów które istnieją tylko na potrzeby utrzymania ładnego stylu. Nie będą one miały żadnego odzwierciedlenia w rzeczywistości i prawdę mówiąc po opracowaniu zadowalającego stylu dla całego świata nie będą miały żadnej wartości (“śmieciowe dane”).

A i najbardziej typowym przykładem mapowania pod render jest dodawaniu tagu name i dodawanie napisu w stylu “Mój dom”. Drugim w moim przekonaniu to dodawanie opisu obiektu do nazwy: np. “Droga” lub “Budynek”.

nic ważnego. dousunięcia