Nový S-JTSK grid, kdo pomůže? na Talk-cz

Martin Kokes shr3k na typo3-hosting.com #m17ccc3 13. 5. 2014 21:56

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

Petr Vejsada osm na propsychology.cz #m28ce4e 13. 5. 2014 22:49

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 Vejsada osm na propsychology.cz #m6942c9 14. 5. 2014 0:57

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ší?

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):

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

Martin Kokes shr3k na typo3-hosting.com #m1f498f 14. 5. 2014 9:02

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ší?

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):

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

hanoj ehanoj na gmail.com #m1ea862 14. 5. 2014 9:32

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

Jachym Cepicky jachym.cepicky na geosense.cz #m304319 14. 5. 2014 10:55

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

JV j.v.2 na seznam.cz #m86e30b 14. 5. 2014 11:18

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ý

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"

Marián Kyral mkyral na email.cz #m106117 14. 5. 2014 11:31

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

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" "

Jachym Cepicky jachym.cepicky na gmail.com #mcc2014 14. 5. 2014 11:42

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

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 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ý 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
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 _______________________________________________

-- Jachym Cepicky URL: http://les-ejk.cz e-mail: jachym.cepicky at gmail com PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp @jachymc

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:

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 _______________________________________________ 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

Martin Landa landa.martin na gmail.com #m11d1f7 14. 5. 2014 12:06

Zdravim,

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.

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

Petr Vejsada osm na propsychology.cz #mf045eb 15. 5. 2014 13:59

Zdravím,

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í?

Jachym Cepicky jachym.cepicky na gmail.com #m112668 17. 5. 2014 14:06

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

Zdravím,
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í?

-- Jachym Cepicky URL: http://les-ejk.cz e-mail: jachym.cepicky at gmail com PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp @jachymc

Martin Landa landa.martin na gmail.com #m7b37a3 17. 5. 2014 14:55

Ahoj,

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

hanoj ehanoj na gmail.com #m15d14b 18. 5. 2014 1:11

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

Petr Vejsada osm na propsychology.cz #m8effdb 18. 5. 2014 3:09

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?

hanoj ehanoj na gmail.com #m55c108 19. 5. 2014 16:26

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

Martin Landa landa.martin na gmail.com #m3c7aed 19. 5. 2014 17:01

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

Petr Vejsada osm na propsychology.cz #mc32066 19. 5. 2014 22:16

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 :-(

hanoj ehanoj na gmail.com #m89374f 20. 5. 2014 10:23

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.

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.

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

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

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.

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.

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

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

Petr Vejsada osm na propsychology.cz #mde7236 28. 5. 2014 7:16

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)

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):

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

Marián Kyral mkyral na email.cz #m51d1ef 28. 5. 2014 8:09

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

Martin Kokes shr3k na typo3-hosting.com #m1380f2 28. 5. 2014 15:49

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

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 Kokes shr3k na typo3-hosting.com #m42011f 28. 5. 2014 15:54

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

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

Martin Landa landa.martin na gmail.com #m6c0bb8 28. 5. 2014 15:58

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

Martin Kokes shr3k na typo3-hosting.com #m8038c0 28. 5. 2014 17:26

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

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

Martin Landa landa.martin na gmail.com #m502950 28. 5. 2014 17:30

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

Martin Kokes shr3k na typo3-hosting.com #mdc89ae 28. 5. 2014 18:02

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

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

JV j.v.2 na seznam.cz #md048ee 28. 5. 2014 19:44

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ý

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):

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 _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz"

hanoj ehanoj na gmail.com #m523249 29. 5. 2014 1:18

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

A teď moje výsledky: .... 0.747197172 metru

*** souhlas http://pastebin.com/eZ7Km2Mx

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

hanoj ehanoj na gmail.com #mb8f2a9 29. 5. 2014 1:25

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

hanoj ehanoj na gmail.com #m0b6377 29. 5. 2014 8:45

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