ale zasadniczo kłania się chyba kulawa generalizacja całego modelu tagowanie/wyświetlanie. Przy pewnym oddaleniu po prostu park powinien być pokazywany bez wszystkich obszarów trawy, podobnie cmentarz bez alejek, obszary szkół bez boisk itp. Ale w tagach nie widać, że ten trawnik należy do parku i w szerszym widoku powinien być “zniknięty”, żeby nie zasłaniał istoty rzeczy, natomiast ten drugi jest samodzielny i nie powinien znikać, bo nic nie zakrywa.
3 h) - tak jest we francuskim stylu i technicznie to jest już możliwe (jest już Mapnik 3 na serwerach OSM), ale nie rozstrzygnęliśmy dotąd, czy to ma sens w osm-carto:
A możnaby teoretycznie użyć tutaj is_in? W sensie, że gdyby elementom dodać tag is_in, wskazujący na park, to poniżej pewnego przybliżenia te elementy by znikały. A które to byłoby pewne przybliżenie mogłoby zależeć od wielkości parku, i.e. im większy parka, na tym niższym przybliżeniu znikają elementy otagowane is_in=park.
A nie byłoby prostszym i bardziej ogólnym rozwiązaniem, gdyby przy renderowaniu kafli, dla określonych klas obiektów liczyć, ile ich wystąpi na kaflu i na tej podstawie podejmować decyzję, czy je rysować na kaflu? Jeśli liczba obiektów danego rodzaju na kaflu jest mała, to rysujemy, jeśli większa - to nie.
Wtedy odpada kombinowanie, co jest terenem zabudowanym, a efekt pokazywania np. bankomatów wcześniej, jeśli w okolicy jest ich mało uzyskujemy automagicznie.
O ile rozumiem is_in dotyczy konkretnych obiektów, a nie typu. Ja to widzę tak, jak tag parking_aisle, który wskazuje, że to jest droga parkingowa, ale nie że jest częścią parkingu o nazwie FooBar. I o takich uzupełnieniach myślę - tudzież od razu tag typu highway=corridor (czyli wiemy, że “należy do budynku”), który pozwoli wyświetlać korytarze w budynkach znacznie później niż ogólne drogi dla pieszych, o których nic dokładniej nie wiemy:
Dla trawników i innych obiektów w parku to może być problem wymyślić odpowiedni tag, a relacja to by było chyba za ciężkie. Musiałby chyba Mapnik dawać taką funkcję jak wykrywanie kontekstu, a może jakimś SQL-em? Tak czy owak to już poważna zabawa, bo kod osm-carto już jest ogromny i pewnie nikt go już nie ogarnia w całości.
W tej chwili mamy tylko parametr odpowiedzialny za minimalny odstęp między ikonami (jak będzie gęściej, to nie wszystkie się wyświetlą) oraz możemy uwzględniać powierzchnię (way_area), żeby móc inaczej traktować obiekty większe, a inaczej mniejsze. To chyba wszystko co mamy jeśli idzie o kontekst. Jak rozumiem to pierwsze nie wystarczy, żeby coś wyświetlić na wcześniejszym zbliżeniu, to działa tylko w bieżącym.
Dziękuję wszystkim, którzy odpowiedzieli, a w szczególności koledze Kocio za podlinkowanie konkretnych bilecików. Cieszę się że zgadzacie się z większością moich propozycji, lub przynajmniej dostrzegacie problemy.
Po przejrzeniu kilku dyskusji pod bilecikami i ponownym przemyśleniu sprawy, dochodzę do wniosku, że najlepszym rozwiązaniem będzie powrót do pomysłu stworzenia polskiego stylu OSM (na zasadzie np. stylu francuskiego), z area:highway włącznie. Cenię swój i wasz czas, a użeranie się na Githubie z ludźmi, którzy żadnych większych zmian nie chcą będzie tylko jego stratą. Idąc tą alternatywną drogą testowalibyśmy punkt po punkcie propozycje zmian z listy i ewentualnie proponowali je do Mapnika z gotową wizualizacją.
Ostatni raz sprawa utknęła na braku serwera, nie wiem czy od tego czasu coś się zmieniło? Co Wy o tym sądzicie i czy byliby chętni do zaangażowania się w to? (głównie mam na myśli osoby już teraz zajmujące się projektami zmian, ja niestety pisać kodu mapy nie potrafię, więc zostaje mi tylko kartograficzna analiza mapy i podsuwanie uwag)
3 g) - wydaje mi się dość sensowne - leisure=stadium było często używane do terenu stadionu, natomiast sam budynek stadionu to pewnie po prostu building=stadium.
Co do vending_machine to pytanie jak to wyświetlać - jako ikonkę maszynki, czy może jak sklep z takim towarem? Pierwsze dałoby szybkie pokrycie wszystkich takich obiektów, ale mnie się wydaje, że dla użytkowników ważniejszy jest asortyment, czyli żeby było od razu widać, że ten sprzedaje papierosy, a tamten napoje:
Pijesz do zmian w kolorze wody? =} Ja tam wolę spokojnie taką dużą zmianę omówić, bo to na dłuższą metę ułatwia pracę i zwiększa zaufanie ludzi w zespole, a czasem jakiś problem faktycznie wyniknie. Nie szkodzi, że jakieś argumenty mogą się wydawać bez sensu - dla zgłaszającego mają sens, a to ma być styl dla szerokiej publiczności.
Tu pozwolę się nie zgodzić. IMHO własny styl to ostateczność i tak naprawdę należy pracować nad rozwojem głównego, który mniejsze czy większe ale jednak kroki do przodu (choć często po skosie lub w bok) to wykonuje. Tworzenie kolejnego stylu będzie powodować rozdrobnienie zasobów, problemy z aktualizacjami widoku względem głównego etc. Jeśli już miałby powstać osobny styl to najlepiej tylko wówczas jak byłby widoczny jako osobna warstwa na openstreetmap.
Zakładając danie carto szansy zauważyłem śledząc ostatnimi czasy w nim zmiany pewną prawidłowość, która wydaje się mieć istotne znaczenie. Na githubie wydaje się lepszy efekt się osiąga koncentrując się praktycznie na jednym problemie na raz i go przepychać inaczej rozmowa się rozwlecze po kilku wątkach i ostatecznie z żadnego się nic nie wykluje. Wydaje się że najodpowiedniejszą drogą jest faktycznie założyć dla każdego poruszonego problemu stosowne zgłoszenie jeśli go jeszcze nie ma i zebrać je w całość w kolejnym meta zgłoszeniu, które by je wszystkie spinało. Coś na kształt zgłoszenia “przejście z bazy danych 2.x na 3.x”. Po tym zaś zacząć kampanię na rzec zmian naciskając kolejnym propozycjami kodu/wypowiedziami/polubieniami/etc. w proponowanych tematach
Ja też tak uważam, dlatego właśnie się zaangażowałem do zmian w osm-carto, chociaż gdy zaczynałem to było wąskie grono i zasadniczo trudno było cokolwiek przepchać. Obecnie jest dużo lepiej i coraz więcej ludzi spoza ścisłej załogi się udziela, co moim zdaniem jest najlepszym wskaźnikiem zdrowia tego projektu.
Z forkami jest trochę tak, że na początku jest OK, ale z czasem rozjeżdża się kod z oryginałem i nie jest tak, że możemy mieć obie rzeczy za darmo na raz - z czasem może być brak tego, co się poprawiło w oryginale. Mnie się bardzo podobał styl francuski, zwłaszcza że miał tyle ikonek dla sklepów, ale dziś nie tylko w osm-carto mamy ich dużo (do czego osobiście przyłożyłem rękę), ale są lepsze i bardziej spójne, w dodatku od razu gotowe do wysokich rozdzielczości, bo wektorowe. Mamy coraz lepsze kolory obszarów i drogi po rewolucji Mateusza - a francuski fork przestał się rozwijać i nie ma jak w łatwy sposób dorzucić naszych poprawek, bo tam jest tylko cquest chyba. Tymczasem my powoli sobie wdrażamy jego wybrane pomysły i rozwiązania, bo jest nas więcej aktywnych.
Słuszna uwaga z tym dzieleniem na małe porcje - tylko tak to działa skutecznie. Grupowanie nie musi być w GitHubie, bo to robi zespół opiekunów wedle uznania, ale co szkodzi mieć np. stronę wiki z linkami, stanem wykonania i uwagami? Tak, jak to koordynujemy dla tłumaczeń (swoją drogą też bym to wolał na wiki, a nie gdzieś u Googla). A na pewno głosy wsparcia świadczą, że więcej ludzi za tym stoi i ma to znaczenie. Czasem decyzje podejmujemy trochę na ślepo, np. z ikonką dla delikatesów odezwały się tylko 3 osoby i to już musi wystarczyć. Ale więcej głosów to lepiej - także więcej pomysłów i argumentów oraz więcej osób gotowych coś zrobić: kod, ikonki, testy, przeglądy…
Co sądzisz o tym, aby poszukać jakiegoś eksperta od kartografii z prawdziwego zdarzenia, który oprócz uniwersalnej wiedzy ma pojęcie na temat specyfiki różnych rejonów świata? Ja wiem, że prawie nic nie wiemy (poza tym, co zgłoszą nam lokalsi). Przykładowa kwestia to Japonia: jak zostało wskazane, o wiele inaczej nawigują oni po mieście (tj. wg nazw skrzyżowań).
Zarówno Google jak i Bing większość dróg mają tam zmapowaną powierzchniowo (czyli area:highway). Dalej, specyficzna sieć drogowa (zarówno funkcjonalnie, jak i z punktu widzenia momentami nierealistycznej oficjalnej klasyfikacji). To tylko jeden kraj, nie wspominając o specyfice np. Afryki. Ktoś kto ma doświadczenie pomógłby nam to ogarnąć.
Fajnie by było zgadać się z ludźmi od OSM2VectorTiles teraz gdy po “aferze mapboxowej” opracowują własny schemat kafelków wektorowych. Teraz, gdy rastry można generować z nich równie łatwo, to mógłby być “domyślny” format dla każdego kto chce hostować OSM.
Widzę tu szansę zrobienia drugiego, bardziej “produkcyjnego” de-facto stylu OSM nie odstającego od reszty komercyjnych map - odchodzącego od dominacji mapy obiektami powierzchniowymi na rzecz POI (wraz z klikalnością). Można spojrzeć na możliwości które daje przetwarzanie nie w czasie rzeczywistym (co jest niemożliwe w carto które musi być aktualizowane co minutę) - w kwestii generalizacji mapy i nie tylko.
3 poza konkursem) Dobrze, że carto i JOSM-em ktoś od naszych się zajmuje, ja natomiast myślę, że iD także potrzebuje aktywizacji maintainerów (tak jak to nastąpiło z carto). To stamtąd pochodzi duża część edycji OSM, ale i błędów. Naturalnym jest, że wiele z nich unikniemy dopieszczając edytor. Całe szczęście JS jest dość popularny.
Ja mam ograniczone zaufanie do ekspertów kartografii, czy w ogóle ekspertów. Na osm-carto mamy teraz mieszankę różnych postaw (od ekspertów do entuzjastów i ludzi zgłaszających pojedyncze problemy), ale kiedy zaczynałem, dominowało poczucie, że jest wreszcie przepisane na czysto z XML na Carto i żeby tego nie zaśmiecać. Nie było decyzyjności i jak rozumiem to wynikało po części z poczucia, że jest dobrze zrobione i po co psuć. Ale to nie uwzględniało potrzeb społeczności. Ja rozumiem teraz, że różne ograniczenia wynikają także z powodów wydajnościowych albo jakichś konwencji, ale widzę też, jak wiedza specjalistyczna potrafi zakryć problemy użytkowników, zwłaszcza, że OSM to nie jest typowy projekt GIS.
Pewnie nikt z ekspertów nie robi uniwersalnego stylu dla całego świata na wszystkich poziomach przybliżenia, bez gotowej ontologii obiektów, które chcemy wyświetlać, a w dodatku z czasem się to zmienia, bo tagi nie są raz na zawsze ustalone. Nie sądzę (to moje wyczucie), żeby przeciętny pojedynczy ekspert obejmował wszystkie ważne problemy kartograficzne na całym świecie - najwyżej per kontynent albo dwa.
Rozumiem, że pytanie dotyczy osobnego stylu - wtedy może się przydać, byle krytycznie podchodzić do jego/jej pomysłów. W przypadku osm-carto może by się przydało kilka rad, ale problemy widzę głównie w ograniczeniach narzędzi informatycznych (Mapnik, Carto, SQL), jakich używamy.
Ciekawostka wektorowa: jest taki sprytny fork, który wykorzystuje styl osm-carto do reprezentacji wektorowej, co umożliwia gładką migrację, a nawet równoległe serwowanie kafelków rastrowych i wektorowych:
Jeszcze jedna rzecz, a propos klikalnej warstwy POI, która powraca w różnych marzeniach o rozwoju: moim zdaniem to najbardziej realistyczna rzecz, którą można wykonać i wdrożyć własnymi siłami. Osobne style rastrowe, wektorowe kafelki, area:highway i 3D - to wszystko fajne, ale trudne. Natomiast jeśli udałoby się zorganizować zasoby ludzkie i sprzętowe, żeby powstała taka warstwa, to można zawnioskować o dodanie do strony OSM. Warunki są znane:
Odświeżanie może nie być nawet codziennie, maksymalnie raz na dwa tygodnie, więc pozostaje kwestia obsługi światowego ruchu no i stabilnego działania, czyli obsługi admińskiej. Odpada kwestia renderowania kafelków i kombinowania jak wyświetlić mnóstwo różnych obiektów, ilość danych powinna być mniejsza (przecież nie musimy wszystkich rodzajów punktów wyświetlać od razu, tylko zacząć od wybranych rodzajów - jak np. tu: http://open.mapquest.com/ ), tym bardziej jeśli to nie byłaby warstwa automatycznie włączona, tylko dla chętnych, którzy sami to zrobią.
Jeśli to by się udało zorganizować, to już byłoby zwycięstwo dla wszystkich, a z czasem można sięgnąć po te bardziej ambitne cele, bo czemu nie?
To jak z tymi tanimi dyskami w chmurach i techniczną prostotą? =}
Ja widziałbym to tak, że zakres powinien być o wiele większy niż to co jest na domyślnym stylu, tak żeby nie było trzeba dopowiadać ludziom w odpowiedzi “ale to się nie renderuje”. Znacznie więcej office, craft itd. - im więcej tym lepiej. Dla porównania liczba klas (tzw. GCID) w Google Maps to >2k.
Wszelkie mapki które mamy - pokroju OSM24 itp. niestety mają ten posmak “zabawki dla nerdów”.
poprzez umieszczenie POI pokroju hydrantów, szlabanów i ławek… Oprócz skopiowania listy z Map Features i dobrania ikonek nikt nie przysiadł nad klasyfikacją POI. Czasem tag w teorii doprecyzowujący powinien stworzyć własną klasę, a czasem odwrotnie, kilka tagów znaczy to samo (choć głównie dla celów wyszukiwania).
Warto by było iść w kierunku standaryzacji presetów między edytorami oraz konsumentami. Może to “omijanie” Wiki, ale maszyny i tak wolą kod Trzeba trochę pomóc konsumentom, bo są leniwi, tutaj można zrobić z tego jakiś pożytek.
Jak napisałem - office i craft mają być jak będzie hstore. A co jest złego w wyborze najbardziej użytecznych typów punktów? Choćby po to, żeby to przetestować zanim się doda kolejne i żeby nie było hydrantów. Tagów nie poprawimy sobie w locie, choć może to dać asumpt do takiej poprawy.
Mnie jednak najbardziej ciekawią nie te detale, bo to można dogadać, tylko czy ktoś jest w stanie zorganizować taki względnie prosty serwis i go utrzymać? Żebyśmy nie pływali tylko w teoriach co “by można”, bo “przecież to jest proste”. To ja wolę sensowne minimum, ale jednak w praktyce.
Można nawet zacząć od samodzielnego serwisu z podkładem z OSM i dopiero wtedy zgłosić do dodania, jak się sprawdzi, to by była jeszcze gładsza droga rozwoju. Ale to wszystko się zaczyna od tego, czy ktoś się weźmie za organizację tego przedsięwzięcia.
Chętnie pomogę jakby co, ale na pewno nie pociągnę, bo ja akurat nie uważam, żeby to było takie proste - inaczej już dawno bym to zrobił. Ale skoro są głosy, że to proste i potrzebne, to mam nadzieję, że się mylę i faktycznie to się uda wcielić w życie.
Trzeba trochę pomóc konsumentom, bo są leniwi, tutaj można zrobić z tego jakiś pożytek.