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

[Petr Vejsada]

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

> 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


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Morávek [Xificurk]]

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):
> 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.83 +alpha=30.2881397222
>>> +k=0. +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@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Vejsada]

Dne Út 3. ledna 2017 20:38:14, Petr Vejsada napsal(a):

> 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


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Vejsada]

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.83 +alpha=30.2881397222
> > +k=0. +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@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Morávek [Xificurk]]

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.83 +alpha=30.2881397222 
> +k=0. +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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> 


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Jan Macura]

Ahoj,

2017-01-01 13:16 GMT+01:00 Petr Vejsada :

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

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

[Petr Vejsada]

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.83 +alpha=30.2881397222 
+k=0. +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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Pavel Kwiecien]

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 <macura...@gmail.com>
Komu: OpenStreetMap Czech Republic <talk-cz@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.kwiec...@seznam.cz
(mailto:pavel.kwiec...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Jan Macura]

Ahoj,

2016-12-30 20:31 GMT+01:00 Pavel Kwiecien :

> 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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Pavel Kwiecien]

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 <macura...@gmail.com>
Komu: OpenStreetMap Czech Republic <talk-cz@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 <mky...@email.cz
(mailto:mky...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Jan Macura]

Ahoj,

2016-12-29 9:02 GMT+01:00 Marián Kyral :

>
> 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
(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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Jan Macura]

Ahoj,

2016-12-27 8:44 GMT+01:00 Marián Kyral :

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

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

[Marián Kyral]

Dne 29.12.2016 v 08:47 Marián Kyral napsal(a):
> 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



___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

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

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


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


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Morávek [Xificurk]]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

Dne 27.12.2016 v 11:40 Petr Morávek [Xificurk] napsal(a):
> 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:
>>> 
>>>   
>>>   
>>>   >> value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>>>   
>>>   
>>>   
>>> 
>>>
>>> Žá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

>
> S pozdravem,
> Petr
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Ha Noj]

> Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84)
> pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl
> otevřít :-))
*** Chystám na to téma článek na wiki, ale musím to konzultovat, taky to
není pro mne zcela na první pochopitelné. Bude to možná až po vánocích.

> Zajímalo by mne odkud pochází tvoje transformační parametry towgs84?
> Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě
> zdrojů narážel na doporučení považovat oba systémy za "shodné".
*** V obecné rovině jsou si dnes ETRS a WGS84 podobné na úrovni metrů. Jak
jsem psal, v ČR jsou odlišnosti v řádech 30 cm.

> A když
> se podívám na definici v /usr/share/proj/epsg tak tam je:
>
> > # ETRS89
> > <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs  <>
*** To může také říkat, že takový vztah není vůbec definován.

ha
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Morávek [Xificurk]]

Dne 27.12.2016 v 11:40 Petr Morávek [Xificurk] napsal(a):
> 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:
>>> 
>>>   
>>>   
>>>   >> value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>>>   
>>>   
>>>   
>>> 
>>>
>>> Žá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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Morávek [Xificurk]]

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:
>> 
>>   
>>   
>>   > value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>>   
>>   
>>   
>> 
>>
>> Žá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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

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:
> 
>   
>   
>value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>   
>   
>   
> 
>
> Žá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

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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a):
> 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:

  
  
  
  
  
  


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

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

[Petr Morávek [Xificurk]]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Ha Noj]

> 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=wcts=19

> 2) Dělá něco špatně ČÚZK a jeho souřadnice v EPSG:4326 jsou chybné?
*** CUZK říká, že ho přesnost RUIAN pod 1,5 m netrápí.

> 3) Skutečně je grid Ježek2008 přesný řádově na centimetry?
*** ano, ted ho tu testuji na 41 000 bodech. Chyba mezi ERTF2000 a JTSK je
menší než 5cm je v 81,3 %, menší než 10cm v 99,4%. Ve zbylých 0,6% nelze
rozhodnout zda jde o chybu v datech nebo lokální deformace základů JTSK.

> 4) Jak je možné, že se transformace moje a ČÚZK rozchází v tomhle
> případě víc jak o metr?
*** CUZK říká, že ho přesnost RUIAN pod 1,5 m netrápí.

> 5) Pokud je transformace ČUZK správná, jak ji můžu implementovat u sebe
> aniž bych se na každou souřadnici musel ptát WFS?
*** jakou transformaci CUZK používá se mi nepodařilo zjistit a já sám to z
výsledků neumím odhadnout.


ha
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Morávek [Xificurk]]

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
>> 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=urn:ogc:def:crs:EPSG::4326=2.0.0=GetFeature_id=urn:ogc:def:query:OGC-WFS::GetFeatureById=BU.12847628
> 
> 
> ha
> hanoj

Ahoj,

včera večer jsem si potvrdil, že mám u sebe grid Ježek2008 -sedí mi
transfomace kontrolního bodu uváděného na wiki:

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

A tak jsem to rovnou testnul na odkazované budově (prostě jsem vzal
první bod z geometrie budovy):

ČUZK EPSG:5514:
-432758.18 -1136758.78

ČUZK EPSG:4326:
49.547998 18.845223

ČUZK EPSG:4326 -> EPSG:5514 převedeno pomocí gridu:
-432759.004430401 -1136759.53511646

Tzn. celkový posun je cca 112cm.

Ono to není nijak tragické, ale už je to prostě poznat. Ale především je
to o dva řády vyšší odchylka než tebou udávané centrimetry.

Omlouvám se pokud přehlížím nějakou trivialitu, která je jasná každému
prvákovi na geoinformatice... v tomhle jsem prostě amatér a do vnitřních
složitostí tematiky různých projekcí vidím jen natolik, kolik bylo doteď
potřeba pro práci s RUIAN v OSM. Takže se možná budu dál ptát trochu
jako blbeček, ale...

1) Dělám něco špatně já?

2) Dělá něco špatně ČÚZK a jeho souřadnice v EPSG:4326 jsou chybné?

3) Skutečně je grid Ježek2008 přesný řádově na centimetry?

4) Jak je možné, že se transformace moje a ČÚZK rozchází v tomhle
případě víc jak o metr?

5) Pokud je transformace ČUZK správná, jak ji můžu implementovat u sebe
aniž bych se na každou souřadnici musel ptát WFS?


Předem díky za jakékoliv info,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Jan Macura]

Ahoj, díky za nastínění problému.

2016-12-21 7:20 GMT+01:00 Marián Kyral :

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

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

[Marián Kyral]

Dne 22.12.2016 v 20:51 Ha Noj napsal(a):
> > > Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
> vlastně není a všichni jsou happy.
> > *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co
> nám vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
> > No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych
> nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový
> plugin a do toho momentálně nejdu. Už tak mám na seznamu plno věcí,
> které bych chtěl někdy udělat. Třeba pár vylepšení na osmap.cz
> .
> *** a nebo pro poloha.net/budovy  napsat
> skript, který pro každou budovu vloží novou geometrii z WFS a není
> třeba nic měnit na tracer pluginu.
>

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

> ha
> hanoj
>
>
>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Ha Noj]

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

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

[Ha Noj]

> > Že já se do toho vůbec pouštěl. Nakonec to dopadlo tak, že problém
vlastně není a všichni jsou happy.
> *** Snad nebude tak zle. Myslím, že to WFS je hezká cesta k tomu co nám
vyhovuje a označil bych to podle pravidla "blbě ale jednotně." ;)
> No pro mně by bylo ideální, kdyby to za mně přepočítal Petr. To bych
nemusel nic dělat. Ale přejít na WFS znamená, udělat komplet nový plugin a
do toho momentálně nejdu. Už tak mám na seznamu plno věcí, které bych chtěl
někdy udělat. Třeba pár vylepšení na osmap.cz.
*** a nebo pro poloha.net/budovy napsat skript, který pro každou budovu
vloží novou geometrii z WFS a není třeba nic měnit na tracer pluginu.

ha
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Petr Morávek [Xificurk]]

Dne 20.12.2016 v 11:40 Ha Noj napsal(a):
> 2) Transformace gridem je znama: http://k154.fsv.cvut.cz/~seidl/
> http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid

Ahoj,

tohle je třeba pro mne nové info - přiznám se, že jsem to tu poslední
dobou moc nesledoval, tak nevím jestli jsem zmínku o tomto gridu jen
přehlédl, nebo sem opravdu doputovala až teď.

Jsem si celkem jistý, že v databázi, ze které pouštím aktualizace
administrativních hranic mám nějaký starší méně přesný grid... a vůbec
bych se nedivil, kdyby to měl Petr na poloha.net taky tak.

Každopádně díky za info, aspoň si mám s čím přes vánoce hrát :-)

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

Dne 22.12.2016 v 13:32 Ha Noj napsal(a):
> > Ž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


> ha
> hanoj
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Ha Noj]

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

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

[Marián Kyral]

-- Původní zpráva --
Od: Ha Noj <eha...@gmail.com>
Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
Datum: 21. 12. 2016 21:11:44
Předmět: Re: [Talk-cz] RUIAN posun - konečné řešení?

"


> > > Pro korekci tohoto posunu se dá použít korekční Grid ( http://freegis.
fsv.cvut.cz/gwiki/S-JTSK_/_Grid
(http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid) ), který ovšem > > po změně
algoritmu nedává správná data, takže přepočet není správný.
> > *** nic takového se neprokázalo. ;)
> >
> Fááákt? A proč mám sakra tady v Beskydech ty rozdíly :-D
*** ze dvou výsledků zpravidla nelze určit, který je blíže cíli ;)


Na 28 bodů CZEPOS s obojími souřadnicemi lze naše metody elementárně 
otestovat:
http://pastebin.com/eFidfVuQ(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=TextMeta;
text=wcts=19
(http://geoportal.cuzk.cz/Default.aspx?head_tab=sekce-01-gp=TextMeta=wcts=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:
1.5 





"



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

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

[Ha Noj]

> > > Pro korekci tohoto posunu se dá použít korekční Grid (
http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid ), který ovšem > > po změně
algoritmu nedává správná data, takže přepočet není správný.
> > *** nic takového se neprokázalo. ;)
> >
> Fááákt? A proč mám sakra tady v Beskydech ty rozdíly :-D
*** ze dvou výsledků zpravidla nelze určit, který je blíže cíli ;)

Na 28 bodů CZEPOS s obojími souřadnicemi lze naše metody elementárně
otestovat:
http://pastebin.com/eFidfVuQ

1) Výše v tomto vlákně zmíněný GRID od Seidl2014 dává tyto výsledky:
xy<8cm z<3cm
stdev_xy<2cm, stdev_z<1cm


2) Transformační služba CUZK dává tyto výsledky:
http://geoportal.cuzk.cz/Default.aspx?head_tab=sekce-01-gp=TextMeta=wcts=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:
1.5


ha
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

Dne 21.12.2016 v 16:16 Ha Noj napsal(a):
> 0   > Teoreticky bych se u každé budovy mohl zeptat WFS a korigované
> souřadnice, ale je to zase další dotaz do sítě, další zdržení během
> trasování.
> *** tak se zeptejme WFS předem hromadně přes BBOX či podobně.
>

Tak jestli se budu někdy nudit, tak se na to možná kouknu.

> > Pro korekci tohoto posunu se dá použít korekční Grid (
> http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid
>  ), který ovšem po
> > změně algoritmu nedává správná data, takže přepočet není správný.
> *** nic takového se neprokázalo. ;)
>

Fááákt? A proč mám sakra tady v Beskydech ty rozdíly :-D

> > No a celé je to o tom, jak získat opravený Grid, aby objekty
> natrasované z RUIANu co nejvíce pasovaly na KM.
> > Proběhly tady nějaké pokusy, byla na to diplomka, pan Souček z ČÚZK
> slíbil, že se přes vánoce na ten algoritmus
> > mrkne a dá vědět, který přesně se používá, ale zatím vše selhalo.
> Takže se stále pro přepočet používá starý Grid, který
> > však nedává přesné výsledky.
> *** ještě bych možná dodal, že ČUZK používá 7prvkový klíč +
> dotransformaci(JTSK-JTSK05), kdežto grid jde na to přímo.
>
>

Já nemluvit jazyk tvého kmene.

Marián

> ha
> hanoj
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Ha Noj]

0   > Teoreticky bych se u každé budovy mohl zeptat WFS a korigované
souřadnice, ale je to zase další dotaz do sítě, další zdržení během
trasování.
*** tak se zeptejme WFS předem hromadně přes BBOX či podobně.

> Pro korekci tohoto posunu se dá použít korekční Grid (
http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid ), který ovšem po
> změně algoritmu nedává správná data, takže přepočet není správný.
*** nic takového se neprokázalo. ;)

> No a celé je to o tom, jak získat opravený Grid, aby objekty natrasované
z RUIANu co nejvíce pasovaly na KM.
> Proběhly tady nějaké pokusy, byla na to diplomka, pan Souček z ČÚZK
slíbil, že se přes vánoce na ten algoritmus
> mrkne a dá vědět, který přesně se používá, ale zatím vše selhalo. Takže
se stále pro přepočet používá starý Grid, který
> však nedává přesné výsledky.
*** ještě bych možná dodal, že ČUZK používá 7prvkový klíč +
dotransformaci(JTSK-JTSK05), kdežto grid jde na to přímo.


ha
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Jan Macura]

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  wrote:
> 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
>> 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=urn:ogc:def:crs:EPSG::4326=2.0.0=GetFeature_id=urn:ogc:def:query:OGC-WFS::GetFeatureById=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
>
> ha
> hanoj
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>

-- 
Sent from phone
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

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
> > 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=urn:ogc:def:crs:EPSG::4326=2.0.0=GetFeature_id=urn:ogc:def:query:OGC-WFS::GetFeatureById=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

> ha
> hanoj
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Ha Noj]

> 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=urn:ogc:def:crs:EPSG::4326=2.0.0=GetFeature&
StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById=BU.12847628

ha
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

Ahoj,


-- Původní zpráva --
Od: Ha Noj <eha...@gmail.com>
Komu: OpenStreetMap Czech Republic <talk-cz@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 <mky...@email.cz
(mailto:mky...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Ha Noj]

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  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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[Marián Kyral]

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