[Talk-cz] Nový S-JTSK grid, kdo pomůže?
Vlákno 13.5. - 29.5.2014, počet zpráv: 31
Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v GDAL
(Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
http://lists.maptools.org/pipermail/proj/2013-January/006539.html
Docela by nám to všem pomohlo v souvislosti s propojením s RÚIAN, protože
přiznejme si, sedmiprvková transformace není v pohraničí to pravé ořechové.
viz. http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
http://www.kma.zcu.cz/main.php?KMAfile=./STRUCTURE/05_ebooks/04_Zaverecne_prace/zav_prace.php&DRC=./STRUCTURE/05_ebooks/04_Zaverecne_prace/&DRL=CZ&DROF=0&osCislo=52920
Psal jsem si na to téma s p. Ježkem, zkoušel jsem kontaktovat p. Chlupa, ale
bez výsledku. Jsem na to ochotný dát volnou výpočetní kapacitu na postgisu
na Xeon E5 3.6 GHz s SSD.
MK
Zdravím,
tato problematika mi není úplně jasná, tak se třeba zeptám blbě - co je na tom
k počítání? IMO jde o to, tu databázi, co máte k dispozici, převést do
zdrojové formy pro nad2bin, pustit na to nad2bin a pak už jen upravit definici
+proj ... a od té doby to Postgis bude umět, ne? Netuším formát té zdrojové
formy ani nevím, jak vypadá ta databáze bodů. Je někde k dispozici k
nahlédnutí či sosnutí?
--
Petr
Dne Út 13. května 2014 21:56:26, Martin Kokes napsal(a):
zobrazit citaci
> Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v GDAL
> (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
> http://lists.maptools.org/pipermail/proj/2013-January/006539.html
> Docela by nám to všem pomohlo v souvislosti s propojením s RÚIAN, protože
> přiznejme si, sedmiprvková transformace není v pohraničí to pravé ořechové.
>
> viz. http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
> http://www.kma.zcu.cz/main.php?KMAfile=./STRUCTURE/05_ebooks/04_Zaverecne_pr
> ace/zav_prace.php&DRC=./STRUCTURE/05_ebooks/04_Zaverecne_prace/&DRL=CZ&DROF=
> 0&osCislo=52920
>
> Psal jsem si na to téma s p. Ježkem, zkoušel jsem kontaktovat p. Chlupa, ale
> bez výsledku. Jsem na to ochotný dát volnou výpočetní kapacitu na postgisu
> na Xeon E5 3.6 GHz s SSD.
>
> MK
>
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
Dobrá, tak jsem se mírně znemožnil ;-). Počítat potřebujeme ten vlastní grid.
Vstupem je databáze bodů a ta se bude interpolovat.
Kromě Postgisu tedy potřebujeme ještě R a PL/R, k tomu možná něco z CRANu.
Zacházet s R celkem zvládám, i když v jiné oblasti než jsou geo-úlohy. Zdá se
mi, že k pochopení, dostatečnému ke zprovoznění úlohy, mi chybí porozumění
všem parametrům funkce dataz_tps_raster.
Máme tam:
CREATE OR REPLACE FUNCTION dataz_tps_raster
(
tab character varying,
col character varying,
numx integer,
numy integer,
srid integer,
zoom numeric
)
RETURNS raster AS
$$
...
parametry:
tab - jméno tabulky s body
col - jméno sloupce, jakého?
numx - nevím - používá se jako parametr st_makeemptyraster
numy - nevím - dtto
srid - čeho SRID?
nemohu nalézt tyto funkce:
- dataz_create_vector
- dataz_return_value
struktura tabulky tab:
- the_geom - asi geometrie bodu, kterého? Křovákova nebo WGS84?
- 'col' - ???
Je to někomu jasnější?
--
Petr
Dne Út 13. května 2014 22:49:17, Petr Vejsada napsal(a):
zobrazit citaci
> Zdravím,
>
> tato problematika mi není úplně jasná, tak se třeba zeptám blbě - co je na
> tom k počítání? IMO jde o to, tu databázi, co máte k dispozici, převést do
> zdrojové formy pro nad2bin, pustit na to nad2bin a pak už jen upravit
> definici +proj ... a od té doby to Postgis bude umět, ne? Netuším formát té
> zdrojové formy ani nevím, jak vypadá ta databáze bodů. Je někde k dispozici
> k nahlédnutí či sosnutí?
>
> --
> Petr
>
> Dne Út 13. května 2014 21:56:26, Martin Kokes napsal(a):
> > Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> > ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v
> > GDAL (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
> > http://lists.maptools.org/pipermail/proj/2013-January/006539.html
> > Docela by nám to všem pomohlo v souvislosti s propojením s RÚIAN, protože
> > přiznejme si, sedmiprvková transformace není v pohraničí to pravé
> > ořechové.
> >
> > viz. http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
> > http://www.kma.zcu.cz/main.php?KMAfile=./STRUCTURE/05_ebooks/04_Zaverecne_
> > pr
> > ace/zav_prace.php&DRC=./STRUCTURE/05_ebooks/04_Zaverecne_prace/&DRL=CZ&DR
> > OF= 0&osCislo=52920
> >
> > Psal jsem si na to téma s p. Ježkem, zkoušel jsem kontaktovat p. Chlupa,
> > ale bez výsledku. Jsem na to ochotný dát volnou výpočetní kapacitu na
> > postgisu na Xeon E5 3.6 GHz s SSD.
> >
> > MK
> >
> >
> >
> > _______________________________________________
> > Talk-cz mailing list
> > Talk-cz na openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
Mně to přijde taky nekompletní, asi by to chtělo chtělo sehnat ten CD-ROM, o
kterém autor ve své práci píše, že je přílohou. :-) Proto jsem chtěl zkusit
tu cestu přes GDAL.
Udělal jsem bodove_pole.txt -
https://drive.google.com/file/d/0B5J67rBdf34NbVhtWTJHN1hiWUE/edit?usp=sharing
- souřadnice bodů TB, ZhB a CZEPOS v S-JTSK a WGS84
Chybu transformačního klíče lze vizualizovat tak, že se vezmou ty S-JTSK
souřadnice, natransformují se v PostGISu pomocí
+towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 do WGS84 jako jeden bod
úsečky a ty WGS84 souřadnice jako druhý konec úsečky.
Nebo si lze vyhrát s GRASSem:
http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK
MK
"Petr Vejsada" píše v diskusním příspěvku news:1703919.yriTVijfGK na mrnous...
Dobrá, tak jsem se mírně znemožnil ;-). Počítat potřebujeme ten vlastní
grid.
Vstupem je databáze bodů a ta se bude interpolovat.
Kromě Postgisu tedy potřebujeme ještě R a PL/R, k tomu možná něco z CRANu.
Zacházet s R celkem zvládám, i když v jiné oblasti než jsou geo-úlohy. Zdá
se
mi, že k pochopení, dostatečnému ke zprovoznění úlohy, mi chybí porozumění
všem parametrům funkce dataz_tps_raster.
Máme tam:
CREATE OR REPLACE FUNCTION dataz_tps_raster
(
tab character varying,
col character varying,
numx integer,
numy integer,
srid integer,
zoom numeric
)
RETURNS raster AS
$$
...
parametry:
tab - jméno tabulky s body
col - jméno sloupce, jakého?
numx - nevím - používá se jako parametr st_makeemptyraster
numy - nevím - dtto
srid - čeho SRID?
nemohu nalézt tyto funkce:
- dataz_create_vector
- dataz_return_value
struktura tabulky tab:
- the_geom - asi geometrie bodu, kterého? Křovákova nebo WGS84?
- 'col' - ???
Je to někomu jasnější?
--
Petr
Dne Út 13. května 2014 22:49:17, Petr Vejsada napsal(a):
zobrazit citaci
> Zdravím,
>
> tato problematika mi není úplně jasná, tak se třeba zeptám blbě - co je na
> tom k počítání? IMO jde o to, tu databázi, co máte k dispozici, převést do
> zdrojové formy pro nad2bin, pustit na to nad2bin a pak už jen upravit
> definici +proj ... a od té doby to Postgis bude umět, ne? Netuším formát
> té
> zdrojové formy ani nevím, jak vypadá ta databáze bodů. Je někde k
> dispozici
> k nahlédnutí či sosnutí?
>
> --
> Petr
>
> Dne Út 13. května 2014 21:56:26, Martin Kokes napsal(a):
> > Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> > ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v
> > GDAL (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
> > http://lists.maptools.org/pipermail/proj/2013-January/006539.html
> > Docela by nám to všem pomohlo v souvislosti s propojením s RÚIAN,
> > protože
> > přiznejme si, sedmiprvková transformace není v pohraničí to pravé
> > ořechové.
> >
> > viz. http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
> > http://www.kma.zcu.cz/main.php?KMAfile=./STRUCTURE/05_ebooks/04_Zaverecne_
> > pr
> > ace/zav_prace.php&DRC=./STRUCTURE/05_ebooks/04_Zaverecne_prace/&DRL=CZ&DR
> > OF= 0&osCislo=52920
> >
> > Psal jsem si na to téma s p. Ježkem, zkoušel jsem kontaktovat p. Chlupa,
> > ale bez výsledku. Jsem na to ochotný dát volnou výpočetní kapacitu na
> > postgisu na Xeon E5 3.6 GHz s SSD.
> >
> > MK
> >
> >
> >
> > _______________________________________________
> > Talk-cz mailing list
> > Talk-cz na openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
zobrazit citaci
> Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v GDAL
> (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
*** ten grid je už spočtený, jen je třeba ho převést do správného
formátu pro GDAL.
http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR.aspx
ha
hanoj
Mno, děkuji pěkně za důvěru. GDAL sice obsluhovat umím (nebo jsem si to do teď
myslel), ale pro tuhle oblast aplikace si tedy nejsem jistý ...
Na GDAL je po největší zvíře (i když tak nevypadá) Martin Landa - a kromě toho
ví, o čem mluvíš :-)
Honza Ježek pokud vím se v tom problému fakt vyzná, i když je spíš přes Javu
(což je detail), ale počítám, že teď má celkem plno rodinných a pracovních
povinností.
Můžete mi zkusit když tak po lopatě, jako někomu kdo sice držel Theo 20 v ruce a
chápe z rychlíku problém transformace mezi souř. systémy vysvětlit, co
potřebujete a proč nestačí standardní 7prvká transformace (alias +towgs84) a k
čemu je tenhle grid vlasně dobre do OSM?
Jestli by to bylo moc vysvětlování, tak se omlouvám, ..., holt jsem studoval
špatnou školu
dík
J
On Wed, May 14, 2014 at 09:32:15AM +0200, hanoj wrote:
zobrazit citaci
> > Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> > ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v GDAL
> > (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
> *** ten grid je už spočtený, jen je třeba ho převést do správného
> formátu pro GDAL.
> http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR.aspx
>
> ha
> hanoj
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
--
Jachym Cepicky
URL: http://geosense.cz
e-mail: jachym.cepicky at geosense cz
PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp
@jachymc
Velice stručně - dotransformace pomocí gridu se dělá kvůli tomu, že S-JTSK
není homogenní a má lokální deformace (dané už historicky od jeho vzniku).
Jednoznačný matematický vztah je mezi WSG84 a S-JTSK/05 a grid právě
vyjadřuje rozdíly mezi "hladkým" S-JTSK/05 a lokálně deformovaným S-JTSK.
Takže jeho použitím se zvýší přesnost transformace a lze používat globální
transformační klíč pro celou republiku s přesností, vyhovující katastru.
J. Veselý
---------- Původní zpráva ----------
Od: Jachym Cepicky <jachym.cepicky na geosense.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
Datum: 14. 5. 2014 10:56:12
Předmět: Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
"Mno, děkuji pěkně za důvěru. GDAL sice obsluhovat umím (nebo jsem si to do
teď
myslel), ale pro tuhle oblast aplikace si tedy nejsem jistý ...
Na GDAL je po největší zvíře (i když tak nevypadá) Martin Landa - a kromě
toho
ví, o čem mluvíš :-)
Honza Ježek pokud vím se v tom problému fakt vyzná, i když je spíš přes Javu
(což je detail), ale počítám, že teď má celkem plno rodinných a pracovních
povinností.
Můžete mi zkusit když tak po lopatě, jako někomu kdo sice držel Theo 20 v
ruce a
chápe z rychlíku problém transformace mezi souř. systémy vysvětlit, co
potřebujete a proč nestačí standardní 7prvká transformace (alias +towgs84) a
k
čemu je tenhle grid vlasně dobre do OSM?
Jestli by to bylo moc vysvětlování, tak se omlouvám, ..., holt jsem studoval
špatnou školu
dík
J
On Wed, May 14, 2014 at 09:32:15AM +0200, hanoj wrote:
zobrazit citaci
> > Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> > ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v
GDAL
zobrazit citaci
> > (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
> *** ten grid je už spočtený, jen je třeba ho převést do správného
> formátu pro GDAL.
> http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-
realizace-systemu-ETRS89-v-CR.aspx
zobrazit citaci
>
> ha
> hanoj
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
--
Jachym Cepicky
URL: http://geosense.cz
e-mail: jachym.cepicky at geosense cz
PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp
@jachymc
_______________________________________________
Talk-cz mailing list
Talk-cz na openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140514/8241679e/attachment.html>
Nebudu předstírat, že tomu rozumím. Jediné co vím je, že u nás v Beskydech
to způsobuje docela výrazný posun RUAN vs. KM. Půl metru je už docela dost.
Viz tato mapka: http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Chyba_p%C5%99i_
transformaci_z_WGS84_do_S-JTSK
Marián
---------- Původní zpráva ----------
Od: JV <j.v.2 na seznam.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
Datum: 14. 5. 2014 11:19:34
Předmět: Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
"
Velice stručně - dotransformace pomocí gridu se dělá kvůli tomu, že S-JTSK
není homogenní a má lokální deformace (dané už historicky od jeho vzniku).
Jednoznačný matematický vztah je mezi WSG84 a S-JTSK/05 a grid právě
vyjadřuje rozdíly mezi "hladkým" S-JTSK/05 a lokálně deformovaným S-JTSK.
Takže jeho použitím se zvýší přesnost transformace a lze používat globální
transformační klíč pro celou republiku s přesností, vyhovující katastru.
J. Veselý
---------- Původní zpráva ----------
Od: Jachym Cepicky <jachym.cepicky na geosense.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
Datum: 14. 5. 2014 10:56:12
Předmět: Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
"Mno, děkuji pěkně za důvěru. GDAL sice obsluhovat umím (nebo jsem si to do
teď
myslel), ale pro tuhle oblast aplikace si tedy nejsem jistý ...
Na GDAL je po největší zvíře (i když tak nevypadá) Martin Landa - a kromě
toho
ví, o čem mluvíš :-)
Honza Ježek pokud vím se v tom problému fakt vyzná, i když je spíš přes Javu
(což je detail), ale počítám, že teď má celkem plno rodinných a pracovních
povinností.
Můžete mi zkusit když tak po lopatě, jako někomu kdo sice držel Theo 20 v
ruce a
chápe z rychlíku problém transformace mezi souř. systémy vysvětlit, co
potřebujete a proč nestačí standardní 7prvká transformace (alias +towgs84) a
k
čemu je tenhle grid vlasně dobre do OSM?
Jestli by to bylo moc vysvětlování, tak se omlouvám, ..., holt jsem studoval
špatnou školu
dík
J
On Wed, May 14, 2014 at 09:32:15AM +0200, hanoj wrote:
zobrazit citaci
> > Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> > ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v
GDAL
zobrazit citaci
> > (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
> *** ten grid je už spočtený, jen je třeba ho převést do správného
> formátu pro GDAL.
> http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-
realizace-systemu-ETRS89-v-CR.aspx
zobrazit citaci
>
> ha
> hanoj
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
--
Jachym Cepicky
URL: http://geosense.cz
e-mail: jachym.cepicky at geosense cz
PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp
@jachymc
_______________________________________________
Talk-cz mailing list
Talk-cz na openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz"
"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140514/6785e8ad/attachment.html>
Jo,
to chápu. A co chceme od GDAL? Nažrat nějaký soubor z
www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR.aspx
? to není problém, jako co to chcete? GeoTIFF? Nebo do GRASSu? Nebo jako nějaký
vektor? A jaký soubor případně
J
On Wed, May 14, 2014 at 11:31:01AM +0200, Marián Kyral wrote:
zobrazit citaci
> Nebudu předstírat, že tomu rozumím. Jediné co vím je, že u nás v Beskydech
> to způsobuje docela výrazný posun RUAN vs. KM. Půl metru je už docela
> dost.
>
> Viz tato mapka:
> http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK
>
> Marián
>
> ---------- Původní zpráva ----------
> Od: JV <j.v.2 na seznam.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
> Datum: 14. 5. 2014 11:19:34
> Předmět: Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
>
> Velice stručně - dotransformace pomocí gridu se dělá kvůli tomu, že
> S-JTSK není homogenní a má lokální deformace (dané už historicky od jeho
> vzniku). Jednoznačný matematický vztah je mezi WSG84 a S-JTSK/05 a grid
> právě vyjadřuje rozdíly mezi "hladkým" S-JTSK/05 a lokálně deformovaným
> S-JTSK. Takže jeho použitím se zvýší přesnost transformace a lze
> používat globální transformační klíč pro celou republiku s přesností,
> vyhovující katastru.
>
> J. Veselý
>
> ---------- Původní zpráva ----------
> Od: Jachym Cepicky <jachym.cepicky na geosense.cz>
> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
> Datum: 14. 5. 2014 10:56:12
> Předmět: Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
>
> Mno, děkuji pěkně za důvěru. GDAL sice obsluhovat umím (nebo jsem si
> to do teď
> myslel), ale pro tuhle oblast aplikace si tedy nejsem jistý ...
>
> Na GDAL je po největší zvíře (i když tak nevypadá) Martin Landa - a
> kromě toho
> ví, o čem mluvíš :-)
>
> Honza Ježek pokud vím se v tom problému fakt vyzná, i když je spíš
> přes Javu
> (což je detail), ale počítám, že teď má celkem plno rodinných a
> pracovních
> povinností.
>
> Můžete mi zkusit když tak po lopatě, jako někomu kdo sice držel Theo
> 20 v ruce a
> chápe z rychlíku problém transformace mezi souř. systémy vysvětlit, co
> potřebujete a proč nestačí standardní 7prvká transformace (alias
> +towgs84) a k
> čemu je tenhle grid vlasně dobre do OSM?
>
> Jestli by to bylo moc vysvětlování, tak se omlouvám, ..., holt jsem
> studoval
> špatnou školu
>
> dík
>
> J
>
> On Wed, May 14, 2014 at 09:32:15AM +0200, hanoj wrote:
> > > Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v
> > > ETRS89(ETRF2000) <> S-JTSK, nechtěl by mi někdo, kdo se víc
> orientuje v GDAL
> > > (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2?
> > *** ten grid je už spočtený, jen je třeba ho převést do správného
> > formátu pro GDAL.
> >
> http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR.aspx
> >
> > ha
> > hanoj
> >
> > _______________________________________________
> > Talk-cz mailing list
> > Talk-cz na openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
>
> --
> Jachym Cepicky
> URL: http://geosense.cz
> e-mail: jachym.cepicky at geosense cz
> PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp
> @jachymc
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
zobrazit citaci
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
--
Jachym Cepicky
URL: http://les-ejk.cz
e-mail: jachym.cepicky at gmail com
PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp
@jachymc
Zdravim,
Dne 14. května 2014 10:55 Jachym Cepicky <jachym.cepicky na geosense.cz> napsal(a):
zobrazit citaci
> Na GDAL je po největší zvíře (i když tak nevypadá) Martin Landa - a kromě toho
> ví, o čem mluvíš :-)
no, nejake zarezy tam mam (VFK, VFR), ale tohle se tyka spise knihovny
Proj.4. Grid generoval v ramci DS Jan Jezek [1], jak psal Jachym.
Bohuzel ty linky ted nefunguji, zkusil jsem oslovit JJ, zda je nekde
jeste nenajde.
zobrazit citaci
> Honza Ježek pokud vím se v tom problému fakt vyzná, i když je spíš přes Javu
> (což je detail), ale počítám, že teď má celkem plno rodinných a pracovních
> povinností.
Az bude nejaky cas, tak se snad k tomu dostanu.
ML
[1] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Zdravím,
On Wed, May 14, 2014 at 12:06:40PM +0200, Martin Landa wrote:
zobrazit citaci
> no, nejake zarezy tam mam (VFK, VFR), ale tohle se tyka spise knihovny
> Proj.4. Grid generoval v ramci DS Jan Jezek [1], jak psal Jachym.
> Bohuzel ty linky ted nefunguji, zkusil jsem oslovit JJ, zda je nekde
> jeste nenajde.
ano, jde o vytvoření vstupního (zdrojového) souboru pro nad2bin. Pro začátek
by mohlo úplně stačit plné pochopení syntaxe a sémantiky toho vstupu. Já tomu
nerozumím. Je tu někdo, kdo tomu rozumí?
--
Petr
Martine, ty máš nějakou zkušenost s formátem pro nat2bin? Já našel jenom tohle
http://lists.maptools.org/pipermail/proj/2014-April/006834.html
A jaký je vlastně formát těch souborů v
www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR.aspx
Možná by to bylo zajímavé téma pro VUGTK?
J
On Thu, May 15, 2014 at 01:59:04PM +0200, Petr Vejsada wrote:
zobrazit citaci
> Zdravím,
>
> On Wed, May 14, 2014 at 12:06:40PM +0200, Martin Landa wrote:
>
> > no, nejake zarezy tam mam (VFK, VFR), ale tohle se tyka spise knihovny
> > Proj.4. Grid generoval v ramci DS Jan Jezek [1], jak psal Jachym.
> > Bohuzel ty linky ted nefunguji, zkusil jsem oslovit JJ, zda je nekde
> > jeste nenajde.
>
> ano, jde o vytvoření vstupního (zdrojového) souboru pro nad2bin. Pro začátek
> by mohlo úplně stačit plné pochopení syntaxe a sémantiky toho vstupu. Já tomu
> nerozumím. Je tu někdo, kdo tomu rozumí?
>
> --
> Petr
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
--
Jachym Cepicky
URL: http://les-ejk.cz
e-mail: jachym.cepicky at gmail com
PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp
@jachymc
Ahoj,
Dne 17. května 2014 14:06 Jachym Cepicky <jachym.cepicky na gmail.com> napsal(a):
zobrazit citaci
> Martine, ty máš nějakou zkušenost s formátem pro nat2bin? Já našel jenom tohle
Honza Jezek mi psal, ze ma studenta, ktery pracuje na novem gridu,
doufam, ze se dozvime vic na Geoinformatics [1]...
Martin
[1] http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2014
Ahoj,
na základě teorie i výpočtů konstatuji, že dříve dostupný grid
Ježek2008 (jehož kopie je opět na odkazu níže dostupná) je do doby
novějšího oficiálního řešení možno používat pro běžné potřeby OSM za
účelem zvýšení přesnosti transformace S-JTSK <-> WGS84.
více viz tento odstavec:
http://jdem.cz/ba4eu7
ha
hanoj
zobrazit citaci
> Honza Jezek mi psal, ze ma studenta, ktery pracuje na novem gridu,
> doufam, ze se dozvime vic na Geoinformatics ...
Ahoj,
díky. To je ten stejný grid, jako měl schovaný Xificurk, binárku. Ten jsme
přeci zkoušeli a dopadlo to špatně. Jevilo se to jakoby ten grid korigoval
obráceně, na opačnou stranu, ale ani tak to nesedělo. Bez něj to vypadá
přesněji vůči KM. Viz archiv konference.
Fajn je ten zdroják, zírám na ta čísla a vůbec nic mi neříkají :-)
Snad ta hlavička - počet sloupců, počet řádků, 1 netuším, pak je souřadnice,
kde grid začíná, pak je step a zase souřadnice a step.
Řádek by vlastně mohl být souřadnice a pak vždy dvojice čísel ten vlastní
posun? Co to může být za jednotky?
Dne Ne 18. května 2014 01:11:19, hanoj napsal(a):
zobrazit citaci
> Ahoj,
>
> na základě teorie i výpočtů konstatuji, že dříve dostupný grid
> Ježek2008 (jehož kopie je opět na odkazu níže dostupná) je do doby
> novějšího oficiálního řešení možno používat pro běžné potřeby OSM za
> účelem zvýšení přesnosti transformace S-JTSK <-> WGS84.
>
> více viz tento odstavec:
> http://jdem.cz/ba4eu7
>
> ha
> hanoj
>
> > Honza Jezek mi psal, ze ma studenta, ktery pracuje na novem gridu,
> > doufam, ze se dozvime vic na Geoinformatics ...
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
zobrazit citaci
> díky. To je ten stejný grid, jako měl schovaný Xificurk, binárku. Ten jsme
> přeci zkoušeli a dopadlo to špatně. Jevilo se to jakoby ten grid korigoval
> obráceně, na opačnou stranu, ale ani tak to nesedělo. Bez něj to vypadá
> přesněji vůči KM. Viz archiv konference.
*** Co jste věcně zkoušeli a jak to odpadlo jsem v archivu nevyčetl,
nebo nepochopil, PostGIS není moje parketa, ale:
bash:
wget http://gis.templ.net/grid_jezek2008/jezek_czech08.llb
sudo cp jezek_czech08.llb /usr/share/proj
postgres:
INSERT INTO spatial_ref_sys(srid, auth_name, auth_srid, srtext, proj4text)
VALUES (999, 'jezek', 999, 'NULL', '+proj=krovak +ellps=bessel
+nadgrids=jezek_czech08.llb');
#Dotaz probehl úspešne: bylo ovlivnený 1 rádek
SELECT ST_AsText(ST_Transform(ST_GeomFromText('POINT(-718583.33
-949224.46)',999),4326)) As wgs_geom;
#"POINT(14.5808761364013 50.9523314825017)"
což dává očekáváný výsledek
ha
hanoj
Dne 19. května 2014 16:26 hanoj <ehanoj na gmail.com> napsal(a):
zobrazit citaci
> wget http://gis.templ.net/grid_jezek2008/jezek_czech08.llb
> sudo cp jezek_czech08.llb /usr/share/proj
toto je jediny funkcni link s gridem pokud vim, poznamenal jsem to na wiki [1].
Martin
[1] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid#Transformace_S-JTSK_-_WGS84_.28ETRS.29_pomoc.C3.AD_gridu
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Ahoj,
stejný výsledek (až na poslední platnou číslici v délce - mě to dává na konci
5016 místo 5017) dostanu z té konfigurace, kterou jsme testovali.
Udělal jsem to znovu - http://ruian.poloha.net , vrstva je
http://tile.poloha.net/budovy-grid/.....
Je to úplně stejně špatně jako při prvním pokusu. Jakoby byl ten posun
otočený.
Nerozumím větě z odkazovaného webu:
"Problém se znaménky a případným přehozením os je věc samotného zobrazení
(+proj=krovak) a tedy stále zůstává. Pro souřadnice vztažené k osám ve směru
'sever východ' (záporné hodnoty) lze přidat parametr +czech a používat Proj.4
ve verzi větší než 4.5.0."
Proj mám 4.8, co že to udělá ten parametr +czech ? Přidat +czech do definice a
mělo by se to posunout žádoucím směrem? Tápu :-(
--
Petr
Dne Po 19. května 2014 16:26:00, hanoj napsal(a):
zobrazit citaci
> wget http://gis.templ.net/grid_jezek2008/jezek_czech08.llb
> sudo cp jezek_czech08.llb /usr/share/proj
>
>
> postgres:
>
> INSERT INTO spatial_ref_sys(srid, auth_name, auth_srid, srtext, proj4text)
> VALUES (999, 'jezek', 999, 'NULL', '+proj=krovak +ellps=bessel
> +nadgrids=jezek_czech08.llb');
> #Dotaz probehl úspešne: bylo ovlivnený 1 rádek
>
> SELECT ST_AsText(ST_Transform(ST_GeomFromText('POINT(-718583.33
> -949224.46)',999),4326)) As wgs_geom;
> #"POINT(14.5808761364013 50.9523314825017)"
>
> což dává očekáváný výsledek
--
Petr
zobrazit citaci
> stejný výsledek (až na poslední platnou číslici v délce - mě to dává na konci
> 5016 místo 5017) dostanu z té konfigurace, kterou jsme testovali.
*** ano to je v pořádku, to jsme daleko za číslicí přesnosti
transformace, max. 10 místo.
zobrazit citaci
> Udělal jsem to znovu - http://ruian.poloha.net , vrstva je
> http://tile.poloha.net/budovy-grid/.....
>
> Je to úplně stejně špatně jako při prvním pokusu. Jakoby byl ten posun
> otočený.
*** Já ti nerozumím, mluv čísly souřadnic a příkazovou řádkou, SQL
dotazy, ne obrázky dvou map s různou transformační chybou
Vezmeme si bod Jablunkov Navsi [1], kde má být chyba s globalnim
klicem az 0,7m [2]:
000937190090 ETRS-89: B=49 34 25.6508 L=18 47 38.2211 H(el.)=561.77
S-JTSK: Y=436231.78 X=1133608.56 H(Bpv)=519.20
nyni transformujme globalnim klicem[3]:
echo "-436231.78 -1133608.56" | cs2cs +init=esri:102067
+towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326
18d47'38.2"E 49d34'25.631"N 41.921
nyni transformujme gridem[4]:
echo "-436231.78 -1133608.56" | cs2cs +proj=krovak +ellps=bessel
+nadgrids=jezek_czech08.llb +to +proj=longlat +datum=WGS84
18d47'38.222"E 49d34'25.65"N 0.000
To znamena o 2 setiny lepsi vysledek s gridem pro oboje souradnice,
tj. cca 40 a 50 cm pro lat/lon posun na SV. A to zda se koresponduje s
i s tvym vysledkem na mape tj. posun na SV.
zobrazit citaci
> Nerozumím větě z odkazovaného webu:
>
> "Problém se znaménky a případným přehozením os je věc samotného zobrazení
> (+proj=krovak) a tedy stále zůstává. Pro souřadnice vztažené k osám ve směru
> 'sever východ' (záporné hodnoty) lze přidat parametr +czech a používat Proj.4
> ve verzi větší než 4.5.0."
*** celkem není třeba rozumnět, to se použije jen když lezou zcela
nesmysné výsledky v řádech 10^6 metru
zobrazit citaci
> Proj mám 4.8, co že to udělá ten parametr +czech ? Přidat +czech do definice a
> mělo by se to posunout žádoucím směrem? Tápu :-(
*** ne, nic nepřidávat, taky mám proj 4.8
ha
hanoj
[1] http://dataz.cuzk.cz/gu.php?1=37&2=19&3=009&4=a&stamp=3eZrAviURcutu2rKsp9slPcCYmOfccCL
[2] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK
[3] http://freegis.fsv.cvut.cz/gwiki/S-JTSK#S-JTSK_.E2.86.92_WGS84
[4] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid#Pr.C3.A1ce_s_gridem
Ahoj,
ještě se k tomu vracím.
Nejprve převeďme tvé výsledky na počítačovější formu. Jestli počítám správně,
tak tvé výsledky pro transformaci bez gridu jsou:
18.7939444444 49.5737863889
a pro transformaci s gridem
18.793978333333 49.5737916667
což je rozdíl:
select
import.distance_meters(st_setsrid(st_makepoint(18.7939444444,49.5737863889),4326),st_setsrid(st_makepoint(18.793978333333,49.5737916667),4326));
distance_meters
-----------------
2.520413388
(1 řádka)
to je trochu moc, ne? 2.5 metru?
A teď moje výsledky:
bez gridu:
select st_astext(st_transform(st_setsrid(st_makepoint(-436231.78,
-1133608.56),5514),4326));
st_astext
------------------------------------------
POINT(18.7939443539245 49.5737863847451)
(1 řádka)
s gridem:
select st_astext(st_transform(st_setsrid(st_makepoint(-436231.78,
-1133608.56),999),4326));
st_astext
------------------------------------------
POINT(18.7939504934423 49.5737917877839)
(1 řádka)
Rozdíl:
select
import.distance_meters(st_setsrid(st_makepoint(18.7939443539245,49.5737863847451),4326),st_setsrid(st_makepoint(18.7939504934423,49.5737917877839),4326));
distance_meters
-----------------
0.747197172
(1 řádka)
To už odpovídá deklarovaným 0.7m
Seknul jsem se při převodu těch tvých výsledků? Přepočítával jsem to 2x,
stupně+(minuty/60)+(vteřiny/3600)
Dejme tomu, že je posun při transformaci s gridem správným směrem a že je tedy
výsledek přesnější než bez gridu. Když si dáme v JOSM přes sebe průhlednou KM
a k tomu moje vrstvy budov, proč se tedy lépe kryjí růžové budovy (t.j. bez
gridu) než budovy modré (t.j. s gridem) ???Růžové se lépe kryjí i s tím, co je
v OSM. Znamená to, že máme vše v OSM špatně? A hlavně - co s tím dál?
Poznámka: funkce distance_meters vrací:
st_distance(st_transform(geom_a,4326)::geography,st_transform(geom_b,4326)::geography)
Dne Út 20. května 2014 10:23:32, hanoj napsal(a):
zobrazit citaci
> echo "-436231.78 -1133608.56" | cs2cs +init=esri:102067
> +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326
> 18d47'38.2"E 49d34'25.631"N 41.921
>
> nyni transformujme gridem[4]:
>
> echo "-436231.78 -1133608.56" | cs2cs +proj=krovak +ellps=bessel
> +nadgrids=jezek_czech08.llb +to +proj=longlat +datum=WGS84
> 18d47'38.222"E 49d34'25.65"N 0.000
---------- Původní zpráva ----------
Od: Petr Vejsada <osm na propsychology.cz>
Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org>
Datum: 28. 5. 2014 7:43:08
Předmět: Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
"
Dejme tomu, že je posun při transformaci s gridem správným směrem a že je
tedy
výsledek přesnější než bez gridu. Když si dáme v JOSM přes sebe průhlednou
KM
a k tomu moje vrstvy budov, proč se tedy lépe kryjí růžové budovy (t.j. bez
gridu) než budovy modré (t.j. s gridem) ???Růžové se lépe kryjí i s tím, co
je
v OSM. Znamená to, že máme vše v OSM špatně? A hlavně - co s tím dál?
"
No pokud to je v JOSM špatně, tak by to znamenalo, že to je špatně i ve
WMS vrstvě katastrálních map. Vrstvu RUIAN vždy zarovnávám dle KM.
Marián
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140528/f586167a/attachment.html>
Ohledně té chyby http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid, díval jsem
se na ten XLS a vzal bod s největší odchylkou
930102291
http://dataz.cuzk.cz/hledej.php?a=1 > podle čísla bodu > číslo TL = 3010,
číslo bodu = 229 tak vyjede zrušený bod, bohužel při "hromadnějším" exportu
do texťáku podle mapových listů je informace o zrušeném bodu ztracena, proto
v tom mém txt na Google Drive tato informace není.
MK
"Martin Landa" píše v diskusním příspěvku
news:CA+Ei1Ofzp2Bm_1MbKtQrgtZrfKp=DfWo2yXEVk1FVSfx6=aWKQ na mail.gmail.com...
Dne 19. května 2014 16:26 hanoj
<ehanoj na gmail.com> napsal(a):
zobrazit citaci
> wget http://gis.templ.net/grid_jezek2008/jezek_czech08.llb
> sudo cp jezek_czech08.llb /usr/share/proj
toto je jediny funkcni link s gridem pokud vim, poznamenal jsem to na wiki
[1].
Martin
[1]
http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid#Transformace_S-JTSK_-_WGS84_.28ETRS.29_pomoc.C3.AD_gridu
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Ozval se mi p. Ondřej Chlup, co nový grid počítá, můj poslední mail se mu
někde ztratil v korespondenci, konkrétně píše:
"V současné době ještě není výsledný grid k dispozici. Zatím jsem ve stavu,
že se podařilo vypočítat grid pro celou ČR, ale zatím bohužel vrací nepřesné
výsledky. Metoda popsaná v mé diplomové práci je funkční, ale problém
nastává u využití knihovny R pro práci s maticemi. Pro omezené území, na
kterém byla metoda testována v rámci DP běží výpočet bez problému. Pokud se
však výpočet provede pro body z celé ČR, tak jsem narazil na limit knihovny
R, jelikož není možné alokovat vektor větší než 3, nebo 4 GB. Proto jsem
musel přistoupit k rozdělení výpočtu na několik menších částí, které budou
následně spojeny v jeden grid. Jsem v kontaktu s panem Ježkem, kterého
informuji o aktuálních výsledcích. Jakmile tedy bude nový grid hotový, tak
budu pana Ježka informovat a následně bude dán k dispozici veřejnosti."
MK
"Martin Landa" píše v diskusním příspěvku
news:CA+Ei1OdYW5Cuyx2jjgzFTu4=03TxOB0JAwO2QMgGQ0G5q=jjEA na mail.gmail.com...
Ahoj,
Dne 17. května 2014 14:06 Jachym Cepicky
<jachym.cepicky na gmail.com> napsal(a):
zobrazit citaci
> Martine, ty máš nějakou zkušenost s formátem pro nat2bin? Já našel jenom
> tohle
Honza Jezek mi psal, ze ma studenta, ktery pracuje na novem gridu,
doufam, ze se dozvime vic na Geoinformatics [1]...
Martin
[1] http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2014
Dne 28. května 2014 15:54 Martin Kokes <shr3k na typo3-hosting.com> napsal(a):
zobrazit citaci
> Ozval se mi p. Ondřej Chlup, co nový grid počítá, můj poslední mail se mu
> někde ztratil v korespondenci, konkrétně píše:
>
> "V současné době ještě není výsledný grid k dispozici. Zatím jsem ve stavu,
> že se podařilo vypočítat grid pro celou ČR, ale zatím bohužel vrací nepřesné
> výsledky. Metoda popsaná v mé diplomové práci je funkční, ale problém
> nastává u využití knihovny R pro práci s maticemi. Pro omezené území, na
> kterém byla metoda testována v rámci DP běží výpočet bez problému. Pokud se
> však výpočet provede pro body z celé ČR, tak jsem narazil na limit knihovny
> R, jelikož není možné alokovat vektor větší než 3, nebo 4 GB. Proto jsem
> musel přistoupit k rozdělení výpočtu na několik menších částí, které budou
> následně spojeny v jeden grid. Jsem v kontaktu s panem Ježkem, kterého
> informuji o aktuálních výsledcích. Jakmile tedy bude nový grid hotový, tak
> budu pana Ježka informovat a následně bude dán k dispozici veřejnosti."
mozna nemistna otazka, ale proc proboha R-ko? Martin
Netuším to je spíš otázka na Ondřeje Chlupa - chtěl to asi prostě spočítat v
PGSQL v R :-). Proto jsem ostatně chtěl "urychlit" výsledek a prostě vzít
DATAZ body a jít nějakou jinou cestou (Jan Ježek-way) nebo způsob naznačený
v http://lists.maptools.org/pipermail/proj/2013-January/006539.html
Ale sám to nezvládnu, já jsem spíš IT allrounder, tohle je na mne už vyšší
GDAL dívčí.
MK
"Martin Landa" píše v diskusním příspěvku
news:CA+Ei1Of6gPBYytQFHR1Ux7BWAYiBvoAPS5H=WW22T4BRWO0xsA na mail.gmail.com...
Dne 28. května 2014 15:54 Martin Kokes
<shr3k na typo3-hosting.com> napsal(a):
zobrazit citaci
> Ozval se mi p. Ondřej Chlup, co nový grid počítá, můj poslední mail se mu
> někde ztratil v korespondenci, konkrétně píše:
>
> "V současné době ještě není výsledný grid k dispozici. Zatím jsem ve
> stavu,
> že se podařilo vypočítat grid pro celou ČR, ale zatím bohužel vrací
> nepřesné
> výsledky. Metoda popsaná v mé diplomové práci je funkční, ale problém
> nastává u využití knihovny R pro práci s maticemi. Pro omezené území, na
> kterém byla metoda testována v rámci DP běží výpočet bez problému. Pokud
> se
> však výpočet provede pro body z celé ČR, tak jsem narazil na limit
> knihovny
> R, jelikož není možné alokovat vektor větší než 3, nebo 4 GB. Proto jsem
> musel přistoupit k rozdělení výpočtu na několik menších částí, které budou
> následně spojeny v jeden grid. Jsem v kontaktu s panem Ježkem, kterého
> informuji o aktuálních výsledcích. Jakmile tedy bude nový grid hotový, tak
> budu pana Ježka informovat a následně bude dán k dispozici veřejnosti."
mozna nemistna otazka, ale proc proboha R-ko? Martin
Dne 28. května 2014 17:26 Martin Kokes <shr3k na typo3-hosting.com> napsal(a):
zobrazit citaci
> Netuším to je spíš otázka na Ondřeje Chlupa - chtěl to asi prostě spočítat v
> PGSQL v R :-). Proto jsem ostatně chtěl "urychlit" výsledek a prostě vzít
> DATAZ body a jít nějakou jinou cestou (Jan Ježek-way) nebo způsob naznačený
> v http://lists.maptools.org/pipermail/proj/2013-January/006539.html
>
> Ale sám to nezvládnu, já jsem spíš IT allrounder, tohle je na mne už vyšší
> GDAL dívčí.
tema na diskuzi na Geoinformatics [1] ? ;-)
Martin
[1] http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2014
Kdybych nebyl zrovna na dovolené, určitě bych přišel poznat české OSMaře a
ČÚZKy na vlastní oko... Tak třeba byste si o tom mohli nějak popovídat sami,
cílem by mělo být dosáhnout přesnosti
oficiální transformační služby
http://geoportal.cuzk.cz/Default.aspx?head_tab=sekce-01-gp&mode=TextMeta&text=wcts&menu=19
v prostředí PROJ4 a GDAL. Té IMHO ve vztahu k využitelnosti dat v OSM
dosahuje jen WFS ČÚZKu - služba INSPIRE (CP, případně AU, AD). Předpokládám
tedy, že tam Petr Souček má zabudovanou jejich oficiální transformaci, když
nabízí data i ve WGS84
http://services.cuzk.cz/wfs/inspire-cp-wfs.asp?service=WFS&request=GetCapabilities
...
MK
"Martin Landa" píše v diskusním příspěvku
news:CA+Ei1Od97aUWc_8B4+NyO2x+TyOrnqB8jM8qB9Qtxc_+MgnxAQ na mail.gmail.com...
Dne 28. května 2014 17:26 Martin Kokes
<shr3k na typo3-hosting.com> napsal(a):
zobrazit citaci
> Netuším to je spíš otázka na Ondřeje Chlupa - chtěl to asi prostě spočítat
> v
> PGSQL v R :-). Proto jsem ostatně chtěl "urychlit" výsledek a prostě vzít
> DATAZ body a jít nějakou jinou cestou (Jan Ježek-way) nebo způsob
> naznačený
> v http://lists.maptools.org/pipermail/proj/2013-January/006539.html
>
> Ale sám to nezvládnu, já jsem spíš IT allrounder, tohle je na mne už vyšší
> GDAL dívčí.
tema na diskuzi na Geoinformatics [1] ? ;-)
Martin
[1] http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2014
Zdravím všechny,
ano, mapové služby (jak na geoportal.cuzk.cz, tak na services.cuzk.cz - WMS
i WFS nebo GML) obsahují oficiálně schválené algoritmy pro transformaci
(http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/
Programy-pouzitelne-pro-data-ziskana-pomoci-GN-%281%29.aspx).
J. Veselý
---------- Původní zpráva ----------
Od: Martin Kokes <shr3k na typo3-hosting.com>
Komu: talk-cz na openstreetmap.org
Datum: 28. 5. 2014 18:04:45
Předmět: Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
"Kdybych nebyl zrovna na dovolené, určitě bych přišel poznat české OSMaře a
ČÚZKy na vlastní oko... Tak třeba byste si o tom mohli nějak popovídat sami,
cílem by mělo být dosáhnout přesnosti
oficiální transformační služby
http://geoportal.cuzk.cz/Default.aspx?head_tab=sekce-01-gp&mode=TextMeta&
text=wcts&menu=19
v prostředí PROJ4 a GDAL. Té IMHO ve vztahu k využitelnosti dat v OSM
dosahuje jen WFS ČÚZKu - služba INSPIRE (CP, případně AU, AD). Předpokládám
tedy, že tam Petr Souček má zabudovanou jejich oficiální transformaci, když
nabízí data i ve WGS84
http://services.cuzk.cz/wfs/inspire-cp-wfs.asp?service=WFS&request=
GetCapabilities
...
MK
"Martin Landa" píše v diskusním příspěvku
news:CA+Ei1Od97aUWc_8B4+NyO2x+TyOrnqB8jM8qB9Qtxc_+MgnxAQ na mail.gmail.com...
Dne 28. května 2014 17:26 Martin Kokes
<shr3k na typo3-hosting.com> napsal(a):
zobrazit citaci
> Netuším to je spíš otázka na Ondřeje Chlupa - chtěl to asi prostě spočítat
zobrazit citaci
> v
> PGSQL v R :-). Proto jsem ostatně chtěl "urychlit" výsledek a prostě vzít
> DATAZ body a jít nějakou jinou cestou (Jan Ježek-way) nebo způsob
> naznačený
> v http://lists.maptools.org/pipermail/proj/2013-January/006539.html
>
> Ale sám to nezvládnu, já jsem spíš IT allrounder, tohle je na mne už vyšší
> GDAL dívčí.
tema na diskuzi na Geoinformatics [1] ? ;-)
Martin
[1] http://geoinformatics.fsv.cvut.cz/gwiki/Geoinformatics_FCE_CTU_2014
_______________________________________________
Talk-cz mailing list
Talk-cz na openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140528/59d8c32f/attachment.html>
zobrazit citaci
> Nejprve převeďme tvé výsledky na počítačovější formu. Jestli počítám správně,
> tak tvé výsledky pro transformaci bez gridu jsou:
> ...
> 2.520413388
> to je trochu moc, ne? 2.5 metru?
*** myslím, že jsi opsal špatně jednu číslici jedné souřadnice
zobrazit citaci
> A teď moje výsledky:
> ....
> 0.747197172 metru
*** souhlas
http://pastebin.com/eZ7Km2Mx
zobrazit citaci
> Dejme tomu, že je posun při transformaci s gridem správným směrem a že je
> tedy výsledek přesnější než bez gridu. Když si dáme v JOSM přes sebe
> průhlednou KM
> a k tomu moje vrstvy budov, proč se tedy lépe kryjí růžové budovy (t.j. bez
> gridu) než budovy modré (t.j. s gridem) ???Růžové se lépe kryjí i s tím, co je
> v OSM. Znamená to, že máme vše v OSM špatně? A hlavně - co s tím dál?
*** Nejprve je treba vedet co je spravne a proc. Proto jsem vznesl
oficiální dotaz na CUZK ohledne transformaci.
ha
hanoj
zobrazit citaci
> ano, mapové služby (jak na geoportal.cuzk.cz, tak na services.cuzk.cz - WMS
> i WFS nebo GML) obsahují oficiálně schválené algoritmy pro transformaci
*** tak zda se, ze jadro pudla pri prevodu gridem[1] je v tom, ze
tento grid dela transf EPSG:5514 <-> EPSG:4258 (a pribuzne), kdezto my
v OSM pouzivame EPSG:4326 (a pribuzne) a chybi nam popsat vztah
EPSG:4258 a EPSG:4326 tj. ETRS89 a WGS84.
Muze CUZK tento transf postup ETRS89 <-> WGS84 (predpokladam ze je to
7 prvkovy klic) pro aktualni verzi ETRF2000 publikovat?
priklad viz:
http://pastebin.com/rDgjErEt
ha
hanoj
[1] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
zobrazit citaci
> obávám se že ČÚZK nemůže - ani jeden z těchto systémů nemá pod svou správou
> a schvalování algoritmů se týká pouze ETRS (možná bude někdo jiný vědět
> víc). Ale přítel Google mi hned jako první odkaz dal
> http://transformace.webst.fd.cvut.cz/Iframe/WGS_ETRS_iframe.htm ...
*** ze je 7/14 prvkova je asi pochopitelne, ale tech klicu jsem na
googlu nasel pro ruzne epochy a realizace desitky, např [1]. Takze by
mi velmi pomohlo ukazat prstem, kterou verzi pouziva CUZK.
nebo alespon popsat to slovne např.: ETRS89-ETRF2000 R8 epocha 2000.0
a WGS84-G1150 epocha 2000.0:
[1] http://www.defensie.nl/binaries/defence/documents/circulars/2013/08/23/transformation-parameters-between-itrs-wgs84-and-etrs89/trafoparsitrs_v2013en.xls
ha
hanoj« zpět na výpis měsíce