🚀 go-pugleaf

On 11/11/10 21:11, mt wrote:
> Witam.
> Za pomocą wtyczki GDAL Tools do QGISa (wersja 1.2.0 opartego na GDAL  w
> wersji 1.6.3) dokonałem hurtowej reprojekcji rastrów z 1965/3 na 1992 no
> i po otwarciu z pozostałymi danymi wektorowymi zdziwienie, gdyż nastąpił
> spory rozjazd między wektorami a rastrami w nowym odwzorowaniu, zacząłem
> sprawdzać dokładniej i się okazało, że po reprojekcji błąd przeliczenia
> współrzędnych wynosi około 130 metrów w osi równoleżnikowej i około 30
> metrów w osi południkowej. Spotkał sie ktoś z Was już z czymś takim?

Ja się nie spotkałem, ale nie wykluczone, że jest błąd.
Proponuję wrzucić ticket do bazy błędów:

http://trac.osgeo.org/qgis

Pozdrawiam,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org

Mateusz Loskot pisze:

> Ja się nie spotkałem, ale nie wykluczone, że jest błąd.
> Proponuję wrzucić ticket do bazy błędów:
> 
> http://trac.osgeo.org/qgis

Dzięki, zgłoszone.
Aczkolwiek doczytałem jeszcze na forum QGIS, że nie tylko ja mam 
problemy z reprojekcją rastrów z układu 1965 do 1992 czy 2000. Pewnym 
rozwiązaniem jest reprojekcja pośrednia przez np. WGS84, wtedy błąd 
przeliczenia wynosi około 5 - 6 metrów w obu osiach, ale już nie ponad 
100 :). Inną sprawą jest co gdalwarp robi z tym plikiem pośrednim w 
WGS84. Co prawda współrzędne zaszyte w geotiffie są mniej więcej ok, ale 
raster jest jakby mocno rozciągnięty poziomo. Podejrzałem nagłówek tiffa 
i z pliku o wymiarach ok. 12000x8000 pikseli po reprojekcji do WGS84 
powstaje plik o wymiarach ok. 14000x5000 pikseli, stąd ten efekt 
rozciągnięcia/spłaszczenia, a to chyba też nie powinno mieć miejsca?

-- 
marcin

mt pisze:
> Mateusz Loskot pisze:
> 
>> Ja się nie spotkałem, ale nie wykluczone, że jest błąd.
>> Proponuję wrzucić ticket do bazy błędów:
>>
>> http://trac.osgeo.org/qgis
> 
> Dzięki, zgłoszone.
> Aczkolwiek doczytałem jeszcze na forum QGIS, że nie tylko ja mam 
> problemy z reprojekcją rastrów z układu 1965 do 1992 czy 2000. Pewnym 
> rozwiązaniem jest reprojekcja pośrednia przez np. WGS84, wtedy błąd 
> przeliczenia wynosi około 5 - 6 metrów w obu osiach, ale już nie ponad 
> 100 :). Inną sprawą jest co gdalwarp robi z tym plikiem pośrednim w 
> WGS84. Co prawda współrzędne zaszyte w geotiffie są mniej więcej ok, ale 
> raster jest jakby mocno rozciągnięty poziomo. Podejrzałem nagłówek tiffa 
> i z pliku o wymiarach ok. 12000x8000 pikseli po reprojekcji do WGS84 
> powstaje plik o wymiarach ok. 14000x5000 pikseli, stąd ten efekt 
> rozciągnięcia/spłaszczenia, a to chyba też nie powinno mieć miejsca?

To jeszcze odpowiem poniekąd sobie. Problem zdaje się jest w nowych 
wydaniach bibliotek GDAL. W starszej wersji FWTools (ja mam 1.3.5) 
reprojekcja z 1965/3 do 1992 przebiega bezbłędnie. Używając QGIS 1.5.0 
czy FWTools w wydaniu 2.4.7 ten sam raster jest przesunięty o ponad 130 
metrów! Nie śledzę dokładnie historii implementacji różnych wersji GDAL, 
więc nie wiem kiedy jakiś ewentualny błąd mógł się pojawić.
Jeszcze mam pytanie, da się, mając zainstalowanego QGIS i FWTools w 
jakiejś starszej wersji, podmienić pliki i które ewentualnie, aby 
wtyczka do QGIS korzystała ze starszych wersji bibliotek GDAL? Sama 
zamiana pliku gdalwarp.exe nie daje porządanego rezultatu i raster po 
reprojekcji wciąż jest przesunięty.

-- 
pozdrawiam
marcin

"mt" <telepski@interia.pl> wrote in message 
news:ibjami$so5$1@usenet.news.interia.pl...
> mt pisze:
>> Mateusz Loskot pisze:
>>
>>> Ja się nie spotkałem, ale nie wykluczone, że jest błąd.
>>> Proponuję wrzucić ticket do bazy błędów:
>>>
>>> http://trac.osgeo.org/qgis
>>
>> Dzięki, zgłoszone.
>> Aczkolwiek doczytałem jeszcze na forum QGIS, że nie tylko ja mam problemy 
>> z reprojekcją rastrów z układu 1965 do 1992 czy 2000. Pewnym rozwiązaniem 
>> jest reprojekcja pośrednia przez np. WGS84, wtedy błąd przeliczenia 
>> wynosi około 5 - 6 metrów w obu osiach, ale już nie ponad 100 :). Inną 
>> sprawą jest co gdalwarp robi z tym plikiem pośrednim w WGS84. Co prawda 
>> współrzędne zaszyte w geotiffie są mniej więcej ok, ale raster jest jakby 
>> mocno rozciągnięty poziomo. Podejrzałem nagłówek tiffa i z pliku o 
>> wymiarach ok. 12000x8000 pikseli po reprojekcji do WGS84 powstaje plik o 
>> wymiarach ok. 14000x5000 pikseli, stąd ten efekt 
>> rozciągnięcia/spłaszczenia, a to chyba też nie powinno mieć miejsca?
>
> To jeszcze odpowiem poniekąd sobie. Problem zdaje się jest w nowych 
> wydaniach bibliotek GDAL.

GDAL używa PROJ.4 - http://trac.osgeo.org/proj

Jeśli błąd leży w samej transformacji, to jest to problem PROJ.4.
Możesz spróbować wyizolować przykładowe punkty z rastra i sprawdzić
ich transformację za pomocą narzędzi proj:

http://trac.osgeo.org/proj/wiki/man_proj
http://trac.osgeo.org/proj/wiki/man_cs2cs

> Jeszcze mam pytanie, da się, mając zainstalowanego QGIS i FWTools w 
> jakiejś starszej wersji, podmienić pliki i które ewentualnie, aby wtyczka 
> do QGIS korzystała ze starszych wersji bibliotek GDAL? Sama zamiana pliku 
> gdalwarp.exe nie daje porządanego rezultatu i raster po reprojekcji wciąż 
> jest przesunięty.

Teoretycznie jest to możliwe, ale jedynie w obrębie kompatybilnych wersji 
GDAL.
Na przykład, jeśli QGIS używa GDAL 1.7.0, a w FWTools masz GDAL 1.6.0
to podmiana biblioteki GDAL w instalacji QGIS nie zadziała.
Ale jeśli to podmiana GDAL 1.7.0 na np. 1.7.2, to powinno zadziałać.

Idzie o kompatybilność binarną bibliotek.

Podmiana polega na skopiowaniu gdal.dll.

Pozdrawiam,
-- 
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite 

Użytkownik mt napisał:
> Mateusz Loskot pisze:
>
>> Ja się nie spotkałem, ale nie wykluczone, że jest błąd.
>> Proponuję wrzucić ticket do bazy błędów:
>>
>> http://trac.osgeo.org/qgis
>
> Dzięki, zgłoszone.
> Aczkolwiek doczytałem jeszcze na forum QGIS, że nie tylko ja mam
> problemy z reprojekcją rastrów z układu 1965 do 1992 czy 2000. Pewnym
> rozwiązaniem jest reprojekcja pośrednia przez np. WGS84, wtedy błąd
> przeliczenia wynosi około 5 - 6 metrów w obu osiach, ale już nie ponad
> 100 :). Inną sprawą jest co gdalwarp robi z tym plikiem pośrednim w
> WGS84. Co prawda współrzędne zaszyte w geotiffie są mniej więcej ok, ale
> raster jest jakby mocno rozciągnięty poziomo. Podejrzałem nagłówek tiffa
> i z pliku o wymiarach ok. 12000x8000 pikseli po reprojekcji do WGS84
> powstaje plik o wymiarach ok. 14000x5000 pikseli, stąd ten efekt
> rozciągnięcia/spłaszczenia, a to chyba też nie powinno mieć miejsca?

Przy przejściu między 1965 a 2000 uwzględniłeś zmianę elipsoidy ?
Standardowo nie jest to robione. Pytałem na grupie proj4 i tam mi 
zwrócono uwagę na to.
Pozdrawiam
Michał

Fri, 12 Nov 2010 19:36:45 +0100  *Michal Baranski*  w bezpośredniej relacji
z pl.comp.gis donosi:

> Przy przejściu między 1965 a 2000 uwzględniłeś zmianę elipsoidy ?
> Standardowo nie jest to robione. Pytałem na grupie proj4 i tam mi 
> zwrócono uwagę na to.
> Pozdrawiam
> Michał

Najprawdopodobniej to jest właśnie powodem tych rozbieżności przy przejściu
1965->2000 (a także 1992).
Na szczęście wystarczy drobna poprawka w definicji układu - zamiast
parametru ellps należy użyć +datum=wgs84 - i wtedy transformacje powinny
wykonywać się poprawnie. Być może w nowszych wersjach proj i GDAL są już
poprawione definicje, ale kiedyś wszystkie polskie układy nie miały
uwzględnionego datum. 

-- 
pozdrawiam,
Michał

Michał Kursa pisze:
> Fri, 12 Nov 2010 19:36:45 +0100  *Michal Baranski*  w bezpośredniej relacji
> z pl.comp.gis donosi:
> 
>> Przy przejściu między 1965 a 2000 uwzględniłeś zmianę elipsoidy ?
>> Standardowo nie jest to robione. Pytałem na grupie proj4 i tam mi 
>> zwrócono uwagę na to.
>> Pozdrawiam
>> Michał
> 
> Najprawdopodobniej to jest właśnie powodem tych rozbieżności przy przejściu
> 1965->2000 (a także 1992).
> Na szczęście wystarczy drobna poprawka w definicji układu - zamiast
> parametru ellps należy użyć +datum=wgs84 - i wtedy transformacje powinny
> wykonywać się poprawnie. Być może w nowszych wersjach proj i GDAL są już
> poprawione definicje, ale kiedyś wszystkie polskie układy nie miały
> uwzględnionego datum. 

No ale to właśnie w nowszych wersjach jest ponad 100-metrowy błąd, w 
starszym (1.3.5) FWTools transformacja jest poprawna :)
Ale sprawdzę o czym piszecie.

-- 
marcin

Użytkownik Michał Kursa napisał:
> Najprawdopodobniej to jest właśnie powodem tych rozbieżności przy przejściu
> 1965->2000 (a także 1992).
> Na szczęście wystarczy drobna poprawka w definicji układu - zamiast
> parametru ellps należy użyć +datum=wgs84 - i wtedy transformacje powinny
> wykonywać się poprawnie. Być może w nowszych wersjach proj i GDAL są już
> poprawione definicje, ale kiedyś wszystkie polskie układy nie miały
> uwzględnionego datum.
>

Określenie datum przy definicji układu nie jest potrzebne, potrzebne 
jest przy przejściu.
Michał

W dniu 11.11.2010 22:11, mt pisze:

> Za pomocą wtyczki GDAL Tools do QGISa (wersja 1.2.0 opartego na GDAL
> w wersji 1.6.3) dokonałem hurtowej reprojekcji rastrów z 1965/3 na
> 1992 no i po otwarciu z pozostałymi danymi wektorowymi zdziwienie,
> gdyż nastąpił spory rozjazd między wektorami a rastrami w nowym
> odwzorowaniu, zacząłem sprawdzać dokładniej i się okazało, że po
> reprojekcji błąd przeliczenia współrzędnych wynosi około 130 metrów w
> osi równoleżnikowej i około 30 metrów w osi południkowej. Spotkał sie
> ktoś z Was już z czymś takim?

Przyczyna błedu jest (była) w GDALu - w 1.7.x wcięło definicję towgs84
dla polskich układów opartych na elipsoidzie Krasowskiego. Wcześniej,
jeszcze przed 1.6.3, GDAL przestał stosować towgs84=0,0,0 dla układów
opartych na GRS80. Skutki uboczne koniecznych zmian w realizacji układów
współrzędnych w GDALu.

Popraw (albo stwórz, jeśli nie istnieje) plik
sciezka_do_gdala/share/gdal/gcs.override.csv zgodnie z
http://trac.osgeo.org/gdal/changeset/19810. Daj znać czy to załatwia sprawę.

W starszych QGISach warto też przejrzeć czy wpisy dla nastepujących
EPSG: 3120 2172 2173 2174 2175 3333 3334 3335 3329 3330 3331 3332 3328
4179 mają jawne, poprawne towgs84. Jeśli nie, należy zdefiniować własne
parametry dla tych układów - jako kopie istniejących w QGISie plus
odpowiednia definicja towgs84, poprzez Opcje > Układ współrzędnych
użytkownika.

Niedawno wydany GDAL 1.7.3 zawiera już poprawkę. Oparte na nim
oprogramowanie (miejmy nadzieję, że równiez nadchodzący QGIS 1.6)
powinny być pozbawione problemu raz na zawsze.

BTW: w GRASSie, który używa własnej kopii gdalowych *.csv z definicjami
układów, poprawkę naniosłem jeszcze przed wydaniem 6.4.0
(http://trac.osgeo.org/grass/changeset/42666).

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

W dniu 12.11.2010 01:29, mt pisze:
> Mateusz Loskot pisze:
>
>> Ja się nie spotkałem, ale nie wykluczone, że jest błąd. Proponuję
>> wrzucić ticket do bazy błędów:
>>
>> http://trac.osgeo.org/qgis
>
> Dzięki, zgłoszone.

Podaj link.

> Aczkolwiek doczytałem jeszcze na forum QGIS, że nie tylko ja mam
> problemy z reprojekcją rastrów z układu 1965 do 1992 czy 2000. Pewnym
>  rozwiązaniem jest reprojekcja pośrednia przez np. WGS84, wtedy błąd
>  przeliczenia wynosi około 5 - 6 metrów w obu osiach,

Cos tam czytałem ale tego o "5 - 6 metrach" sobie nie przypominam.
Możesz podać link?

> ale już nie ponad 100 :). Inną sprawą jest co gdalwarp robi z tym
> plikiem pośrednim w WGS84. Co prawda współrzędne zaszyte w geotiffie
> są mniej więcej ok, ale raster jest jakby mocno rozciągnięty poziomo.
> Podejrzałem nagłówek tiffa i z pliku o wymiarach ok. 12000x8000
> pikseli po reprojekcji do WGS84 powstaje plik o wymiarach ok.
> 14000x5000 pikseli, stąd ten efekt rozciągnięcia/spłaszczenia, a to
> chyba też nie powinno mieć miejsca?

Powinno. Zupełnie inna geometria układów - układ współrzędnych
geodezyjnych jest "bardziej prostokątny", a układy takie jak PUWG 1992
"kwadratowawe".

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

W dniu 12.11.2010 22:38, Michał Kursa pisze:

> Być może w nowszych wersjach proj i GDAL są już poprawione definicje,
> ale kiedyś wszystkie polskie układy nie miały uwzględnionego datum.

Długie lata temu. Potem zrobiłem żeby miały. Potem sie zrypało, bo mi
się nie chciało pilnować. Teraz znowu powinno być OK. Kto teraz
popilnuje :)?

Parafrazując wieszcza - "FOSS4G to wielki zbiorowy obowiązek" :D.

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

Maciej Sieczka pisze:

>> Dzięki, zgłoszone.
> 
> Podaj link.

Ticket był zgłoszony, lecz już go zamknąłem ze względu na to iż problem 
nie był po stronie implementacji modułu, lecz samego GDAL (czy też 
PROJ4). Tutaj link:
https://trac.osgeo.org/qgis/ticket/3199

>> Aczkolwiek doczytałem jeszcze na forum QGIS, że nie tylko ja mam
>> problemy z reprojekcją rastrów z układu 1965 do 1992 czy 2000. Pewnym
>>  rozwiązaniem jest reprojekcja pośrednia przez np. WGS84, wtedy błąd
>>  przeliczenia wynosi około 5 - 6 metrów w obu osiach,
> 
> Cos tam czytałem ale tego o "5 - 6 metrach" sobie nie przypominam.
> Możesz podać link?

A te 5-6 metrów (z tolerancją na chociażby grubość ramki mapy) to z 
moich własnych prób wyszło.

>> ale już nie ponad 100 :). Inną sprawą jest co gdalwarp robi z tym
>> plikiem pośrednim w WGS84. Co prawda współrzędne zaszyte w geotiffie
>> są mniej więcej ok, ale raster jest jakby mocno rozciągnięty poziomo.
>> Podejrzałem nagłówek tiffa i z pliku o wymiarach ok. 12000x8000
>> pikseli po reprojekcji do WGS84 powstaje plik o wymiarach ok.
>> 14000x5000 pikseli, stąd ten efekt rozciągnięcia/spłaszczenia, a to
>> chyba też nie powinno mieć miejsca?
> 
> Powinno. Zupełnie inna geometria układów - układ współrzędnych
> geodezyjnych jest "bardziej prostokątny", a układy takie jak PUWG 1992
> "kwadratowawe".

Ale aż takie różnice? Po reprojekcji arkusza mapy topo 1 : 10 000 z 65/3 
do WGS84 pod względem "geometrycznym" nowy arkusz jest praktycznie 
dwukrotnie rozciągnięty.

-- 
marcin

Witam
Korzystałem z biblioteki proj4, która była dostępna na początku roku i 
musiałem sobie dopisać +towgs84=,,,.
Czy tam też są zrobione poprawki w definicjach ?
Dobrze by było aby polskie układy w końcu dobrze przeliczałyby się.
Pozdrawiam
Michał

Maciej Sieczka pisze:

> Przyczyna błedu jest (była) w GDALu - w 1.7.x wcięło definicję towgs84
> dla polskich układów opartych na elipsoidzie Krasowskiego. Wcześniej,
> jeszcze przed 1.6.3, GDAL przestał stosować towgs84=0,0,0 dla układów
> opartych na GRS80. Skutki uboczne koniecznych zmian w realizacji układów
> współrzędnych w GDALu.
> 
> Popraw (albo stwórz, jeśli nie istnieje) plik
> sciezka_do_gdala/share/gdal/gcs.override.csv zgodnie z
> http://trac.osgeo.org/gdal/changeset/19810. Daj znać czy to załatwia 
> sprawę.

No niestety nie załatwia, chyba że ja coś źle robię, ale o tym poniżej.
Generalnie plik gcs.override.csv występuje w QGIS w trzech miejscach:
C:\QGIS\apps\gdal-16\share\gdal\
C:\QGIS\share\epsg_csv\
C:\QGIS\share\gdal\
W pierwszym i trzecim przypadku dodałem do wspomnianego pliku:
4284,Pulkovo 1942,6284,Pulkovo 
1942,6284,9122,7024,8901,1,0,6422,9607,23.9,-141.3,-80.9,0,-0.37,-0.85,-0.12
W drugim przypadku ten zapis był już standardowo w pliku gcs.override 
jednak po wszystkich zmianach qgis nadal podaje
towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs
Jak domniemam to jest przyczyna błędnego przeliczania?
Ponadto, w panelu Układ współrzędnych użytkownika zdefiniowałem na nowo 
65/3 z poprawionym parametrem towgs84, pełne parametry poniżej:
+proj=sterea +lat_0=53.58333333333334 +lon_0=17.00833333333333 +k=0.9998 
+x_0=3501000 +y_0=5999000 +ellps=krass 
+towgs84=23.9,-141.3,-80.9,0,-0.37,-0.85,-0.12 +units=m +no_defs
No i dalej jest ten sam ponad 100-metrowy błąd po reprojekcji, więc sam 
już nie wiem gdzie leży przyczyna. Ale dzięki za poświęcony czas!

-- 
pozdrawiam
marcin

Pytałem o EPSG:2175 <=>EPSG:2177
Może ci pomoże, a odpowiedzieli mi:

http://trac.osgeo.org/proj/wiki/FAQ#WhydoIgetdifferentresultswith4.5.0and4.6.0


EPSG:2175 is based on the old geodetic datum Pulkovo 1942(58), while
EPSG:2177 is based
on the modern datum ETRS89, which is nearly the same as WGS84.

The following seems to work fine, with errors around 0.02 meters:

     cs2cs +init=EPSG:2175 +towgs84=33.4,-146.6,-76.3,-0.359,
-0.053,0.844,-0.84 +to +init=EPSG:2177 +datum=WGS84

I found the parameters on www.epsg-registry.org,via Query by Filter:
      Name: pulkovo
      Type: Coordinate Transformation
      Area: Poland

Since EPSG published these parameters as a
"Position Vector transformation", I did not have to reverse the signs
of the three rotation angles.

W dniu 18.11.2010 01:45, mt pisze:
> Maciej Sieczka pisze:
>
>> Przyczyna błedu jest (była) w GDALu - w 1.7.x wcięło definicję towgs84
>> dla polskich układów opartych na elipsoidzie Krasowskiego. Wcześniej,
>> jeszcze przed 1.6.3, GDAL przestał stosować towgs84=0,0,0 dla układów
>> opartych na GRS80. Skutki uboczne koniecznych zmian w realizacji układów
>> współrzędnych w GDALu.
>>
>> Popraw (albo stwórz, jeśli nie istnieje) plik
>> sciezka_do_gdala/share/gdal/gcs.override.csv zgodnie z
>> http://trac.osgeo.org/gdal/changeset/19810. Daj znać czy to załatwia
>> sprawę.
>
> No niestety nie załatwia, chyba że ja coś źle robię, ale o tym poniżej.
> Generalnie plik gcs.override.csv występuje w QGIS w trzech miejscach:
> C:\QGIS\apps\gdal-16\share\gdal\
> C:\QGIS\share\epsg_csv\
> C:\QGIS\share\gdal\
> W pierwszym i trzecim przypadku dodałem do wspomnianego pliku:
> 4284,Pulkovo 1942,6284,Pulkovo
> 1942,6284,9122,7024,8901,1,0,6422,9607,23.9,-141.3,-80.9,0,-0.37,-0.85,-0.12
>
> W drugim przypadku ten zapis był już standardowo w pliku gcs.override
> jednak po wszystkich zmianach qgis nadal podaje
> towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs
> Jak domniemam to jest przyczyna błędnego przeliczania?
> Ponadto, w panelu Układ współrzędnych użytkownika zdefiniowałem na nowo
> 65/3 z poprawionym parametrem towgs84, pełne parametry poniżej:
> +proj=sterea +lat_0=53.58333333333334 +lon_0=17.00833333333333 +k=0.9998
> +x_0=3501000 +y_0=5999000 +ellps=krass
> +towgs84=23.9,-141.3,-80.9,0,-0.37,-0.85,-0.12 +units=m +no_defs
> No i dalej jest ten sam ponad 100-metrowy błąd po reprojekcji, więc sam
> już nie wiem gdzie leży przyczyna. Ale dzięki za poświęcony czas!

Ciort znajet. Żeby odtworzyć twój problem musiałbym tak samo 
skonfigurować instalację QGISa i GDALa. Mogę spróbować w weekend, skoro 
juz zacząłem temat ;). Piszesz, że QGIS 1.2. Żadnych innych instalacji 
GDAL, GRASS, PROJ.4 czy samego QGISa? A dlaczego nie nowszy QGIS?

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

W dniu 17.11.2010 23:42, mt pisze:
> Maciej Sieczka pisze:

>>> Podejrzałem nagłówek tiffa i z pliku o wymiarach ok. 12000x8000
>>> pikseli po reprojekcji do WGS84 powstaje plik o wymiarach ok.
>>> 14000x5000 pikseli, stąd ten efekt rozciągnięcia/spłaszczenia, a to
>>> chyba też nie powinno mieć miejsca?
>>
>> Powinno. Zupełnie inna geometria układów - układ współrzędnych
>> geodezyjnych jest "bardziej prostokątny", a układy takie jak PUWG 1992
>> "kwadratowawe".
>
> Ale aż takie różnice? Po reprojekcji arkusza mapy topo 1 : 10 000 z 65/3
> do WGS84 pod względem "geometrycznym" nowy arkusz jest praktycznie
> dwukrotnie rozciągnięty.

Tak, takie. Zrób sobie w QGISie siatkę kilometrową w PUWG 1992 i 
przekonwertuj do EPSG:4326. Się rozciągnie 2 razy.

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

W dniu 17.11.2010 23:57, Michal Baranski pisze:
> Witam
> Korzystałem z biblioteki proj4, która była dostępna na początku roku i
> musiałem sobie dopisać +towgs84=,,,.
> Czy tam też są zrobione poprawki w definicjach ?

Pliki epsg itd. do PROJ.4 robione są zwykle za pomocą ostatniego 
stabilnego GDALa (sic). Więc dopiero epsg w PROJ.4, który wyjdzie po 
niedawnym GDAL 1.7.3, będzie te poprawki zawierał.

> Dobrze by było aby polskie układy w końcu dobrze przeliczałyby się.

Ostatni GDAL jest OK, GRASS też, w QGISie też powinno być w porządku, 
ale to zależy od GDALa, z którym jest budowany i używany. Z czym było 
dostarczone 1.5 pod Winde nie wiem, bo nie używam na co dzień. W każdym 
razie w nast. tygodniu ma wyjść 1.6, a ten na zdrowy rozum powinien 
używać już GDALa 1.7.3. A propos: ktoś na wszelki wypadek powinien 
przelecieć srs.db w SVN na branchu wydania [1] czy napewno wszystkie 
"nasze" EPSG mają dobre stringi w formacie PROJ.4, zanim 1.6 zostanie 
wydany. Jak coś jest źle to critical Trac ticket i zamieszanie na QGIS 
dev :). Albo prosto do rodaka Borysa Jurgiela, który ma zapis w SVN 
QGISa. A co do PROJ.4, to następny będzie OK. Póki co należy poprawki w 
jego pliku epsg robić ręcznie.

Najważniejszym kawałkiem jest więc GDAL. Deweloperzy GDALa dodali 
regression test dla "polskiego przypadku" [2], więc powinno byc 
stabilnie pod w tym względem w przyszłości. Ale pańskie oko konia 
tuczy/ufać dobrze - kotrolowac lepiej/co dwie pary oczu to nie jedna, 
więc należy czuwać.

[1] 
http://trac.osgeo.org/qgis/browser/branches/Release-1_6_0/resources/srs.db
[2] http://trac.osgeo.org/gdal/changeset/19719/

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

Maciej Sieczka pisze:

> Ciort znajet. Żeby odtworzyć twój problem musiałbym tak samo 
> skonfigurować instalację QGISa i GDALa. Mogę spróbować w weekend, skoro 
> juz zacząłem temat ;). Piszesz, że QGIS 1.2. Żadnych innych instalacji 
> GDAL, GRASS, PROJ.4 czy samego QGISa? A dlaczego nie nowszy QGIS?

Nie nie, QGIS jest nowy, 1.5.0.
1.2 to wersja wtyczki GDAL Tools do QGISa oparta na GDAL 1.6.3
Instalacja QGISa sieciowa, przez OsGeo4W. Zresztą nie musisz jakoś 
specjalnie odtwarzać konfiguracji, jak pisałem wcześniej nowe FWTools 
(2.4.7) produkuje pliki z takim samym błędem, gdzie starsza wersja (mam 
też 1.3.5) robi to poprawnie.

-- 
marcin

W dniu 20.11.2010 16:55, mt pisze:
> Maciej Sieczka pisze:
>
>> Ciort znajet. Żeby odtworzyć twój problem musiałbym tak samo
>> skonfigurować instalację QGISa i GDALa. Mogę spróbować w weekend,
>> skoro juz zacząłem temat ;). Piszesz, że QGIS 1.2. Żadnych innych
>> instalacji GDAL, GRASS, PROJ.4 czy samego QGISa? A dlaczego nie nowszy
>> QGIS?
>
> Nie nie, QGIS jest nowy, 1.5.0.
> 1.2 to wersja wtyczki GDAL Tools do QGISa oparta na GDAL 1.6.3
> Instalacja QGISa sieciowa, przez OsGeo4W. Zresztą nie musisz jakoś
> specjalnie odtwarzać konfiguracji, jak pisałem wcześniej nowe FWTools
> (2.4.7) produkuje pliki z takim samym błędem, gdzie starsza wersja (mam
> też 1.3.5) robi to poprawnie.

Zainstalowałem diś QGISa 1.6.0 z OSGeo4W (Express Isstall) i Raster > 
Zmień Odwzorowanie działa u mnie poprawnie dla U65/III>U92. GdalTools 
1.2.16 w QGIS 1.6.0 używają już GDAL 1.7.3. Proponuję upgrade. Podczas 
konwersji upewnij się, że podany jest poprawny "Źrodłowy układ 
współrzędnych".

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

Maciej Sieczka pisze:

> Zainstalowałem diś QGISa 1.6.0 z OSGeo4W (Express Isstall) i Raster > 
> Zmień Odwzorowanie działa u mnie poprawnie dla U65/III>U92. GdalTools 
> 1.2.16 w QGIS 1.6.0 używają już GDAL 1.7.3. Proponuję upgrade. Podczas 
> konwersji upewnij się, że podany jest poprawny "Źrodłowy układ 
> współrzędnych".

Dzięki wielkie, teraz jest OK. Ciekawe w sumie gdzie leżała przyczyna i 
ile softu poszło z wadliwym GDAL :)

-- 
pozdrawiam
marcin

W dniu 21.11.2010 16:17, mt pisze:
> Maciej Sieczka pisze:
>
>> Zainstalowałem diś QGISa 1.6.0 z OSGeo4W (Express Isstall) i Raster >
>> Zmień Odwzorowanie działa u mnie poprawnie dla U65/III>U92. GdalTools
>> 1.2.16 w QGIS 1.6.0 używają już GDAL 1.7.3. Proponuję upgrade. Podczas
>> konwersji upewnij się, że podany jest poprawny "Źrodłowy układ
>> współrzędnych".
>
> Dzięki wielkie, teraz jest OK. Ciekawe w sumie gdzie leżała przyczyna i
> ile softu poszło z wadliwym GDAL :)

Swoją drogą dziwne że GdalTools 1.2 + GDAL 1.6.3 liczą źle. Mi 
wychodziło, że tylko GDAL 1.7.1 i 1.7.2 powinny mieć ten problem - 
http://trac.osgeo.org/gdal/ticket/3579#comment:6. Do ponownego 
sprawdzenia dla chętnych :).

Maciek

-- 
Maciej Sieczka
http://www.sieczka.org

Maciej Sieczka pisze:
> W dniu 21.11.2010 16:17, mt pisze:
>> Maciej Sieczka pisze:
>>
>>> Zainstalowałem diś QGISa 1.6.0 z OSGeo4W (Express Isstall) i Raster >
>>> Zmień Odwzorowanie działa u mnie poprawnie dla U65/III>U92. GdalTools
>>> 1.2.16 w QGIS 1.6.0 używają już GDAL 1.7.3. Proponuję upgrade. Podczas
>>> konwersji upewnij się, że podany jest poprawny "Źrodłowy układ
>>> współrzędnych".
>>
>> Dzięki wielkie, teraz jest OK. Ciekawe w sumie gdzie leżała przyczyna i
>> ile softu poszło z wadliwym GDAL :)
> 
> Swoją drogą dziwne że GdalTools 1.2 + GDAL 1.6.3 liczą źle. Mi 
> wychodziło, że tylko GDAL 1.7.1 i 1.7.2 powinny mieć ten problem - 
> http://trac.osgeo.org/gdal/ticket/3579#comment:6. Do ponownego 
> sprawdzenia dla chętnych :).

A tak jeszcze swoją drogą, jak sprawdzić z jakiej wersji GDAL korzystają 
poszczególne wersje FWTools?

-- 
marcin