Dużo danych o budynku kolega przedstawił za to mało tagów dodał do obiektu gdyż nie ma tam nic poza “building=train_station”, choćby coś co odzwierciedlało to, że budynek jest zamknięty. Zresztą to, że jest zamknięty wcale nie oznacza, że zmienił swoje przeznaczenie mimo że na chwilę bieżącą niewykorzystywane. Idąc tym tropem to jeśli mamy boisko piłkarskie na wsi na którym od kilku lat nikt nie rozegrał meczu a co najwyżej raz do roku skosił trawę to wówczas należało by go oznaczyć jako łąkę a nie boisko, a tam mimo wszystko bramki cały czas stoją.
Dziwnie to wygląda taka plama na morzu. Rozumiem konieczność pola wojskowego, ale po co przesłaniać cały obszar zamiast zaznaczyć jedynie jego granice.
http://www.openstreetmap.org/way/173480185#map=10/54.4656/14.2836
Różowy kolor poziom niżej rozumiem odzwierciedla nastawienie bojowe naszych zachodnich sąsiadów
www.openstreetmap.org/way/173480185#map=11/54.4079/14.1669
U nas było podobnie, dopóki tagowanie nie zostało zmienione z danger_area na training_area, które się nie renderuje:
http://osm.mapki.com/history/relation.php?id=3246413
Niestety - restricted_area nawet na OpenSeaMap nie widać :-S
???
Otagowanie przedstawia stan przeze mnie opisany. Jakie tagi mam tam dodać, opisujące to, czego nie ma? I czy w OSM taguje się to, co jest, czy to, co mogłoby być, ale nie ma?
Skoro budynek zamknięty na głucho, to może access=no?
Dokładnie choćby tak. Logika się kłania. Nie mamy tu problemu z tym, że **nie mamy **niczego tylko że jest zakaz/brak możliwości wejścia/skorzystania.
Czy zmiana w domyślnym stylu polegająca na wyświetlaniu ikonki dla emergeny=phone zamiast amenity=emergency_phone jest skomplikowana i czasochłonna?
Pytam bo nadal niektórzy nie chcą się pozbyć starego tagu na rzecz nowego, bo go nie widać na mapie osm.org.
Musi nastąpić duża zmiana w infrastrukturze kodu, czyli przejście na gałąź lua. Wtedy będą dostępne na serwerach bazodanowych OSM klucze inne niż tylko te wyfiltrowane tu:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style
Sądząc po deklaracjach Paula Normana to kwestia jakichś 3-4 miesięcy do serii 4.x, wtedy można będzie dodawać poszczególne nowe elementy:
https://github.com/gravitystorm/openstreetmap-carto/issues/2555#issuecomment-275306964
Konkretny bilecik jest tu:
https://github.com/gravitystorm/openstreetmap-carto/issues/318
Od kilku dni jest już nowa wersja stylu (OpenStreetMap Carto v3.1.0):
Kod dla wież przygotowany i niemalże gotowy.
https://github.com/gravitystorm/openstreetmap-carto/issues/2556#issuecomment-278262720
Ze względu na wykorzystanie tagów height oraz tower:construction które w stylu dotychczas nie istniały konieczne jest przeładowanie bazy, więc pewnie nie zostanie z tego powodu użyty przynajmniej przez jakiś czas, ale zobaczymy. Ciekaw jestem komentarzy 
zawężyłem na kilku osiedlach obrysy landuse=residential do części mieszkalnych (tak, żeby nie obejmowały np. parków czy polan), a granice tych osiedli wyznaczyłem w relacjach type=boundary + place=neighbourhood i tam też przeniosłem nazwy osiedli, teraz widzę że po takim zabiegu zaczęły one zanikać; jak dla mnie to błąd logiczny - budynki mieszkalne mogą przecież stanowić tylko część osiedla, a w wielu miejscach jako residential zaznacza się całe osiedla, prawdopodobnie tylko po to, żeby mapa raczyła wyświetlić ich nazwę, to place=neighbourhood powinno mieć tutaj pierwszeństwo (tzn. w ogóle powinno być wyświetlane, bo z tego co rozumiem, to teraz nie jest) jako obrys bardziej administracyjny niż uznaniowy
Hm, nie sprawdzałem tego, ale chyba jest wyświetlane:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/placenames.mss#L375
Sprawdziłem - wyświetla się:
węzły się wyświetlają, mój problem dotyczy relacji (które w tym przypadku pełnią rolę obrysów place=neighbourhood), kojarzę że jest coś takiego jak rola “label” w relacji, ale w tym przypadku oznacza to dublowanie informacji z relacji do osobnego węzła, prostszym rozwiązaniem byłoby wyświetlanie nazwy relacji w środku obrysu który wyznaczają członkowie outer
chodzi o tę dzielnicę, tam gdzie edycja się zrenderowała, nie ma już nazw osiedli
http://www.openstreetmap.org/#map=15/52.3853/16.9636
Trudno mi powiedzieć czemu tak jest i co poprawić. Polecam założenie bilecika, to wtedy jest szansa coś z tym zrobić.
założyłem, https://github.com/gravitystorm/openstreetmap-carto/issues/2566
mam nadzieję że nic przy tym nie sknociłem 
Edit:
Jest to większy problem z relacjami granic na wszystkich szczeblach. Tutaj jest poruszający ten problem bilecik:
https://github.com/gravitystorm/openstreetmap-carto/issues/103
Zalew Szczeciński - Trzebież. Wyspa refluacyjna i Chełminek na zoom 12 są widoczne powyżej coś jest nie tak z wyświetlaniem ich chyba?
https://www.openstreetmap.org/#map=12/53.6604/14.5751&layers=N
Wyświetlanie typów boisk i to bez przeniesienia kodu ze stylu francuskiego:
http://www.openstreetmap.org/#map=19/53.16112/17.91507
Kiedyś zoom 14 i 13 renderował się jako pierwszy, praktycznie nigdy dłużej niż 1 minutę.
Teraz mi się wydawało, że brakuje kafli sprzed 3 dni mimo wielokrotnego odświeżania ale przełączyłem się na firefoxa i widzę, że problem dotyczy chrome, które jakoś mocno trzyma kafle w cache-u.
Jak problem obejść?
Po dłuższej przerwie domyślna mapka aktualizuje się do stylu OpenStreetMap Carto v3.3.0 - wersja 3.2.0 została pominięta z powodu problemów z dyskiem na jednym z serwerów renderujących, a i styl miał niedawno po prostu przestój w rozwoju.
Ważniejsze ostatnie zmiany:
- budynki terminali lotniczych wyświetlają się jak budynki dworców kolejowych i innych budynków “specjalnych” (ciemny brąz)
- przestarzałe tagowanie landuse=farm nie jest już wyświetlane
- dodane wyświetlanie arts_centre (ikonka m.in. dla domów kultury), fitness_centre (tak samo jak sports_centre), plant_nursery (wzorek dla szkółek jest podobny jak dla sadów), aerialway=mixed_lift (tak samo jak kolejka gondolowa)
- zmiana wyświetlania wetland=fen
- bardziej dyskretna obwódka dla terenów szkół, szpitali, centrów sportowych itp.
- większość ikonek sklepów wyświetla się teraz od z18, na z17 symbolizują je fioletowe kropki
Kolejne wydanie ma być podwójne - 3.3.1/4.0.0. Wizualnie nie powinny się różnić, natomiast seria 4.x wprowadzi transformacje lua. Ten kod pozwoli na korzystanie z hstore, czyli na długo oczekiwane odświeżenie “podręcznej” bazy danych używanej do wyświetlania domyślnej mapki. Obecnie ta baza jest okrojona do wybranych tagów, użycie hstore da nam wreszcie dostęp wszystkich tagów, co pozwoli na załatwienie różnych problemów.
w miejscu które od jakiegoś czasu mapuję część kafelków zaczęła przy zoomowaniu pokazywać stan sprzed kilku miesięcy, czy ma to związek z aktualizacją stylu, a jeśli tak, to dlaczego i kiedy się to unormuje?
http://www.openstreetmap.org/#map=17/52.39058/16.94503