Aktualizace RUIAN na Talk-cz - OpenStreetMap.cz

Petr Vejsada osm na propsychology.cz #mcf4f33 2. 5. 2014 10:50

Zdravim, na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB trva dlouho.

Marián Kyral mkyral na email.cz #mb1ef08 2. 5. 2014 14:36

Zdravim, na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB trva dlouho.

Ahoj, na jak dlouho to vidíš? On totiž nefunguje ani PointInfo, tak ať vím, co si mám naplánovat. Marián

Petr Vejsada osm na propsychology.cz #m45a57c 2. 5. 2014 14:59

Zdravim, na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB trva dlouho.
Ahoj, na jak dlouho to vidíš? On totiž nefunguje ani PointInfo, tak ať vím, co si mám naplánovat.

Zrovna jsem ti psal do mailu - pointinfo by mělo fungovat, ovšem jen na místech, kde už jsou data nahraná. Nahrávám od rána znovu, jsem v necelé půlce. Myslím, že do půlnoci by mělo vše být. V Praze je vadný polygon, čeká mě ruční editace řádku dlouhého 888 MB :-\. Nechápu, jak může být v datech z ČÚZK vadný polygon.

"Petr Morávek [Xificurk]" petr na pada.cz #m4fe08e 2. 5. 2014 15:15

Zrovna jsem ti psal do mailu - pointinfo by mělo fungovat, ovšem jen na místech, kde už jsou data nahraná. Nahrávám od rána znovu, jsem v necelé půlce. Myslím, že do půlnoci by mělo vše být. V Praze je vadný polygon, čeká mě ruční editace řádku dlouhého 888 MB :-\. Nechápu, jak může být v datech z ČÚZK vadný polygon.

Nevím, co se změnilo, ale poslední cca 3 měsíce se to stává nepříjemně často. Dřív jsem na tenhle problém nenarážel. Petr Morávek aka Xificurk

Marián Kyral mkyral na email.cz #mf68346 2. 5. 2014 15:19

Zdravim, na zaklade vcerejsiho zjisteni jsem se pustil do kompletne noveho nahrani dat z RUIAN. To znamena, ze vrstvy z tile.poloha.net budou fungovat az do nahrani omezene. Co je vyrenderovane, to se zobrazi, co vyrenderovane neni, tak pak zalezi na tom, zda konkretni obec uz je nahrana. Bohuzel to nahrani do DB trva dlouho.
Ahoj, na jak dlouho to vidíš? On totiž nefunguje ani PointInfo, tak ať vím, co si mám naplánovat.
Zrovna jsem ti psal do mailu - pointinfo by mělo fungovat, ovšem jen na místech, kde už jsou data nahraná. Nahrávám od rána znovu, jsem v necelé půlce. Myslím, že do půlnoci by mělo vše být. V Praze je vadný polygon, čeká mě ruční editace řádku dlouhého 888 MB :-\. Nechápu, jak může být v datech z ČÚZK vadný polygon.

Právě, že jsem teď chtěl editovat, kde data ještě nejsou ;-) Ad XML) Co takhle si jej přeformátovat? Třeba pomocí XMLStarlet ( http://xmlstar.sourceforge.net ) Marián

"Petr Morávek [Xificurk]" petr na pada.cz #m77f610 2. 5. 2014 15:24

Ad XML) Co takhle si jej přeformátovat? Třeba pomocí XMLStarlet ( http://xmlstar.sourceforge.net ) Marián

Na to stačí i libxml2: xmllint --format file.xml Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/ Petr

Marián Kyral mkyral na email.cz #m793a11 2. 5. 2014 17:17

Ad XML) Co takhle si jej přeformátovat? Třeba pomocí XMLStarlet ( http://xmlstar.sourceforge.net ) Marián
Na to stačí i libxml2: xmllint --format file.xml Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/ Petr

Však to byl jen příklad. Xmlstarlet umí navíc to xml prohledávat, editovat, transformovat i validovat. A stejně je rozdíl, jestli to je 800MB na jednom řádku nebo 800MB rozdělených na milión řádků. Marián

Petr Vejsada osm na propsychology.cz #m3771a1 3. 5. 2014 13:51

Na to stačí i libxml2: xmllint --format file.xml Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/

Jo, to je dobrý, dík. Tak s Prahou konečně dobojováno, vadný polygon u ZSJ 306045 Za Hornoměcholupskou a prázdný polygon u ZSJ 132021 - Horní Měcholupy-sever. Začnu rozesílat objednaná data na import adres.

Martin Kokes shr3k na typo3-hosting.com #mced5da 13. 5. 2014 20:58

Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz. MK "Petr Vejsada" píše v diskusním příspěvku news:5233309.6ma79d05rp na mrnous...

Na to stačí i libxml2: xmllint --format file.xml Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/

Jo, to je dobrý, dík. Tak s Prahou konečně dobojováno, vadný polygon u ZSJ 306045 Za Hornoměcholupskou a prázdný polygon u ZSJ 132021 - Horní Měcholupy-sever. Začnu rozesílat objednaná data na import adres.

Petr Vejsada osm na propsychology.cz #m4d9615 13. 5. 2014 21:11

Zdravím,

Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz.

jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podpora na cuzk.cz tento mail: ******************* Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá "ocásek" v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy <vf:xxxxx></vf:xxxxx>. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření.

Martin Kokes shr3k na typo3-hosting.com #ma2e6de 13. 5. 2014 21:24

Nojo, paní Landová z podpory bývá dost skoupá na vyjádření, většinou něco někam forwardne a děj se vůle boží. Pak možná forwardne zpátky nějakou odpověď. :-) Většinou pomůže oslovení někoho dalšího, který je více vstřícný, třeba tu vidím, že se zapojil Petr Souček. Můžete zkusit i Pavel Šidlichovský, který vede správu ZABAGEDu (a tím pádem asi i adresní místa). E-maily snadno odvodíte jmeno.prijmeni. MK "Petr Vejsada" píše v diskusním příspěvku news:2002810.zTFi1LYSpi na mrnous... Zdravím,

Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz.

jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podpora na cuzk.cz tento mail: ******************* Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá "ocásek" v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy <vf:xxxxx></vf:xxxxx>. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření.

Nojo, paní Landová z podpory bývá dost skoupá na vyjádření, většinou něco někam forwardne a děj se vůle boží. Pak možná forwardne zpátky nějakou odpověď. :-) Většinou pomůže oslovení někoho dalšího, který je více vstřícný, třeba tu vidím, že se zapojil Petr Souček. Můžete zkusit i Pavel Šidlichovský, který vede správu ZABAGEDu (a tím pádem asi i adresní místa). E-maily snadno odvodíte jmeno.prijmeni. MK "Petr Vejsada" píše v diskusním příspěvku news:2002810.zTFi1LYSpi na mrnous... Zdravím, Dne Út 13. května 2014 20:58:37, Martin Kokes napsal(a):

Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz.

jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podpora na cuzk.cz tento mail: ******************* Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá "ocásek" v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy <vf:xxxxx></vf:xxxxx>. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření. -- Zdraví Petr Vejsada ******************* Odpověď žádná, polygon neopraven, ta vazba na obec opravena byla i bez mého upozornění. -- Petr

Petr Souček soucekp na atlas.cz #me75733 18. 5. 2014 13:23

Dobrý den, pokusím se zareagovat na níže uvedený dotaz. Většinou se ke mně dotazy na VFR z podpory ČÚZK dostávají a snažím se na ně (ve spolupráci s kolegy) odpovídat. Tenhle jsem ovšem nezaznamenal. Adresní místa jsou součástí RÚIAN, takže je možné kontaktovat kolegu Ing. Jiřího Formánka - ten určitě poradí také, případně předá kompetentnímu kolegovi. A nyní k diskutovaným problémům: 1) nevalidní polygony - o tomto problému víme. Jedná se o chybu v aplikaci, kterou řešíme s naším dodavatelem. Doufám, že se nám podaří novou verzi nasadit co nejdříve. 2) katastrální území bez obce - to se stát může. Jedná se o dočasné řešení, které souvisí s procesem vzniku katastrálního území (v současné době probíhá vytváření nových k.ú. v souvislosti s optimalizacemi vojenských újezdů v ČR). Nejdříve se vytvoří prázdná obálka k.ú. v ISKN (1), následně se v ISÚI přiřadí k.ú. vazba na obec (2) a nakonec v ISKN proběhlo naplnění k.ú. parcelami (3). Pokud body (1) a (2) neproběhnou v rámci jednoho dne, tak se v datech RÚIAN objeví k.ú. bez vazby na obec. My na ČÚZK se o tento postup snažíme, ale v některých případech se to nepovede. 3) XML na jednom řádku - pokusíme se zajistit. My některá XML už takto poskytujeme - viz základní sada RÚIAN, např. soubor http://vdp.cuzk.cz/vymenny_format/soucasna/20140430_OB_550671_UZSZ.xml.gz .Tyto soubory totiž vytváříme pomocí XSLT transformace z kompletní datové sady vlastními prostředky. Kompletní datovou sadu vytváří aplikace - tudíž budeme muset řešit s naším dodavatelem jako změnový požadavek, abychom sjednotili poskytování našich dat. Pěkný den přeje Petr Souček

Dobrý den, pokusím se zareagovat na níže uvedený dotaz. Většinou se ke mně dotazy na VFR z podpory ČÚZK dostávají a snažím se na ně (ve spolupráci s kolegy) odpovídat. Tenhle jsem ovšem nezaznamenal. Adresní místa jsou součástí RÚIAN, takže je možné kontaktovat kolegu Ing. Jiřího Formánka - ten určitě poradí také, případně předá kompetentnímu kolegovi. A nyní k diskutovaným problémům: 1) nevalidní polygony - o tomto problému víme. Jedná se o chybu v aplikaci, kterou řešíme s naším dodavatelem. Doufám, že se nám podaří novou verzi nasadit co nejdříve. 2) katastrální území bez obce - to se stát může. Jedná se o dočasné řešení, které souvisí s procesem vzniku katastrálního území (v současné době probíhá vytváření nových k.ú. v souvislosti s optimalizacemi vojenských újezdů v ČR). Nejdříve se vytvoří prázdná obálka k.ú. v ISKN (1), následně se v ISÚI přiřadí k.ú. vazba na obec (2) a nakonec v ISKN proběhlo naplnění k.ú. parcelami (3). Pokud body (1) a (2) neproběhnou v rámci jednoho dne, tak se v datech RÚIAN objeví k.ú. bez vazby na obec. My na ČÚZK se o tento postup snažíme, ale v některých případech se to nepovede. 3) XML na jednom řádku - pokusíme se zajistit. My některá XML už takto poskytujeme - viz základní sada RÚIAN, např. soubor http://vdp.cuzk.cz/vymenny_format/soucasna/20140430_OB_550671_UZSZ.xml.gz . Tyto soubory totiž vytváříme pomocí XSLT transformace z kompletní datové sady vlastními prostředky. Kompletní datovou sadu vytváří aplikace - tudíž budeme muset řešit s naším dodavatelem jako změnový požadavek, abychom sjednotili poskytování našich dat. Pěkný den přeje Petr Souček -----Original Message----- From: Martin Kokes [mailto:shr3k na typo3-hosting.com] Sent: Tuesday, May 13, 2014 9:25 PM To: talk-cz na openstreetmap.org Subject: Re: [Talk-cz] Aktualizace RUIAN Nojo, paní Landová z podpory bývá dost skoupá na vyjádření, většinou něco někam forwardne a děj se vůle boží. Pak možná forwardne zpátky nějakou odpověď. :-) Většinou pomůže oslovení někoho dalšího, který je více vstřícný, třeba tu vidím, že se zapojil Petr Souček. Můžete zkusit i Pavel Šidlichovský, který vede správu ZABAGEDu (a tím pádem asi i adresní místa). E-maily snadno odvodíte jmeno.prijmeni. MK "Petr Vejsada" píše v diskusním příspěvku news:2002810.zTFi1LYSpi na mrnous... Zdravím, Dne Út 13. května 2014 20:58:37, Martin Kokes napsal(a):

Ty chyby jsou tam myslím od března, už jsem to hlásil na podpora na cuzk.cz.

jelikož zpracovávám změnové soubory takřka denně, tak jsem si toho všiml asi brzy. 28. března jsem posílal na podpora na cuzk.cz tento mail: ******************* Dobrý den, pro projekt Openstreetmap používáme jako jeden ze zdrojů dat RUIAN. V poslední době dochází k neobvyklostem ve změnových souborech. Konkrétně se jedná o nevalidní polygony a chybějící identifikaci obce u katastrálního území. Příklady: Změnový soubor 20140324_ST_ZKSH.xml.gz obsahuje, podle mého názoru, nevalidní polygon u ZSJ 306045 - polygon je uzavřený a na jeho konci ještě přebývá "ocásek" v podobě jednoho bodu navíc Změnový soubor 20140327_ST_ZKSH.xml.gz obsahuje katastrální území 920681 a katastrální území 929930, ale u obou chybí vazba na obec (chybí kód obce). Je to takto v pořádku? Může být katastrální území, které nenáleží žádné obci? Pokud jde opravdu o chyby, přimlouval bych se za to, aby změnový soubor byl rozdělený na řádky alespoň elementy <vf:xxxxx></vf:xxxxx>. Řádek, dlouhý 67MB se opravdu ručně opravuje dost nepohodlně. Děkuji předem za vyjádření. -- Zdraví Petr Vejsada ******************* Odpověď žádná, polygon neopraven, ta vazba na obec opravena byla i bez mého upozornění. -- Petr