Owszem, jednak oba zbiory danych różnią się jeszcze jednym szczegółem: dane SRTM zbierane z satelity metodą jakąśtam uwzględniają np. pokrywę roślinną (innymi słowami: pokazuje wysokość wierzchołków drzew w lesie, nie terenu w nim), dane z CODGiK-u — tu zakładam, iż są zbierane tak samo jak dane dostępne na wartswie ISOK_CIEN w Geoportalu — zbierane są laserem z samolotu i (prawdopodobnie) pokazują rzeczywiste ukształtowanie terenu.
Nie mówię, że NMT-100 będzie lepsze niż SRTM. Ba, już wcześniej podejrzewałem, że jakość będzie porównywalna. Ale mimo wszystko chciałbym sprawdzić to empircznie.
Na przykładzie OpenTopoMap z warstwicami z SRTM, mapa topograficzna z Geoportalu oraz wspomniany ISOK_CIEN z Geoportalu (nieziemska rozdzielczość 1m; mam oczywiście świadomość, że 100m będzie bez porównania gorsze). Nawiasem mówiąc rejony te znam jak niemal jak własną kieszeń i dodatkowo zaręczam własnym słowem, że SRTM pokazuje bzdury. http://imgur.com/a/scFaw
Jak widać SRTM pokazuje zmiany wysokości niezupełnie w tych miejscach co trzeba. Najbardziej „podobają” mi się warstwice na jeziorze Parów Kar(a)ski (dziury w pokrywie leśnej?).
(Nawiasem mówiąc choć początkowo byłem sceptyczny co do możliwości wykorzystania ISOK_CIEN do rysowania OSM, teraz po lekkim wgryzieniu się w temat jestem prawie pewien, że jednak jako podkład możemy wykorzystwać. Przynajmniej prawnie, z technikaliami jest drobny problem. Ale o tym szerzej będę pisał, jak wgryzę się trochę bardziej).
Twoje zastrzeżenia sprowadzają się do tego, że SRTM mają ograniczoną dokładność, jakieś 16m w pionie. Ale to wiadomo. Bzdury to by były, gdybyś pokazał artefakty lub większe błędy.
Możesz też w ciemno przyjąć, że warstwice z NMT-100 też będą przechodzić po jeziorach. Nawet na tym ISOK_CIEN widać jakieś fale na jeziorze
@popej - te dziury w Tatrach można załatać - przy generowaniu warstwic za pomocą phyghtmap jest przełącznik, który pobiera brakujące fragmenty z jakiegoś innego serwisu (nazwy nie pamiętam - ponoć przerysowywali dane z radzieckich sztabówek). Może bez szału, ale chyba lepsze niż dziury.
Jest kilka źródeł oferujących przetworzone SRTM z wypełnieniem dziur. Ale te łaty widać. W udostępnionych NMT-100 także widać takie regularne wzory warstwic, jak w łatanym SRTM.
Hm, nie wiecie co się dzieje, że od 17 dni nic nie zostało zrobione w kodzie - Andy ma urlop czy co? Bo dla kontrastu ilość sensownych bilecików (szczególnie dzięki math1985) urosła w tym czasie znacznie i chętnie bym zobaczył wreszcie jakieś wdrożenia.
No właśnie np. Mateusz zrobił implementację kilku rzeczy i czeka już tylko na włączenie do głównej gałęzi… Ja też bym chciał najpierw mieć pewność, że projekt żyje, zanim sam coś od siebie zrobię, żeby nie zmarnować sił i się przy okazji nie zniechęcić Dlatego pytam.
Ikonki dla sklepów już zadziałały! Domyślnie jest fioletowa kropka z nazwą (zamiast numeru budynku), więc nie ma obaw, że nietypowe rodzaje sklepów pozostaną niezauważone.
Puszczenie pull requesta daje duże szanse na to iż proponowana zmiana pojawi się w stylu, jeśli zmienia ona coś co jest już wyświetlane. Jeśli proponuje coś nowego - musi to być naprawdę dobry pomysł.
Nie ma co się spodziewać iż pull request zostanie szybko rozważony, najprostsza zmiana może leżeć miesiącami i czekać. Pull requesty akceptowane są partiami które za każdym razem obejmują tylko część oczekujących, z pierwszeństwem dla tych które poprawiają regresje i naprawdę ewidentne problemy.
A może ktoś sprawdzić jeden obiekt? Chodzi o węzeł POI z rzeźbą, o tutaj - link. Widać go jedynie w podglądzie danych mapy, a na renderze mapy rowerowej, który wyświetla również rzeźby już go nie widać. Inne POI z rzeźbą, dodane bardzo dawno temu, które ma te same tagi (link) na mapie widać.
