Wyświetlanie na domyślnej mapie

dokładnie jak pisze psadk - musimy mieć własny styl dostosowany do polskich warunków, bo różnice pomiędzy krajami są zbyt duże żeby zachować użyteczność mapy. Dodatkowo dowód na to, że jakaś zmiana działa i jest fajna jest o niebo lepszy niż jakakolwiek inna argumentacja dla developerów mapnika :).

A czy moglibyśmy przy okazji zrobić polską wersję mapy topograficznej?

A propos wyświetlania - trafiłem na termin way_area i nawet jest o nim hasło na wiki:

http://wiki.openstreetmap.org/wiki/Key:way_area

ale dla mnie jest to mało zrozumiałe nadal. Wiecie z czym to się je?

Nie jestem pewien, czy to właściwy wątek, ale jest to niewątpliwie problem.
Coś się mocno skiepściło w renderingu, dopiero co. Na dworcu w Katowicach http://osm.org/go/0LeVbEBbA podziemna wysepka z przystankami autobusowymi nagle wylazła na powierzchnię i przykryła budynek dworca. Podobnie drogi podziemne z layer=-1 i tunnel=yes w obrębie budynku są renderowane jak na powierzchni, co ciekawe poza budynkiem jest OK, czyli jest jakiś związek. Nie było tam edycji od roku. Wygląda to beznadziejnie.

To chyba ten sam problem, co z Dworcem Centralnym w Warszawie - możesz się dopisać do tego bilecika:

https://github.com/gravitystorm/openstreetmap-carto/issues/685

Na razie jest niemiecka:

http://opentopomap.org

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.