« zpět na výpis měsíce |

[Talk-cz] RUIAN posun - konečné řešení?

Vlákno 20.12.2016 - 9.1.2017, počet zpráv: 42


20.12.2016 10:34:20 (#1)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161220/85b6a18b/attachment.html>

20.12.2016 11:40:59 (#2)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
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 Dne 20. prosince 2016 10:34 Marián Kyral <mkyral na email.cz> napsal(a): zobrazit citaci
> 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. >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161220/249069a9/attachment.html>

20.12.2016 12:39:07 (#3)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Ahoj,
---------- Původní zpráva ---------- Od: Ha Noj <ehanoj na gmail.com> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org> Datum: 20. 12. 2016 11:42:22 Předmět: Re: [Talk-cz] RUIAN posun - konečné řešení? " 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. " Tak to je škoda :-( Kdyby alespoň publikovali informace, které potřebujeme. " 2) Transformace gridem je znama: http://k154.fsv.cvut.cz/~seidl/ (http://k154.fsv.cvut.cz/~seidl/) http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_ Grid(http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid) " Jo, ale nemáme ten grid ne? Bohužel se v tom fakt nevyznám. GIS, různé projekce a šílená matematika kolem toho jde úplně mimo mně. Koukal jsem na ten lla soubor. Vidím 130 řádků různých čísel. Co znamenají, to nevím a jak je upravit už vůbec netuším.   " 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? " 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ě. :-( Marián " ha hanoj Dne 20. prosince 2016 10:34 Marián Kyral <mkyral na email.cz (mailto:mkyral na email.cz)> napsal(a): " 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. " _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz " ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161220/4b7dd2e1/attachment.html>

20.12.2016 04:39:29 (#4)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
zobrazit citaci
> 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 zobrazit citaci
> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161220/02d02145/attachment.html>

20.12.2016 08:07:30 (#5)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 20.12.2016 v 16:39 Ha Noj napsal(a): zobrazit citaci
> > 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 zobrazit citaci
> ha > hanoj > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161220/a02d9125/attachment.html>

20.12.2016 11:54:05 (#6)
gravatar

Jan Macura

<macurajan at gmail.com>
755 2731
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. On Tuesday, 20 December 2016, Marián Kyral <mkyral na email.cz> wrote: zobrazit citaci
> Dne 20.12.2016 v 16:39 Ha Noj napsal(a): > >> 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 zobrazit citaci
>> 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: zobrazit citaci 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 zobrazit citaci
> > > 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. zobrazit citaci
> > 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í. zobrazit citaci
> > 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. zobrazit citaci
> > Marián > > ha > hanoj > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz > >
-- Sent from phone ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161220/af09832b/attachment.html>

21.12.2016 07:20:24 (#7)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
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
---------- Původní zpráva ---------- Od: Jan Macura <macurajan na gmail.com> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org> Datum: 20. 12. 2016 23:55:41 Předmět: Re: [Talk-cz] RUIAN posun - konečné řešení? "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. On Tuesday, 20 December 2016, Marián Kyral <mkyral na email.cz (mailto:mkyral na email.cz)> wrote: zobrazit citaci
> Dne 20.12.2016 v 16:39 Ha Noj napsal(a): > >> 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 zobrazit citaci
>> 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: zobrazit citaci (http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/12381535) zobrazit citaci 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) zobrazit citaci
> > > Aha, a něco jednoduššího by nebylo :-D > > S tím co mi posílá Petr z poloha.net(http://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. zobrazit citaci
> > 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í. zobrazit citaci
> > 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. zobrazit citaci
> > Marián > > ha > hanoj > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org(mailto:Talk-cz na openstreetmap.org) > https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz) zobrazit citaci
> >
-- Sent from phone _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz " ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161221/5145eb32/attachment.html>

21.12.2016 04:16:13 (#8)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
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ě. zobrazit citaci
> Pro korekci tohoto posunu se dá použít korekční Grid (
http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid ), který ovšem po zobrazit citaci
> změně algoritmu nedává správná data, takže přepočet není správný.
*** nic takového se neprokázalo. ;) zobrazit citaci
> No a celé je to o tom, jak získat opravený Grid, aby objekty natrasované
z RUIANu co nejvíce pasovaly na KM. zobrazit citaci
> 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 zobrazit citaci
> 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ý zobrazit citaci
> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161221/d3d214fa/attachment.html>

21.12.2016 06:38:39 (#9)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 21.12.2016 v 16:16 Ha Noj napsal(a): zobrazit citaci
> 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. zobrazit citaci
> > 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 zobrazit citaci
> > 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 zobrazit citaci
> ha > hanoj > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161221/daab6e73/attachment.html>

21.12.2016 09:10:17 (#10)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
zobrazit citaci
> > > 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ý. zobrazit citaci
> > *** 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161221/be86f557/attachment.html>

22.12.2016 06:59:05 (#11)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
---------- Původní zpráva ---------- Od: Ha Noj <ehanoj na gmail.com> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org> Datum: 21. 12. 2016 21:11:44 Předmět: Re: [Talk-cz] RUIAN posun - konečné řešení? " zobrazit citaci
> > > 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ý. zobrazit citaci
> > *** 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(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 (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 _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz " ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161222/bd90b583/attachment.html>

22.12.2016 01:32:37 (#12)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
zobrazit citaci
> Ž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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161222/46830271/attachment.html>

22.12.2016 05:02:14 (#13)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 22.12.2016 v 13:32 Ha Noj napsal(a): zobrazit citaci
> > Ž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 zobrazit citaci
> ha > hanoj >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161222/7ff31931/attachment.html>

22.12.2016 07:35:41 (#14)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
Dne 20.12.2016 v 11:40 Ha Noj napsal(a): zobrazit citaci 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

22.12.2016 08:51:16 (#15)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
zobrazit citaci
> > Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
vlastně není a všichni jsou happy. zobrazit citaci
> *** 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ě." ;) zobrazit citaci
> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161222/4372d75d/attachment.html>

22.12.2016 08:54:57 (#16)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
zobrazit citaci
> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161222/6744a432/attachment.html>

22.12.2016 09:51:20 (#17)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 22.12.2016 v 20:51 Ha Noj napsal(a): zobrazit citaci
> > > Ž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 zobrazit citaci
> ha > hanoj > > > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161222/7f4aed17/attachment.html>

22.12.2016 10:40:39 (#18)
gravatar

Jan Macura

<macurajan at gmail.com>
755 2731
Ahoj, díky za nastínění problému. 2016-12-21 7:20 GMT+01:00 Marián Kyral <mkyral na email.cz>: zobrazit citaci
> 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161222/81478e3e/attachment.html>

23.12.2016 10:42:00 (#19)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
Dne 20.12.2016 v 16:39 Ha Noj napsal(a): zobrazit citaci
>> 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: zobrazit citaci
> 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

24.12.2016 12:04:27 (#20)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
zobrazit citaci
> 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 zobrazit citaci
> 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í. zobrazit citaci
> 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. zobrazit citaci
> 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í. zobrazit citaci
> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161224/238e3b1d/attachment.html>

26.12.2016 11:55:10 (#21)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
Dne 24.12.2016 v 00:04 Ha Noj napsal(a): zobrazit citaci
>> 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: zobrazit citaci
> # 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

27.12.2016 08:29:08 (#22)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> Dne 24.12.2016 v 00:04 Ha Noj napsal(a): >>> 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 zobrazit citaci
> S pozdravem, > Petr Morávek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

27.12.2016 08:44:40 (#23)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 27.12.2016 v 08:29 Marián Kyral napsal(a): zobrazit citaci
> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a): >> @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 zobrazit citaci
>> S pozdravem, >> Petr Morávek aka Xificurk >> >> _______________________________________________ >> 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
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161227/2b3a7b57/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: jdjgaemajhmajemc.png Type: image/png Size: 11900 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161227/2b3a7b57/attachment.png>

27.12.2016 11:40:55 (#24)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
Dne 27.12.2016 v 08:44 Marián Kyral napsal(a): zobrazit citaci
> Dne 27.12.2016 v 08:29 Marián Kyral napsal(a): >> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a): >>> @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

27.12.2016 12:55:29 (#25)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
Dne 27.12.2016 v 11:40 Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> Dne 27.12.2016 v 08:44 Marián Kyral napsal(a): >> Dne 27.12.2016 v 08:29 Marián Kyral napsal(a): >>> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a): >>>> @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

27.12.2016 01:30:21 (#26)
gravatar

Ha Noj

<ehanoj at gmail.com>
718
zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161227/de63fc24/attachment.html>

27.12.2016 02:32:53 (#27)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 27.12.2016 v 11:40 Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> Dne 27.12.2016 v 08:44 Marián Kyral napsal(a): >> Dne 27.12.2016 v 08:29 Marián Kyral napsal(a): >>> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a): >>>> @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 zobrazit citaci
> > S pozdravem, > Petr > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

28.12.2016 09:27:07 (#28)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
Dne 27.12.2016 v 14:32 Marián Kyral napsal(a): zobrazit citaci
> 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... zobrazit citaci
> 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: zobrazit citaci
> *** 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.12.2016 08:47:42 (#29)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 28.12.2016 v 09:27 Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> Dne 27.12.2016 v 14:32 Marián Kyral napsal(a): >> 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 ;-) zobrazit citaci
>> 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 zobrazit citaci
> S pozdravem, > Petr Morávek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

29.12.2016 09:02:37 (#30)
gravatar

Marián Kyral

<mkyral at email.cz>
2501 2837
Dne 29.12.2016 v 08:47 Marián Kyral napsal(a): zobrazit citaci
> Dne 28.12.2016 v 09:27 Petr Morávek [Xificurk] napsal(a): >> Dne 27.12.2016 v 14:32 Marián Kyral napsal(a): >>> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161229/a24210c7/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: pakiifkdmohpeobc.png Type: image/png Size: 21842 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161229/a24210c7/attachment.png>

30.12.2016 06:27:25 (#31)
gravatar

Jan Macura

<macurajan at gmail.com>
755 2731
Ahoj, 2016-12-27 8:44 GMT+01:00 Marián Kyral <mkyral na email.cz>: zobrazit citaci
> 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161230/7db19c43/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: jdjgaemajhmajemc.png Type: image/png Size: 11900 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161230/7db19c43/attachment.png>

30.12.2016 06:31:16 (#32)
gravatar

Jan Macura

<macurajan at gmail.com>
755 2731
Ahoj, 2016-12-29 9:02 GMT+01:00 Marián Kyral <mkyral na email.cz>: zobrazit citaci
> > 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161230/610d4a7d/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: ruian-budova_v_budove.png Type: image/png Size: 5770 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161230/610d4a7d/attachment.png>

30.12.2016 08:31:18 (#33)
gravatar

Pavel Kwiecien

<pavel.kwiecien at seznam.cz>
48 5000
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
---------- Původní zpráva ---------- Od: Jan Macura <macurajan na gmail.com> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org> Datum: 30. 12. 2016 18:32:31 Předmět: Re: [Talk-cz] RUIAN posun - konečné řešení? " Ahoj, 2016-12-29 9:02 GMT+01:00 Marián Kyral <mkyral na email.cz (mailto: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. _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz " ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161230/476301ca/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: ruian-budova_v_budove.png Type: image/png Size: 5770 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161230/476301ca/attachment.png>

30.12.2016 09:48:04 (#34)
gravatar

Jan Macura

<macurajan at gmail.com>
755 2731
Ahoj, 2016-12-30 20:31 GMT+01:00 Pavel Kwiecien <pavel.kwiecien na seznam.cz>: zobrazit citaci
> 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161230/387d18d2/attachment.html>

31.12.2016 09:12:10 (#35)
gravatar

Pavel Kwiecien

<pavel.kwiecien at seznam.cz>
48 5000
Ahoj, ty data byla převzána z RÚIANu, proto tam patří cuzk:ruian, zpracoval jsem je vlastním skriptem. Zdraví Pavel Kwiecien
---------- Původní zpráva ---------- Od: Jan Macura <macurajan na gmail.com> Komu: OpenStreetMap Czech Republic <talk-cz na openstreetmap.org> Datum: 30. 12. 2016 21:49:20 Předmět: Re: [Talk-cz] RUIAN posun - konečné řešení? " Ahoj, 2016-12-30 20:31 GMT+01:00 Pavel Kwiecien <pavel.kwiecien na seznam.cz (mailto: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. _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz " ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20161231/c51d61b5/attachment.html>

1.1.2017 01:16:43 (#36)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
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! -- Petr

3.1.2017 01:08:17 (#37)
gravatar

Jan Macura

<macurajan at gmail.com>
755 2731
Ahoj, 2017-01-01 13:16 GMT+01:00 Petr Vejsada <osm na propsychology.cz>: zobrazit citaci
> 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170103/94855b64/attachment.html>

3.1.2017 09:15:09 (#38)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
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 Dne 1.1.2017 v 13:16 Petr Vejsada napsal(a): zobrazit citaci
> 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! > > -- > Petr > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

3.1.2017 08:38:14 (#39)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
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. Dne Út 3. ledna 2017 09:15:09, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> 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 > > Dne 1.1.2017 v 13:16 Petr Vejsada napsal(a): > > 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! > > > > -- > > Petr > > > > _______________________________________________ > > 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
------------- další část --------------- A non-text attachment was scrubbed... Name: josm.png Type: image/png Size: 102212 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170103/acb967e2/attachment.png>

3.1.2017 09:16:48 (#40)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Dne Út 3. ledna 2017 20:38:14, Petr Vejsada napsal(a): zobrazit citaci
> 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

8.1.2017 11:53:11 (#41)
gravatar

Petr Morávek [Xificurk]

<petr at pada.cz>
139
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 Dne 3.1.2017 v 20:38 Petr Vejsada napsal(a): zobrazit citaci
> 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. > > Dne Út 3. ledna 2017 09:15:09, Petr Morávek [Xificurk] napsal(a): > >> 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 >> >> Dne 1.1.2017 v 13:16 Petr Vejsada napsal(a): >>> 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! >>> >>> -- >>> Petr >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- A non-text attachment was scrubbed... Name: bukovec.png Type: image/png Size: 30695 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20170108/89e25057/attachment.png>

9.1.2017 12:08:46 (#42)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
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. Dne Ne 8. ledna 2017 23:53:11, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> 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-) -- Petr

« zpět na výpis měsíce