Polskie Forum Entomologiczne

W wątku
Potrzebna siatka UTM z wrysowanymi krainami
ktoś zamieścił bardzo dobre mapki.
A na przykład tutaj:
http://darekk.com/db/UTM/
znajduje się plik KML do Google Earth i Google Maps (oraz kalkulator do Accessa przeliczający współrzędne geograficzne na UTM).
Czerwone linie - siatka co 100 km, razem z niebieskimi co 50 km.
Jeżeli chodzi o kml to położenie z dokładnością do 10 km można łatwo określić przy pomocy Rulera, który znajduje się w narzędziach w Google Earth. Na przykład jeżeli coś jest 15 km na prawo od niebieskiej linii to znajduje się w 5 + 2 = siódmym słupie, czyli 6  (o jeden mniej, bo ta numeracja zaczyna się od 0, natomiast 5 to poprzedni kwadrat 50x50 km wewnętrz czerwonego kwadratu 100x100 km). A jak 12 km na lewo od niebieskiej linii to w drugim słupie od prawej, czyli czwartym od lewej, czyli 3.
Z kolei 37 km w górę od czerwonej linii to czwarty rządek czyli 3, itd.

W Google Maps można otworzyć chociażby tak:
http://maps.google.com/maps?q=http:%2F%2Fdarekk.com%2Fdb%2FUTM%2FUTM.kml&hl=en&sll=37.0625,-95.677068&sspn=30.875284,56.162109&vpsrc=0&t=m&z=5
Nie ma tam jednak linijki jak w Google Earth.

Fajnie to zrobiłeś, jednak jest przesuniecie (slynne już). Twoja siatka jest przesunięta o 4,1 km na południe. Zamieszczam UTM z lepidoptera.eu i Twoje.
Skąd się przesuniecie wzięło, to już było chyba tlumaczone.
Trzeba to dopracować.

Trzeba to rozbić conajmniej na 2 części:

1) Google Earth / Google Maps

W Google Maps rzeczywiście jest poważnie przesunięcie, w Google Earth jednak siatka jest dokładna. Więc informacja dotycząca Google Maps staje się nieaktualna. Tam jest stosowane odwzorowanie Mercatora, ale linie powinny być prowadzone najkrótszą trasą po powierzchni ziemi ... Może dałoby się to skorygować zamieniając plik KML na rysowanie linii przy pomocy JavaScript. Jest jednak strona
www.lepidoptera.eu
z Google Maps ...

2) algorytm użyty do obliczeń

W przypadku pliku KML do obliczenia współrzędnych końców linii został użyty algorytm Dutcha ze strony:
http://www.uwgb.edu/dutchs/usefuldata/C ... TMNoOZ.HTM
Natomiast przebieg linii między punktami ustala Google Earth.  
Twój punkt (niebieska flaga na lewo) znajduje się około 173 m na południe od linii łączącej punkty obliczone powyższym sposobem (a nie 4.1 km jak w Google Maps). No i około 35 metrów na zachód od linii pionowej. Jeżeli jednak poprawi się jego współrzędne na Lon = 21, jest już idealnie na linii pionowej (niebieska flaga na prawo). Bo to meridian tej strefy, więc musi być równo (18 + 24) / 2 = 21 stopni. Nie zdziwiłbym się, gdyby również w pionie była jakaś różnica.

Kwadracik w pobliżu punktu przecięcia się linii to punkt styku kwadratów EC, DC, DB i EB, obliczony z użyciem algorytmu Dutcha. Znajduje się on 11 m na północ od punktu przecięcia się linii. Więc pewien błąd jest, jednak kilkumetrowy, wynikający ze sposobu rysowania linii przez Google. Natomiast twój punkt jest około 185 metrów na południe od tego punktu styku. Reasumując jest poważna różnica w waszym sposobie obliczania współrzędnych, a algorytmem Dutcha. Niestety nie jestem w stanie tego ocenić. Chociaż wyniki otrzymane sposobem Dutcha są zgodne z przykładem z Wikipedii w haśle o UTM (CN Tower). No ale z drugiej strony Wikipedia nie jest jakąś wyrocznią, chociaż to bardzo dobra encyklopedia.

Natomiast wracając do tego 11-metrowego przesunięcia to dałoby się je jeszcze bardziej zredukować rysując linie nie między dwoma punktami odległymi aż o jakieś 500 km, ale przez kilka punktów, na przykład co 100 km. Nie mam jednak siły się tym zająć ...

Jeszcze współrzędne tych czterech punktów znajdujących się w czterech kwadratach oraz punktu styku kwadratów obliczone z użyciem algorytmu ze strony Dutcha:

Teraz linie siatki nie są rysowane między dwoma punktami odległymi o kilkaset kilometrów:
ale przez serię punktów oddalonych zwykleo 50 km, na krańcach mniej:
To zwiększyło rozmiary pliku, ale wyeliminowało całkowicie przesunięcie linii o 11 metrów w Google Earth (załącznik przesuniecie1.jpg). Przy narzędziu do mierzenia odległości jest narysowana kreska o długości 95 centymetrów w terenie (!). Widać, że niebieski marker leży idealnie na linii. Nie jest ona teraz obniżona ani trochę. I to pomimo tego, że marker został umieszczony dokładnie pośrodku dwoma punktami oddalonymi o 50 km czyli w miejscu, gdzie obniżenie powinno być największe. Więc jak tu nie ma błędu, tym bardziej nie ma go w innych miejscach.

Natomiast jeżeli chodzi o Google Maps to widać, że linie poziome wyginają się do góry (załącznik wygiecia.jpg). Więc gdyby nie było tych dodatkowych punktów co 50 km, byłyby obniżone. Sytuacja nieco poprawiła się, ale linia nadal jest poniżej tego samego niebieskiego markera (czyli tam gdzie gdzie powinna być) o około 60 metrów (załącznik przesuniecie2.jpg).
Więc niestety Google Maps w przeciwieństwie do Google Earth łączy punkty z pliku KML najkrótszą trasą nie po powierzchni globu, ale po powierzchni mapy (siatce Merkatora). Możliwe że dałoby się to obejść, gdyby linie były rysowane przy pomocy JavaScript, a nie z pliku KML.

W każdym razie są nowe wersje tych plików kml do pobrania (http://darekk.com/db/UTM/).

Jakie znaczenie ma 11 metrów dla rozmieszczenia gatunku ? Żadne ! Mapy sporządza się nie po to, żeby uszczegóławiać - ale uogólniać.

Do ustalania położenia używamy GPS'ów, powszechnie dostępnych, tanich i dokładnych, może być w komórce, palmtopie czy osobnym urządzeniu. W ostateczności baz danych miejscowości z danymi UTM albo np. lepidoptera.eu lub google.earth.

Współrzędne geograficzne bardzo łatwo nanieść na mapę oraz przeliczyć na UTM (generalnie siatka UTM jest pewnym uproszczeniem współrzędnych geograficznych, łatwiejszym do eksponowania na mapach i zakładającą mniejszą dokładność).

Jest kilka prostych map umożliwiających nanoszenie na nie obserwacji i ewentualną analizę rozmieszczenia - choćby te na entomo.pl

Owady jako zwierzęta ruchliwe i łatwo się przemieszczające nie wymagają dokładności do metra czy kilku metrów. W zupełności wystarczy to co oferuje UTM czyli błąd kilku kilometrów.
Nikt nie opisuje rozmieszczenia: od drzewa w północnej części działki Kowalskiego do dużego kamienia na środku pola kukurydzy Nowaka. Często ograniczamy się do krain, czyli obszarów dużo większych niż kwadraty UTM. Nie rozumiem zatem całej tej dyskusji o dokładnościach, metrach, błędach w google.maps itp. Szkoda czasu, już dawno wszystko wiadomo w tej sprawie, ładna pogoda jest i sezon zaraz się skończy, nie szkoda Wam czasu ?

Ja uważam, ze dobrze jest mieć pewność co do układu siatki UTM. Są one "rózne" i od zawsze były lepsze i gorsze. Kolega Darek próbuje zrobić mapę idealną, uwzględniającą rózne apsekty - krzywizny ziemi, wysokosci npm itd. Jasne ze dla rozmieszczenia owadów to znaczenia nie ma. Warto byloby stworzyć porządną siatkę i algorytmy pewne, przeliczające je poprawnie. Rózne serwisy podkladają nam gotowe rozwiązania, które miedzy sobą wykazują róznice. I tu warto zastanowić sie skąd się biorą i ktre są bliższe prawdy. Z których narzędzi korzystać, skoro wyniki sa rózne? Jeśli tylko ktoś ma czas i potrafi te sprawy analizować to ja jestem ciekaw, co z tego się wykluje....

Poza tym Darkowi chodzi pewnie o skontrolowanie swoich algorytmów,  czy aby dobrze nanoszą siatkę. Z tego powstanie narzędzie, z ktorego będziemy mogli korzystać a to mnie szczególnie interesuje, pomimo, iż juz kilka jest.

A taki wniosek:



jest już bardzo ciekawy z punktu widzenia działania tych aplikacji. Dotąd bylem przekonany, że to co jest w Google Earth to jest to samo co w maps.google.com  

To w ramach wyjaśniania przyczyn tego przesunięcia linii poziomych. Chyba już wiadomo o co chodzi.
Rysowanie linii:
geodesic oznacza, że punktu są łączone najkrótszą trasą po powierzchni kuli ziemskiej, a nie mapy.

Linie w pliku KML są łączone najkrótszą trasą po powierzchni:
Google Earth - kuli ziemskiej
Google Maps - mapy (przekształcenie Mercatora)

Linie w JavaScript (Google Maps) są rysowane różnie w zależności od ustawienia opcji "geodesic" (true / false).

Tutaj:
http://darekk.com/db/UTM/UTM_geodesic.htm (i załącznik)
jest mapka z kilkoma liniami narysowanymi przez JavaScript.
Niebieska na dole to gedesic: false - obniżona o 4.3 km w tym miejscu mapy (!).
Czerwona o góry to geodesic: true - niemal idealna, tylko 11 metrów za nisko (jak KML w Google Earth).
Nakładają się na nią
- różowa - geodesic: true, ale punkty gęściej - nie 2 odległe o kilkaset kilometrów, ale kilka punktów, co 50 km. Znika przesunięcie 11 m (jak w analogicznej sytuacji w przypadku KML w Google Earth) !
- jasnoniebieska - geodesic: false, punkty co 50 km j.w. Sytuacja znacznie lepsza w porównaniu do łączenia 2 punktów odległych o kilkaset km i geodesic: false, ale linia obniżona o około 60 m.
Największe różnice między poziomymi liniami są widoczne pośrodku odległości między liniami pionowymi.
No i jak widać w tym wszystkim nie chodzi o traktowanie kuli ziemskiej jak kuli zamiast geoidy, ale rysowanie linii jako niegeodezyjnej (po powierzchni mapy) lub geodezyjnej (po powierzchni Ziemi).

Krótko mówiąc w tych plikach KML:
http://darekk.com/db/UTM/
linie siatki UTM są rysowane dokładnie w Google Earth, bo Google Earth traktuje linie jak geodezyjne. Oczywiście na tyle, na ile dokładny jest wspominany wyżej algorytm Dutcha.

Pytanie dotyczące granicy stref. Te pionowe linie w załączniku kończą się na poziomych, czy też powinny dojść do granicy stref, tzn. pionowej linii, a zostały skrócone dla przejrzystości rysunku ?

Rysunek został uproszczony... Pionowe linie kończą się na granicach stref.

Dwa nowe pliki KML do Google Earth, z siatką co 10 km.
http://darekk.com/db/UTM/
(UTM_10.kml, UTM_10_markery.kml)
Ogromna liczba punktów, ale Google Earth wciąż nie zapycha się.
W Google Maps w przeciwieństwie do Google Earth linie są za nisko o 0-60 metrów, co jest spowodowane łączeniem tam punktów nie po powierzchni Ziemi (linią geodezyjną), ale mapy (odwzorowanie Mercatora). Co dotyczy tylko punktów z plików kml, nie JavaScript.
Ale Google Maps jest na stronie lepidoptera.eu.

Napracowałeś się, efekty są.
Przeglądając siatkę w Google Earth zauważylem dwie sprawy:

Markery (nazwy kwadratów) są na środku, trudno jest odgadnąć (odczytać) z mapki przy dużym powiększeniu jaki to jest kwadrat, przy tym mozna się tez pomylić. Lepiej jest, jak jest to napisane.

Jest jeszcze przesunięcie 380 m między siatką z Google Earth (Twoją) a siatką UTM generowaną na lepidopera.pl (Krzysztof Jonko). Z czego to może wynikać nie mam pojecia, ale podpowiadam, bo może to doprowadzić do stworzenia "idealnej" mapy UTM..... Załączam screeny na punkt - Spała

(w tej chwili odbywają się tam właśnie Dożynki Prezydenckie Spała 2011, od 14tej przemawia Prezydent B.Komorowski na głównej scenie, wieczorem Budka Suflera  - wejście gratis). A ja nie lubię tłumów i siedzę w domku

Raczej około 170 m. To na pewno wynika ze sposobu obliczania. Ja zastosowałem algorytm pochodzący z JavaScript kalkulatora ze strony Dutcha:
http://www.uwgb.edu/dutchs/usefuldata/ConvertUTMNoOZ.HTM
do którego objaśnienia i wzory są tutaj:
http://www.uwgb.edu/dutchs/UsefulData/UTMFormulas.HTM
Niestety potrzebna jest tutaj bardzo skomplikowana teoria, żeby wydać opinię na temat dokładności. Nie jestem tego w stanie zrobić.
Wynik obliczeń jest jednak zgodny z przykładem ze strony Wikipedii:
http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system:
43°38′33.24″N 79°23′13.7″W / 43.6425667°N 79.387139°W / 43.6425667; -79.387139 (CN Tower)
Kalkulator Dutcha podaje
Easting: 630084.3
Northing: 4833438.5
czyli tyle samo co Wikipedia:
17T 630084 4833438
Algorytm użyty do tworzenia tej mojej siatki będący konwersją algorytmu Dutcha z JavaScript do VBA Accessa:
630084.301482139
4833438.55257754
(usunąłem zaokrąglanie żeby uniknąć sumowania się jakichś błędów)
Kalkulator na stronie lepidoptera.eu:
17TPJ 30106 33519
Więc różnica między kalkulatorem lepidoptera.eu a Wikipedią (i algorytmem Dutcha oraz opartymi na nim moimi obliczeniami) wynosi dla tego przykładu (CN Tower):
30106 - 30084 = 22 metry w poziomie (W-E)
33519 - 33439 = 80 metrów w pionie (N-S)
Istnieje oczywiście możliwość, że na przykład Wikipedia i Dutch korzystają z tego samego błędnego algorytmu.

Przy okazji wysyłania wiadomości jeszcze siatka UTM na Google Maps
http://darekk.com/db/UTM/
(pliki UTM_Google_Maps.bmp (2.8 MB) oraz UTM_Google_Maps.gif (650 KB), obydwa 1001x971px)
Przy takim zoomie prowadzenie linii jako niegeodezyjnych nie ma żadnego znaczenia:
W pionie na wysokości okolic na pn-zach od Łodzi
1 px = 759 m
1 km = 1.3175 px
Więc nie zawiera żadnego błędu, pomimo tego że jest to Google Maps, a nie Earth. A nawet gdyby przyjąć 380 metrowe przesunięcie.

(załączona zmniejszona kopia, chociaż za dużo tej grafiki ...)

Jeszcze raz ...
Jednak jest mapa Google Maps nie pobierająca danych z pliku KML, ale rysująca linie przy pomocy JavaScript (Google Maps JavaScript API V3), gdzie polilinie poziome mają ustawioną opcję geodesic: true. Linie nie są więc obniżone. Mapa jednak długo ładuje się. Ze względu na ogromną liczbę punktów, którą być może dałoby się zredukować. Jak i zmniejszyć dokładność współrzędnych. Są wpisane na stałe, obliczone wcześniej przy pomocy Accessa, co teoretycznie powinno przyśpieszyć działanie JavaScript, chociaż zwiększyło rozmiary pliku.
Google Maps, UTM, siatka 10 km (link)
Są też nowe pliki UTM_Google_Maps.bmp oraz UTM_Google_Maps.gif będące zrzutami ekranu tej nowej mapy:
http://darekk.com/db/UTM/

Jeszcze w sprawie różnicy UTM na stronie lepidoptera.eu i tej mojej siatki, co wytknięto. Udało mi się wklepać wzory z Wikipedii:
http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system
do Accessa. Jedyne czego tam brakowało to wzór na lambda0, czyli meridian strefy. Wychodzi:
Easting: 630084.300906794
Northing: 4833438.58048011
Natomiast według wzorów NIMA:
http://earth-info.nga.mil/GandG/publications/tm8358.2/TM8358_2.pdf
(za http://www.ibm.com/developerworks/java/library/j-coordconvert/#resources)
Easting: 630084,300831664
Northing: 4833438,74925118
Przypomnę, że lepidoptera.eu podaje:
17TPJ 30106 33519
Podsumowując, kalkulator Dutcha jak i mój na nim oparty (w tym te siatki), wzory z Wikipedii oraz wzory NIM podają niemal ten sam wynik, inny niż na stronie lepidoptera.eu (różnica 22 metrów w poziomie i 80 metrów w pionie dla tej konkretnej lokalizacji z Wikipedii).
We wszystkich przypadkach został zastosowany standard WGS 84. Zauważyłem, że jeżeli wstawi się do kodu wymiary elipsoidy inne niż WGS 84, wychodzą nieco inne wyniki. To jest jedna z możliwych przyczyn różnic w obliczeniach.

Spokojnie, to nie jest wytykanie tylko porownywanie i zgłaszanie różnic. To 380m, ktore sygnalizowalem w poprzednim poscie jest wzięte bezpośrednio z pomiaru na mapach (żółta kreska, w Google Earth jest miarka i zmierzylem odległość miedzy dwoma punktami na mapie) i to jest 380 m pomijając wszelkie obliczenia.

Różnice, jakie wynikają z przyjecia róznych modeli i wzorów są nieistotne i pomijalne w mapowaniu owadów i mają na tym etapie już czysto teoretyczny charakter.

Ale właśnie te 380 czy chyba raczej sto kilkadziesiąt metrów wynika z różnicy w sposobie obliczania, czyli przyjętego modelu i wzorów. Bo linie są prowadzone przez punkty, których współrzędne zostały obliczone. Co 50 km jest postawiony punkt, którego długość i szerokość geograficzna zostały obliczone. Ten sposób którego użyłem daje takie same wyniki jak wzory z publikacji NIM, algorytm Dutcha i Wikipedia. Jedynie kalkulator lepidoptera.eu pokazuje wynik różniący się od tych wszystkich źródeł. Więc niestety, ale najprawdopodobniej tam tkwi błąd. A już na pewno przyczyna różnicy.
Na tej mapie (punkty z JavaScript, nie pliku KML):
http://darekk.com/db/UTM/UTM.htm
po kilknięciu pod spodem wyświetlają się współrzędne, w tym UTM. Czyli też wyniki obliczeń. Można sprawdzić, czy linie są rzeczywiście granicami kwadratów. Chociaż to nowa mapa, nie ten KML od którego się zaczęło.

Minęło za dużo czasu, więc musi być nowa wiadomość bo nie można redagować poprzedniej.
W załączniku są 3 zrzuty ekranu:

- lepidoptera.eu - linia pozioma (czerwona na dole)

- ten mój plik KML w Google Earth - linia pozioma (tu niebieska) rzeczywiście wyżej o około 350 metrów (linijka mierząca to na żółto) w porównaniu do lepidoptera.eu. Ale dodatkowo czerwony marker wyznaczający róg kwadratu:
34U 440000 5710000 (51.5379101890142 N, 20.13493223013313 E)
Znajduje się on idealnie w punkcie przecięcia linii. Więc położenie linii jest idealnie zgodne z obliczeniami. Czyli różnica w położeniu linii na pewno jest związana z odmiennymi sposobami obliczania.
A ponieważ tutaj wyniki obliczeń są zgodne z NIMA, algorytmem Dutcha, Wikipedią, więc to najprawdopodobniej na lepidoptera.eu jest coś nie tak. Chociąz pewności oczywiście nie ma.
Bardzo ładna ta strona lepidoptera.eu. A ewentualna drobna niedokładność obliczeń jest łatwa do skorygowania. To jakaś jedna funkcja.

- dodatkowo ta nowa wspomniana wcześniej mapa Google Maps z siatką zrobioną przy użyciu JavaScript, nie z pliku KML. Położenie linii takie samo jak w Google Earth na środkowym obrazku.

Dokładnie. Przesadna dokładność (do metrów) w badaniach entomologicznych jest zupełnie zbędna. Jeśli ktoś potrzebuje większej dokładności to korzysta się z GPS i ze współrzędnych geograficznych (z możliwością ich dowolnego przeliczania / kalkulowania / przedstawiania na mapach).
Z jednej strony prezentacja rozmieszczenia za pomocą map UTP jest powszechnie stosowana, z drugiej - równie często korzysta się z umownego podziału Polski na krainy i w publikacjach odnosi się raczej do tej drugiej opcji. Cokolwiek by w temacie nie pisać badania zoogeograficzne znacznej części owadziego świata wymagają dużo pracy i wysiłku. Metodyka jest dawno znana i opanowana i chyba nic nowego ostatnio w tej kwestii nie wymyślono. W ogólnych badaniach (np. GBIF) przyjmuje się dokładność kilku kilometrów jako zupełnie wystarczającą. Zwiększanie dokładności nie wnosi do badań absolutnie niczego... no chyba, że macie jakąś argumentację za zwiększaniem tej dokładności...?

Tak sobie Was czytam, czytam...
W latach 1987-1994 jeździłem w pewne miejsce. Wtedy siatka UTM wykreślona była na mapie..."na oko". Oczywiście były też dostępne mapy (ksero) od prof. J. Buszko. Ale tam o ile pamiętam też były poprawki...
Po paru latach chciałem nanieść na etykiety kody UTM, no i zaczęło się.
Skończyło się na jednym kodzie UTM.
Myślą, że zbyt duża dokładność to też przesada, ale w moim przypadku dojście do miejsca łapania nawet po miesiącu już nie wchodzi w grę

Etykietka nie zastąpi notatnika
Jak się ma talent to można niezłe dzieło napisać

Kiedyś pasjami czytałem dzienniki Miczurina i Darwina które poza suchym opisem faktów pokazywały tok myślenia i to było najciekawsze... no iten "duch" epoki... bezcenne.

Właśnie. Najważniejsze i najbardziej uniwersalne są współrzędne geograficzne. To podstawa wszystkiego.

UTM dzieli Polskę aż na 3 strefy, kwadraty na ich granicach są pościnane. Z tego punktu widzenia lepsza byłaby jedna strefa obejmująca cały kraj. Chociaż i tak byłyby wciąż pościnane przez granicę państwa (chociaż to znacznie mniej), no i nie byłby to uniwersalny kod UTM. To drugie byłoby wadą szczególnie w dobie integracji z Europą.
Do tej wiadomości jest dołączone zrzuty ekranu Google Maps i Google Earth takiego przykładowego, niestandardowego podziału UTM. A może nawet nie UTM. W każdym razie ma on się nijak do stref UTM. Powstał poprzez zastąpienie niektórych parametrów w algorytmie ze strony Dutcha
- zmianę położenia meridian - nie jest to już meridian strefy UTM (meridian jest oznaczona kolorem białym, sprawia wrażenie przerwy)
- odliczanie odległości od 350 km na wschód od meridian (zamiast 500). Tak żeby tuż za wschodnią granicą wyszło równo 700.
- odliczanie odległości w pionie od punktu położonego około 5 km na południe od południowej granicy państwa w Bieszczadach (zamiast od równika)
Ta trzecia zmiana nie była konieczna.
To amatorska ingerencja w algorytm, możliwe że powstały jakieś zniekształcenia i że trzeba by jakoś dodatkowo zmodyfikować wzory.
W każdym razie cała Polska jest w kwadracie 7x7 mniejszych kwadratów, każdy o boku 100 km. No i każdy 100 kilometrowy jest dodatkowo podzielony na 10 kilometrowe kwadraciki.
Analogiczne mapy są na pewno od dawna stosowane w zoologii i ekologii, ja niestety nie jestem w tym zorientowany.
I jeszcze plik KML do Google Earth:
http://darekk.com/db/UTM/UTM_x.kml (to nie UTM, w każdym razie nie standardowe)

Tak naprawdę jeżeli ktoś ma zapisane klasyczne współrzędne, to może robić z nimi wszystko - przeliczać na UTM jak i na każdą inną dowolną siatkę. Więc siatka nie ma znaczenia. Można używać również nietypowych.

Ani komputer. Bo jak prund wyłączą to koniec. Niedługo wyczerpuą się źródła energii, nastąpi katastrofa ekologiczna i spadnie meteoryt. W zasadzie jedyną gwarancję dają zapiski wykute w kamieniu.
W to pierwsze nie wierzę.

Nie napisałem tego żebyś wierzył, wierz w co chcesz nawet w Ojca Dyrektora, Google Earth i koniec świata w 2012

Na stronie
eBird
obserwacje są grupowane według jakichś kwadratów. Ale czy to UTM ? Na pierwszy rzut oka nie wygląda na to.

Za dużo tych wiadomości, ale jeszcze raz. Nowe informacje + podsumowanie poprzednich.

1) Google Maps

Do tej pory były dwa linki:
http://lepidoptera.pl/UTM_Europe.php
oraz powyższy z plikami gif i bmp oraz linkiem do takiej dość roboczej mapy.

Dzisiaj znalazłem stronę mappingsupport.com. Przykładowe linki:
Piątek k.Łodzi (środek Polski, zoom = 8 ) :
http://www.mappingsupport.com/p/gmap4.php?ll=52.0691667,19.4805556&t=t1&z=8&coord=utm
Zakrzew:
http://www.mappingsupport.com/p/gmap4.php?ll=51.448684,20.975382&t=m&z=13&coord=utm
Spała:
http://www.mappingsupport.com/p/gmap4.php?ll=51.533581,20.13511&t=s&z=15&coord=utm (załącznik)
Dostępne typy map:
t=m lub t=s lub t=h lub t=t1 lub t=t2 lub t=t3, domyślnie jest t=t1.
Przy okazji - te mapy pokazują, że ta zaatakowana moja jest dokładna.

2) Google Earth

Dlaczego wszyscy okazali się tak mało spostrzegawczy ? Google Earth może wyświetlać współrzędne UTM (załączniki). Wystarczy zaznaczyć odpowiednią opcję w narzędziach:
Tools - Options - 3DView - Show Lat/Long
i na dole mapy jak i w okienkach podczas na przykład dodawania markerów są współrzędne UTM zamiast stopni.
Przy okazji - pliki KML z siatką UTM dla Polski:
http://darekk.com/db/UTM/
są dokładne. Podczas przejeżdżania myszą przez jakąkolwiek linię zmieniają się z ..9999.. na ..0000.. lub odwrotnie. Nawet jak się zjedzie niemal do samej ziemi.

Dobre rzeczy. Mamy więc jasnośc co do prawidlowego UTM.
(no i drobna uwaga - Twoja mapa nie była "atakowana" tylko porównywana).

Teraz własnie skoncentruję się na UTM z lepidoptera.eu i nie jest to żaden 'atak" tylko porownanie z http://www.mappingsupport.com


Rzeczywiscie tak jest! Siatka wyrysowana jest inaczej niż pokazują to wartości otrzymane z klikniecia w mapę. Granica, na przykladzie Spały przy moscie, przebiega na poziomie skrzyzowania. Linie pionowe są idealnie tak samo jak wartości podawane z obliczeń siatki. Linie poziome (te prawidłowe) dzielące kwadraty są niewidoczne.
Ponizej pokazuję punkt klikany obok z różnicą o kilka pikseli  - dwie wartości kwadratów: DC40 i DC41.


No ale teraz  - jesli siatka UTM na lepidoptera.eu przebiega tam, to nie przebiega dokładnie tak jak na dobrym UTMie-  posluże się siatką z http://www.mappingsupport.com.


a różnica wynosi tylko 120 m. To informacja dla Krzysztofa Jonko, ktory zapewne w wolnej chwili dopracuje ten szegół. wtedy UTM na lepidoptera.eu będzie idealnie pokrywała się z UTM, sprawdzonym przez mysz leśną

Pozostaje jeszcze tylko żalować, że na mapie http://www.mappingsupport.com kwadraty nie nazywają się wg schematu DC41 tylko:
UTM    Zone 34
442327,5708462

(klikając prawym przyciskiem w mapę otrzymujemy info.


chociaż juz było tlumaczone jak to rozczytywać, tylko ze trzeba .. nauczyć się tego:
viewtopic.php?p=144513#p144513
A na lepidoptera.eu jest juz gotowiec.

Na zakończenie jako podsumowanie na jednym rysunku zaznaczyłem te linie (od góry):

linia UTM prawidlowa
linia UTM z obliczeń na lepidoptera.eu (klikać prawym przyciskiem w mapę)
linia UTM wyrysowana na mapie na lepidoptera.eu

Czy z tych wszystkich map współrzędne geograficzne odczytywane są prawidłowo ? Jeśli tak, to chyba prościej jest posługiwać się nimi i ewentualnie przeliczać na UTM w razie potrzeby. Myślę, że nie generuje się wtedy "braku zaufania" do informacji na ekranie.

Przeliczanie z współrzędnych na UTM osobnym narzędziem jest jak najbardziej dobrą metodą, ale to są dwa kroki:
1- odczytanie współrzędnych
2 -konwersja na UTM

a tu caly czas chodzi o narysowanie siatki wraz z informacją jaki to kwadrat UTM czyli spojrzeć na mapę i odczytać UTM.  I siatka na lepidoptera.eu jest prawie idealna, ale trochę się różni. Odczyty też róznią się o ok.120 m co generalnie nie ma ŻADNEGO znaczenia, poza teorią i komfortem psychicznym.

A może takie coś już gdzieś w sieci jest, jesli nie, to wyglada na to, że wkrótce będzie.

Siatka przygotowana przez mysz lesną (Darek) też wpisuje się tu jako dobre narzędzie (w GoogleEarth), wymaga tylko dodatkowych zabiegow kosmetycznych (np. nazwy kwadratów w każdym kwadracie).

Natomiast ta robocza siatka: http://darekk.com/db/UTM/UTM.htm
pokazuje już i współrzędne i kwadrat UTM (na czerwono), więc to jest TO.
A zauważyłem to dopiero teraz!  

Mapkę UTM z rozmieszczeniem jakiegoś gatunku można zrobić również na przykład przy pomocy programu Microsoft Access i Google Maps lub Earth. Tutaj:
http://darekk.com/db/UTM/
jest plik UTM.zip (zapakowany geog_do_UTM.mdb), który tworzy przykładową, prostą mapkę. To wersja minimum, demonstracyjna, możliwe że niedopracowana gdzieniegdzie. Zwłaszcza że niemal przed chwilą skończona (włączając wywrócony do góry nogami dotychczasowy kalkulator).
Kwadraty wyglądają jak w załączniku.
Każdy jest zapisywany oddzielnie w pliku kml, więc niewykluczone że przy ich dużej ilości Google moze się zapchać. W całym kraju jest chyba nieco ponad 4 tys kwadratów 10 km ...
Bardzo możliwe, że przed użyciem plik trzeba odblokować (pod prawym przyciskiem myszy na ikonie).

Tworzy on plik o nazwie mapa_UTM.kml w załączonym katalogu UTM_pliki. Plik otwiera się przy pomocy programu Google Earth lub w Google Maps:
http://maps.google.com/
Współrzędne wpisuje się do tabeli "wspolrzedne". Jeżeli są rozbite na stopnie, minuty a nawet sekundy po ich wpisaniu trzeba wcisnąć przycisk [Współrzędne - konwersja] w menu u góry. Zostaną przeliczone na same stopnie w kolumnach lon i lat.
Potem wystarczy wcisnąć przycisk [Utwórz plik KML]. Baza nie pyta się o zgodę na nadpisanie (chodzi o skrócenie kodu ...), więc trzeba uważać, żeby nie skasować poprzedniego pliku "UTM_pliki\mapa_UTM.kml" o ile jest potrzebny.
Z pewnego technicznego powodu baza mapuje tylko punkty na terytrorium Polski. Na innych obszarach omija kwadraty poprzecinane przez granice stref UTM.

Do obliczeń został użyty algorytm ze strony:
http://www.uwgb.edu/dutchs/usefuldata/ConvertUTMNoOZ.HTM(Steven Dutch, Natural and Applied Sciences,University of Wisconsin - Green Bay, Convert Between Geographic and UTM Coordinates)
z drobnymi modyfikacjami. Wyniki są identyczne jak w Google Earth oraz paru innych wiarygodnych źródłach.

Współrzędne z plików kml można masowo przerzucać do tabeli przy pomocy pliku gpxkml.mdb wchodzącego w skład innej bazy:
http://darekk.com/db/obserwacje/
Można na przykład dodawać markery w Google Earth, zapisać katalog je zawierający jako jakiś plik kml, otworzyć go przy pomocy gpxkml.mdb, a następnie przekopiować za jednym zamachem myszą wszystkie współrzędne do tabeli "wspolrzedne" w pliku geog_do_UTM.mdb.

Znalazłem ostatnio taką oto stronkę, szybka czytelna z możliwością dużego przybliżenia.
Wystarczy kliknąć w wybrany punkt, a dane same wyskakują u dołu strony.
http://darekk.com/db/UTM/UTM-mapa-Polski.htm

Co o niej sądzicie?

Podkład z google maps (więc nic nadzwyczajnego) z naniesioną siatką UTM.
Na lepidoptera.eu jest to samo i nanosi identycznie siatkę UTM.

Jak chcesz przybliżeń (choć bez siatki) zajrzyj tutaj:
http://mapy.geoportal.gov.pl/imap/

No nie. Cały wątek doprowadził do znalezienia siatki "idealnej", którą darekk umieścił właśnie w podanym linku:
http://darekk.com/db/UTM/UTM-mapa-Polski.htm
UTM na lepidoptera.eu jest  inny co przedstawia załączony poniżej obrazek (kilka postów wyżej o tym pisałem tutaj). Na mapach zaznaczyłem most w Spale. Zauważcie, gdzie leży przecięcie kwadratów. Te 170 m to czysto techniczna różnica, ale właśnie to pokazuje, ze te siatki są różne. Mapa Darka (myszlesna) jest prawdopodobnie dokładniejsza:


-------
https://entomo.pl/forum/viewtopic.php?p=200853#p200853