Re: [Talk-cz] pLPIS a WFS - jak na to?
Shodou okolností jsem bývalým zaměstnancem Sitewellu a na základech LPISu jsem také před 12 lety dělal a Sitewell si u mne dodnes outsourcuje nějaké služby. Není šance, že by to kdokoliv ze Sitewellu opravil, to spíš tlač na MZE. Sitewell byl jen subdodavatel pro Telefonicu a kvůli právním sporům ohledně provozovaných licencí byla veškerá aktiva týkající se této věci převedena na společnost Tescium viz zápis v OR. MK Jachym Cepicky píše v diskusním příspěvku news:20140529065701.GD23593@doctor... LPIS nenabízí data v EPSG:4326, pouze v křovákovi-gis a ještě se špatným EPSG kódem (102067 ale to je jedno). Je to na MapServeru, přihodit další souř. systémy je otázka konfigurace (doslova 1 řádek), ale z firmy která to pásla mi nikdo neodpověděl (sitewell). ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
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=a...@mail.gmail.com... Dne 19. května 2014 16:26 hanoj eha...@gmail.com napsal(a): 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
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=j...@mail.gmail.com... Ahoj, Dne 17. května 2014 14:06 Jachym Cepicky jachym.cepi...@gmail.com napsal(a): 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
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-gpmode=TextMetatext=wctsmenu=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=WFSrequest=GetCapabilities ... MK Martin Landa píše v diskusním příspěvku news:ca+ei1od97auwc_8b4+nyo2x+tyornqb8jm8qb9qtxc_+mgn...@mail.gmail.com... Dne 28. května 2014 17:26 Martin Kokes sh...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
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@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.phpDRC=./STRUCTURE/05_ebooks/04_Zaverecne_prace/DRL=CZDR OF= 0osCislo=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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Aktualizace RUIAN
Ty chyby jsou tam myslím od března, už jsem to hlásil na podp...@cuzk.cz. MK Petr Vejsada píše v diskusním příspěvku news:5233309.6ma79d05rp@mrnous... Dne Pá 2. května 2014 15:24:05, Petr Morávek [Xificurk] napsal(a): Na to stačí i libxml2: xmllint --format file.xml Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/ Jo, to je dobrý, dík. Tak s Prahou konečně dobojováno, vadný polygon u ZSJ 306045 Za Hornoměcholupskou a prázdný polygon u ZSJ 132021 - Horní Měcholupy-sever. Začnu rozesílat objednaná data na import adres. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Aktualizace RUIAN
Nojo, paní Landová z podpory bývá dost skoupá na vyjádření, většinou něco někam forwardne a děj se vůle boží. Pak možná forwardne zpátky nějakou odpověď. :-) Většinou pomůže oslovení někoho dalšího, který je více vstřícný, třeba tu vidím, že se zapojil Petr Souček. Můžete zkusit i Pavel Šidlichovský, který vede správu ZABAGEDu (a tím pádem asi i adresní místa). E-maily snadno odvodíte jmeno.prijmeni. MK Petr Vejsada píše v diskusním příspěvku news:2002810.zTFi1LYSpi@mrnous... Zdravím, Dne Út 13. května 2014 20:58:37, Martin Kokes napsal(a): Ty chyby jsou tam myslím od března, už jsem to hlásil na podp...@cuzk.cz. jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podp...@cuzk.cz tento mail: *** Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá ocásek v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy vf:x/vf:x. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření. -- Zdraví Petr Vejsada *** Odpověď žádná, polygon neopraven, ta vazba na obec opravena byla i bez mého upozornění. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-hr] Corinne Land Cover test import
Pozdrav iz Praga, napravio sam test import Corinne Land Cover u općini poluotoka Pelješca i otoka Mljeta. Što mislite o tome? Trebam li nastaviti od Konavle više Dubrovačko primorje do dolini Neretve? MK ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Corinne Land Cover test import
Hi, Pelješac Mljet were complete empty. Just zoom out to http://osm.org/go/xfEqFdj- and zoom in to http://osm.org/go/xfEqBTG and you'll see difference. Attribution comes mainly from http://wiki.openstreetmap.org/wiki/Corine_Land_Cover. MK ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
