RUIAN posun - konečné řešení?

42 zpráv
Zpět na přehled

RUIAN posun - konečné řešení?

42 zpráv MHUJPP 6 účastníků 35 min čtení
  1. Marián Kyral mkyral na email.cz #m06b680
    Ahoj, další vánoce před námi a stále nám chybí ta korekční matice či co to je. Asi žádný posun nenastal co? Co přesně potřebujeme? V jakém formátu a kolik bodů to má být? V souvislosti s tím, co psal Martin Janda mne napadlo, jestli by třeba nestačilo vzít pár míst, kde to ulítává nejvíc, tam ručně napasovat RUAIN a KM a zjistit posun, který pak nacpeme do nějaké tabulky, ze které se to pak bude korigovat? Mohlo by to takto nějak fungovat? Nemáme sice ten algoritmus, ale máme referenci, ke které se potřebujeme přiblížit. Marián
  2. Ha Noj ehanoj na gmail.com #m9d6ed4
    Cau 1) CUZK problem svych dat RUIAN mimo JTSK (rozdily WFS v ETRS89 vs WGS84) napul nevnima, napul neovlada a tak ho resit zda se nehodla. Mluvil jsem opet v lete p. Souckem. Zrejme jsme jedini, ktery RUIAN uzivaji mimo JTSK a vadi jim to. 2) Transformace gridem je znama: http://k154.fsv.cvut.cz/~seidl/ http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid 3) Co konkretne chceme s cim spasovat (uz jsem to asi zapomnel)? Chceme aby to bylo dobre (pak viz bod 2) nebo aby dve mapy k sobe sesedly? ha hanoj
  3. Marián Kyral mkyral na email.cz #m1c653f
    Ahoj,
  4. Ha Noj ehanoj na gmail.com #mf77c53
    Aktuálně je rozdíl RUIAN vs. KM. Takže jsem předpokládal, že stačí
    napasovat RUIAN na KM. Ale jestli je KM taky
    mimo, tak jsme v pr..li úplně. :-(
    *** tak pokud nám stačí, aby to sedělo na cuzk:km v epsg:4326 pak použijme WFS např. Bukovec č.p.109 okres FrýdekMístek: http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/12381535 http://services.cuzk.cz/wfs/inspire-bu-wfs.asp?service=WFS&srsName=urn:ogc:def:crs:EPSG::4326&VERSION=2.0.0&request=GetFeature&StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&Id=BU.12847628 ha hanoj
  5. Marián Kyral mkyral na email.cz #m00d567
    Aktuálně je rozdíl RUIAN vs. KM. Takže jsem předpokládal, že stačí
    napasovat RUIAN na KM. Ale jestli je KM taky
    mimo, tak jsme v pr..li úplně. :-(
    *** tak pokud nám stačí, aby to sedělo na cuzk:km v epsg:4326 pak použijme WFS např. Bukovec č.p.109 okres FrýdekMístek: http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/12381535 http://services.cuzk.cz/wfs/inspire-bu-wfs.asp?service=WFS&srsName=urn:ogc:def:crs:EPSG::4326&VERSION=2.0.0&request=GetFeature&StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&Id=BU.12847628 <http://services.cuzk.cz/wfs/inspire-bu-wfs.asp?service=WFS&srsName=urn:ogc:def:crs:EPSG::4326&VERSION=2.0.0&request=GetFeature&StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&Id=BU.12847628>
    Aha, a něco jednoduššího by nebylo :-D S tím co mi posílá Petr z poloha.net jsem spokojen, jen chci lepší geometrii. A to ideálně i pro ty generované TMS vrstvy s budovani a budovy-todo. Tady mám geometrii, ale zase nevidím další atributy. Asi tam někde budou, ale bude to chtít jiný dotaz. Teoreticky bych se u každé budovy mohl zeptat WFS a korigované souřadnice, ale je to zase další dotaz do sítě, další zdržení během trasování. Ale nešlo by to nějak použít pro vygenerování té matice? Máme dva zdroje, jeden je RUIAN databáze, druhá RUIAN WFS - stačí vybrat vhodné objekty, porovnat a vygenerovat odchylku? Pokud by byl přesný popis, co s tím, tak by to asi šlo automatizovat. Marián
  6. Jan Macura macurajan na gmail.com #mec1c5e
    Ahojte, může někdo srozumitelně formulovat problém? O jakém posunu čeho vůči čemu a v jakých řádech se tu bavíme? Díky H.
    Aktuálně je rozdíl RUIAN vs. KM. Takže jsem předpokládal, že stačí
    napasovat RUIAN na KM. Ale jestli je KM taky
    mimo, tak jsme v pr..li úplně. :-(
    *** tak pokud nám stačí, aby to sedělo na cuzk:km v epsg:4326 pak
    použijme WFS např. Bukovec č.p.109 okres FrýdekMístek:
    http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/12381535
    http://services.cuzk.cz/wfs/inspire-bu-wfs.asp?service=WFS&srsName=urn:ogc:def:crs:EPSG::4326&VERSION=2.0.0&request=GetFeature&StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&Id=BU.12847628
    Aha, a něco jednoduššího by nebylo :-D S tím co mi posílá Petr z poloha.net jsem spokojen, jen chci lepší
    geometrii. A to ideálně i pro ty generované TMS vrstvy s budovani a budovy-todo. Tady mám geometrii, ale zase nevidím další atributy. Asi tam někde budou, ale bude to chtít jiný dotaz.
    Teoreticky bych se u každé budovy mohl zeptat WFS a korigované
    souřadnice, ale je to zase další dotaz do sítě, další zdržení během trasování.
    Ale nešlo by to nějak použít pro vygenerování té matice? Máme dva zdroje,
    jeden je RUIAN databáze, druhá RUIAN WFS - stačí vybrat vhodné objekty, porovnat a vygenerovat odchylku? Pokud by byl přesný popis, co s tím, tak by to asi šlo automatizovat.
  7. Marián Kyral mkyral na email.cz #meb6aa5
    Ahoj, problém se dá dohledat v historii konference - třeba tady: http://markmail.org/message/4xdjsijmf7cchbag#query:+page:1+mid:i3afu4vvpa2gxwem+state:results (ale je toho více) Ve zkratce, při převodu křováka (souřadnicový systém užívaný v katastrálních mapách) na WGS84 (souřadnicový systém GPS) používá ČÚZK program, který přepočet nějakým algoritmem koriguje. Aktuální  algoritmus ovšem není známý. Takže když pak Petr stáhne data z RUIAN a přepočítá souřadnice do WGS84, přepočtená data na některých místech republiky nesedí vůči KM. Čím dále od centra, tím je to horší. Nejvzdálenější jsou Beskydy, takže tam je to nejhorší. Co si matně vzpomínám, bavíme se o odchylce pár cm až půl metru. Viz: http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Chyba_p%C5%99i_transformaci_z _WGS84_do_S-JTSK (tohle je sice opačný směr, ale problém je snad jasný ;-) ) Pro korekci tohoto posunu se dá použít korekční Grid ( http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid ), který ovšem po změně algoritmu nedává správná data, takže přepočet není správný. No a celé je to o tom, jak získat opravený Grid, aby objekty natrasované z RUIANu co nejvíce pasovaly na KM. Proběhly tady nějaké pokusy, byla na to diplomka, pan Souček z ČÚZK slíbil, že se přes vánoce na ten algoritmus mrkne a dá vědět, který přesně se používá, ale zatím vše selhalo. Takže se stále pro přepočet používá starý Grid, který však nedává přesné výsledky. Do Traceru jsem sice přidal možnost nastavit si posun - když člověk trasuje jen ve svém okolí, tak si to nastaví jednou a má vystaráno - ty odchylky v okolí jsou plus/mínus stejné. Ale pokud pak třeba jedu na druhý konec republiky a chci následně něco domapovat, musím pamatovat na to, že ta odchylka bude jiná. No a když na to zapomenu, tak to natrasuji posunuté, někdo další to pak přetrasuje a posune jinam a vznikají tak zbytečné změny v databázi. Tak takhle tomu rozumím já. Omlouvám se za nepřesnosti Marián
  8. Ha Noj ehanoj na gmail.com #m2d4ee0
    0 > Teoreticky bych se u každé budovy mohl zeptat WFS a korigované souřadnice, ale je to zase další dotaz do sítě, další zdržení během trasování. *** tak se zeptejme WFS předem hromadně přes BBOX či podobně.
    Pro korekci tohoto posunu se dá použít korekční Grid (
    http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid ), který ovšem po
    změně algoritmu nedává správná data, takže přepočet není správný.
    *** nic takového se neprokázalo. ;)
    No a celé je to o tom, jak získat opravený Grid, aby objekty natrasované
    z RUIANu co nejvíce pasovaly na KM.
    Proběhly tady nějaké pokusy, byla na to diplomka, pan Souček z ČÚZK
    slíbil, že se přes vánoce na ten algoritmus
    mrkne a dá vědět, který přesně se používá, ale zatím vše selhalo. Takže
    se stále pro přepočet používá starý Grid, který
    však nedává přesné výsledky.
    *** ještě bych možná dodal, že ČUZK používá 7prvkový klíč + dotransformaci(JTSK-JTSK05), kdežto grid jde na to přímo. ha hanoj
  9. Marián Kyral mkyral na email.cz #m3b1d77
    0 > Teoreticky bych se u každé budovy mohl zeptat WFS a korigované souřadnice, ale je to zase další dotaz do sítě, další zdržení během trasování. *** tak se zeptejme WFS předem hromadně přes BBOX či podobně.
    Tak jestli se budu někdy nudit, tak se na to možná kouknu.
    Pro korekci tohoto posunu se dá použít korekční Grid (
    http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid <http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid> ), který ovšem po
    změně algoritmu nedává správná data, takže přepočet není správný.
    *** nic takového se neprokázalo. ;)
    Fááákt? A proč mám sakra tady v Beskydech ty rozdíly :-D
    No a celé je to o tom, jak získat opravený Grid, aby objekty
    natrasované z RUIANu co nejvíce pasovaly na KM.
    Proběhly tady nějaké pokusy, byla na to diplomka, pan Souček z ČÚZK
    slíbil, že se přes vánoce na ten algoritmus
    mrkne a dá vědět, který přesně se používá, ale zatím vše selhalo.
    Takže se stále pro přepočet používá starý Grid, který
    však nedává přesné výsledky.
    *** ještě bych možná dodal, že ČUZK používá 7prvkový klíč + dotransformaci(JTSK-JTSK05), kdežto grid jde na to přímo.
    Já nemluvit jazyk tvého kmene. Marián
  10. Ha Noj ehanoj na gmail.com #m3c5705
    Pro korekci tohoto posunu se dá použít korekční Grid (
    http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid ), který ovšem > > po změně algoritmu nedává správná data, takže přepočet není správný.
    *** nic takového se neprokázalo. ;)
    Fááákt? A proč mám sakra tady v Beskydech ty rozdíly :-D
    *** ze dvou výsledků zpravidla nelze určit, který je blíže cíli ;) Na 28 bodů CZEPOS s obojími souřadnicemi lze naše metody elementárně otestovat: http://pastebin.com/eFidfVuQ 1) Výše v tomto vlákně zmíněný GRID od Seidl2014 dává tyto výsledky: xy<8cm z<3cm stdev_xy<2cm, stdev_z<1cm 2) Transformační služba CUZK dává tyto výsledky: http://geoportal.cuzk.cz/Default.aspx?head_tab=sekce-01-gp&mode=TextMeta&text=wcts&menu=19 xy<6cm z<4cm stdev_xy<2cm, stdev_z<1cm Tedy metody GRID jsou (a po celou doby byly) OK. mimochodem CUZK ve WFS RUIAN u každé geometrie píše: <bu-base:horizontalGeometryEstimatedAccuracy uom="m">1.5</bu-base:horizontalGeometryEstimatedAccuracy> ha hanoj
  11. Marián Kyral mkyral na email.cz #md88a19
    Pro korekci tohoto posunu se dá použít korekční Grid ( http://freegis.
    fsv.cvut.cz/gwiki/S-JTSK_/_Grid (http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid) ), který ovšem > > po změně algoritmu nedává správná data, takže přepočet není správný.
    *** nic takového se neprokázalo. ;)
    Fááákt? A proč mám sakra tady v Beskydech ty rozdíly :-D
    *** ze dvou výsledků zpravidla nelze určit, který je blíže cíli ;) Na 28 bodů CZEPOS s obojími souřadnicemi lze naše metody elementárně otestovat: http://pastebin.com/eFidfVuQ 1) Výše v tomto vlákně zmíněný GRID od Seidl2014 dává tyto výsledky: xy<8cm z<3cm stdev_xy<2cm, stdev_z<1cm 2) Transformační služba CUZK dává tyto výsledky: http://geoportal.cuzk.cz/Default.aspx?head_tab=sekce-01-gp&mode=TextMeta&text=wcts&menu=19 xy<6cm z<4cm stdev_xy<2cm, stdev_z<1cm Tedy metody GRID jsou (a po celou doby byly) OK. mimochodem CUZK ve WFS RUIAN u každé geometrie píše: <bu-base:horizontalGeometryEstimatedAccuracy uom="m">1.5</bu-base: horizontalGeometryEstimatedAccuracy> Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém vlastně není a všichni jsou happy. Radši budu mapovat. Marián ha hanoj
  12. Ha Noj ehanoj na gmail.com #m40b7ab
    Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
    vlastně není a všichni jsou happy. *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co nám vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;) ha hanoj
  13. Marián Kyral mkyral na email.cz #m7aa976
    Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
    vlastně není a všichni jsou happy. *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co nám vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
    No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový plugin a do toho momentálně nejdu. Už tak mám na seznamu plno věcí, které bych chtěl někdy udělat. Třeba pár vylepšení na osmap.cz. Marián
  14. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #m79202c
    2) Transformace gridem je znama: http://k154.fsv.cvut.cz/~seidl/ http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
    Ahoj, tohle je třeba pro mne nové info - přiznám se, že jsem to tu poslední dobou moc nesledoval, tak nevím jestli jsem zmínku o tomto gridu jen přehlédl, nebo sem opravdu doputovala až teď. Jsem si celkem jistý, že v databázi, ze které pouštím aktualizace administrativních hranic mám nějaký starší méně přesný grid... a vůbec bych se nedivil, kdyby to měl Petr na poloha.net taky tak. Každopádně díky za info, aspoň si mám s čím přes vánoce hrát :-) Zdraví, Petr Morávek aka Xificurk
  15. Ha Noj ehanoj na gmail.com #m3c70c9
    Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
    vlastně není a všichni jsou happy.
    *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co nám
    vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
    No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych
    nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový plugin a do toho momentálně nejdu. Už tak mám na seznamu plno věcí, které bych chtěl někdy udělat. Třeba pár vylepšení na osmap.cz. *** a nebo pro poloha.net/budovy napsat skript, který pro každou budovu vloží novou geometrii z WFS a není třeba nic měnit na tracer pluginu. ha hanoj
  16. Ha Noj ehanoj na gmail.com #m40621f
    Jsem si celkem jistý, že v databázi, ze které pouštím aktualizace administrativních hranic mám nějaký starší méně přesný grid... a vůbec bych se nedivil, kdyby to měl Petr na poloha.net taky tak.
    *** není žádný starší méně přesný a nový přesnější. Jsou dva gridy starý Ježek2008 XY a nový Seidl2014 XYZ, nic víc, o změně přesnosti nebyla řeč. ha hanoj
  17. Marián Kyral mkyral na email.cz #m7cd01e
    Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
    vlastně není a všichni jsou happy.
    *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co
    nám vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
    No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych
    nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový plugin a do toho momentálně nejdu. Už tak mám na seznamu plno věcí, které bych chtěl někdy udělat. Třeba pár vylepšení na osmap.cz <http://osmap.cz>.*** a nebo pro poloha.net/budovy <http://poloha.net/budovy> napsat skript, který pro každou budovu vloží novou geometrii z WFS a není třeba nic měnit na tracer pluginu.
    To by asi v ČÚZK nebyli moc rádi. Právě proto dávají k dispozici ty importy, aby se zbytečně nepřetěžovaly jejich servery. Marián
  18. Jan Macura macurajan na gmail.com #md7a815
    Ahoj, díky za nastínění problému. 2016-12-21 7:20 GMT+01:00 Marián Kyral <mkyral na email.cz>:
    Ve zkratce, při převodu křováka (souřadnicový systém užívaný v katastrálních mapách) na WGS84 (souřadnicový systém GPS) používá ČÚZK program, který přepočet nějakým algoritmem koriguje. Aktuální algoritmus ovšem není známý. Takže když pak Petr stáhne data z RUIAN a přepočítá souřadnice do WGS84, přepočtená data na některých místech republiky nesedí vůči KM. Čím dále od centra, tím je to horší. Nejvzdálenější jsou Beskydy, takže tam je to nejhorší. Co si matně vzpomínám, bavíme se o odchylce pár cm až půl metru. Viz: http://freegis.fsv.cvut.cz/gwi ki/S-JTSK_/_Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK (tohle je sice opačný směr, ale problém je snad jasný ;-) )
    Takže problém je, že vrstva vektorové KM opticky nesedí na vstvu budov RÚIAN? Zkusmo jsem si v JOSM otevřel Rožnov pod Radhoštěm, Uherský Brod, Valtice a Karvinou. Nikde jsem nenaměřil větší rozdíl, než 0,3 m. O tom se tady bavíme? O 30 cm? V momentě, kdy 40 % k.ú. má KMD se střední souřadnicovou chybou 1 m (což odpovídá dopustné odchylce až 2,8 m), a za předpokladu, že celá OSM vlastně vychází z GPS měření, který i v lepších navigačncíh přístrojích (vůbec nepočítaje GPS čipy v mobilech) má přesnost +-metrovou v otevřeném prostoru a +-metry až desítky metrů v zákrytech, případně vychází z družicových snímků s prostorovým rozlišením 0,7 m v tom lepším případě, 12 m v tom horším (a to nepočítaje chybu posunutí, která bývá u Bingu až několikametrová) mi přijde řešit 30 cm jako práce pro práci. 30 cm je v tomhle kontextu jako plivnout do moře. H.
  19. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #m4d52be
    Aktuálně je rozdíl RUIAN vs. KM. Takže jsem předpokládal, že stačí
    napasovat RUIAN na KM. Ale jestli je KM taky
    mimo, tak jsme v pr..li úplně. :-(
    *** tak pokud nám stačí, aby to sedělo na cuzk:km v epsg:4326 pak použijme WFS např. Bukovec č.p.109 okres FrýdekMístek: http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/12381535 http://services.cuzk.cz/wfs/inspire-bu-wfs.asp?service=WFS&srsName=urn:ogc:def:crs:EPSG::4326&VERSION=2.0.0&request=GetFeature&StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&Id=BU.12847628 <http://services.cuzk.cz/wfs/inspire-bu-wfs.asp?service=WFS&srsName=urn:ogc:def:crs:EPSG::4326&VERSION=2.0.0&request=GetFeature&StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&Id=BU.12847628> ha hanoj
    Ahoj, včera večer jsem si potvrdil, že mám u sebe grid Ježek2008 -sedí mi transfomace kontrolního bodu uváděného na wiki:
    SELECT ST_AsText(ST_Transform(ST_GeomFromText('POINT(-718583.33 -949224.46)',999),4326)) As wgs_geom; "POINT(14.5808761364013 50.9523314825017)"
    A tak jsem to rovnou testnul na odkazované budově (prostě jsem vzal první bod z geometrie budovy): ČUZK EPSG:5514: -432758.18 -1136758.78 ČUZK EPSG:4326: 49.547998 18.845223 ČUZK EPSG:4326 -> EPSG:5514 převedeno pomocí gridu: -432759.004430401 -1136759.53511646 Tzn. celkový posun je cca 112cm. Ono to není nijak tragické, ale už je to prostě poznat. Ale především je to o dva řády vyšší odchylka než tebou udávané centrimetry. Omlouvám se pokud přehlížím nějakou trivialitu, která je jasná každému prvákovi na geoinformatice... v tomhle jsem prostě amatér a do vnitřních složitostí tematiky různých projekcí vidím jen natolik, kolik bylo doteď potřeba pro práci s RUIAN v OSM. Takže se možná budu dál ptát trochu jako blbeček, ale... 1) Dělám něco špatně já? 2) Dělá něco špatně ČÚZK a jeho souřadnice v EPSG:4326 jsou chybné? 3) Skutečně je grid Ježek2008 přesný řádově na centimetry? 4) Jak je možné, že se transformace moje a ČÚZK rozchází v tomhle případě víc jak o metr? 5) Pokud je transformace ČUZK správná, jak ji můžu implementovat u sebe aniž bych se na každou souřadnici musel ptát WFS? Předem díky za jakékoliv info, Petr Morávek aka Xificurk
  20. Ha Noj ehanoj na gmail.com #md957b2
    1) Dělám něco špatně já?
    *** GRID je spočítán mezi ETRS89 a JTSK, takže by tam mělo být ještě něco mezi ETRS89 a WGS84. Ale nepotěším tě, neboť to dělá jen cca 30 cm. echo "18.845223 49.547998" | cs2cs +init=epsg:4326 +to +init=epsg:4258 +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f "%.6f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=./jezek08_jtskcz.llb -f "%.3f" -432758.771 -1136759.330 -0.009 *** Zkus výsledek GRID Ježek2008 srovnat s transformační službou CUZK. Výsledek bude téměř stejný: http://geoportal.cuzk.cz/Default.aspx?head_tab=sekce-01-gp&mode=TextMeta&text=wcts&menu=19
    2) Dělá něco špatně ČÚZK a jeho souřadnice v EPSG:4326 jsou chybné?
    *** CUZK říká, že ho přesnost RUIAN pod 1,5 m netrápí.
    3) Skutečně je grid Ježek2008 přesný řádově na centimetry?
    *** ano, ted ho tu testuji na 41 000 bodech. Chyba mezi ERTF2000 a JTSK je menší než 5cm je v 81,3 %, menší než 10cm v 99,4%. Ve zbylých 0,6% nelze rozhodnout zda jde o chybu v datech nebo lokální deformace základů JTSK.
    4) Jak je možné, že se transformace moje a ČÚZK rozchází v tomhle případě víc jak o metr?
    *** CUZK říká, že ho přesnost RUIAN pod 1,5 m netrápí.
    5) Pokud je transformace ČUZK správná, jak ji můžu implementovat u sebe aniž bych se na každou souřadnici musel ptát WFS?
    *** jakou transformaci CUZK používá se mi nepodařilo zjistit a já sám to z výsledků neumím odhadnout. ha hanoj
  21. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #m870a6e
    1) Dělám něco špatně já?
    *** GRID je spočítán mezi ETRS89 a JTSK, takže by tam mělo být ještě něco mezi ETRS89 a WGS84. Ale nepotěším tě, neboť to dělá jen cca 30 cm. echo "18.845223 49.547998" | cs2cs +init=epsg:4326 +to +init=epsg:4258 +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f "%.6f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=./jezek08_jtskcz.llb -f "%.3f" -432758.771 -1136759.330 -0.009
    Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84) pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl otevřít :-)) Zajímalo by mne odkud pochází tvoje transformační parametry towgs84? Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě zdrojů narážel na doporučení považovat oba systémy za "shodné". A když se podívám na definici v /usr/share/proj/epsg tak tam je:
    # ETRS89 <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs <>
    Snažil jsem se dál empiricky dopátrat, jaké transformace provádí ČÚZK. Jako dataset jsem použil adresní místa - pro každou obec (>6000) jsem náhodně vybral jedno adresní místo (to by snad mělo zajistit reprezentativní vzorek). Z WFS jsem pak stáhl souřadnice v EPSG:4258 a EPSG:4326, na ně vyzkoušel různé transformace a výsledek porovnával s původními souřadnicemi v EPSG:5514 z WFS. A mám pocit, že čím víc se v tom rýpu, tím větší zmatek v tom mám :/ 1) EPSG:4258 -> EPSG:5514 pomocí gridu, např. echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=czech -f "%.3f" -576504.892 -1168238.275 -0.000 Výsledná odchylka na souboru adresních bodů: 4 +/- 2 cm (max. 15 cm) HURÁ! Zdá se, že grid skutečně funguje skvěle a souhlasí s tím, co posílá ČÚZK. 2) EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace, např. echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f" -576504.701 -1168238.186 -44.382 Výsledná odchylka na souboru adresních bodů: 16 +/- 11 cm (max. 82 cm) Podle očekávání dává sedmiprvková transformace horší výsledky. 3) EPSG:4326 -> EPSG:5514 pomocí gridu, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514 +nadgrids=czech -f "%.3f" -576505.338 -1168238.341 0.000 Výsledná odchylka na souboru adresních bodů: 18 +/- 16 cm (max. 116 cm) Tohle je to, co používám teď na import administrativních hranic (AFAIK to samé je na poloha.net) a řeším, proč se ta čísla v některých případech rozcházejí o více jak metr. 4) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí gridu, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258 +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f "%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=czech -f "%.3f" -576505.114 -1168238.150 -0.009 Výsledná odchylka na souboru adresních bodů: 31 +/- 10 cm (max. 86 cm) Nápad s přidáním transformace WGS84<->ETRS89 sice stáhnul maximální chybu o těch 30 cm, na druhou stranu průměrná chyba šla nahoru, takže tohle asi taky nebude správná cesta (?) 5) EPSG:4326 -> EPSG:5514 pomocí sedmiprvkové transformace, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514 +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f" -576505.148 -1168238.251 -44.382 Výsledná odchylka na souboru adresních bodů: 14 +/- 7 cm (max. 36 cm) Tohle je další překvapení - tahle cesta nejlépe reprodukuje transformaci ČÚZK přestože víme, že rozhodně není nejpřesnější. 6) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258 +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f "%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f" -576504.923 -1168238.061 -44.391 Výsledná odchylka na souboru adresních bodů: 24 +/- 9 cm (max. 49 cm) Tohle už uvádím jen pro úplnost. Abych pravdu řekl, tak vůbec netuším, jaký z toho všeho udělat závěr. Vypadá to, že grid, co jsme používali doteď, stále "funguje" správně. A naopak jsou to data ČÚZK v EPSG:4326, kterým se nedá moc věřit. @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258. S pozdravem, Petr Morávek aka Xificurk
  22. Marián Kyral mkyral na email.cz #m304f73
    1) Dělám něco špatně já?
    *** GRID je spočítán mezi ETRS89 a JTSK, takže by tam mělo být ještě něco mezi ETRS89 a WGS84. Ale nepotěším tě, neboť to dělá jen cca 30 cm. echo "18.845223 49.547998" | cs2cs +init=epsg:4326 +to +init=epsg:4258 +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f "%.6f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=./jezek08_jtskcz.llb -f "%.3f" -432758.771 -1136759.330 -0.009
    Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84) pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl otevřít :-)) Zajímalo by mne odkud pochází tvoje transformační parametry towgs84? Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě zdrojů narážel na doporučení považovat oba systémy za "shodné". A když se podívám na definici v /usr/share/proj/epsg tak tam je:
    # ETRS89 <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs <>
    Snažil jsem se dál empiricky dopátrat, jaké transformace provádí ČÚZK. Jako dataset jsem použil adresní místa - pro každou obec (>6000) jsem náhodně vybral jedno adresní místo (to by snad mělo zajistit reprezentativní vzorek). Z WFS jsem pak stáhl souřadnice v EPSG:4258 a EPSG:4326, na ně vyzkoušel různé transformace a výsledek porovnával s původními souřadnicemi v EPSG:5514 z WFS. A mám pocit, že čím víc se v tom rýpu, tím větší zmatek v tom mám :/ 1) EPSG:4258 -> EPSG:5514 pomocí gridu, např. echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=czech -f "%.3f" -576504.892 -1168238.275 -0.000 Výsledná odchylka na souboru adresních bodů: 4 +/- 2 cm (max. 15 cm) HURÁ! Zdá se, že grid skutečně funguje skvěle a souhlasí s tím, co posílá ČÚZK. 2) EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace, např. echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f" -576504.701 -1168238.186 -44.382 Výsledná odchylka na souboru adresních bodů: 16 +/- 11 cm (max. 82 cm) Podle očekávání dává sedmiprvková transformace horší výsledky. 3) EPSG:4326 -> EPSG:5514 pomocí gridu, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514 +nadgrids=czech -f "%.3f" -576505.338 -1168238.341 0.000 Výsledná odchylka na souboru adresních bodů: 18 +/- 16 cm (max. 116 cm) Tohle je to, co používám teď na import administrativních hranic (AFAIK to samé je na poloha.net) a řeším, proč se ta čísla v některých případech rozcházejí o více jak metr. 4) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí gridu, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258 +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f "%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=czech -f "%.3f" -576505.114 -1168238.150 -0.009 Výsledná odchylka na souboru adresních bodů: 31 +/- 10 cm (max. 86 cm) Nápad s přidáním transformace WGS84<->ETRS89 sice stáhnul maximální chybu o těch 30 cm, na druhou stranu průměrná chyba šla nahoru, takže tohle asi taky nebude správná cesta (?) 5) EPSG:4326 -> EPSG:5514 pomocí sedmiprvkové transformace, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514 +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f" -576505.148 -1168238.251 -44.382 Výsledná odchylka na souboru adresních bodů: 14 +/- 7 cm (max. 36 cm) Tohle je další překvapení - tahle cesta nejlépe reprodukuje transformaci ČÚZK přestože víme, že rozhodně není nejpřesnější. 6) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace, např. echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258 +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f "%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f" -576504.923 -1168238.061 -44.391 Výsledná odchylka na souboru adresních bodů: 24 +/- 9 cm (max. 49 cm) Tohle už uvádím jen pro úplnost. Abych pravdu řekl, tak vůbec netuším, jaký z toho všeho udělat závěr. Vypadá to, že grid, co jsme používali doteď, stále "funguje" správně. A naopak jsou to data ČÚZK v EPSG:4326, kterým se nedá moc věřit. @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
    Snažím se to napasovat na KM. Konkrétně na tuhle definici: <map> <tag key='name' value='český CUZK: barevný'/> <tag key='type' value='wms'/> <tag key='url' value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/png&amp;VERSION=1.1.1&amp;SERVICE=WMS&amp;REQUEST=GetMap&amp;LAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_i&amp;STYLES=&amp;SRS={proj}&amp;WIDTH={width}&amp;HEIGHT={height}&amp;BBOX={bbox}&amp;TRANSPARENT=true'/> <tag key='pixel-per-eastnorth' value='9.045115508227324'/> <tag key='max-zoom' value='100'/> <tag key='projections' value=''/> </map> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí. Marián
  23. Marián Kyral mkyral na email.cz #m30180a
    @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
    Snažím se to napasovat na KM. Konkrétně na tuhle definici: <map> <tag key='name' value='český CUZK: barevný'/> <tag key='type' value='wms'/> <tag key='url' value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/png&amp;VERSION=1.1.1&amp;SERVICE=WMS&amp;REQUEST=GetMap&amp;LAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_i&amp;STYLES=&amp;SRS={proj}&amp;WIDTH={width}&amp;HEIGHT={height}&amp;BBOX={bbox}&amp;TRANSPARENT=true'/> <tag key='pixel-per-eastnorth' value='9.045115508227324'/> <tag key='max-zoom' value='100'/> <tag key='projections' value=''/> </map> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí. Marián
    Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného: To je OK, nebo to mám nějak změnit? Marián
  24. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #md5c977
    @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
    Snažím se to napasovat na KM. Konkrétně na tuhle definici: <map> <tag key='name' value='český CUZK: barevný'/> <tag key='type' value='wms'/> <tag key='url' value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/png&amp;VERSION=1.1.1&amp;SERVICE=WMS&amp;REQUEST=GetMap&amp;LAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_i&amp;STYLES=&amp;SRS={proj}&amp;WIDTH={width}&amp;HEIGHT={height}&amp;BBOX={bbox}&amp;TRANSPARENT=true'/> <tag key='pixel-per-eastnorth' value='9.045115508227324'/> <tag key='max-zoom' value='100'/> <tag key='projections' value=''/> </map> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí. Marián
    Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného: To je OK, nebo to mám nějak změnit? Marián
    Ahoj, pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v JOSM podívat na Jablunkov s vrstvami: - WMS přesně podle tvé definice - Český RUIAN budovy (TMS z poloha.net) A přišlo mi, že to na sebe pěkně pasuje. S pozdravem, Petr
  25. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #m0a497f
    @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
    Snažím se to napasovat na KM. Konkrétně na tuhle definici: <map> <tag key='name' value='český CUZK: barevný'/> <tag key='type' value='wms'/> <tag key='url' value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/png&amp;VERSION=1.1.1&amp;SERVICE=WMS&amp;REQUEST=GetMap&amp;LAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_i&amp;STYLES=&amp;SRS={proj}&amp;WIDTH={width}&amp;HEIGHT={height}&amp;BBOX={bbox}&amp;TRANSPARENT=true'/> <tag key='pixel-per-eastnorth' value='9.045115508227324'/> <tag key='max-zoom' value='100'/> <tag key='projections' value=''/> </map> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí. Marián
    Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného: To je OK, nebo to mám nějak změnit? Marián
    Ahoj, pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v JOSM podívat na Jablunkov s vrstvami: - WMS přesně podle tvé definice - Český RUIAN budovy (TMS z poloha.net) A přišlo mi, že to na sebe pěkně pasuje. S pozdravem, Petr
    Ale jak na to koukám, tak JOSM asi stejně neumí udělat reprojekci lokálně :/ Takže je nereálné stahovat EPSG:4258 dlaždice a do mercatora (EPSG:3857) to převádět až u sebe. Petr
  26. Ha Noj ehanoj na gmail.com #m9ef043
    Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84) pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl otevřít :-))
    *** Chystám na to téma článek na wiki, ale musím to konzultovat, taky to není pro mne zcela na první pochopitelné. Bude to možná až po vánocích.
    Zajímalo by mne odkud pochází tvoje transformační parametry towgs84? Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě zdrojů narážel na doporučení považovat oba systémy za "shodné".
    *** V obecné rovině jsou si dnes ETRS a WGS84 podobné na úrovni metrů. Jak jsem psal, v ČR jsou odlišnosti v řádech 30 cm.
    A když se podívám na definici v /usr/share/proj/epsg tak tam je:
    # ETRS89 <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs <>
    *** To může také říkat, že takový vztah není vůbec definován. ha hanoj
  27. Marián Kyral mkyral na email.cz #md64328
    @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
    Snažím se to napasovat na KM. Konkrétně na tuhle definici: <map> <tag key='name' value='český CUZK: barevný'/> <tag key='type' value='wms'/> <tag key='url' value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/png&amp;VERSION=1.1.1&amp;SERVICE=WMS&amp;REQUEST=GetMap&amp;LAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_i&amp;STYLES=&amp;SRS={proj}&amp;WIDTH={width}&amp;HEIGHT={height}&amp;BBOX={bbox}&amp;TRANSPARENT=true'/> <tag key='pixel-per-eastnorth' value='9.045115508227324'/> <tag key='max-zoom' value='100'/> <tag key='projections' value=''/> </map> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí. Marián
    Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného: To je OK, nebo to mám nějak změnit? Marián
    Ahoj, pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v JOSM podívat na Jablunkov s vrstvami: - WMS přesně podle tvé definice - Český RUIAN budovy (TMS z poloha.net) A přišlo mi, že to na sebe pěkně pasuje.
    Abych pravdu řekl, dle všech dostupných indícií vlastně nemám žádný problém. Pro ČÚZK je to metr a půl sem, metr a půl tam :-D A abych pravdu řekl, vůbec jsem nezaregistroval, že je dostupný nějaký nový grid, který se zřejmě už normálně používá. Já žil v domnění, že ještě stále potřebujeme ten algoritmus od ČÚZK, abychom jej mohli přepočítat. Já jen reagoval na email "[Talk-cz] Trasovani RUIAN - prosim poradne" od Martina Jandy, který mi připomněl, že jsou zase vánoce a možná by to chtělo dořešit ten grid. No a asi se to už mezitím nějak dořešilo :-D Marián
  28. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #m0baa63
    Abych pravdu řekl, dle všech dostupných indícií vlastně nemám žádný problém. Pro ČÚZK je to metr a půl sem, metr a půl tam :-D
    Jo, někde ale ten rozdíl asi vidět bude...
    A abych pravdu řekl, vůbec jsem nezaregistroval, že je dostupný nějaký nový grid, který se zřejmě už normálně používá. Já žil v domnění, že ještě stále potřebujeme ten algoritmus od ČÚZK, abychom jej mohli přepočítat.
    Žádný nový grid nepoužívám... jsem stále na starém Ježek08, viz co psal hanoj:
    *** není žádný starší méně přesný a nový přesnější. Jsou dva gridy starý Ježek2008 XY a nový Seidl2014 XYZ, nic víc, o změně přesnosti nebyla řeč.
    Taky jsem si doteď myslel, že potřebujem spočítat nový grid. Celé to vycházelo z toho, že když já vezmu zdrojové souřadnice v EPSG:5514 z RUIAN a pomocí gridu je převedu na latlon (EPSG:4326), tak dostanu jiná čísla (občas o víc jak metr) než jaká vrací ČÚZK ve svém WMS/WFS. A tenhle problém předpokládám nepřímo trápí i tebe. Jenže z mého testování na adresních bodech to spíš vypadá, že chyba při transformaci ze zdrojového EPSG:5514 nevzniká na naší straně, ale na straně ČÚZK. A tedy starý grid Ježek08 dává stále dobré výsledky. S pozdravem, Petr Morávek aka Xificurk
  29. Marián Kyral mkyral na email.cz #m6718c2
    Abych pravdu řekl, dle všech dostupných indícií vlastně nemám žádný problém. Pro ČÚZK je to metr a půl sem, metr a půl tam :-D
    Jo, někde ale ten rozdíl asi vidět bude...
    Asi jo, já si napasoval zdejší posun RUAN vrstev a Traceru dle svého okolí a moc to neřeším. Ale když občas chci něco domapovat v Praze, tak na to musím myslet, aktuální posun je 30cm. Ovšem to se tak moc často nestává. Prahu nechávám jiným ;-)
    A abych pravdu řekl, vůbec jsem nezaregistroval, že je dostupný nějaký nový grid, který se zřejmě už normálně používá. Já žil v domnění, že ještě stále potřebujeme ten algoritmus od ČÚZK, abychom jej mohli přepočítat.
    Žádný nový grid nepoužívám... jsem stále na starém Ježek08, viz co psal hanoj:
    *** není žádný starší méně přesný a nový přesnější. Jsou dva gridy starý Ježek2008 XY a nový Seidl2014 XYZ, nic víc, o změně přesnosti nebyla řeč.
    Taky jsem si doteď myslel, že potřebujem spočítat nový grid. Celé to vycházelo z toho, že když já vezmu zdrojové souřadnice v EPSG:5514 z RUIAN a pomocí gridu je převedu na latlon (EPSG:4326), tak dostanu jiná čísla (občas o víc jak metr) než jaká vrací ČÚZK ve svém WMS/WFS. A tenhle problém předpokládám nepřímo trápí i tebe. Jenže z mého testování na adresních bodech to spíš vypadá, že chyba při transformaci ze zdrojového EPSG:5514 nevzniká na naší straně, ale na straně ČÚZK. A tedy starý grid Ježek08 dává stále dobré výsledky.
    Tak to je zajímavá informace. S tím já ale moc nenadělám, já se ztratil už na začátku :-D Marián
  30. Marián Kyral mkyral na email.cz #m8f40ba
    Abych pravdu řekl, dle všech dostupných indícií vlastně nemám žádný problém. Pro ČÚZK je to metr a půl sem, metr a půl tam :-D
    Jo, někde ale ten rozdíl asi vidět bude...
    Asi jo, já si napasoval zdejší posun RUAN vrstev a Traceru dle svého okolí a moc to neřeším. Ale když občas chci něco domapovat v Praze, tak na to musím myslet, aktuální posun je 30cm. Ovšem to se tak moc často nestává. Prahu nechávám jiným ;-)
    Mimochodem: koukám teď na Bukovec (nejvýchodnější obec republiky), tam řádili @kwiecpav a @minimalis a budovy většinou sedí přesně na RUIAN (a jsou v tomto případě posunuty o 30cm vůči katastru). Ovšem některé budovy jsou posunuty až o 1,7m. Mají ref:ruian i ostatní tagy, evidentně tedy byly natrasovány, ale RUAN obrys dnes už sedí na katastr. Zřejmě tam došlo k nějaké korekci na straně ČÚZK. A bylo by dobré to tedy přetrasovat. Takhle hodně posunutých budov je tam více. Marián
  31. Jan Macura macurajan na gmail.com #m9f76f4
    Ahoj, 2016-12-27 8:44 GMT+01:00 Marián Kyral <mkyral na email.cz>:
    Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného: To je OK, nebo to mám nějak změnit?
    Co máš nastaveno v JOSM je v podstatě jedno. H.
  32. Jan Macura macurajan na gmail.com #m96249f
    Ahoj, 2016-12-29 9:02 GMT+01:00 Marián Kyral <mkyral na email.cz>:
    Mimochodem: koukám teď na Bukovec (nejvýchodnější obec republiky), tam řádili @kwiecpav a @minimalis a budovy většinou sedí přesně na RUIAN (a jsou v tomto případě posunuty o 30cm vůči katastru). Ovšem některé budovy jsou posunuty až o 1,7m. Mají ref:ruian i ostatní tagy, evidentně tedy byly natrasovány, ale RUAN obrys dnes už sedí na katastr. Zřejmě tam došlo k nějaké korekci na straně ČÚZK. A bylo by dobré to tedy přetrasovat. Takhle hodně posunutých budov je tam více.
    Ten Bukovec u Jablunkova musí být nějaký kiks. Digitalizace tam byla dokončena až letos <http://cuzk.cz/Dokument.aspx?AKCE=META:SESTAVA:MDR002_XSLT:WEBCUZK_ID:615994>(2016) v dubnu, takže v roce 2014 to @kwiecpav těžko mohl natrasovat z RÚIANu...Nechápu jak to mohlo vzniknout. P.S. Bukovec je vůbec veselý katastr. Dvě prolínající se budovy jsem ještě jinde neviděl.. :-) ? H.
  33. Pavel Kwiecien pavel.kwiecien na seznam.cz #md704bf
    Ahoj, použil jsem Účelovou katastrální mapu (ÚKM). Do RÚIAN je ÚKM přebírána jako orientační mapa parcel, z toho vyplývají nepřesnosti při importu. Zdraví Pavel Kwiecien
  34. Jan Macura macurajan na gmail.com #m8652dd
    Ahoj, 2016-12-30 20:31 GMT+01:00 Pavel Kwiecien <pavel.kwiecien na seznam.cz>:
    Do RÚIAN je ÚKM přebírána jako orientační mapa parcel, z toho vyplývají nepřesnosti při importu.
    To je pro mě novina. Zní mi to teda jako blbost.. ale budu ti věřit. Jak jsi teda algoritmicky postupoval? Použil jsi tracer RÚIAN, protože ty objekty tam jsou, nebo jsi použil TracerServer nad vrstvou ÚKM, kterou sis nahrál do JOSM? Nebo jinak? Každopádně do source by v tomhle případě nemělo přijít cuzk:ruian. I cuzk:km je hodně zavádějící, lepší by bylo prostě vyplnit ÚKM. S pozdravem H.
  35. Pavel Kwiecien pavel.kwiecien na seznam.cz #mca10b0
    Ahoj, ty data byla převzána z RÚIANu, proto tam patří cuzk:ruian, zpracoval jsem je vlastním skriptem. Zdraví Pavel Kwiecien
  36. Petr Vejsada osm na propsychology.cz #m798836
    Ahoj po čase :-) nejprve chci moc poděkovat všem podporovatelům, penízky se opravdu hodí. Díky moc. Na poloha.net proběhl před nějakou dobou dlouho slibovaný major upgrade a je zaktualizované vše, od OS přes post[gres|gis], mapnik etc., vlastně instalováno from scratch znovu, aby se vše pročistilo. Mapnik je tedy chytřejší a pokus se zdá, že je pomalejší, tak to zcela určitě je :(. To se vědělo už dříve. K tématu - pokusně jsem obnovil TMS vrstvu budovy-grid a zdá se, že s úplně stejným (blbým) výsledkem, jako byly pokusy před dvěma lety. Grid stažený z http://web.archive.org/web/20091003020944/http://git.zcu.cz/grid/czech.lla . Zavedl jsem švindl projekci se SRID 999, která zní: +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +nadgrids=cze ch +pm=greenwich +units=m +no_defs +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 Transformaci tabulky s budovami jsem provedl příkazem: update grid set hranice= (st_transform(st_setsrid(st_transform(hranice,5514),999),900913)); tedy - z 900913, ve které mám RUIAN uložen, transformace zpět na 5514 a odtud transformace zpět na 900913 přes grid. Výsledek na tile.poloha.net vrstva budovy-grid, zobrazitelné na http://ruian.poloha.net. Vrstva http://tile.poloha.net/budovy-grid/{z}/{x}/{y}.png Zkoušel jsem i do pokusného schematu čerstvě importovat Jablunkov, je to stejné, jako když udělám výše uvedenou transformaci, tedy blbě. Takže od počátku roku 2014, kdy jsme dělali tyto pokusy, jsme se nikam neposunuli :-) Jinak v novém postgisu/proj už je definice Křováka 5514, u ostatních Křováků toliko poznámka: --- EPSG 5515 : S-JTSK/05 / Modified Krovak --- -- (unable to translate) --- --- EPSG 5516 : S-JTSK/05 / Modified Krovak East North --- -- (unable to translate) --- Tak jestli někoho napadlo, proč se to pořád posunuje opačným směrem, než bychom čekali ... A PF 2017!
  37. Jan Macura macurajan na gmail.com #m3b2c9b
    Ahoj, 2017-01-01 13:16 GMT+01:00 Petr Vejsada <osm na propsychology.cz>:
    Grid stažený z http://web.archive.org/web/20091003020944/http://git.zcu.cz/grid/czech.lla . (...) s úplně stejným (blbým) výsledkem, jako byly pokusy před dvěma lety.
    Ha Noj ti sem nehodil odkaz, což se divím. Zkus to podle jeho návodu s GRIDem Seidl16 a třeba to ten váš 30 cm megaproblém vyřeší: http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid Honza Mac.
  38. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #m13e654
    Ahoj, mohl bys prosím poslat konkrétní příklad, kde je vidět posun, o kterém mluvíš? Mám pocit, že se v tomhle vlákně míchá více věcí dohromady - jeden o voze, druhý o koze ;) Ideálně nějaký obrázek s dvěma vrstvama a popisem, z jakého zdroje a jakými transformacemi vznikly. S pozdravem, Petr Morávek aka Xificurk
  39. Petr Vejsada osm na propsychology.cz #m9650f7
    Ahoj, příloha. KM, růžové jsou transformací z 5514 tak, jak je v postgisu, tedy 7 prvková transformace. Oranžové jsou přes grid, odkazovaný v mé zprávě. Pustím se teď do toho Seidlova díla.
  40. Petr Vejsada osm na propsychology.cz #m88a9e0
    Pustím se teď do toho Seidlova díla.
    Výsledek víceméně stejný, ale nemám dost nový proj, abych mohl dát +czech. Upgrade proj-> rekompilace geos,gdal, postgis etc., možná v noci. Petr
  41. =?UTF-8?Q?Petr_Mor=c3=a1vek_ =?UTF-8?Q?Petr_Mor=c3=a1vek_ #m9b9b27
    Ahoj, udělal jsem ještě pár testů na budovách v Bukovci a výsledky jsou v podstatě stejné jako jsem psal u těch adres, viz příloha. - tmavě zelená je transformace 5514 -> 4326 pomocí gridu, tj. tvoje oranžová vrstva - tmavě červená je transformace 5514 -> 4326 pomocí sedmiprvkové transformace, tj. tvoje tvoje růžová. - světle červená je to, co zobrazuje ČÚZK v námi používaných WMS podkladech... data získána dotazem na WFS v projekci 4326 - světle zelená získána dotazem na WFS v projekci 4258 Jak už jsi psal ty - je jasně vidět, že ta sedmiprvková transformace nesedí na podklady od ČUZK úplně přesně, ale rozhodně lépe než transformace pomocí gridu, ale... Ty dvě zelené čáry (transformace gridem a ČUZK v EPSG:4258) jsou prakticky identické. I když uvážíme, že EPSG:4236 != EPSG:4258, tak by ten rozdíl neměl být tak velký, jako na obrázku. Opravdu to vypadá, že ČUZK transformaci do EPSG:4236 dělá blbě a vzniká tam dodatečná chyba. Zdraví, Petr Morávek aka Xificurk
  42. Petr Vejsada osm na propsychology.cz #ma9321f
    Ahoj, mezitím jsem zjistil, že jsem kecal a že mám nejnovější proj ;-) Udělal jsem testy podle té stránky http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid a dostal jsem naprosto stejné výsledky, jaké se očekávají na oné stránce, a to jak v postgisu tak cs2cs.
    Opravdu to vypadá, že ČUZK transformaci do EPSG:4236 dělá blbě a vzniká tam dodatečná chyba.
    Jako že my to máme dobře a ČÚZK špatně? Oó B-)
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.