Skip to Content.
Sympa Menu

freegeocz - Re: [FreeGeoCZ] S-JTSK proj4 verzus OracleSpatial 10g

freegeocz AT fsv.cvut.cz

Předmět: Svobodná geoinformační infrastruktura

List archive

Re: [FreeGeoCZ] S-JTSK proj4 verzus OracleSpatial 10g


Chronological Podle vláken 
  • From: Filip Okáľ <filipokal AT slovplast.sk>
  • To: Jano Kianicka <kianicka123jano AT yahoo.com>
  • Cc: freegeocz AT fsv.cvut.cz
  • Subject: Re: [FreeGeoCZ] S-JTSK proj4 verzus OracleSpatial 10g
  • Date: Thu, 06 Sep 2007 01:43:39 +0200
  • List-archive: <http://mailman.fsv.cvut.cz/pipermail/freegeocz>
  • List-id: Svobodná geoinformační infrastruktura <freegeocz.fsv.cvut.cz>

Jano Kianicka wrote:
Ahojte,
Viem, ze hodne diskutovalo o chybnej definicii Krovakovej projekcie v kniznici proj4. Totiz testujem presnost noveho modulu v Oracle Spatial


sorry ze tak neskoro a nie odborne ale S-JTSK je
jednoducho trauma:

pre mna proj4 (Rel. 4.5.0, 22 Oct 2006)
az na drobnu chybicku v kode (Slovensko diskriminujuci
parameter czech) a nemoznost (nemal som cas preskumat,
takze sa mozem aj mylit) prace s osami pracuje celkom uspokojivo:


/* x and y are reverted! */
xy.y = ro * cos(eps) / a;
xy.x = ro * sin(eps) / a;

if( !pj_param(P->params, "tczechoslovak").i )
{
xy.y *= -1.0;
xy.x *= -1.0;
}

return (xy);

cat epsg | grep "<2065>"
<2065> +proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs <>
cat esri | grep -E "<2065>|<102065>|<102066>|<102067>"
<2065> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs no_defs <>
<102065> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m no_defs <>
<102066> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=-17.66666666666667 +units=m no_defs <>
<102067> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m no_defs <>


echo "12d48' 49d27'" | cs2cs +proj=latlong +datum=WGS84 +to +init=epsg:2065
-868830.71 -1096101.11
echo "12d48' 49d27'" | cs2cs +proj=latlong +datum=WGS84 +to +init=esri:2065
408091.93 -1149690.95
echo "12d48' 49d27'" | cs2cs +proj=latlong +datum=WGS84 +to +init=esri:102065
-868830.71 -1096101.11
echo "12d48' 49d27'" | cs2cs +proj=latlong +datum=WGS84 +to +init=esri:102066
408091.93 -1149690.95
echo "12d48' 49d27'" | cs2cs +proj=latlong +datum=WGS84 +to +init=esri:102067
-868830.71 -1096101.11
echo "12d48' 49d27'" | cs2cs +proj=latlong +datum=WGS84 +to +proj=krovak +czechoslovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m
868830.71 1096101.11
echo "868830.71 1096101.11" | cs2cs +proj=krovak +czechoslovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m +to +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m
-868830.71 -1096101.11
echo "-868830.71 -1096101.11" | cs2cs +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m +to +proj=krovak +czechoslovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m
868830.71 1096101.11

na transformaciu suradnic pomocou definicie cez EPSG kody. Ale, bohuzial Oracle je schopny transformovat len kod 2065 s nazvom "S-JTSK (Ferro) / Krovak". Ked vlozim testovacie suradnice z

Kedze EPSG:2065 nikdo nepouziva takze je to asi dost zbytocne. Dost
by ma inak zaujimalo co sa vtedy zaciatkom 90. rokov ked tu ArcViewy
vo velkom prevracali osi prehanalo po hlavach pracovnikom VUGTK Praha.

http://gis.zcu.cz/studium/ugi/referaty/05/GeometrickeTransformace/index.html (uplne na spodku)
Tak mi z WGS84 long/lat (EPSG 8307):15.0092, 50.16535 vyrobí S-JTSK suradnice:
-559482,31; 1056474.27 .. pricom spravne suradnice S-JTSK su s presnstou 3m:
700000, 1040000 ako je uvedene v clanku.
Skusal som vyrobit podobnu transformaciu pre proj4:
echo "15d00'33.11 50d09'55.27" | cs2cs +proj=latlong +ellps=bessel +pm=ferro +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:2065
Ale vysledky su uplne ine. Pricom som skusal aj jednoduchsiu

no u mna to dost dobre sedi (samozre za cudzi transf. kluc
ruky do ohna nedavam):

echo "15d00'33.11 50d09'55.27" | cs2cs +init=epsg:4326 +to +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +proj=krovak +czechoslovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m
699993.94 1039993.82


transformaciu WGS84 do UTM a tam sa vysledky Oracle, clanok sa zhoduju, teda plus minus 5m (EPSG 32633 zona 33).
Neviete mi poradit, co su vlastne 2065 suradnice v porovnani s klasickym S-JTSK (EPSG 4156)? Aky je ten posun, pripadne aka je definicia

keby som bol Hupky-Dupky tak by som povedal ze
klasicke S-JTSK je kvaziEPSG:102067 lebo sa najviac
pouziva (mimo katastra samozrejme) alebo to
dejure S-JTSK teda kvaziEPSG:102065 samozrejme
uzivatelia ESRI a mozno aj Intergrafu (teda
asi vacsina statnoakademickej byrokracie) by sa
divali na republiky nastojakazrkadlovo (ak uz
samozrejme tieto firmy neinventli nieco ako nastavenie
sur. osi pre lokalny sur. system mapoveho okna).
Kedze nie sme v rozpravke, dobra rada nad zlato
jablcka (ProjectedCRS /EPSG:2065/ ) by sa
nemali miesat s hrustickami (GeographicCRS /EPSG:4156/)
a statna byrokracia by mohla pohnut zadkom
a v sulade s ISO 19111 a ISO 19127 zadefinovat/zaregistrovat/garantovat
v EPSG to co sa tu pouziva.



transformacie WGS84 -> do S-JTSK Ferro, ak hore uvedena je nespravna?
A tiez, ako presne definovat transformaciu WGS84 -> UTM zona33 pre proj4?
(Nie som s proj4 az taky skuseny ..)
Pripadne ak viete o nejakej studii co porovnava presnost transformacii klasickych GIS software (proj4, ESRI, Integraph, pripadne ten Oracle Spatial) ci sa neda niekde zohnat.

Na co by uz komu taka studia bola, cisla su reprezentovane
ako double (vo vacsine pripadov IEEE 754), matematika je
popisana v kazdych skriptach mat. kartografie, jedinym problemom
by mohlo byt hlupe zaokruhlenie pripadne magicke
konstaty pri iterativnych metodach (napr. ako ta v
inverznej krovakovej projekcii) v pripade open source
sa mozete presvedcit na vlastne oci ci tam autor kodu
nespravil chybu. Cela ta studia by po kvantitativnej
stranke asi najskor skonstatovala ze vypocty v Oracle
Spatial a PROJ.4 sa odchyluju na 14 desatinnom mieste.
Aj by som to overil sam keby som mal zbytocnych 2000MB
na Oracle 10g.

Potrebujeme totiz ist na vyzsiu presnost transformacii .. radovo az na cm.

Nie som geodet ani neviem vymenovat geodeticke presnosti
(takze ma treba brat z rezervou) pri spomenutych prevodoch typu
WGS84_S-JTSK a pouzitych podobnostnych transformaciach (Bursa-Wolf,
Molodensky-Badekas) s globalnymi transf. klucmi (pocitane napr. z
identickych bodov z celeho uzemia Slovenska) je intuitivne
zrejme ze na cm asi mozete lokalne zabudnut.
Osobne keby mi slo o presnost tak by som vybral z modernych
referencnych systemov s jednoznacne definovanymi prevodnymi vztahmi
(ETRS, SKTRF) a zabudol na prezitky z doby kedy sa
kartograficka projekcia navrhovala tak ze sa do globusu zapichlo
kruzidlo ,-)

Dakujem pekne za akukolvek radu.
Jano

------------------------------------------------------------------------
Yahoo! oneSearch: Finally, mobile search that gives answers <http://us.rd.yahoo.com/evt=48252/*http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC>, not web links.


------------------------------------------------------------------------

_______________________________________________
FreeGeoCZ mailing list
FreeGeoCZ AT fsv.cvut.cz
http://mailman.fsv.cvut.cz/mailman/listinfo/freegeocz


--
() The ASCII Ribbon Campaign - against HTML Email,
/\ vCards, and proprietary formats.
-----
NO BANANA UNION!
NO SOFTWARE PATENTS!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Filip Okáľ
e-mail: filipokal AT slovplast.sk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




  • Re: [FreeGeoCZ] S-JTSK proj4 verzus OracleSpatial 10g, Filip Okáľ, 09/06/2007

Archivace běží na MHonArc 2.6.19+.

Top of Page