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

> Aktuálně je rozdíl RUIAN vs. KM. Takže jsem předpokládal, že stačí

> mimo, tak jsme v pr..li úplně. :-(

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

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

>> mimo, tak jsme v pr..li úplně. :-( > > *** tak pokud nám stačí, aby to sedělo na cuzk:km v epsg:4326 pak

> http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/12381535 > >

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

> > Teoreticky bych se u každé budovy mohl zeptat WFS a korigované

> > Ale nešlo by to nějak použít pro vygenerování té matice? Máme dva zdroje,

> > Marián > > ha > hanoj > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz > >

> Pro korekci tohoto posunu se dá použít korekční Grid (

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

> Proběhly tady nějaké pokusy, byla na to diplomka, pan Souček z ČÚZK

> mrkne a dá vědět, který přesně se používá, ale zatím vše selhalo. Takže

> však nedává přesné výsledky.

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

> > > Pro korekci tohoto posunu se dá použít korekční Grid (

> > *** nic takového se neprokázalo. ;) > > > Fááákt? A proč mám sakra tady v Beskydech ty rozdíly :-D

> Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém

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

> 2) Transformace gridem je znama: http://k154.fsv.cvut.cz/~seidl/ > http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid

> > Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém

> *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co nám

> No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych

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

> > > Ž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. >

> ha > hanoj > > > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-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ý ;-) ) >

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

> SELECT ST_AsText(ST_Transform(ST_GeomFromText('POINT(-718583.33 -949224.46)',999),4326)) As wgs_geom; > "POINT(14.5808761364013 50.9523314825017)"

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

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

> # ETRS89 > <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs <>

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

> S pozdravem, > Petr Morávek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

> 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

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

> 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

> 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

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

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

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

> *** 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č.

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

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

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

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

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

> Do RÚIAN je ÚKM přebírána jako orientační mapa parcel, z toho vyplývají > nepřesnosti při importu. >

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

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

> 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

> Pustím se teď do toho Seidlova díla.

> 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

> Opravdu to vypadá, že ČUZK transformaci do EPSG:4236 dělá blbě a vzniká > tam dodatečná chyba.