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.
Tagi craft=* i office=* czekają głównie na przeładowanie bazy danych (brak hstore):
https://github.com/gravitystorm/openstreetmap-carto/issues/1697
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:
https://github.com/gravitystorm/openstreetmap-carto/issues/1561
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.
Nie wiem czy to pytanie do mnie, czy do wmyrdy?
- 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:
https://github.com/geofabrik/openstreetmap-carto-vector-tiles/blob/master/README_VECTOR_TILES.md
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:
http://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers
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.
Mapa klikalna do działania wymagałaby dodatkowo wsparcia ze strony openstreetmap-website. Bez tego serwer nie bedzie nic wiedział o kliknięciu.
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.