Wyświetlanie na domyślnej mapie

Jeśli będą zasoby na hostowanie topograficznej i ktoś chętny do dłubania, to pewnie tylko.

Przydałby się jednak jeszcze nieco lepszy model terenu niż używany obecnie SRTM, bo niestety poza partiami górskimi pokazuje on bzdury. I skoro o tym mowa, próbował ktoś coś zrobić z danymi udostępnionymi niedawno przez CODGiK? Chciałem sobie testowo przygotować warstwice dla Mazowsza, ale ciągle wyrzuca mi błąd:

$ gdal_contour -i 10.0 mazowieckie_grid100.txt warstwice.shp
ERROR 1: Ungridded dataset: At line 21, X is 670127.160000, where as 672326.630000 was expected

To samo przy próbie konwersji za pomocą gdal_translate.

SRTM ma rozdzielczość 90m, NMT-100, jak nazwa sugeruje, ma rozdzielczość 100m. Czyli raczej nie będzie lepiej.
Format, w jakim udostępniono dane, najwyraźniej nie jest siatką wysokości ale chyba zbiorem punktów wysokości, więc procedury nie działają.

Jakie masz zastrzeżenia do SRTM? Wg moich obserwacji dane są przyzwoite i problemy właściwie dotyczą tylko wysokich Tatr, gdzie w danych SRTM jest dziura. Moim zdaniem SRTM jest jeszcze najlepszy z darmowych danych. ASTER jest pełen artefaktów, XSAR fragmentaryczny, EU-DEM ma jakieś przypadkowe błędy a NMT-100 słabą rozdzielczość.

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 :wink:

Tak na szybko warstwice z NMT-100:

@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.

Warto by go wspomóc. W końcu wakacje są…
Jeśli ktoś napisze kawałek kodu to Andy z pewnością to zaimplementuje.

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.

tak, jak wspominałem - nie zmarnuje, bo moim zdaniem powinniśmy własną gałąź rozwijać na potrzeby osmapa.pl :slight_smile:

No dobra, wszystko pięknie, ale czy ta gałąź na osmapę to już zdecydowane i jest przygotowywana, czy ten pomysł dopiero się opierza? :slight_smile:

Czy może wszyscy gadają jaki to świetny pomysł i ogląda się na innych („weźmy zróbcie”)?

Rozwijanie mnie interesuje ale za serwer nie dam rady zapłacić.

to bardziej apel do osób, które ogarniają tile-servery i style jak i do administratorów osmapa.pl.

Nadciąga dobre - duży update domyślnego stylu: https://www.facebook.com/osmpolska/posts/837264119630992

Mam mieszane uczucia co do ikonki dla shop=* Juz teraz mamy tagi typu shop=Bideronka, a jesli i tak bedzie sie pokazywac to ludzie nie beda zmieniac :confused:

Mamy też wiele gorszych rzeczy, a jeśli będzie tylko domyślna ikonka, a nie odpowiednia do danego typu, to będzie jednak widać.

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.

Wnioski z moich eksperymentalnych pull requestów ( https://github.com/gravitystorm/openstreetmap-carto/pulls?q=is%3Apr+is%3Aclosed+author%3Amkoniecz+sort%3Aupdated-desc ) i generalnej obserwacji projektu.

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.

Na głównej mapie OSM zniknęły przystanki autobusowe, np. to: http://www.openstreetmap.org/way/203934755, co ciekawe tramwajowe ocalały.