Path z access=no wygląda teraz prawie jak railway=disused.
highway=service z access=private ma tak subtelny szary, że prawie niewidoczny.
“Na z7 to jednak również Bydgoszcz raczej powinnna się już pojawić”.
Chyba TADA.WAW… 
Jest już założony bilecik w sprawie dalszych poprawek dla miast:
https://github.com/gravitystorm/openstreetmap-carto/issues/2378
A nie, bo TADA.WAV jest poprawną nazwą pliku dźwiękowego 
O. Nie mogłem dojść, co mi tam nie pasowało… 
To jest (chyba zbyt pochopnie zamknięty) ten bilecik:
https://github.com/gravitystorm/openstreetmap-carto/issues/1391
Na francuskiej wersji wygląda to znacznie lepiej, mniej województw widać, jest za to Bydgoszcz, Poznań, Lublin (a lubelskie też akurat widać, tylko przesunięte):
http://tile.openstreetmap.fr/?zoom=7&lat=52.19392&lon=19.55276&layers=B0000000FFFFFF
ale nie udało mi się jeszcze znaleźć co u nich jest inaczej, bo kod oryginału bardzo się już różni od tego forka.
Dlaczego kolej w tulejach podziemnych wyświetla sie jakby jeździła na powierzchni?
http://www.openstreetmap.org/#map=17/50.63788/16.41774
Co ciekawe niektóre tunele wyświetlają się prawidłowo.
Dlaczego osm.org zablokowało dla Firefoksa “pokaz obrazek tła” przez co nie można używać funkcji dirty?
Już się poprawnie te tunele kolejowe wyświetlają
http://www.openstreetmap.org/#map=16/50.6367/16.4217
Jednak wczoraj cały dzień nie można było uzyskać zmiany renderingu, mimo zmiany tagu na jednej z nitek.
Być może ta drobna zmiana przypomniała OSM o zapomnianym kaflu.
Czy ktoś potrafi wyjaśnić jak to jest możliwe, że od kwietnia czyli od pół roku kafel nie był odświeżony na żadnym zoomie?
Widziałem, że layer=-1 nie jest konieczne aby sam tag tunnel wyświetlał się prawidłowo a tunnel=yes wisi tam od wielu lat. Zatem to nie problem trzymania w cache mojej przeglądarki starych kafli.
Wygląda, że spaprano generator kafli (styl) a po naprawie nie przeskanowano danych ponownie.
W tego nasuwa się wniosek, że takich tuneli nie renderujących się może być wiele i rzeczywiscie tak jest np. ten tunel długi na 1300 m
http://www.openstreetmap.org/#map=15/50.7376/16.3105
Jak tu żyć?
Możecie skłonić OSMF do restartu generatora kafli, bo nie ma sensu aby to wszytko tykać ręcznie szczególnie, że dirty w Firefoksie wyłączyli?
Działa dirty w innych przeglądarkach?
Dodałem wszystkie strumienie jakie tylko są na podkładzie Geoportalu z poprawkami wg ISOK w Worku Bieszczadzkim i dalej dochodząc powoli pod Jezioro Solińskie. Można by ten rejon dorzucić do testów, gdyż mapa na zoomach z13/z14 zrobiła się zupełnie przez to nieczytelna. Aż nie chcę myśleć jak będzie wyglądała gdyby dodał wszystkie tymczasowe [waterway=stream + intermittent=yes]
A na czym ta nieczytelność polega? Za blady kolor, za gęsto od tych strumieni czy coś innego?
obecnie na carto wyświetlane w lasach strumienie mają szerokość dróg. Powoduje to wraz, że na pierwszy rzut oka mamy praktycznie alternatywną sieć drogową na mapie gęstszą niż wspomniana drogowa do tego ze względu na niewyrazisty kolor mało czytelną. Dokładniej opisałem powyżej http://forum.openstreetmap.org/viewtopic.php?pid=609816#p609816 jak bym widział to docelowo.
Co do koloru patrząc na osmapa.pl tam kolory wody różnią się w zależności od tego czy mamy do czynienia z kreską przedstawiającą strumień/rzekę czy też OSM zawiera dane o brzegach. Może można by powielić to rozwiązanie?
Skoro to chodzi o coś innego niż sam kolor, to najlepiej załóż osobny bilecik. Jak mówiłem, nie chcę wszystkich problemów z wodą pchać do jednego PR, bo praktyka pokazuje, że przez następne pół roku albo i dłużej nie uda się tego zmienić. Pojedynczo idzie sprawniej - np. wielkość nazw jeziora udało się zmienić po miesiącu:
https://github.com/gravitystorm/openstreetmap-carto/pull/2302
zgadzam się pojedynczo nie wszystko na raz. Być może faktycznie sama zmiana koloru wiele nie zmieni niemniej na pewno warto sprawdzić czy w takim miejscu po takiej zmianie nie będzie gorzej Co do pozostałych rzeczy to myślę ze zgłoszeniem też można poczekać do momentu wprowadzenia zmiany koloru, który sam w sobie mocno zlewa się z zielenią lasów czy łąk.
EDIT:
Zauważyłem również, że przy obecnym wyświetlaniu niewielkie odległości pomiędzy tymczasowymi strumieniami powodują że zamiast pokazywać one kierunki cieków wyświetlając jednoznaczne przerywane kreski mamy prostokąciki niewiele odbiegające od kwadratów. Powoduje to że zwłaszcza na z13 mamy http://www.openstreetmap.org/#map=13/49.2458/22.2791 obszar, który zamiast pokazywać co mamy w terenie wygląda jak by pokryła go wysypka i tak naprawdę nie można być pewnym które prostokąty należą do którego strumienia. Na z14 jest już lepiej, ale dopiero z15 jest w tym przypadku stosunkowo czytelne http://www.openstreetmap.org/#map=15/49.2494/22.3044
Będzie bardziej wyraziście, a w tym przypadku to chyba gorzej. =}
mógłby ktoś przetłumaczyć na ludzki język, na czym to stanęło https://github.com/gravitystorm/openstreetmap-carto/pull/2394 ?
Nie ma sprzeciwu od 2 tygodni, więc raczej zostanie uwzględnione. Zrobiła się kolejka podobnych, tzn. bez sprzeciwu od dłuższej chwili, więc pewnie to kwestia aż ktoś z ekipy znajdzie zwyczajnie czas żeby zająć się tym kodem w poczekalni.
Właśnie zaproponowałem, żeby osm-carto zaczął wyświetlać wszystkie standardowe sklepy jako kropki:
https://github.com/gravitystorm/openstreetmap-carto/issues/2099#issuecomment-203133103
To nie jest nowa propozycja, ale zebrałem argumenty, że to faktycznie ma sens: mniej kodu, mniej paskudnych problemów z aktualizacją (zarówno w usuwaniu jak i dodawaniu) oraz uznanie, że uniwersalna mapa to nie jest narzędzie do kontroli szczegółowych danych.
Ten kod został właśnie zaakceptowany, więc jeśli ktoś miał dylematy moralne między wyświetlaniem a tagowaniem, to teraz nie ma już wymówki - należy tagować każdy sklep zgodnie z jego rzeczywistym typem, zamiast ogólnego “shop=yes”.
Czy kiedyś był już na githubie poruszany temat wyświetlania “traffic_calming=island”? Jego brak powoduje że ludzie obchodzą go dorysowując barrier=kerb, często bardzo niedokładnie, strasznie mnie to drażni
Bilecik jest, ale dyskusja póki co się urwała:
https://github.com/gravitystorm/openstreetmap-carto/issues/2086