Andy Allan zdecydował iż rezygnuje z wyłączności na akceptowanie PR. W mojej ocenie pomysł był udany i się sprawdził (więcej osób mogących akceptować PR → szybsze przetwarzanie PR → więcej PR).
Jest tez taka mozliwosc, ze aktualny stan im odpowiada. Nie wiem czy tak jest w tym wypadku, ale przekonalem sie miedzy innymi przez dyskusje openstreetmapowe na listach, ze ludzie, ktorzy widza jakis problem i chca zmiany generalnie maja przewage w wolnych projektach (i nie tylko), a istniejacy stan jest na lekko przegranej pozycji bo oczywiscie jego zwolennicy nie beda zaangazowani w szukanie alternatyw. W zwiazku z tym czasem widac bardzo dlugofalowe oscylacje gdzie co pare lat “wielkim krokiem na przod” jest odwrocenie zmiany ktora kilka lat wczesniej byla “wielkim krokiem na przod”.
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