Re: [Talk-cz] Data RUIAN - výměnný formát
Dne 30.6.2012 22:55, hanoj napsal(a): Ahoj Takže v první fázi udělat program, který porovná stav v OSM a v RUIAN. Jak by měl vypadat výstup tohoto porovnání? Může nastat mnoho případů (nejde o disjunktní případy): *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina) Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima oznacime kde je vchod + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. = opet se znici spousta prace spousty lidi. 2) mixovane addr+POI vymazat info o addr a POI tagy v nodu ponechat (cca 1000 nodu) = misto jedny tecky jich udelame na kazdy budove nekolik? A jak zjistim ze to vsechno patri k sobe? Jak zjistim, ze na adrese XYZ je hospoda? To si na to mam psat expertni system a analizovat vzdalenosti jednotlivych bodu? Nehlede na to, ze to opet budes delat kazdy den znova? 3) budovy s addr prevest na body (cca 13.000 way) = viz vejs, editori je opet zacnou posunovat ke vchodu = budes den co den mazat stovky bodu a znova je importovat? 4) addr ktere se shoduji tagem a polohou z OSM vymazat (polohova shoda do 10m) 5) uplny itinerar to neni, ale vetsinu to snad pokryva, co se zbytkem, se ukaze az pri cinu 6) to co zbyde priradit fixme Proto si myslim, ze je lepsi dat adresu na budovu. Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod. U budov a jakýchkoliv jiných polygonů je to těžké, možná by byl lepší nějaký tracer, co by netracoval, ale jen tahal napozicované a transformované vektory z prostorové databáze, přičemž samotné vkládání nebo rozhodnutí, zda vložit, by bylo už na uživateli. *** to nas potom ceka CR navzdy bez budov..., vzdyt stavajici tracer mame uz tretim rokem. To se týká i WFS s tématem INSPIRE parcely, které jsou krásně vyčištěny a ze kterých by šly dělat např. zahrady, pole, lesy atp. podobným způsobem. *** je treba nezapomenout, typ parcely na les/pole/louky vychazeji z nominalni predstavy o urceni hodnoty parcely, nikoliv co na parcele skutecne je/roste/stoji. PS: transformace skrze proj/gdal: * bez parametru towgs presnost 100m * s parametrem towgs presnost 1m (tedy nikoliv 70m) * s parametrem +nadgrids=czech 0,1m ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
jzvc wrote: Proto si myslim, ze je lepsi dat adresu na budovu. Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod. Mně by se taky líbílo dávat adresu spíše na budovu, ale vidím tu dva problémy: 1) Občas má jedna (reálná) budova více adres a občas je v OSM budova zakreslena pomocí více cest (např. pro možnost označení nižší/vyšší části jedné budovy), takže vztah OSM budova:adresní bod je obecně N:M a nevím, jak to elegantně vyřešit. 2) Aktualizace bodů je řádově jednodušší než cest. Jak tagování pomocí bodů, tak i cest má svá pro a proti... možná bysme to mohli začít sepisovat někde na wiki, včetně návrhů řešení. Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Data RUIAN - výměnný formát
Ahoj, Takže v první fázi udělat program, který porovná stav v OSM a v RUIAN. Jak by měl vypadat výstup tohoto porovnání? Může nastat mnoho případů (nejde o disjunktní případy): *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina) Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima oznacime kde je vchod + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. = opet se znici spousta prace spousty lidi. *** V OSM mame verzovani, takze urcit co je jen import UIR-ADR bez zasahu useru nebude problem. *** Oznacovani tzv. vchodu je myslim minoritni vec. Hlavni duvod posunu je, ze adresni body jsou casto o desitky metru jinde. *** Ja jsem posunul cca 10.000 adresnich bodu, ale rad si je necham nahradit necim, co ma systematicky pristup a vizi udrzby. 2) mixovane addr+POI vymazat info o addr a POI tagy v nodu ponechat (cca 1000 nodu) = misto jedny tecky jich udelame na kazdy budove nekolik? A jak zjistim ze to vsechno patri k sobe? Jak zjistim, ze na adrese XYZ je hospoda? To si na to mam psat expertni system a analizovat vzdalenosti jednotlivych bodu? Nehlede na to, ze to opet budes delat kazdy den znova? *** to neni expertni system, ale trivialni prostorove dotazy (co je nejbliz). Navic to tak uz dnes v mape funguje. Jde o sjednoceni ruznych pristupu. *** Navic adresa/POI je vzdycky priblizna at uz fakticky (sidlo/provozovna) nebo lokacne (napr. prumyslovy areal o 10 hektarech ma 1 adresni bod) 3) budovy s addr prevest na body (cca 13.000 way) = viz vejs, editori je opet zacnou posunovat ke vchodu = budes den co den mazat stovky bodu a znova je importovat? *** tohle myslim problem plugin building v JOSM, ktery automaticky predelava adresni bod do nove vytvorene budovy. *** Co bude den co den zalezi na tom, jak budeme chtit udrzet v chodu aktualizace s RUIAN Proto si myslim, ze je lepsi dat adresu na budovu. *** Budovu myslis jako way (OSM building), nebo budovu v RUIAN (bod) nebo parcelu se stavbou RUIAN (polygon z katastru na 1/2 uzemi CR)? Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod. *** No ja nevim, doposud se to tak nazyvalo v UIR-ADR jako Adresni bod. V RUIAN AdresniMisto, reprezentovane bodem navic s vazbou na budovu (zase bod). *** Reprezentace objektu v OSM je o dohode, jakou miru generalizace prijimame. Napr silnice kreslime jako osy, ikdyz by bylo zdanlive vhodnejsi uzit plochy. Aby mapa mohla fungovat, je nutna mira zjednoduseni skutecnosti. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN - veřejný dálkový přístup
Dne 30. června 2012 20:44 JV j@seznam.cz napsal(a): Zdravím všechny, na adrese http://vdp.cuzk.cz/ byl zpřístupněn veřejný dálkový přístup k RUIAN. Momentálně je tam dostupný stavový export ke včerejšku - další se bude dělat zítra a pak už se najede na běžný režim (stavový export jednou za měsíc a denně změny). V exportech jsou už uliční čáry, definiční body vyšších územně správních celků a hranice záhkladních sídelních jednotek. *** A ze jsem tak smely, neplanujete nahradit Marushku nejakou pricetnejsi aplikaci? Velky krok by byl, kdyby pouzivala TMS nebo alespon WMS na TMS principu. Tzn. ze cachuje dlazdice na urcitem zoomu, coz vyrazne zrychluje praci (a setri server), jako napr. ikatastr.cz nebo JOSM. Dale urcite moznost odkazovat se na urcitou konkretni mapu... Take formulare pouzivane pro vyhledavani parcel/obci apod by take mohly byti vice pristupne. Nez clovek do nich neco naklika to je komplikovane..., stejne tak moznost odkazovat se na urcitou cast uz naklikaneho formulare. ahoj hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN - veřejný dálkový přístup
no, ono to s tou grafikou není tak jednoduché. O WMTS jsme uvažovali, ale zrovna pro katastrální mapu to není dobré řešení. Každý den se aktualizuje grafika v cca 700 katastrálních územích, takže data jsou docela živá a nějaké vyrábění dlaždic (navíc průběžně - mapové služby mají zpoždění pouze v řádu hodin proti produkčnímu systému) by bylo vysoce problematické. Pro informaci - současné reálné špičky v zatížení WMS jsou kolem 5000 požadavků za minutu. Pokud je tím myšleno dlaždicování na straně klienta, tak o tom jsme se také bavili. Tam je ale problém s prvky, které řeže hrana dlaždice (popisy definičních bodů atd.) - na dlaždici s bodem pak je kus popisu a na sousední dlaždici není nic (protože tam není ten bod, ke kterému se doplňuje popis). Zrovna na ikatastr.cz to jde pěkně demonstrovat. Ten přímý odkaz do grafiky je. Možná trochu zasunutý, ale je :-) V grafickém okně tlačítko GPS a tam zkopírovat zobrazený odkaz. Jirka Dne 1.7.2012 12:34, hanoj napsal(a): Dne 30. června 2012 20:44 JVj@seznam.cz napsal(a): Zdravím všechny, na adrese http://vdp.cuzk.cz/ byl zpřístupněn veřejný dálkový přístup k RUIAN. Momentálně je tam dostupný stavový export ke včerejšku - další se bude dělat zítra a pak už se najede na běžný režim (stavový export jednou za měsíc a denně změny). V exportech jsou už uliční čáry, definiční body vyšších územně správních celků a hranice záhkladních sídelních jednotek. *** A ze jsem tak smely, neplanujete nahradit Marushku nejakou pricetnejsi aplikaci? Velky krok by byl, kdyby pouzivala TMS nebo alespon WMS na TMS principu. Tzn. ze cachuje dlazdice na urcitem zoomu, coz vyrazne zrychluje praci (a setri server), jako napr. ikatastr.cz nebo JOSM. Dale urcite moznost odkazovat se na urcitou konkretni mapu... Take formulare pouzivane pro vyhledavani parcel/obci apod by take mohly byti vice pristupne. Nez clovek do nich neco naklika to je komplikovane..., stejne tak moznost odkazovat se na urcitou cast uz naklikaneho formulare. ahoj hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN - veřejný dálkový přístup
Zdravím, nemohu si pomoci, ale souhlasím s hanojem a jsem přesvědčen, tak dlaždicování je správná cesta. Marushka je opravdu strašně pomalá - generování výřezu 10 sekund není nic výjimečného - naštěstí s ní nepracuji. Ono tedy nahlížení do katastru je také velmi pomalé (4 až 5 sekund běžně) - dokonce dříve to bývalo rychlejší. Každý den se aktualizuje grafika v cca 700 katastrálních územích, takže data jsou docela živá a nějaké vyrábění dlaždic (navíc průběžně - mapové služby mají zpoždění pouze v řádu hodin proti produkčnímu systému) by bylo vysoce problematické Dlaždice se aktualizují pouze při změně (dané dlaždice). Tedy při změně dat se zjistí jejich rozdíl (pokud není možné jej zjistit přímo) a zneplatní se zasažené dlaždice, které se průběžně s menší prioritou generují. S větší prioritou se generují dlaždice, které si někdo vyžádal a nejsou již vygenerované. Nevěřím, že každý den změní relativně velké množství dlaždic. Mapy jsou ve velkých zoomech a dlaždice tak pokrývá poměrně malé území. Pro informaci - současné reálné špičky v zatížení WMS jsou kolem 5000 požadavků za minutu. Čím více požadavků, tím více je to ve prospěch dlaždic. Generování výřezu mapky z dat trvá dle pozorování hodně dlouho. Pokud je tím myšleno dlaždicování na straně klienta, tak o tom jsme se také bavili. Tam je ale problém s prvky, které řeže hrana dlaždice (popisy definičních bodů atd.) - na dlaždici s bodem pak je kus popisu a na sousední dlaždici není nic (protože tam není ten bod, ke kterému se doplňuje popis). Zrovna na ikatastr.cz to jde pěkně demonstrovat. Tohle má celkem jednoduché řešení - pro každý takový prvek je třeba zjistit ohraničující obdélník a ten zanést do prostorového indexu, ze kterého se pak zjišťuje, které objekty zasahují do daného výřezu (dlaždice). Ale tento problém musíte stejně řešit již nyní, kdy generujete výřez na přání. Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
