Budynki i inne “ficzery” terenu zostały odjęte w obróbce… choć wypełnione trochę nieudolnie (patrz trójkąty jakie tam zostały - ja bym to jakimś spline’em na ich miejscu wypełnił)
Swoją drogą pewnie nieźle się napracowali odejmując różne mosty, estakady i inne konstrukcje 
Leży w jakim sensie? Padł fizycznie czy jakieś inne problemy, którym można zaradzić?
Programowo-fizycznie. 
Po migracji z jednego systemu na inny, i przy okazji wymiany systemu wirtualizacji na głównym hoście serwera, coś nie zaskoczyło i witualka nie jest uprzejma się uruchamiać. Ktoś musi się do serwera udać i zobaczyć co mu właściwie dolega. Podejrzewamy, że coś jest nie tak z RAM-em.
Nawiasem mówiąc w międzyczasie dopracowałem niemal do perfekcji tworzenie TMS ręcznie dla określonych lokalizacji. Metoda wymaga trochę klikologii w Qgisie a potem czasu procesora w gdal2tiles, więc sprawdza się tylko dla mniejszych lokalizacji. No i w sumie jakby było zainteresowanie, to mógłbym co jakiś czas (tydzień? dwa?) zrobić ISOK-owy podkład dla jakiegoś parku narodowego czy innego ważnego miejsca, które ciężko zmapować tylko z orto, na swego rodzaju “mini maping party”.
Temat nie przeszedł przez GSoC, ale jeden ze studentów był na tyle ambitny, że niezależnie od stypendium będzie nad tym pracował, a ja mu w tym pomagam.
O, super. Fajnie wiedzieć. 
czy takie coś kwalifikuje się na barrier=wall?
https://www.google.pl/maps/@52.408018,16.930549,3a,75y,76.59h,66.42t/data=!3m6!1e1!3m4!1sTXh2WzE45Mevmrt-nauhgg!2e0!7i13312!8i6656!6m1!1e1
tak, jeśli podasz height=0.45
Od strony chodnika to bardziej barrier=retaining_wall.
barrier=retaining_wall jest do ścian ze zmianą poziomu, np. tu:
https://www.google.pl/maps/@52.405692,16.918391,3a,60y,211.28h,84.47t/data=!3m6!1e1!3m4!1sB15Zc2UgDt_hYIQ9urpKNg!2e0!7i13312!8i6656!6m1!1e1
Ja tu właśnie widzę zmianę poziomu…
Wątek na liście Tagging dotyczący mapowania wyposażenia placu zabaw:
https://lists.openstreetmap.org/pipermail/tagging/2015-July/025679.html
Nie jest to chyba do końca mikromapowanie, ale na pewno się z nim blisko wiąże - pojawiła się propozycja dokładniejszego tagowania różnych typów kostek, kafelków i innych tego typu elementów utwardzania nawierzchni (w tym powszechnej w Polsce trylinki):
http://wiki.openstreetmap.org/wiki/Proposed_features/Paving_stone_details
Nanomapowanie bardziej by pasowało…
błagam zróbcie coś z tymi niewidzalnymi przeszkodami na obszarach chodników, przecież to jest jeden z największych absurdów osm, w wielu miejscach mapa przez to może wprowadzać w błąd
W latach 90 tych rozmawiałem y jednym profesorem Uniwersytetu Bundeswehry w Hamburgu. Dyskutowaliśmy o modelach 3D i mogłem przy okazji obejrzeć symulator dla kierowców: Każdy chodnik, trawnik, miał tam odpowiednią teksturę ze skalą i prawidłowym kierunkiem tekstury. Jak ważny jest kierunek tekstury można zobaczyć tutaj:
http://znajomy.home.pl/area/index2.html
Globalnie przyjęty jest jeden kierunek tekstury dla przejść dla pieszych. Raz to pasuje, a raz nie.
Podanie kierunku i skali, najlepiej w modelerze WYSIWYG, czyli skalujemy sobie i obracamy teksturkę w okienku preview zamiast wspiywać wartości liczbowych z pewnością się przyda.
?? Może jakis przykład. Bo ja nic nie zrozumiałem.
Uważam, że zapisywanie kierunku za pomocą tagu z kątem może powodować błędy. Czy nie lepiej używać drogi jako wektor kierunku? Warto pamiętać, że dla obszaru chodnik może się on zmieniać gdy jest on np. po łuku.
To nie mój cytat, Dotevo.
Czasem jest tak, że tekstura ma inny kierunek niż droga. Co wtedy?
Pytanie o tekstury po łuku jest jak najbardziej słuszne. Tordanik pisząc specyfikację nie przewidział tego. Warto mu zwrócić uwagę pisząc na talk tego proposalu.
Przepraszam, nie wiem jak się to stało. Poprawiłem.
No to wtedy można ją faktycznie jeszcze tagiem obrócić. Pewnie zazwyczaj o ± 90/180 stopni. Proszę bardzo, możesz pisać 
sam znam sporo ścieżek, które robią spory łuk i już widzę te lamenty, że tektura pasuje ale tylko na początku chodnika.
przykład 1., chodnik który przebiega “zawijasem” https://www.google.pl/maps/@52.412327,16.845639,3a,75y,74.55h,89.39t/data=!3m6!1e1!3m4!1so5iQzF3SFQ8rdZARgbK6lQ!2e0!7i13312!8i6656 w osm wygląda na jedną część http://osmapa.pl/#lat=52.41245&lon=16.84682&z=19&m=ma
przykład 2., mur na lewo od bramy https://www.google.pl/maps/@52.41232,16.851228,3a,75y,0.43h,97.52t/data=!3m6!1e1!3m4!1sNk8JQfZSmP0yrSO9y8g8pQ!2e0!7i13312!8i6656 w osm jest niewidoczny http://osmapa.pl/#lat=52.41267&lon=16.85128&z=19&m=ma
to wszystko przez przyjęcie zasady priorytetu renderowania chodnika nad przeszkodami, nie widzę żadnego argumentu za taką logiką
@Tomasz_W: Ale to raczej kwestia wyświetlania, a nie (mikro)mapowania, więc może chodzi o ten wątek dotyczący domyślnego stylu:
http://forum.openstreetmap.org/viewtopic.php?id=26176
Była taka zmiana rok temu, która spowodowała, że powierzchnie piesze mają chyba najwyższy priorytet i wywołała protesty, ale nic się nie zmieniło:
https://github.com/gravitystorm/openstreetmap-carto/issues/688
Te niewidoczne przeszkody to nic, popatrz jak wygląda np. Wieża Eiffela:
http://www.openstreetmap.org/way/5013364
Inna sprawa, że w stylu Osmapy też jest problem - wprawdzie przy zawijasie widać ekran prawidłowo, ale brama się w ogóle nie wyświetla:
http://osmapa.pl/#lat=52.41245&lon=16.84682&z=19&m=os
http://osmapa.pl/#lat=52.41249&lon=16.85137&z=20&m=os
A w ogóle można to chyba dokładniej zmapować - nie linia, tylko obrys muru (czyli jego powierzchnia), natomiast co z bramą to trudno mi powiedzieć, ja mam do czynienia tylko z mało istotnymi, które wystarczy zaznaczyć jako punkt na przecięciu ogrodzenia i drogi.