Jasne, że im odpowiada. Jednak brak argumentów może wskazywać na różne rzeczy - w tym zwykły brak czasu albo po prostu nadzieję, że sprawa się rozpełznie po kościach. Choć dziwi mnie, że nie mają nawet w zapasie gotowych odpowiedzi “na odczepnego”, więc wydaje mi się, że jednak chodzi o to, że nie jest to przemyślane stanowisko, tylko intuicyjne przywiązanie do prostoty.
Ciekawy przypadek - ktoś sam przyszedł i z miejsca zgłosił chęć przygotowania kodu do wyświetlania sal koncertowych:
https://github.com/gravitystorm/openstreetmap-carto/issues/1677
Na wyświetlanie rzeczywiście za wcześnie - nie wiemy, czy to tagowanie się szerzej przyjmie, a na razie jest bałagan:
https://lists.openstreetmap.org/pipermail/talk/2015-July/073537.html
ale pomyślałem, że warto się zastanowić od razu jak chcielibyśmy takie miejsca wyświetlać (niezależnie od schematu, jaki się utrze), a przede wszystkim przemówić do człowieka ludzkim głosem: skoro zamiast kląć w kąciku na brak standardów i koordynacji postarał się zrobić coś pozytywnego, to warto mu podpowiedzieć co może zrobić w tej sytuacji. Zobaczymy, jak to się rozwinie, ale fajnie, że mu się chciało przeciwstawić tagowaniu pod renderowanie zamiast olać problem!
A co jest nie tak z tagiem amenity=theatre? Przecież, teatr to ogólnie miejsce odgrywania sztuki, koncert też jest sztuką.
Tylko to, że jest zbyt ogólny, o czym świadczy fakt, że powszechnie rozróżnia się teatry (w tym teatry muzyczne) od sal koncertowych. Jeśli zamiast tego schematu zostanie przyjęty schemat w rodzaju:
amenity=theatre
theatre:type=concert_hall
albo inny, w którym będzie można sale koncertowe łatwo zidentyfikować, to mnie to rybka, byle był spójny i rzeczywiście używany w świecie. Będzie o tyle łatwiej to zweryfikować, że jest ta wikipediowa lista sal koncertowych na świecie, więc którykolwiek schemat przekroczy 1000, to będzie natychmiast do wyświetlenia, bo to już ten rząd wielkości, a jak mniej, to też będzie mniej więcej wiadomo, czy jest wystarczająco powszechny.
Kolejny wciągający i fascynujący odcinek serialu o przerabianiu wyświetlania dróg, w którym Mateusz omawia ostatnie liczne zmiany i propozycje (nie kończy tylko na drogach, dotyka to także torów tramwajowych czy budynków):
http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35437
A jak ktoś nie chce tyle czytać, to polecam przynajmniej obrazki :).
Poza tym można komentować (lepiej teraz niż jak zmiany w końcu wejdą do stylu, a Mateusz reaguje naprawdę szybko i jest otwarty na sprawdzanie różnych pomysłów), no i jeszcze prośba o przykład jakiegoś dobrze zmapowanego miasteczka tym razem (jak najlepiej zmapowane landuse, budynki i dobrze poklasyfikowane drogi).
Zauważyłem jedną rzecz, którą IMHO należało by poprawić - chociaż może z jakiegoś powodu jest to zrobione specjalnie?
Mniej-więcej po środku zdjęcia widać sporą, brązową, niebieską ikonkę - dominuje na mapie, jest już na zoomie 15 i jest wielkości ikony szpitala. To jest ten node: http://www.openstreetmap.org/node/1720997782#map=17/51.77373/19.43532 - zwykłe turning_circle, tyle że na końcu highway=track. Jest znacznie większe niż turning_circle na końcu np. highway=residential - wydaje mi się, że powinno być takiej samej wielkości.
Bo jeszcze nie było wdrożenia.
Aktualnie używana wersja podana jest na https://github.com/openstreetmap/chef/blob/master/roles/tile.rb#L79
Ciekawe, czy zdążą zaktualizować żeby lodziarnie były widoczne przed końcem lata. 
@kocio - akurat do https://github.com/gravitystorm/openstreetmap-carto/pull/1696#issuecomment-125790884 moje narzędzie może się przydać (ale nie zwiększa ono szybkości TileMilla - w czasie czekania na generację przed/po warto wyjść na spacer czy zrobić obiad).
require 'cartocss_helper'
def main
tags = {'landuse' => 'quarry'}
branch_name = 'quarry-icon'
base_branch_name = 'master'
zlevels = 10..22
type = 'way' #or 'node'
test_locations_count = 10
CartoCSSHelper.test_tag_on_real_data_for_this_type(tags, branch_name, base_branch_name, zlevels, type, test_locations_count)
end
def init
#bez potrzeby zmian
CartoCSSHelper::Configuration.set_style_specific_data(CartoCSSHelper::StyleDataForDefaultOSM.get_style_data)
#gdzie jest folder ze stylem?
project_name = 'osm-carto'
tilemill_project_location = File.join(ENV['HOME'], 'Documents', 'MapBox', 'project', project_name, '')
CartoCSSHelper::Configuration.set_path_to_tilemill_project_folder(tilemill_project_location)
#gdzie powinien być folder do którego zapiszą się wygenerowane pliki?
CartoCSSHelper::Configuration.set_path_to_folder_for_output(File.join(ENV['HOME'], 'Documents', 'OSM', 'CartoCSSHelper-output', ''))
#folder na pliki tymczasowe
CartoCSSHelper::Configuration.set_path_to_folder_for_cache(File.join(ENV['HOME'], 'Documents', 'OSM', 'CartoCSSHelper-tmp', ''))
end
init
main
(jak zainstalować cartocc_helper - jest na https://github.com/matkoniecz/CartoCSSHelper#installation))
A, uwagi na temat działania/niedziałania są mile widziane (najlepiej przez https://github.com/matkoniecz/CartoCSSHelper/issues))!
Sporo tego nawet względem pierwotnej propozycji. Kawał niezłej roboty, że w zasadzie ciężko się o coś przyczepić, ale propozycji usunięcia dróg planowanych z wyświetlania to nie jest to czego jestem fanem. Argumentu, że ciężko je zweryfikować w terenie w ogóle nie kupuję, gdyż takie drogi są narysowane wg zupełnie innych informacji i w miarę możliwości źródła powinny być uwzględnione w tagach. Ponadto po to wprowadzono przeźroczystość tych dróg by nie była to informacja widoczna jako najistotniejsza…
Była propozycja, żeby oddzielić te planowane od proponowanych, bo inwestycje mają wiele etapów, ale okazało się, że ciężko to odróżnić, a zmiany mogą nastąpić nawet w ostatniej chwili, więc gdzie tu “ground truth”? Wizualnie akurat nie mam nic przeciwko, bo od kiedy są przeźroczyste w niczym już nie przeszkadzają ani się nie narzucają.
Nie wiem, jak jest w innych miastach, ale szczecińska Rada Miasta regularnie podejmuje uchwały, w których nadaje nazwy projektowanym ulicom. Oczywiście każda uchwała posiada załącznik graficzny, na którym przebieg ulicy jest zaznaczony. Takie ulice widnieją również w miejskim planie miasta na gis.um.szczecin.pl.
Ale na świecie bywa różnie, dlatego właściwie dopiero w budowie jest grubszy sens zaznaczać, że coś tam jest.
A Mateusz właśnie wymyślił kolejną (nomen omen ;)) poprawkę wizualną na średnim poziomie - żeby linie kolejowe były widoczne w charakterystyczny wzorek nawet w pewnym oddaleniu:
https://github.com/gravitystorm/openstreetmap-carto/issues/1704
Nie spodziewałem się zupełnie, że taka drobna zmiana, teoretycznie zwiększająca zagracenie wizualne, tak bardzo pomaga rozróżnić wszystkie typowe środki transportu: drogi, koleje i tramwaje. To także pasuje bardziej do wizji mapki uniwersalnej, zrównoważonej, a nie przytłoczonej samochodowym spojrzeniem na świat.
Wracając do tematu przerywanej linii w drogach unpaved i wizualnej kolizji z tunelami, chciałbym jednak dać pod rozwagę zastosowanie przerywanej (kwestia jak przerywanej) krawędzi.
Zrobiłem fotoszopkę tego rejonu: http://www.openstreetmap.org/#map=18/48.85570/2.25639:
- z tunelu usunąłem całkowicie kolor drogi - zostaje przerywany kolor krawędzi; widzimy to co na powierzchni
- dodałem na jednej jezdni zoffsetowaną (językiem cada) linię “ściany tunelu” żeby było to wyraźniejsze i wyraźniej odróżniało się od propozycji zastosowania przerywanych linii na drogach nieutwardzonych
- nie wiem czy się tak da: nawiasem kwadratowym oznaczony wlot tunelu (można byłoby spróbować inne kształty np. nawias okrągły czy ostrokątny)
- na wąskiej uliczce (również na części z accessem) zrobiłem przymiarki przerywanej krawędzi - kropkowanej, przerywanej linii, kropki z kreską; tu wydaje mi się istota, żeby przerywane linie tunelu i unpaved miały inny charakter, ale żeby były przerywane, a sama droga żeby miała swój kolor, przy czym kreskowanie jest wewnątrz tego koloru.
Niedawno padł pomysł, żeby w podobny sposób (tzn. obramowanie bez wypełnienia) wyświetlać highway=road:
https://github.com/gravitystorm/openstreetmap-carto/issues/1666
Kilka dni temu wpadłem na chytry pomysł, żeby wyświetlać POI w obszarach niezamieszkałych wcześniej niż w zabudowanych i właśnie założyłem taki bilecik:
https://github.com/gravitystorm/openstreetmap-carto/issues/1705
Zasadniczy pomysł opiera się na wykrywaniu landuse=residential - jeśli punkt znajduje się wewnątrz takiego obszaru, to pojawia się normalnie, ale jeśli poza nim, to odpowiednio wcześniej. Jest problem z tym tagiem, ponieważ nie obejmuje wielu obszarów zamieszkałych, ale myślę, że jeśli wybrać na początek jakiś sensowny rodzaj (np. ośrodki zdrowia, krzyże przydrożne, sklepy spożywcze, pomniki itp.), byle niezbyt liczny, oraz solidnie zanalizować czy słusznie występują poza obszarem, czy tylko taki obszar nie został wyznaczony, to dałoby się zebrać doświadczenie do dalszych prób.
Zresztą już sama taka analiza by się przydała, żeby stwierdzić ile powierzchni mamy oznaczonej w ten sposób i ile mniej więcej jeszcze brakuje oraz w ogóle jak się sprawdza wyświetlanie poza miastami, zwłaszcza w biedniejszych częściach świata.
@marcin_b
z tunelem fajny pomysł. Ciekaw jestem jak by to wyglądało na terenie zabudowanym jak np. Tunel Leopolda w Brukseli http://www.openstreetmap.org/#map=19/50.85941/4.34381
@kocio
Jakie proste a jakie genialne 
Wydaje się, że tam gdzie jest naprawdę ciasno i mamy dużo POI to takie obszary z reguły będą w dużych miastach gdzie i tak oznaczone będą te tereny jako residential, więc nie powinno to sprawiać jakiś większych problemów. Osobiście do wyjątków dał bym również landuse=recreation_ground gdyż tam może być kebab na kebabie a wolę by się mnie wyświetliła nazwa obszaru niż jakieś fastfoody które i tak się spodziewam na miejscu będą 