Przepuściłem ostatnio przez Resamplera fototeksturę o wymiarach 16km x 43km (6336px x 15712px) i napotkałem problem z dokładnością obliczeń.
W pliku *.inf dla resamplera możemy z dowolną dokładnością (ilość miejsc po przecinku) podać współrzędne (x,y) oraz, co jest znacznie bardziej istotne w przypadku dużych materiałów, wymiar x cell dimension oraz y cell dimension.
Po uruchomieniu resampler wyświetla informację z parametrami pracy i tam o zgrozo podaje wpisane wartości zaokrąglone do szóstego miejsca po przecinku.
W przypadku opisywanego materiału jego rzeczywisty wymiar w stopniach wynosi:
lattitude (N-S) 0.390905 stopnia, longitude (W-E) 0.271847 stopnia
Po obróbce przez zaokrąglenie resamplera wymiar zmienia się i wynosi:
rozciągłość lattitude = (cell x dimension deg) x (NumOfCellsPerLine)
co po podstawieniu danych daje 6336 x 0.000043 = 0.272448 stopnia
Różnica pomiędzy faktycznym wymiarem 0.271847 stopnia a obliczonym przez resampler 0.272448 stopnia wynosi 0.000601 stopnia. W wartościach metrycznych jest to ok. 40m
rozciągłość longitude = (cell y dimension deg) x (NumOfLines)
co po podstawieniu danych daje 15712 x 0.000025 = 0.3928 stopnia
Różnica pomiędzy faktycznym wymiarem 0.390905 stopnia a obliczonym przez resampler 0.3928 stopnia wynosi 0.001895 stopnia. W wartościach metrycznych jest to ok. 126m
Różnice te powodują brak spasowania fototekstury na jej granicach z materiałem znajdującym się niżej oraz rozbieżność pozycji dla obiektów zamieszczanych za pomocą zadanych wartości lat i lon.
Jedynym pomysłem jaki mi przychodzi do głowy jest podzielenie fototekstury na kilka mniejszych.
Każdy z mniejszych materiałów będzie miał zadaną pozycję startową (lat, lon) i błąd wynikający z zaokrąglenia wymiaru x cell i y cell będzie mniejszy o tyle o ile mniejszy będzie wymiar bitmapy.
Czy jeszcze ktoś miał z tym problem?
Pozdrawiam,
Macmar
Dokładność Resamplera
Moderatorzy: PZL Belfegor, RzEmYk
Idziesz troszkę złym tropem.
To nie wina resamplera, tylko materiału źródłowego, a raczej jego odwzorowania katrometrycznego.
Jeśli materiał pochodzi z posklejanych zrzutów ekranu np. Earth Google, to uzyskana bitmapa ma odwzorowanie "trapezowe", czyli południki nie są do siebie równoległe.
Przy dużych bitmapach np.LOD8 (32x32 LOD13), dopasowanie sąsiednich obszarów jest niemożliwe.
Wspominał o tym w moim starym wątku o fotoscenerii gminy Zabierzów Wojtek Krzywda z Simdesign.
Ponieważ w FS'ie południki i równoleżniki przecinają się zawsze pod kątem prostym, czyli południki są do siebie równoległe (sic!), duża bitmapa, np.LOD8, musi być najpierw przygotowana (rozciągnięta/wyrównana) za pomocą specjalistycznego oprogramowania do przekształceń kartometrycznych.
Nie znam żadnego darmowego programu, który potrafi to zrobić, a komercyjne są tak gigantycznie drogie, że mogą sobie na nie pozwolić firmy i instytucje.
Jeśli materiał pochodzi z Earth Google, to jest tam checkbox "Terrain", który przed wykonaniem zrzutów trzeba koniecznie wyłączyć. Ale to tylko trochę poprawi sytuację.
Dla twórczości amatorskiej pozostaje więc tylko podział na mniejsze obszary, co zredukuje różnice na łączeniach.
Pozdrawiam, Qba.
To nie wina resamplera, tylko materiału źródłowego, a raczej jego odwzorowania katrometrycznego.
Jeśli materiał pochodzi z posklejanych zrzutów ekranu np. Earth Google, to uzyskana bitmapa ma odwzorowanie "trapezowe", czyli południki nie są do siebie równoległe.
Przy dużych bitmapach np.LOD8 (32x32 LOD13), dopasowanie sąsiednich obszarów jest niemożliwe.
Wspominał o tym w moim starym wątku o fotoscenerii gminy Zabierzów Wojtek Krzywda z Simdesign.
Ponieważ w FS'ie południki i równoleżniki przecinają się zawsze pod kątem prostym, czyli południki są do siebie równoległe (sic!), duża bitmapa, np.LOD8, musi być najpierw przygotowana (rozciągnięta/wyrównana) za pomocą specjalistycznego oprogramowania do przekształceń kartometrycznych.
Nie znam żadnego darmowego programu, który potrafi to zrobić, a komercyjne są tak gigantycznie drogie, że mogą sobie na nie pozwolić firmy i instytucje.
Jeśli materiał pochodzi z Earth Google, to jest tam checkbox "Terrain", który przed wykonaniem zrzutów trzeba koniecznie wyłączyć. Ale to tylko trochę poprawi sytuację.
Dla twórczości amatorskiej pozostaje więc tylko podział na mniejsze obszary, co zredukuje różnice na łączeniach.
Pozdrawiam, Qba.
"Quidquid agis, prudenter agas et respice finem"
-
macmar
Czytałem ten wątek o którym piszesz (Zabierzów), czytałem też wątek o problemach technicznych przy produkcji VFR Poland NW. Swoją drogą dziękuję za przypomnienie, bo ze sklerozy zapomniałem, że dokładność spasowania wynika również z tego powodu.rophone pisze:Idziesz troszkę złym tropem.
To nie wina resamplera, tylko materiału źródłowego, a raczej jego odwzorowania katrometrycznego.
Wspominał o tym w moim starym wątku o fotoscenerii gminy Zabierzów Wojtek Krzywda z Simdesign.
Ponieważ w FS'ie południki i równoleżniki przecinają się zawsze pod kątem prostym, czyli południki są do siebie równoległe (sic!), duża bitmapa, np.LOD8, musi być najpierw przygotowana (rozciągnięta/wyrównana) za pomocą specjalistycznego oprogramowania do przekształceń kartometrycznych.
Jeśli materiał pochodzi z Earth Google, to jest tam checkbox "Terrain", który przed wykonaniem zrzutów trzeba koniecznie wyłączyć. Ale to tylko trochę poprawi sytuację.
Pozdrawiam, Qba.
Wracając do Resamplera i abstrahując od odwzorowania powierzchni w materiale źródłowym, czy nie wydaje Ci się jednak, że zaokrąglanie rozmiaru dla parametru CellXdimensionDeg i CellYdimensionDeg przy dużych wielkościach parametrów NumOfCellsPerLine i NumOffLines powoduje przekłamanie wymiaru zresamplowanej bitmapy?
Popatrz tylko na samo wyliczenie. Wynikowy (po zresamplowaniu) rozmiar w stopniach nie jest równy pierwotnemu rozmiarowi.
Pozdrawiam,
Macmar
PS Google Earth nie jest dobrym źródłem do "amatorskich" fototekstur ze względu na niejednorodne wyświetlanie obrazu (chodzi o ostrość w środku i po bokach), tak miały wszystkie normalne wersje GE które widziałem. Nie wiem jak to wygląda w wersjach Plus czy w Pro. Lepszym rozwiazaniem jest Google Map wraz z programem do "wirtualizowania" rozdzielczości ekranu :-)
Nie. Sugerujesz się raportem resamplera. W wersji SDK 2004 tak to wygląda. W poprzednich wersjach bywało z tym różnie, ale to tylko "raportowe", wizualne uproszczenie. Bezsensowne zresztą. Wersja 2002 nie upraszczała (wizualnie), ale miała inne błędy, o czym wiadomo.macmar pisze:... czy nie wydaje Ci się jednak, że zaokrąglanie rozmiaru dla parametru CellXdimensionDeg i CellYdimensionDeg przy dużych wielkościach parametrów NumOfCellsPerLine i NumOffLines powoduje przekłamanie wymiaru zresamplowanej bitmapy?
W rzeczywistości precyzja jest taka, jak trzeba, a jedynym powodem niedokładności jest "trapez". Wynikowe pliki LOD13 mają ZAWSZE poprawny geograficznie rozmiar CellXDimensionDeg x CellYDimensionDeg.
Trust me
"Quidquid agis, prudenter agas et respice finem"
-
macmar
Pocieszyłeś mnie :-) Dzięki.rophone pisze: Nie. Sugerujesz się raportem resamplera. W wersji SDK 2004 tak to wygląda. W rzeczywistości precyzja jest taka, jak trzeba, a jedynym powodem niedokładności jest "trapez". Wynikowe pliki LOD13 mają ZAWSZE poprawny geograficznie rozmiar CellXDimensionDeg x CellYDimensionDeg.
Trust me
Swoją drogą to po jakie licho program raportuje zaokrąglone wartości?!
W międzyczasie zacząłem pomiary. W rogach scenerii powbijałem "kołki" (ładne mi kołki - 5m x 5m x 100m) czyli obiekty o dokładnie wyznaczonej pozycji. I właśnie mam zamiar sprawdzić przemieszczenia w poszczególnych wierzchołkach. Jak będą wszędzie jednakowe to będzie oznaczać, że nie ma przekłamania w obliczeniach, a przesunięcie wynika tylko z niedokładnego wprowadzenia przeze mnie pozycji początkowej.
Pozdrawiam,
Macmar