[talk-cz] Administrativní hranice
Zdravím, máte nějaký tip, na službu, která by poskytovala vyextrahované hranice administrativních celků? Momentálně potřebuju data pro ČR na úrovni státu (admin-level=3), krajů (admin-level=6) a okresů (admin-level=7), ale do budoucna by se mi hodilo i jiné státy v Evropě a tím pádem i jiné admin-level. Data budu používat pro vykreslování, takže klidně můžou být i nějakým způsobem zjednodušená. Nic použitelného jsem nenašel a tak, než si začnu hrát s Overpass API nebo se snažit vyextrahovat hranice jinak, se chci zeptat tady … existuje nějaká taková služba, nebo jsem jenom špatně hledal. Díky, Luk@s ___ talk-cz mailing list talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz https://openstreetmap.cz/talkcz
Re: [Talk-cz] Pole a sloupy VN - import LPIS
No s realitou si právě nejsem tak jistý ... když porovnám stav v OSM s ortofotomapou, tak mi připadá, že ty díry tam někdo kreslí podle momentální nálady. V místech, kde opravdu stojí jenom sloup uprostřed pole je v LPIS díra a naopak kolem sloupu bezmála malý lesík nebo velý osamocený strom uprostřed pole a v LPIS nic (http://prntscr.com/7n0z45, http://prntscr.com/7n0z45) Stejně tak tvar té díry nemá většinou s realitou nic moc společného, tvar spíš odpovídá tomu, jak bylo zrovna v době pořízení leteckých snímků pole posekané nebo jaký hodil zrovna sloup stín:-) Neměli bychom v takových připadech trochu generalizovat? Sloup = v mapě bod, ale je jasné že ve skutečnosti má nějaké reálné rozměry ... 2015-06-30 9:56 GMT+02:00 Ratt Snake rattsn...@gmail.com: Souhlasím, díry bych nechával, odráží to lépe realitu. Pavel Dne 30. června 2015 9:13 Marián Kyral mky...@email.cz napsal(a): Ahoj, je to různé. V LPIS někdy ty díry jsou, jindy ne. Asi záležím kdo to právě zakresloval. Jsem pro to je tam nechat. Kdybychom je tam nechtěli, tak jsem je mohli mazat už při importu a mohli jsme se vyhnout velké většině problémů, které způsobují relace ;-) Ono typicky kolem toho sloupu roste tráva nebo křoví. A to pole rozhodně není. Marián -- Původní zpráva -- Od: Lukas Kabrt lu...@kabrt.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 30. 6. 2015 9:04:24 Předmět: [Talk-cz] Pole a sloupy VN - import LPIS Při toulkách po mapě jsem si všimnul, že pravděpodobně po importu LPIS, se okolo sloupů VN často objevují maličké díry v polích. Např. http://www.openstreetmap.org/#map=19/50.50930/16.23577 Zajimálo by mě jaký je pohled ostatních na to, jestli se mají při editaci takové díry zachovávat. V naprosté většině případů, co jsem zkoumal je to opravdu jenom sloup (= bod) uprostřed pole, který by se neměl značit jako plocha. Podle mě je ideální postup nakreslit vedení VN, pokud není, a díry smazat. Jaký je pohled ostatních? ___ 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] Pole a sloupy VN - import LPIS
Já rozhodně netvrdím, že Tracer dělá něco špatně, Ve zdrovových datech je díra, tak ji natrasuje a přidá do OSM ...jestli tam má zůstat, žádný program asi spolehlivě rozhodnout nedokáže. Mě jde hlavně o to, jestli takové věci mazat při následné ruční editaci. Teď jsem kreslil právě nějaké vedení VN, rovnal jsem přitom topologii objektů (aby se třebe nepřekrývali různé landuse) a narazil jsem na tyhle ostrůvky v polích. Pokud panuje obecná schoda, že se mají zachovat, i když jsou to často nepřesné nebo neaktuální údaje, tak je mazat nebudu i když můj názor je jiný :-) 2015-06-30 11:14 GMT+02:00 Marián Kyral mky...@email.cz: Jak má Tracer poznat, jestli v té díře je sloup nebo něco jiného? Typicky křoví nebo stromy. Těch důvodů, proč to zemědělci objíždějí, může být více. Třeba vodojem, nějaká tyč značící, že tudy vede potrubí, trvale podmáčený terén, atd. Opravdu hodně záleží na tom, kdo to zakresluje. Díry zakreslené jeden rok můžou další zmizet (viděl jsem) a naopak. Marián -- Původní zpráva -- Od: Lukas Kabrt lu...@kabrt.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 30. 6. 2015 10:59:49 Předmět: Re: [Talk-cz] Pole a sloupy VN - import LPIS No s realitou si právě nejsem tak jistý ... když porovnám stav v OSM s ortofotomapou, tak mi připadá, že ty díry tam někdo kreslí podle momentální nálady. V místech, kde opravdu stojí jenom sloup uprostřed pole je v LPIS díra a naopak kolem sloupu bezmála malý lesík nebo velý osamocený strom uprostřed pole a v LPIS nic (http://prntscr.com/7n0z45, http://prntscr.com/7n0z45) Stejně tak tvar té díry nemá většinou s realitou nic moc společného, tvar spíš odpovídá tomu, jak bylo zrovna v době pořízení leteckých snímků pole posekané nebo jaký hodil zrovna sloup stín:-) Neměli bychom v takových připadech trochu generalizovat? Sloup = v mapě bod, ale je jasné že ve skutečnosti má nějaké reálné rozměry ... 2015-06-30 9:56 GMT+02:00 Ratt Snake rattsn...@gmail.com: Souhlasím, díry bych nechával, odráží to lépe realitu. Pavel Dne 30. června 2015 9:13 Marián Kyral mky...@email.cz napsal(a): Ahoj, je to různé. V LPIS někdy ty díry jsou, jindy ne. Asi záležím kdo to právě zakresloval. Jsem pro to je tam nechat. Kdybychom je tam nechtěli, tak jsem je mohli mazat už při importu a mohli jsme se vyhnout velké většině problémů, které způsobují relace ;-) Ono typicky kolem toho sloupu roste tráva nebo křoví. A to pole rozhodně není. Marián -- Původní zpráva -- Od: Lukas Kabrt lu...@kabrt.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 30. 6. 2015 9:04:24 Předmět: [Talk-cz] Pole a sloupy VN - import LPIS Při toulkách po mapě jsem si všimnul, že pravděpodobně po importu LPIS, se okolo sloupů VN často objevují maličké díry v polích. Např. http://www.openstreetmap.org/#map=19/50.50930/16.23577 Zajimálo by mě jaký je pohled ostatních na to, jestli se mají při editaci takové díry zachovávat. V naprosté většině případů, co jsem zkoumal je to opravdu jenom sloup (= bod) uprostřed pole, který by se neměl značit jako plocha. Podle mě je ideální postup nakreslit vedení VN, pokud není, a díry smazat. Jaký je pohled ostatních? ___ 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 ___ 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] Pole a sloupy VN - import LPIS
Při toulkách po mapě jsem si všimnul, že pravděpodobně po importu LPIS, se okolo sloupů VN často objevují maličké díry v polích. Např. http://www.openstreetmap.org/#map=19/50.50930/16.23577 Zajimálo by mě jaký je pohled ostatních na to, jestli se mají při editaci takové díry zachovávat. V naprosté většině případů, co jsem zkoumal je to opravdu jenom sloup (= bod) uprostřed pole, který by se neměl značit jako plocha. Podle mě je ideální postup nakreslit vedení VN, pokud není, a díry smazat. Jaký je pohled ostatních? ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import chráněných území z EEA
2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená hranice mezi CHKO Železné hory a Žďárské vrchy. (Námět pro ty, co se nudí: sloučení s cestami administrativních hranic na úsecích, které jsou totožné). Hranice CHKO a asi i dalších chráněných území (aspoň těch velkoplošných) jsou definované nejen pomocí administrativních hranic, ale i různými přírodními hranicemi - řeka, silnice apod. Průběh hranice je určený ve vyhlášce o zřízení daného chráněného území - příklad [1] IMHO nejčistší řešení by bylo chráněná do OSM přidat jako relace, kde členové té relace by byli objekty (silnice, řeky, administrativní hranice), tak jak jsou definované v příslušné vyhlášce. [1] old.ochranaprirody.cz/res/data/012/002287.pdf ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adresnich bodu - nova verze programu
Na adrese https://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0d=1 je nova verze programu pro import adresnich bodu. Opravy a upravy programu jsou opet z dilny Libora Pechacka. -- Lukas 2011/8/20 Lukas Kabrt lu...@kabrt.cz: Na adresu https://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0d=1 jsem umistil novou verzi programu pro import adresnich bodu merge-cuzk-db. Nova verze opravuje chybu, diky ktere obcas program vytvoril adresni bod mimo prislusne katastralni uzemi. Autorem opravy je Libor Pechacek, kteremu dekuji. Sam na rozvoj programu bohuzel nemam posleni dobou vubec cas. Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Import adresnich bodu - nova verze programu
Na adresu https://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0d=1 jsem umistil novou verzi programu pro import adresnich bodu merge-cuzk-db. Nova verze opravuje chybu, diky ktere obcas program vytvoril adresni bod mimo prislusne katastralni uzemi. Autorem opravy je Libor Pechacek, kteremu dekuji. Sam na rozvoj programu bohuzel nemam posleni dobou vubec cas. Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tisk mapy
Na Windows se daji bez problemu pouzit programy Kosmos [1] nebo jeho nastupce Maperitive [2]. Taky to ale obnasi vytoreni/upraveni stylu pro renderovani mapy. [1] http://wiki.openstreetmap.org/wiki/Kosmos [2] http://wiki.openstreetmap.org/wiki/Maperitive -- Lukas 2011/2/24 Zdeněk Pražák zpra...@seznam.cz: Bohužel však mám na počítači windows a navíc jsem pouze počítačový laik, takže s úpravami xml stylu a spouštěním skriptů mám problém Původní zpráva Od: Pavel Zbytovský m...@zby.cz Předmět: Re: [Talk-cz] tisk mapy Datum: 24.2.2011 01:39:04 Já bych postupoval asi tak, že bych upravil xml-styl pro mapnika, aby vykresloval jen katastrální území a potom spusti skript generate-image.py s příslušnou oblastí. Je to pěkně renderované do PDFka či do SVG (obojí lze ještě doupravit). Na linuxu je to v pohodě, bohužel na windowsech to může být trnité :) Pavel Zbytovský 2011/2/23 Zdeněk Pražák zpra...@seznam.cz chtěl jsem se zeptat, jak mám postupovat, když bych si chtěl vytisknout z osm dat mapu katastrálního území v předposledním stupni zoomu v mapniku. ___ 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod A04 = ditch
2011/2/20 Michal Grézl michal.gr...@openstreetmap.cz: Vsechny ditch co najdu mazu. Zase tak radikalni bych nebyl. Ale smazal bych ty waterway=ditch z importu, které nikdo od importu neupravil (Kdyz je nekdo upravil a nesmazal, tak predpokladam, ze tam neco takoveho skutecne bude). -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import adres pardubice
V bat souborech jsem nasel chybu ... chybi mezera pred -mappings, staci ji do bat souboru dopsat a uz to funguje. Neumim si to vysvetlit, jak to ze pro benesov tam ty mezery chybi a u ostatnich okresu je to spravne. -- Lukas Kabrt 2011/2/20 Zdeněk Pražák zpra...@seznam.cz: děkuji za radu, po přesunutí adresářů dle vzoru mi to funguje pro data z okresu Pardubice a jiných okresů. Když jsem však zkusil data z okresu Benešov, tak mi nefunguje vytváření dat z souborů s názvy _merge-název obce. V okně programu se napíše: output results-mappings _BENEŠOV.map a objeví se hláška program CUZK Merge přestal pracovat Pražák Původní zpráva Od: Lukas Kabrt lu...@kabrt.cz Předmět: Re: [Talk-cz] import adres pardubice Datum: 18.2.2011 16:56:15 Zkoušel jsem data pro Pardubice vygenerovat a mě funguje vše bez problémů. Zkuste se přesvědčit, jestli je jsou všechna data rozbalená ve správném adresáři. Složka s programem by měla vypadat následovně: - CUZK.Common.dll - GeoUtils.dll - merge-cuzk-db.exe - OSMUtils.dll - data - adresy.xml - kucr.osm - Pardubice - buildings.csv - HOLICE - __merge.bat - . - PARDUBICE - __merge.bat - .. - PĚLOUČ - __merge.bat - .. Lukáš Kábrt 2011/2/18 Zdeněk Pražák zpra...@seznam.cz: Chtěl jsem naimportovat adresní body okresu Pardubice, podle návodu na wiki Import adres jsem si stáhl požadované soubory a rozbalil je do adresáře data. Nyní nevím jak mám spustit soubor _merge.bat na vygenerování osm souborů.. Po poklepání na uvedený soubor mi krátce problikne okno a ihned se zase zavře. V adresáři pro data Pardubice nemám žádnou složku Results ___ 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 ___ 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] import adres pardubice
Zkoušel jsem data pro Pardubice vygenerovat a mě funguje vše bez problémů. Zkuste se přesvědčit, jestli je jsou všechna data rozbalená ve správném adresáři. Složka s programem by měla vypadat následovně: - CUZK.Common.dll - GeoUtils.dll - merge-cuzk-db.exe - OSMUtils.dll - data - adresy.xml - kucr.osm - Pardubice - buildings.csv - HOLICE - __merge.bat - . - PARDUBICE - __merge.bat - .. - PĚLOUČ - __merge.bat - .. Lukáš Kábrt 2011/2/18 Zdeněk Pražák zpra...@seznam.cz: Chtěl jsem naimportovat adresní body okresu Pardubice, podle návodu na wiki Import adres jsem si stáhl požadované soubory a rozbalil je do adresáře data. Nyní nevím jak mám spustit soubor _merge.bat na vygenerování osm souborů.. Po poklepání na uvedený soubor mi krátce problikne okno a ihned se zase zavře. V adresáři pro data Pardubice nemám žádnou složku Results ___ 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] Fwd: [OpenStreetMap] duplicate nodes
Tak ja jsem si chvilku hral a neco jsem si napsal. Zatim jsem to zkousel na malem kousku a vypada to dobre. Postup: nactu toky (waterway:stream) a nadrze (landuse: reservoir) najdu duplicitni body mezi toky a nadrzemi duplicitni body v tocich nahradim odpovidajicimi body z nadrzi puvodni duplicitni body z toku smazu Az mi skript dobehne na cele republice, tak nekam uploduju vysledek, kdyby se chtel nekdo podivat a zkontrolovat to predtim nez to uploduju. --- Lukas 2010/11/14 Petr Morávek [Xificurk] xific...@gmail.com: Jo, určitě... mě jen zajímalo jestli to někdo nemá zautomatizované. Na duplicitní cesty jsem si něco napsal, tak to použiuju na bažiny. Ale hledání duplicitních nodů takhle v místech dělení cest moc snadné není. honny napsal(a): Ve volných chvílích (v místech, kde zrovna něco mapuju) promazávám zdvojený objekty - mám v tom teda pokračovat? Nic automatickýho nemám. :) Já jen jestli v tom nedělám zmatek třeba. ~ honny ___ 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adresních bodů - Nekonzistenc e cuzk:km a mvcr:adresa
S tou verzi programu to muze byt ono ... ja pouzivam verzi z 27.2. a funguje mi to bez problemu. Protoze program nemam v SVN, tak uz nedohledam co se zmenilo. Kazdopadne aktualizoval jsem program na webu [1], nejakymi zmatky tam byla verze z 23. 2. [1] http://osm.kabrt.cz/home/adresy.zip?attredirects=0d=1 -- Lukas 2010/9/28 Petr Dlouhý petr.dlo...@email.cz: Ahoj, to může být příčinou části bodů s nekozistencí, ale ta chyba o které mluvím způsobí, že jsou nekonzistentní všechny body v dané obci. Navíc se odstraní tím, že udělám vlastní soubor adresy.xml, ve které je jen ta daná obec. On Tue, 28 Sep 2010 12:12:18 +0200, Jakub Sykora kub...@kbx.cz wrote: To by zrovna sedelo - v KU Cernosic je totiz treba takovy hezky priklad - Dolni Brezany-Lhota-Zalepy a Ohrobec-Karov a katastralni uzemi tam probiha klikate pres ulice :) -- Petr Dlouhý ___ 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] tema bakalarky
Jeden z dalších nápadů, který jsem zde kdysi nadhodil: Analýza záznamů z GPS s použitím OpenStreetMap ... Nechci si tady delat nejakou reklamu :-), ale na necem podobnem [1] jsem pracoval letos v ramci programu Google Summer of Code. Muj projekt byl zameren spise na analyzu casu potrebneho k projeti trasy (predevsim pro potreby routovani). Pokud by ale nekdo chtel, tak casti programu by se daly pouzit i v navrhovanem projektu. [1] http://wiki.openstreetmap.org/wiki/Routing/Travel_Time_Analysis Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres okresu Benešov
V JOSM si otevru okno se seznamem relaci (standartne Alt+Shift+R), dvakrat kliku na relaci, ona se vybere a pak kopirovat a vlozit. Takhle to jde po jedne relaci. Dalsi moznosti je vybrat hranice, ktere chci kopirovat, kliknout na hledat a vyhledat parent, tim se oznaci relace i s jejimi cleny. -- Lukas 2010/9/9 Zdeněk Pražák zpra...@seznam.cz: tak se pokouším pokračovat dále s adresními body Benešova a zase nevím jak dál Nevím jak z tebou dodaného souboru s hranicemi obcí pro okres Benešov vykopírovat relace pro příslušnou obec. Pokud si označím v JOSM v souboru kucr-croped.osm označím jednotlivé hranice stávajících katastrálních území a dám kopírovat tak po vložení do nové vrstvy neobsahují hranice kú informace o relacích Původní zpráva Od: Lukas Kabrt lu...@kabrt.cz Předmět: Re: [Talk-cz] Import adres okresu Benešov Datum: 06.9.2010 13:45:35 Neprirazene casti obci (zakomentovane na konci souboru) je potreba priradit ke katastralnim uzemim. Muze se stat (a casto se tak stane), ze domy v jednotlivych castech obce na jednom katastalnim uzemi maji stejna c.p., pak si ze souboru s hranicemi vykopiruju prisusnou obec a katastalni uzemi rozdelim na mensi casti podle casti obce, soubor ulozim a v BAT souboru zmenim kucr.osm na vytvoreny soubor. Pak znova vygeneruju soubory s adresami. Nazornejsi je asi priklad [1]. [1] http://sites.google.com/a/kabrt.cz/osm/home/adresy-priklad.zip?attredirects=0d=1 Lukas 2010/9/6 Zdeněk Pražák zpra...@seznam.cz: Začal jsem s importem adresních bodů z okresu Benešov. Podle návodu na wiki jsem si stáhl program merge-cuzk-db.exe, kucr.osm, databázi adres a data pro okres Benešov. Soubory kucr.osm, adresy.xml a data pro okes Benešov jsem rozbalil do adresáře Data, na OSM jsem poté nahrál OSM soubory ze složky results, vyřešil problémy v souborech *_fixme.osm a soubory nahrál rovněž na OSM. Nyní nevím jak mám pokračovat dál s úpravou souborů *._map a následnou generací příslušných osm souborů. Prosím o radu jako pokračvat dále. Děkuji, Pražák ___ 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 ___ 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] Import adres okresu Benešov
Neprirazene casti obci (zakomentovane na konci souboru) je potreba priradit ke katastralnim uzemim. Muze se stat (a casto se tak stane), ze domy v jednotlivych castech obce na jednom katastalnim uzemi maji stejna c.p., pak si ze souboru s hranicemi vykopiruju prisusnou obec a katastalni uzemi rozdelim na mensi casti podle casti obce, soubor ulozim a v BAT souboru zmenim kucr.osm na vytvoreny soubor. Pak znova vygeneruju soubory s adresami. Nazornejsi je asi priklad [1]. [1] http://sites.google.com/a/kabrt.cz/osm/home/adresy-priklad.zip?attredirects=0d=1 Lukas 2010/9/6 Zdeněk Pražák zpra...@seznam.cz: Začal jsem s importem adresních bodů z okresu Benešov. Podle návodu na wiki jsem si stáhl program merge-cuzk-db.exe, kucr.osm, databázi adres a data pro okres Benešov. Soubory kucr.osm, adresy.xml a data pro okes Benešov jsem rozbalil do adresáře Data, na OSM jsem poté nahrál OSM soubory ze složky results, vyřešil problémy v souborech *_fixme.osm a soubory nahrál rovněž na OSM. Nyní nevím jak mám pokračovat dál s úpravou souborů *._map a následnou generací příslušných osm souborů. Prosím o radu jako pokračvat dále. Děkuji, Pražák ___ 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] OpenTrackMap - Vrstva s neúplnými tr asami
Na http://opentrackmap.no-ip.org jsem přidal vrstvu Hiking Tracks Debug, která oranžově podkresluje turistické trasy s tagem complete=no. Super, to se mi libi, takhle je to mnohem prehlednejsi nez v tabulce na wiki. K tagovani turistickych tras bych mel jeden navrh - v datech bych explicitne uvadel zacatek a konec trasy (v terenu znaceno barevnym, bile oramovanym ctvereckem). Nejde o to, aby se to renderovalo nekde v mape, ale pomaha to pri editaci tras - ja pak jasne kde trasa opravu zacina a konci a kde je jenom nezmapovana. Ja osobne jsem zacal pouzivat tag kct_barva:end na bod, kde trasa konci. Ale slo by urcite vymyslet i jiny zpusob - treba koncovy bod pridat do relace trasy s roli end. Jaky zpusob byste preferovali? Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk] Comprehensive set of GPS track logs
On Sun, Jul 11, 2010 at 11:55 PM, john whelan jwhelan0...@gmail.com wrote: To clarify you are looking for GPS traces from car or vehicle traffic ideally in one city. Exactly. Tried a transit authority for their bus traces? That would give you plenty of data plus time of day traffic and consistency on routes and the GPS equipment used for the traces. I tried that with some public transport companies in the Czech republic, but they do not want to share their data. On Mon, Jul 12, 2010 at 12:03 AM, Komяpa m...@komzpa.net wrote: First, what I've seen are GPS traces near Baranovichi on OSM: http://osm.org/go/0k1rqeG - try loading those in josm. Second, you might want to ask user http://www.openstreetmap.org/user/doroga%20tv - they run a monitoring service, and have loaded lots of traces into OSM. Thanks, for the tips. On Mon, Jul 12, 2010 at 1:27 AM, Steve Bennett stevag...@gmail.com wrote: What do you mean by comprehensive? You mean, covering all of one person's movements during some period of time? Or do you just mean lots of? I need data that give overal view of traffic in some area. So basicly I mean lots of. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Comprehensive set of GPS track logs
Hi, I am student working on the GSoC project - Travel time analysis [1], [2]. For the final tuning and demonstration of the utility I am looking for a comprehensive set of GPS track logs. Requirements: Timestamped GPS tracks (if privacy is concern I can provide a utility that will delete unneccessary data - I am interested only in day of the week and time) Cover reasonable size area - big city, small part of the country Real world data - not from mapping parties etc. (these gps logs do not correspond with orinary vehicle behaviour) If someone can provide me such set or suggest me a place, where it can be obtained, it would be great help. Thanks, Lukas [1] http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2010/AcceptedProjects/TimeTravelAnalysis [2] http://wiki.openstreetmap.org/wiki/Routing/Travel_Time_Analysis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cz] Czechaddress a katastrální mapa jako zdroj
Na něčem podobném se pracovalo a stále ještě pracuje. Viz wiki. [1] a několik nechutně dlouhých vláken tady na talk-cz [2], [3]. V současné době je stav takový, že jsou vygenerována podkladová data pro jednotlivé okresy a postupně je zpracovávám. Pokud se chceš zapojit, tak pomoc je určitě vítaná. [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR [2] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004218.html [3] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004425.html -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Czechaddress a katastrální mapa jako zdroj
V tom případě bych se chtěl zeptat, v jakém stavu jsou okresy Prachatice, Žďár nad Sázavou nebo Brno-Venkov. Jednoho z nich bych se rád a ochotně ujal Data pro tyto okresy jsou pripravena ke zpracovani. Odkazy na potrebne soubory a postup je na wiki [1]. Pokud by byl nějaký problém, tak se ozvi, budu se snažit poradit. [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapa hustoty zástavby
Mozna by slo to prekryt/zkombinovat s mapou ukazujici hustotu poctu nodu v OSM a tak zjistit mista, kde sice je zastavba, ale moc dat v tech mistech neni - a tedy by to tam pak chtelo v tech mistech domapovat. Zajímavý nápad - zkusil jsem něco takového spáchat, posuďte sami, jestli to je použitelné. Hustota poctu nodu: http://sites.google.com/a/kabrt.cz/osm/hustota-zastavby/map-osm.png?attredirects=0 Složená mapa: http://sites.google.com/a/kabrt.cz/osm/hustota-zastavby/map-overlay.png?attredirects=0 (hustata zástavby bíle, hustota nodů červeně) -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
Následuje: nahrání relací (potřebuju dodělat NUTS2 relace) NUTS 2 (regiony) v datech jsou. Tak jak je to na wiki s admin_level=4. Nahrana data jsem si prohlizel a narazil jsem na jeden problem. Vsechny ways, na ktere jsou koukal existuji ve dvou duplikatech. Way je vzdy tvorena stejnymi uzly, ale existuje ve dvou exemplarich. Oba dva pritom pochazi ze stejneho changesetu. Napriklad [1] a [2]. Koukal jsem nahodne po cele republice a vsude to bylo stejne. [1] http://www.openstreetmap.org/browse/way/51638208 [2] http://www.openstreetmap.org/browse/way/51639256 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
Což to očekávám, ale jestli to bude jen na tu jednu cestu nebo to skončí úplně, dnes večer se uvidí Citace z wiki: Processing stops at the first error, so if there are multiple conflicts in one diff upload, only the first problem is reported. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
to uploadování najednou bude mít možná jedno úskalí, jelikož to trvá dlouho, budou se tam nějaký čas povalovat neotagované body. Na některé jsem teď narazil při kontrole rybníků, zajímalo by mě co se stane, když je někdo nezasvěcený smaže než se začnou uploadovat waye. Zalezi na tom, jak se to bude uplodovat. Pokud se to bude nahravat cele v jenodnom requestu - lze nastavit v JOSM-latest, tak se changeset bere jako atomicka operace a na serveru se objevi az cely. Pokud jsem to spravne vypozoroval ... -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
To jo, ale v jednom req lze tusim maximalne 50k bodu, takze toto tak poslat nelze, josm umoznuje posilat po definovanem poctu - napr po 10k a ve vysledku to bude ???jeden??? changeset. Changeset se neuzavre automaticky pokud klient komunikuje a pokud to spravne chapu, dokud neni uzavren, tak data z nej nikdo dalsi nevidi. Na wiki [1] je napspano, ze 50 000 je limit na changeset. Pri pouziti JOSM-stable se uploduje entita po entite (predpokladam, ze volanim /api/0.6/[node|way|relation]/create). Mam odzkouseno, ze v tomhle pripade, se data ostatnim uzivatelum zobrazuji postupne, tak jak jsou uplodovana na server. (Lze vyzkouset treba tak, ze spustite upload, otevrete si svuj profil na OSM, podivate se na svoje editace a uvidite jak postupne pribyvaji zmeny do changesetu, co uplodujete) Pri poiziti JOSM-latest a nastaveni vse v jednom requestu (predpokladam, ze se vola /api/0.6/changeset/#id/upload) se zmeny na serveru projevi az po nahrani celeho souboru. Pozor, changeset uzavren byt nemusi! (Opet to lze vyzkouset. Spustit upload, podivat se na svoje editace v profilu - change set se objevi az pote co JOSM dokonci upload souboru. To ale jeste driv nez JOSM changeset zavre - pravdepodobne ceka na odpoved ze serveru - nekdy i dost dlouho, pokud JOSM v tehle fazi schodite, tak zmeny uz zustanou na serveru) Jde o to, zda server changeset uzavre po 5 zmenach i kdyz se vse uploduje v jedno requestu. To se asi dozvime jedine tak, ze to zkusime. Jestli plati to co je na wiki, tak u 2. zpusobu je garantovano provedeni jako atomicka operace, takze nic neriskujeme. [1] http://wiki.openstreetmap.org/wiki/API_v0.6 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
Tak mam odzkouseno - 50 tis. je limit changesetu, vic ani tuk, A jak se to chova? Pokud se to uploduje v jednom requestu, tak to je to skutecne atomicka operace? Nebo to vezme prvnich 5 zmen a ty ulozi? takze uz nahravam po castech, ale jde to pomalu. Koukal jsem a drzim palce :-) -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
Mám jen bobky z toho, co to udělá při uploadu cest, pokud bude nějaký node chybět. Obavam se, ze neco ve smyslu HTTP status code 409 (Conflict) nebo HTTP status code 412 (Precondition Failed) viz. wiki [1]. [1] http://wiki.openstreetmap.org/wiki/API_v0.6 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
jeste resim subarea - ma cenu delat ke vsemu subarea? udelal bych navaznost CR-kraje-okresy, ale ma cenu pokracovat dale -obce-KU ? Tech udaju tam bude moc a bude to vubec k necemu? Ja bych byl pro pridat i obce a KU, at jsou vsechny hranice v hierarchickem usporadani. Vyuzit se to da - napr. pokud vyberu okres, tak muzu zadat ze chci vybrat potomky relace a vyberou se mi vsechny obce v okrese. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
relace: type=multipolygon, ovsem vsechny soucasne hranicni relace (a nejen nase) pouzivaji type=boundary To neni tak uplne pravda - vpostate vsechny hranice v Nemecku, Rakousku a Nizozemi jsou delane pomoci multipolygon. Proc jsem zvolil multipolygon jsem psal tady [1]. Pokud ale prevlada nazor, ze to ma byt boundary, tak se to klidne muze zmenit. chybi administrativni centra, pokud vim, (asi)kazde ku ma urcenou obec/cast ke ktere nalezi. Ano adminnistrativni centra byse mohli pridat, ale asi jenom pro relace obce, okres, kraj, CR. Administrativni centrum pro k.ú. je podle mě nesmysl. Jde o to kde vzít data. Pokud jsou už administrativní centra v mapě, tak asi nebude problém si najít na území které obce se admin. centrum nachází a zařadit ho do příslušné relace. nejsou definovany vztahy mezi ku (mineno potomci/rodice, napr stat obsahuje kraje, ty obsahuji okresy ...) Tady mam asi mezery, jak se to definuje? chtelo by to nejakou poznamku, zdroj je km, ale tohle by zaslouzilo jeste info ze jde o import/automaticke zpracovani ano, to by urcite chtelo. Jinak zdroj neni km, ale prehledky. A to mi pripomona ... jeste je potreba zmenit tag source na cuzk:prehledky, jak tady nekdo uz poznamenal. ways: je pouze tag boundary=administrative, ale IMO by tam mel byt jeste admin_level. To co jsem opsal od ostatnich = lv cesty odpovida nejmensimu cislu = nejvyssi urovni pro kterou je hranici. Takze ways hranice statu by mely mit 2 atd. Vim, ze ways maji prirazene i admin_level, ale nebyl jsem si jisty jak mam chapat admin_level=for the highest border co pisou na wiki [2]. Stejne ale nechapu, proc ways musi mit prirazeny admin_level, kdyz ten je definovan v relaci. Prijde mi jako blbost prirazovat admin_level ceste, kdyz je soucasti vice relaci s ruznymi admin_level. IMO by varianta A(kompletni upload) byla vhodnejsi, ... Taky si myslim, ze nahrat vse najednou je nejlepsi reseni [1] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html [2] http://wiki.openstreetmap.org/wiki/Relation:boundary -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
Viděl bych to tak, že to rozdělím po okresech a napíšu si prográmek, který dokáže oddělit duplicity. Při uploadu musím mít druhý prográmek, který dokáže vzít ID bodů a cest z OSM exportu a změnit je v jiném souboru - asi detekce shodnosti polohy bodů. Takhle to postupně naimportovat. Jak o tom tak uvažuju, tak nejlepší řešení se mi zdá to zkusit uplodovat celé najednou. Podle zkušenosti lidí co nahrávali části DIBAVODu, tak JOSM pošle data celkem rychle na server a pak čeká až si to server přežvýká a vrátí odpoveď (a to trvá mnohem déle) Pokud by spadlo připojení/JOSM potom, co se odeslali vsechna data, tak by to melo byt v pohode. Server transakci uzavre automaticky akorat se o tom klient nedozvi. Pokud je to jinak, tak me opravte. Pokud bys to chtel delit na vic kusu, tak misto detekce polohy se mi zda lepsi nasledujici postup: - kazde entite priradit jedinecne zaporne ID (znaci, ze se jedna o nový objekt) - tak uz to je v souboru kucr.osm - rozdelit mapu na vice casti (treba podle okresu) - zduplikuji se ways na hranicich (kazda way bude ve dvou souborech, ale bude mít stále svoje ID) - uplodovat cast, server jako odpoved vrati prirazena ID - v ostatních souborech změnit záporná ID za skutečná ID vrácená serverem - a tak porad dokola, uplodovat budeme ale pouze entity se záporným ID -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
To mají ale kvůli tomu, že mají často v hranicích díry, takže to dělají jako multipolygon. To my nemáme (nebo jo?), takže bych to radši předělal na boundary. Ale jinak z procesního hlediska je to jedno. Pár k.ú. s dírami je. Pak jsou desítky obcí kde je území nesouvislé. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
A ten soubor [1] je stále aktuální nebo existuje něco novějšího? Nejnovjější verze je na adrese [1]. Co v mapě je a není, co je zkontrolováno a kde ještě jsou nějaké nejasnosti jsem psal do prispevku [2] tady na foru. Já bych to nějak rozsekal, třeba podle okresů, protože stejně to bude chtít celé projít a zkontrolovat. Možná omezit počet bodů a udělat návaznost na hranice státu. Stávající hranice krajů bych smazal, protože co jsem koukal stejně nejsou moc přesné. Rozsekat to příliš nepůjde, protože ways tvořící hranice jsou společné pro více území. Respektive nepůjde nahrávání jednoduše distribuovat jako u DIBAVODU. Možné je mapu rozdělit na více částí, část vždy nahrát, pamatovat si jaká ID server jednotlivým objektům přiřadil a tyhle objekty znova neuplodovat. Ideální by bylo nahrát vše nejednou, ale nevím jestli je to technicky možné (jedná se o cca 1 milion bodů). Má někdo zkušenosti s tak velkým importem? Jak třeba probíhal import lesů? Takže pokud na tom nikdo nedělá, mohu se do toho pustit? Aktivitě se meze nekaldou :-) Rád kdyžtak pomůžu ... [1] http://osm.kabrt.cz/home/kucr.zip?attredirects=0d=1 [2] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
Melo by to jit, JOSM umi pri uploadu rict, ze bude changeset nahravat po castech a po jak velkych. Bude to ale trvat. Druha vec je, zda ze z toho JOSM neopupinkuje :D. Zkusim se na to mrknout. Mam vyzkouseno, ze JOSM ten soubor nacte. Pracovat se s tim sice moc neda, ale otevrit jde, tak by ho snad mohl zvladnou i poslat na server. Jde spis o to jak osetrit, kdyby spadlo spojeni, JOSM nebo pocitac pri uplodu. Jestli jde JSOM rict aby pokracoval, tam kde, prestal (nebo aspon logovat co uz je nahrano). Aby se nahodou nestalo, ze bude 50 duplicitnich nodu rozhazenych po CR ... -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 rozhasila některé věci se mi do toho ani moc nechce. Můžeš dát podrobnější návod, případně link na správnou verzi? Za .NET framework 4 se omlouvám, používám Beta verzi nového Visual Studia a ta má defaultně nastavené použití .NET frameworku 4, nějak jsem si to neuvědomil. Tady [1] program zkompilován pro verzi 3.5. [1] http://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0d=1 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Ve staženém souboru (Beroun) už jsou všechny výstupy udělané, proč je tedy třeba zprovozňovat program? Výstupy jsou udělané pro města, kde se podařil automaticky vytvořit *.map soubor. U dalších (název souboru začíná podtržítkem) je nějaká nejasnost v *.map souboru. Je potřeba map soubor upravit a vygenerovat osm soubory - proto je potřeba zprovoznit program. tam, kde jsou konflikty mi program spadne. Můžu se zeptat co vypíše za chybu? (spustit přes příkazový řádek, pak zůstane chyba na obrazovace) BTW, co ten import ktastrálních území? soubor existuje, proč není zároveň nahrán? Nahrán není, protože to ještě nikdo neudělal :-) A nahrávat ho současně s adresami mi nepřijde jako šťastný nápad - je nutné vyřešit konflikty s existujícími daty, napojení na existující relace apod. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Ahoj, par informací, co je nového ohledně importu adres. Znovu jsem provedl OCR s vylepšeným programem. Výsledek je na [1] Vylepšil jsem program merge-cuzk-db [2] - lepší detekce problémů (duplicity) - možnost zpracování více *.map souborů najednou - rychlejší zpracování osm a xml souborů (bez problémů lze používat soubor s hranicemi k.ú. pro celou ČR) - změna označení nekonzistentních dat (tag note místo tagu fixme) - podle toho co jsem koukal, tak fixme se používá pro závažnější pronlémy Na wiki [3] je pár bodů k nové verzi programu. Postupně tam budu přidávat odkazy na zip soubory s daty pro jednotlivé okresy (archiv obsahuje map soubory, soubor s polohami budov a výsledkem ocr, osm soubory pro obce, kde je předpoklad, že map soubor je správný). V současné době jsou na wiki odkazy na prvních 5 souborů. Pokud se někdo pustíte do importu, tak prosím data aspoň zběžně zkontrolujte - jestli jsem neudělal nějakou chyby, které jsem si nevšimnul. Víc očí, víc vidí :-) [1] lkabrt.aspone.cz/osm/cz.zip [2] http://osm.kabrt.cz/home/adresy.zip?attredirects=0d=1 [3] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR#P.C5.99ehled_import.C5.AF -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dotaz na stav importu z DIBAVOD
Uploduji soubory 006, 007, 008. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dotaz na stav importu z DIBAVOD
Ahoj, koukal na xml soubory z http://www.web2net.cz/osm/dibavod/ a nevim jestli je to chyba nebo umysl, ale nepozdavaji se mi tagy source tag k=source v=source=vuv:dibavod:a05 / neni v hodnote tagu 'source=' navic? -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
Prave toho jsem se bal, protoze zminenym hillshadingem to asi dost dobre nepujde a 90 metru je pro neco jinyho nez himalaje dost nepresny. Pokud si spravne pamatuju, tak tech 90 metru neni presnost nadmorske vysky, ale rozliseni v horizontalnim smeru. (Data jsou ulozena v rastru po 3 uhlovych sekundach a to odpovida cca 90 metrum na rovniku, u nas bude rozliseni v metrech lepsi) Jaka je presnost nadmorske vysky nevim. Vzhledem k tomu, ze SRTM data se pouzivaji treba v OpenTrackMap k vykreselni vrstenvic a ty docela sedi, tak to s tou presnosti bude docela dobre. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Ahoj, ja byl ted tyden pryc, proto jsem se do diskuze a reseni problemu nezapojil. Pokud spravne chapu situaci, tak problem je u c.e., ve kterych je cislice 2 se obcas stava a obcas se stava, ze se rozpozna jako 7. Jak jsem z diskuze pochopil, tak Honza Bilak napsal programek, ktery vezme celou dlazdici a provede OCR jinym zpusobem. Ja mam pripravene skripty na docisteni vysledku (slouceni dat z dlazdic, vymazani duplicit zpusobenych prekryvem dlazdic, vyfiltorvani bodu ktere neodpovidaji vzoru c.p., c.e., bez cp./c.e a jejich stazeni ve vyssim rozliseni a znovuprovedeni OCR - vyreseni prokryvajicich se napisu) Vysledky po stazeni detailu a znovuprovedeni OCR jsou celkem dobre. Na datech, co byla spocitana minuly tyden (cca 2/3 republiky) je po znovuprovedeni OCR jen 1050 adresnich bodu, ktere neodpovidaji zadanemu vzoru. Myslim, ze by bylo zbytecne zpracovavat celou CR znovu. Z dat si muzu vytahnout c.e., ktera obsahuji cislici 7, stahnout si detail ve vyssim rozliceni a ten misto terreractem zpracovat algoritmem od Honzy. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Mapa - k.u.,obce,okresy,kraje,regiony,cr
Konečně se mi podařilo dodělat mapu s hranicemi katastrálních území, obcí, okresů, krajů, regionů a ČR. Mapa je ke stažení na [1]. Na mapě je: 13027 katastrálních uzemí 6249 obcí 77 okresů 14 krajů 8 regionů (NUTS 2) 1 hranice ČR Informace o přiřazení k.ú. - obec - okres - kraj jsem čerpal z [3]. Na mapě je jeden problém o kterém vím: Obec Strýčice [4][5] je na strankách Českého statistického úřadu [6] uvedena jako samostatná obec. Mělo by to být jedeno z míst, kdy bylo více obcí na jedom k.ú. Někdo tady psal, že všechny takové případy už byly vyřešeny.Jak je to ve skutečnosti nevím. Každopádně na katastrální mapě (prehledky), není žádná hranice, tudíž nebylo podle čeho hranici obce nakreslit a proto Strýčice na mapě nejsou. Sporný může být okres na území Hlavního města Prahy. Pokud vím, tak nikdy takový okres neexistoval, přesto na mapě je, aby bylo území s admin_level=7 celistvé (V [6] je také takový okres uveden) Tagování: cesty tvořící hranice tag k='source' v='cuzk:km' / tag k='boundary' v='administrative' / relace reprezentující jednotlivá území tag k='ref' v='xxx' / xxx - identifikátor k.ú., obce (LAU2), okresu (LAU1), kraje (NUTS 3), regionu (NUTS 2), a státu (NUTS 1) tag k='admin_level' v='xxx' / xxx - admin level podle [2] tag k='source' v='cuzk' / tag k='name' v='xxx' / xxx - název tag k='type' v='multipolygon' / tag k='boundary' v='administrative' / K tagování mám několik poznámek / dotazů. Pokud cesty nemají tag admin_level, tak se hranice na mapě nezobrazí. Může mi to někdo potvrdit? Na wiki [7] je uvedeno, že cesta má mít admin_level=for the highest border. Mám to chápat tak, že nejvyšší číslo admin_level, nebo vyšší ve smyslu členění území (takže nejnižší admin_level). Stejně se mi ale nechce přiřazovat všem cestám tag admin_level. Je pro to nějaký rozumný důvod, proč tam musí být? Nestačí když je admin_level definován v relaci? Přijde mi to jako nesmysl přidávat ho každě cestě, když je ta cesta součástí více hranic s různým admin_level. Identifikátor obce LAU2 - na některých místech je jako identifikátor obce vedeno šestimístné číslo, na jiných místech je to samé číslo uvozeno identifikátorem okresu. Netušíte, která varianta je správná? type=multipolygon vs. type=boundary Pro označení hranic se používají oba dva způsoby. Type=multipolygon se používá z okolních zemí používá především v Německu, Rakousku. multipolygon + intuitivnější editace - uživatelé se inner/outer u multipolygon setkávají rozhodně častěji něž s enclave/exclave u boundary, takže je menší pravděpodobnost chyb při editaci + implikuje že se jedná o uzavřený polygon (i když se to při editaci nijak nevynucuje) boundary + je to doporučený způsob podle wiki (i když zastoupení multipolygon:boundary je prý stejné [8]) Na území ČR bude dost případů kdy je uzemí obce nesouvislé nebo se nějaké území nachází uvnitř jiného = použití inner/outer nebo enclave/exclave. Jedná se o 6 k.u., které jsou uvnitř jiného k.ú. a obce, jejichž území je nesouvislé (to nemám spočítané ale na malém kousku, který jsem kontroloval ručně jsem našel 2 takové obce - v celé ČR jich tak můžou být desítky) Já preferuju použití multipolygon, ale pokud se tady dohodneme na použití boundary, tak nemám problém to v mapě změnit. Jak jsem psal v sousedním vlákně, tak momentálně si hraju především s importem adres, takže nevím kdy se dostanu k uplodu mapy. Pokud se někdo chce zapojit a zapracovat na uplodu, tak má volné pole působnosti. [1] http://osm.kabrt.cz/home/kucr.zip?attredirects=0d=1 [2] http://wiki.openstreetmap.org/wiki/Key:admin_level#admin_level [3] http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-SC_SEZNAMKUKRA_DOTAZ [4] http://cs.wikipedia.org/wiki/Strýčice [5] http://www.openstreetmap.org/?lat=49.01027lon=14.26689zoom=15layers=B000FTF [6] http://registry.czso.cz/irso/cisdet.jsp?orgkodcis=43kodcis=43kod=536032z=1603191selvaz=52 [7] http://wiki.openstreetmap.org/wiki/Relation:boundary [8] http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] cíle práce a pár dalších dotaz ů
Taky se přidám s dotazem. Jaký je stav importů KÚ a hranic obcí? Má cenu je dělat ručně nebo se to bude v dohledné době importovat pro celou republiku? Mapa s k.u. je hotova, ted jsem do ni pridal i hranice obci [1]. Jeste to ma ale par musek. A jak se budou řešit ty hranice, které tam už jsou? Ty se smažou nebo se bude dělat nějaké merge? To se musi jeste dohodnout. Co se tyka katastralnich uzemi, tak asi zalezi na tom jak kde. jzvc, tady psal, ze k.u. v okoli teplic kreslil podle katastralni mapy, takze tam bude presnejsi, to co uz je v mape. Pak je v mape zakreslena praha (jak je to s presnosti nevim), par k.u. ve vychodnich cechach (kreslil jsem ja a presnost je vicemene orientacni) + par k.u. ruzne rozesetych po CR. Okresy a kraje na mape nekrere jsou, ale u vetsiny je poznamka nepresne, takze predpokladam, ze ty se mohou bez obav nahradit. Pridat hranice okresu a kraju nebude problem, to bych mohl do vikendu zvladnout. Co je potreba udelat potom: Doladit styl tagovani. Vymyslet import (hlavne slouceni dat a reseni konfliktu) Ja se toho klidne ujmu, ale momentalne me celkem vytezuje prace na importu adres, takze nevim kdy se k tomu dostanu. Jestli se nekdo chce realizovat, tak kazda pomoc je vitana. :-) [1] http://sites.google.com/a/kabrt.cz/osm/home/kucr.zip?attredirects=0d=1 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
uz jsem skoro dopracoval svoje davky, ale nastal maly problem. v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak resit, nebo uz si je zkusis udelat znova sam? Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho provedl. Resit to nijak nemusis, uz jsem si napsal skriptik, ktery projde logy a mista kde se vyskytnul error zpracuje znova. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map
Zkusím nastínit zjednodušeně algoritmus, jak to funguje (tedy jak jsem zamýšlel, třeba je tam chyba): a) napřed se floodfillem vyplní souvislá plocha, na kterou uživatel kliknul b) najde se vnější hranice - množina bodů c) najdou se tam významné/zlomové body d) zjednoduší se a naopak doplní chybějící body (sada různých postupů) Kdysi jsou zkousel napsat neco podobneho, ale moc dobre mi to nefungovalo. Postup byl zhruba stejny, takze koukam, asi jsem delal neco spatne :-) Jak na to lépe? Nějaké nápady? Pro predzpracovani mapy jsem pouzival binarni morfologii [1] a myslim, ze tahle cast docela fungovala. Koukal jsem jestli najdu zdrojaky myho traceru, ale uz zmizely v propadlisti dejin. Jediny co jsem nasel je knihovna pro binarni morfologii [2]. Nevim v jakem je stadiu pouzitelnosti, ale aspon pro inspiraci. Pokud jsi spravne pamatuju, tak jsem pouzival thinning na katastralni mapu a pak dilation nebo closing na vysledek floodfill. Zdrojáky: http://jabi.aspone.cz/osm/TracerPluginBeta2-src.zip http://jabi.aspone.cz/osm/TracerServerBeta2-src.zip Zdrojáky toho pluginu jsou dost hrozné ... a potřebují větší refaktorizaci. U toho serveru je to lepší, ale také by to řadu úprav potřebovalo (včetně rozdělení do metod apod.). Takže to berte jako předzveřejnění pro silné povahy :) Zkousel jsem stahovat zdrojaky serveru a dostavam 404 Not Found, muzes se na to prosim podivat? Docela rad bych si zdrojove kody prohlidnul. [1] http://homepages.inf.ed.ac.uk/rbf/HIPR2/morops.htm [2] http://osm.kabrt.cz/home/morphology.zip?attredirects=0d=1 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
přemýšlel jsem o tom, jestli by nešel vyrobit i skript, co projde všechny adresní body, které nevyhovují vzoru č.e./č.p./bez č.e./č.p a zpracoval je znovu s vyšším rozlišením. Koukal jsem kolika pripadu by se to tykalo a pokud za spravne rozpoznane budeme povazovat i ruzne varianty (ce, c.e, ce., apod.) tak to odhaduju na cca 200 000 pripadu. To by se asi dalo zvladnout. Schvalne zkusim neco vytvorit ... -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
2010/1/27 Petr Dlouhý petr.dlo...@email.cz: Má někdo nápad, jak by to šlo jednoduše obejít? Vyzkousel jsem pouziti tiffcp jak navrhoval Jan Bilak. Na WIN mi to funguje bez problemu. Stahovat muzete opet z mych stranek [1]. Je to o neco pomalejsi, nez kdyz mutli-page tiff vytvarim primo v tile-processor, ale pokud to bude fungovat na LINUXU, tak je to prijatelna obet. Porad je to totiz rychlejsi, nez puvodni verze. [1] http://lkabrt.aspone.cz/osm/cuzk-test.zip -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Je to tak? Pokud ano, tak by to chtělo uživatele důrazně varovat, protože by se mohlo stát, že výsledek bude pomíchaný a nikdo si toho nevšimne. Nešlo by s tím něco udělat? Ne, uz to tak neni, jen jsem to zapomnel zapsat do provedenych zmen. Program si uklada pomocne soubory stale do aktualniho adresare, ale pod unikatnim jmenem (GUID), takze bez problemu muze bezet vice instanci v jednom adresari. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Seznam katastralnich uzemi s umistenim
Proč ne ref? Dá se snad využít nějak jinak? To bude asi ten spravny atribut. Řekl bych, že všechna území, která v mapě jsou (možná s výjimkou hranic s Německem) jsou méně přesná, a je tedy je možné smazat (pokud tedy nejsou nějak vázána na další objekty). Možná by ale bylo dobré zkopírovat otagování (možná tam jsou nějaké mezinárodní názvy a podobné věci). Nebo někdo ve větší míře kreslil podle katastrální mapy (je podrobnější než přehledky). Tak nejak si to taky predstavuju, automatizovat takovy postup bude ale asi docela orisek. Existuje jich víc? Je to jediný případ, který znám. Nasel jsem jich celkem sest: Josefov Kajlovec Jevíčko-město Opava-Město Úsov-Židovská obec Svitavy-město -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Provedl jsem par zmen v programu tile-processor, binarky [1] i zdrojove kody [2] muzete stahovat z mych stranek. Hlavni zmeny: rychlost - OCR utitlita se ted spousti pouze jednou pro kazdou dlazdici - prineslo to cca dvojnasobnou rychlost zpracovani drobne zvyseni presnosti - presnejsi orez popisku a vynechani budov blizko praveho okraje (tak jak navrhoval Petr Dlouhy) pridano logovani cinnosti osetreni chyb - program by se ted mel byt schopny zotavit z vetsiny chyb, pouze zaloguje co se stalo a pokracuje v cinnosti V binarkach jsou dve verze tile processoru - jedna pro LINUX s upravou od Petra Dlouheho ([3], bod 2), druha bez ni. Nechal jsem dve verze, protoze u me verze s upravou dava o neco horsi vysledky pri OCR (cca o 1 - 2% vice chyb) Progam jsem zkousel na platforme Win/.NET a Win/MONO a funguji bez problemu. Nekoho bych poprosil aby vyzkousel jestli neni nejaky problem na Linuxu. Distribuovane pocitani Diky vsem, kteri se ozvali a nabidli se, ze pomuzou s vypoctem. Rozdelil jsem CR na dlazdice 0.2 x 0.2 stupne, celkem je to 302 dlazdic. Hranice jsou definovany v CSV souboru [4], prilozena je i prehledova mapka. Zpracovani jedne dlazdice by se melo vejit do 1 hodiny. CSV soubor ma nasledujici format ID,sever,vychod,jih,zapad Pro koordinaci jsem na wiki zalozil stranku [5]. Pokud se rozhodnete pomoct, zapiste na wiki, jake dlazdice zpracujete - at se neco nepocita vicekrat. Dlazdice prosim vybirejte postupne, at v tom neni zmatek. Moje idea dalsiho postupu je takova, ze vysledky vypoctu (CSV a LOG soubory) zpracuju, pripadne opravim data na mistech, kde se vyskytnul nejaky error a vysledek umistim nekde na web k dalsimu vyuziti pro import adres. Postup 1) na wiki napsat dlazdice, ktere se chystam zpracovat 2) ze souboru [4] zjistit hranice dlazdic 3) stahnout data z WMS CUZK tile-downloader.exe -north [sever] -west [zapad] -south [jih] -east [vychos] -addressPoints -output [ID-Dlazdice] 4) zpracovat dlazdici tile-processor.exe -tiles [ID-Dlazdice] - output [ID-Dlazdice].csv 5) zabalit vytvorene soubory (CSV a LOG) a vysledek nekam uplodovat nebo zaslat na mail o...@kabrt.cz [1] http://lkabrt.aspone.cz/osm/cuzk.zip [2] http://lkabrt.aspone.cz/osm/cuzk-source.zip [3] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004312.html [4] http://lkabrt.aspone.cz/osm/oblasti.zip [5] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR/Prubeh_Zpracovani -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Tomu moc nerozumím, můj postup byl takový, že jsem vyříznul z dlaždice číslo (což by měla být bezestrátová konverze) a potom jsem to zvětšil (což by měla být stejná konverze jako předtím. Postup by mohl být nepatrně náročnější na výpočetní výkon, ale výsledek by snad měl být stejný, ne? Leda že by tam došlo k nějaké ztrátě při převodu mezi různými počty barev - to by šlo asi eliminovat. To mas pravdu, asi jsem blbe identifikoval pricinu. Pravy duvod je asi ten, ze ty jsi vyrezy zvetsoval 3x a ja jen 2x. Tesseract si to potom pravdepodobne prebere trochu jinak. Pravdou je, ze obcas lepe zafunguje ta upravena verze. Kdyz to porovnam u nejakeho vetsiho souboru dat, tak to vychazi priblezne 1 az 2% v neprospech upravene verze. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
nebylo by lepší ukládat a přibalit potom k výsledku i kousky mapy s těmi čísly? Zrychlila by se ruční kontrola, zda to OCR rozpoznal správně. Aneb bylo by možné pak jednoduše třeba zobrazit číslo v textové podobě a vedle číslo v obrázkové podobě. A stejně už se to stahuje, ořezává, ... jen to ukládat. Technicky to neni zadny problem, ale moc se mi to nelibi 1) Je to spousta dat 2) Kontorlovat se to da dobre v JOSM (nebo v jinem editoru), vcetne doplneni prislusnych addr tagu 3) Stejne vetsina spatne rozpoznanych popisku jsou budovy bez c.p./c.e., jako treba garaze nahustene vedle sebe - v editoru pak jednim pohledem a par kliknutima vyresim treba 30 spatne rozpoznanych napisu najednou -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
2010/1/26 Jiri Parkan jpar...@gmail.com: Při zkusmém zpracování oblasti 4 se zdá že mi nějak nefunguje rozpoznávání. Výsledný csv je prázdný a v logu errory podobné tomuto: [ERROR] Tile: 4\14.8270_50.8700_14.8320_50.8750-budovy.png Could not find file 'E:\cuzk\5d8577a6-a71a-454b-9785-354a446ef9d5.tif.txt'.; přitom stažené obrázky jsou v pořádku, tile processor se tváří že také něco dělá: Performing OCR (25 labels): .Processing tile: 15.0250_51.0185_15.0300_51.0235-budovy .. Performing OCR (4 labels): .Processing tile: 15.0250_51.0230_15.0300_51.0280-budovy . Processing tile: 15.0250_51.0275_15.0300_51.0325-budovy To vypada, ze nefunguje OCR utilita, muzes vyzkouset spustit rucne? tesseract jmeno_jednoho_z_tech_tifu output.txt -l cuzk -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Seznam katastralnich uzemi s umistenim
Nazvy jsem zakomponoval do mapy k.u. [1] Na mape je celkem 13036 relaci, nazvy ma prirazeno 13027 relaci. Zbylych 9 relaci predstavuje oblasti, ktere budou prisluset k nekteremu ze sousednich k.u., na mape jsou ale hranice tak blizko sebe, ze tvori jednu caru a nejde poznat, kam oblast patri (priklad [2], v JOSM otevrit a zobrazit prehledku z WMS CUZK). Nechtel jsem vylozene hadat, kam oblast patri, takze jsem je nechal v mape s oznacenim: FIXME - Nejasna prislusnost ke k.u. Treba se najde nekdo, kdo dane misto zna a napovi ... Struktura dat cesty, ktere tvori relace - bez oznaceni, nevim mam kazde ceste pridat tag border: administrative? relace name - nazev katastralniho uzemi ku:id - cislo katastralniho uzemi, nejaky lepsi napad? Presnost dat mam zkontolovano, ze vsechny k.u. jsou na mape, kazdemu je prirazena prave jedna relace a nejsou tam zadne duplicity. Nekolik oblasti jsem kontroloval rucne a zadne chyby jsem nenasel, to neznamená, že nikde žádná chyba nebude (mohlo by se stát, že 2 k.u. budou prohozene). Pokud na nějaký problém narazíte, tak se ozvěte. Pro ucely rozpoznavani adres je tahle mapa vice nez dostatecna, pro upload na server to bude chtit jeste par veci vymyslet / dodelat. Priradit 9 oblasti oznacenych FIXME ke spravnym k.u. Do mapy zadat hranice obci, okresu, kraju a CR (pokud vim tak vsechny tyto hranice vychazeji z hranic k.u.) Vyresit jak sloucit mapu na serveru s mapou k.u. Zauvazovat nad tim jestli mapu trochu nezjednodusit (nyni ma neco malo pres 100 nodu a na nekterych mistech sleduje kazdy zahyb kazdeho potucku) Rozhodnout jak spravne oznacit k.u., ktere je cele uvnitr jineho k.u. (priklad - Josefov a Stare Mesto v Praze)? [1] http://lkabrt.aspone.cz/osm/kucr.zip [2] http://www.openstreetmap.org/?lat=49.30819lon=16.67873zoom=15layers=B000FTF --- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Soubor cr.map pro import adres
vygeneroval jsem soubor cr.map [2] obsahující mapování pro program merge-cuzk-db. Soubor je jednoduše vygenerován z ulic MVČR [1], takže trpí některými zásadními nedostatky: Diky, urcite to hodne pomuze. 1) V MVČR se bohužel vykašlali na velikost písmen a napsali všechno velkýma. V souboru je vždy první písmeno velké a ostatní malá. Je tedy nutné upravit názvy podle pravopisu. S velikosti pismen v souboru *.map si neni potreba lamat hlavu. Nazvy stejne beru z datatabaze MVCR a velikost pismen upravuju podobnym algoritmem, jaky je pouzit v pluginu czechaddress. Proc? Protoze z databaze se berou nazvy ulic a i ty jsou vsechny velkyma pismenema. Tak jsem vzal z databaze vse. Vysledek sice v nekterych pripadech neni podle pravidel ceskeho pravopisu, ale postupne na tom pracuju - kdyz narazim na nejakou chybu, tak se ji snazim do algoritmu zakomponovat. Mozna by stalo za uvahu, zda nazvy mest / mestskych casti nebrat ze souboru *.map, kde je mozne velikost pismen upravit rucne. 2) Nepodařilo se mi najít žádný klíč, podle kterého by bylo možné spojit databáze MVČR a CUZK. Do parametru name elementu territory jsem tedy doplnil jméno oblasti. Je tedy nutné doplnit tam u něčeho, pokud se jméno katastrálního území liší. Klic by mohl byt tady [1], nevim ale jak je to s licenci. Je tam prirazeni k.u. - obec, sice uz ne k.u. mestska cast, ale ve vetsine pripadu se ty nazvy podobaji, takze by to mohlo jit odhadnout. 3) Program merge-cuzk-db nezvládá pokud jsou v .map souboru nějaká území navíc oproti .osm souboru katastrálních území. Je tedy nutné před použitím zakomentovat vše kromě těch území, pro která se budou adresy přiřazovat. Pisu si do TODO listu. Udelam to tak, ze program zarve, ale nespadne. Osobne to stejne delam tak, ze merge pouztim pouze na par k.u. najednou, lip se tim pak pracuje v JOSM, je to prehlednejsi. [1] http://www.cuzk.cz/Dokument.aspx?PRARESKOD=10MENUID=10015AKCE=DOC:10-CISE_KUAP -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to nezkoumal. Urcite funguje i bez DB. pouzivam vyvojovou verzi 0.33 [1] a funguje bez problemu. Musel jsem ale pouzit soubor osmosis.bat z predchozi verze a dopnit do promenne EXEC pridat chybejci knihovnu commons-compress-1.0.jar [1] http://dev.openstreetmap.de:23457/hudson/job/osmosis-SNAPSHOT-ant/lastSuccessfulBuild/artifact/trunk/dist/ -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Co se týče skriptů, tak myslím, že je třeba se vydat jinou cestou. Pokud to jde alespoň trochu jednoduše udělat, tak by ten skript měl dokázat pracovat s celou mapou katastrálních území. Problem to neni. Kdyz jsem program vytvarel, tak jsem nevedel o tom, ze existuje vektorizovana mapa k.u. a tak jsem k.u. kreslil rucne. Vzdycky jen par k.u., ktere jsem chtel zpracovat. Takze me rychlost zpracovani OSM souboru nejak netrapila. Na vektorizovanou mapu jsem narazil az kdyz jsem mel program hotovy a jeste jsem se nedostal k tomu ho predelat - dalsi polozka do TODO listu :-) Koukal jsem, ze by sla pouzit knihovna pro praci s OSM soubory z programu Kosmos [1], takze s tim nakonec asi ani nebude tolik prace. [1] http://wiki.openstreetmap.org/wiki/Kosmos -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Pardon, myslel jsem dní. On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouhý petr.dlo...@email.cz wrote: (mé velmi hrubé odhady se pohybují od 50 do 100 hodin jenom pro 2. fázi). Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to pesimisticky odhad. Podle toho, jak rychle probiha vypocet u me, bych to odhadnul na 30 - 50 dni. Limitujici je tady rychlost procesoru. Nedavno jsem zkousel oblast cca 20 x 25 km a rozpoznavani bezelo neco pres 5 hodin. Muj pocitac pritom neni zadne delo - Intel Core2 Duo @ 2Ghz. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
V kroku 3 (vytvoreni XML souboru, ktery definuje prirazeni mezi katastralnim uzemim a obci / casti obce z databaze adresnich bodu) jsem převzal XML z dokumentace. A k tomu se váže první dotaz. Kde berete tyto informace? A k čemu je to dobré? Upozorňuji, že nejsem zaměměřič, ale programátor, takže o struktuře území toho moc nevím, i když jsem k této oblasti trochu přičichnul. Moje představa je, že čísla domů jsou jedinečná v části obce (proto např. v nahlížení do KN říkám obec, část obce, číslo budovy). Proto je třeba nějak určit část obce, do které dané území patří. Presne tak. číselníky částí obcí a jejich vztahy k obcím, okresům, krajům apod. jsou na Českém Statistikém Úřadě. Ale nevím, zda je lze z licenčních důvodů použít (ví to někdo?). Ruční vytváření XML pro každé katastrální území, kterých jsou tisíce(?) je poněkud nepraktické a hlavně hrozí chyby. Ano je to trochu neprakticke. Asi by to slo castecne automatizovat. Muj postup je, ze si z databaze [1] vytahnu stukturu oblast - obec - cast a z mapy nazvy k. u. a rucne prirazuju, vestinou je to jasne (zatim stejne delam v mistech, ktere jakz takz znam). Prirazeni k.u. - obec lze nalezt na strankach CUZK [2]. Jak je to s licenci nevim. Problemy jsou ale s nekterymi castmi obci - na jednom k.u. muze byt vice casti obce. kterých jsou tisíce(?) Presne 13027. A pak je třeba udělat merge. Odkud pochází databáze adres? To je UIR-ADR? Z jakého původního zdroje pocházejí hranice katastrálních území? Adresy pochazeni z webu MVCR [1], hranice k.u. ktere mam na strankach jsou vektorizovane mapy CUZK - vektorizaci delal hanoj [3], a Martin Kupec pracuje na OCR nazvu k.u., vysledek na mych strankach jeste neni hotovy, chybi jeste cca 800 nazvu. A co vlastně merge dělá? Moje představa je, že pro každý adresní bod z toho CSV souboru vygenerovaném v jednom z předchozích kroků najde katastrální území, jehož hranice je v souboru daném parametrem territories. Merge vezme CSV soubor se souradnicemi budov a rozpoznanym popiskem, najde k.u., ve kterem se budova nachazi, podiva se do souboru *.map jaka obec, mestska cast se na k.u. nachazi a podle toho se budove pokusi priradit adresu z databaze MVCR. U druhého parametru nevím. Zkoušel jsem http://osm.templ.net/kucr.osm.bz2 ten urcite fungovat nebude, tam nejsou nazvy k.u. http://lkabrt.aspone.cz/osm/kucr.zip. ten muzes pouzit, ale je potreba zkotrolovat, jestli tam je zadany to k.u. o ktery se zajimas - nazvy jeste nejsou kompletni. Čtvrtý parametr - to je to XML převzaté pro pokus z dokumentace. priklad z dokumentace mozna nebude kompatiblni s mapu z http://lkabrt.aspone.cz/osm/kucr.zip. Koukam, ze je to jeste z doby, kdy jsem mapu zkousel malovat jen tak priblizne rucne, jen pro ucely tohohle programu takze asi nesedi nazvy. 2) V případě použití http://lkabrt.aspone.cz/osm/kucr.zip program vytíží jedno jádro procesoru a nic ... tedy nechal jsem to pár desítek minut (nebo mám čekat déle?). Poslední hláška je, že Loading territories borders... Pro parsovani XML pouzivam XML.LINQ, a ten neni delany na zpracovani tak velkych souboru, proto si ze souboru kucr.zip vyriznu cast se kterou chci pracovat [4]. S parsovanim XML dokumentu mozna neco udelam, fakt to neni nejrychlejsi. XML.Linq ma ale tu vyhodu, ze se s tim hezky pracuje, takze jsem ho pouzil pri vyvoji. Další věc je, že ten XML soubor z kroku 2 definuje vztahy pomocí názvů. Ale ty myslím nejsou jednoznačné. Přitom číselníky katastru i Stat. úřadu používají pro označení obce, části obce, katastr. území apod. také nějaká číselná IDčka (kupodivu dokonce stejná). Jmena k.u. jsou jedinecna, stejne tak kombinace oblast-obec-cast z databaze. [1] http://aplikace.mvcr.cz/adresa/adresy.zip [2] http://www.cuzk.cz/Dokument.aspx?PRARESKOD=10MENUID=10015AKCE=DOC:10-CISE_KUAP [3] http://lists.openstreetmap.org/pipermail/talk-cz/2009-June/003204.html [4] http://lists.openstreetmap.org/pipermail/talk-cz/2010-January/004310.html -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Ahoj, povedlo se mi zprovoznit kompilaci pod Monodevelop, takže si už můžu program upravit sám (chtěl bych tam přidat podporu pro nativní Linuxový Tesseract, což bude ten hlavní problém proč to nechodí jinak, než pod Wine). Pošli mi prosím tedy aspoň zdrojáky, ve kterých nepoužíváš knihovnu AForge. Ahoj, updatoval jsem zdrojaky [1] i zkompilovane soubory [2] u me na strankach, tak muzes stahovat. [1] http://lkabrt.aspone.cz/osm/cuzk-source.zip [2] http://lkabrt.aspone.cz/osm/cuzk.zip -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
měl bych k tomu ryze praktický dotaz. Jakým způsobem z téhle mapy nejsnáze vyříznout oblast která mě zajímá? Při načtení do JOSM se s takhle velou mapou nedá rozumně pracovat, každou akci provází minimálně několikaminutové čekání. Jedna moznost je v JOSM si cast zkopirovat do nove vrstvy a pak pracovat s ni. Chvili to trva, ale jednou se to da prezit. Dalsi moznost je pouzit osmosis [1]. Prikaz pro orez bude neco jako osmosis --read-xml file=test.osm --sort-0.6 --bounding-box top=50.69 left=15.76 bottom=50.27 right=16.5 clipIncompleteEntities=true --write-xml file=result.osm Nekdo me treba doplni s dalsimi moznostmi. [1] http://wiki.openstreetmap.org/wiki/Osmosis -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy - prvni dojmy
1) Pokud ma tile-downloader prohozeny nort south nebo east west, skonci aniz by cokoli sdelil, je treba kontrolovat Ano vim o tom, ze tam jsou podobne neosetrene vstupy. Pokud nekde ma byt cislo, tak program prdpoklada ze tam to cislo je, pozor si je potreba davat treba pri tovrbe *.map souboru, aby vsechny definovana k.u. byli meli zakreslene kranice apod. Kdyz se stane ze vstup je spatne, tak program tise umre :-) (pokud je spusteny pres prikazovy radek, tak si muzes prohlednou vyjimku, kterou vypise - ta muze napovedet, co je spatne). Delat program blbuvzdorny se mi moc nechce, je to umorna prace, a tohle je v podstate jednorazova utilita. Svuj cas si myslim, ze muzu vyuzit lip. 2) Tile-procesor zhusta nepozna 6 (sestku) a zamenuje ji za 8 (ten font neni zrovna OCR ready rekl bych) - vic nez polovina neprirazenych adres pada tomuhle za obet Muzes vyzkouset vezri, ktera pouziva starsi OCR utilitu [1]. Na nekterych pocitacich ale nefunguje a nepodarilo se mi prijit na to proc, tak jsem ji puvodne ani nechtel davat ke stazeni. Vysledky jsou presnejsi, protoze je natrenovana primo na pismo z katastralnich map. [1] http://lkabrt.aspone.cz/osm/cuzk-tile-processor-old.zip -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u. nemuseli kreslit rucne. Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani prerusenych linii) a vytvoril na ni relace pro jednotliva k.u. Mapu jsem dal dohromady s daty co mi poslal Martin Kupec (nazvy katastralnich uzemi a jejich poloha). Vysledek je ke stazeni tady [2]. Trocha statistiky: CR ma 13027 k.u. Martin mi poslal data pro 12171 k.u. Mapa ma definovano 13028 relaci Mapa je jenom prozatmni, pri prirazeni se vyskytly nejake chyby (vic nazvu pro jedno k.u., jedna se ale o jednotky, max. desitky pripadu) To bych resil az budou hotova data pro vsechy k.u. Stejne tak je v mape 1 relace navic - pravdepodobne nekde zustal nejaky fragment, ten se taky objevi, az se priradi vsechny nazvy. Pokud se nekdo pousti do importu adres, tak mu tohle snad usetri trochu casu. [1] http://osm.templ.net/kucr.osm.bz2 [2] http://lkabrt.aspone.cz/osm/kucr.zip ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Což ani nevypadá, že by byl problém s Monem. Co má být v souboru label.txt? Když ten soubor vytvořím a vložím tam nějaké znaky, tak to začne vypisovat: Program pracuje tak, ze vezme dlaždici, najde na ní definicni body budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku tmp.bmp a potom ho rozpozna exetnim OCR programem (tesseract.exe). Ten ulozi rozpoznany text prave do souboru label.txt Proc program nefunguje, kdyz soubor label.txt pred spustenim neexistuje je mi zahadou. Podle vystupu output.csv co jsi posilal, tak rozpoznavani evidentne funguje ... chtěl bych se zeptat, jak tvůj program řeší ořez čísel na okrajích stažených dlaždic. Ptám se pro jistotu, aby nevznikly zbytečné chyby. dlazdice se prekryvaji o 5% na kazde strane, takze temer jiste, ze alespon na jedne dlazdici je text cely. Tile-processor vysledky nijak nezpracovava, pouze ulozi polohu bodu a jemu prislusejici text. V dalsim kroku, pri prirazovani adres jednotlivym bodum se nesmyslene rozpoznany text vyfiltruje. přes Wine to funguje, ale výsledek není ještě pořád ideální. Spočítaná poloha jednotlivých bodů totiž nedává úplně smysl - občas je tam NaN, občas čísla, mimo rozmezí daného BBOX, občas čísla větší než 10. Nemůže být zase problém s desetinou tečkou/čárkou? Moje chyba. Tile-downloader ukladal dlazdice se spatny jmenem (opet carka / tecka). Oprava opet na [1]. Pokud mas nejake dlazdice stazene, tak staci carky v nazvech souboru nahradit za tecky. V příloze posílám výstup z programu, a zkrácený výpis programu. Wine rád vypisuje velké množství chyb, takže některých údajů ve výpisu si není třeba všímat. Ty errory to vypisuje i na WIN, jedna se o nejaky problem v tesseract.exe, na strankach maji k tomu vytvoreny ticket, s tim ze program ale funguje spravne. [1] http://lkabrt.aspone.cz/osm/cuzk.zip -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Muzu se zeptat, zda pouzivate nejak upraveny/nauceny tesseract na ceske znaky, nebo to cestinu uspesne neumi? Pro verzi 3.0 uz existuje i cestina. Verze 3.0 je v stadiu prerelease, nejsou pro ni binarky a tak je potreba si stahnou zdrojove kody [1] a zkompilovat. Soubor pro cestinu je v adresari tessdata tamtez (ces.traineddata). Nebude ale zpetne kompatibilni s tesseract 2.04. Puvodne jsem pozival verzi 2.04 ale tam jsem narazil na nejake problemy na starsich pocitacich s WinXP. Pro verzi 2.04 jsem mel vytvoreny vlastni jazyk, kde byly definovany pouze znaky ktere se vyskytuji na katastralni mape - bezčpe. 0123456789. Uspesnost rozpoznavani byla o neco lepsi nez ted s celou abecedou, ale to se da celkem dobre vykonpenzovat postprocesingem - stejne zamenuje porad stejne znaky jako o/0, ./_ apod. Chtel jsem si vytvorit vlastni jazyk i pro verzi 3.0 ale nenasel jsem k tomu zadny nastroj. [1] http://tesseract-ocr.googlecode.com/svn/trunk/ -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Omlouvam se za problem. Nejak jsem si neuvedomil, ze mam na pocitaci anglice prostredi a tudiz desetinny oddelovac .. Program jsem upravil a ted by mel fungovat spravne, stahovat muzete opet na [1] [1] http://lkabrt.aspone.cz/osm/cuzk.zip Lukas 2010/1/19 Jiri Parkan jpar...@gmail.com: Totéž u mě pod windows, chtěl jsem to zítra zkoumat, ale vidím že to nebude jen můj problém. 2010/1/19 Petr Dlouhý petr.dlo...@email.cz: Ahoj, zkoušel jsem tvůj skript, a narazil jsem na problém s tile-downloaderem. Pouštím program na Linuxu pod Monem (2.4.2.3), a místo stáhnutých obrázků je v těch souborech následující text(def_body i kn, zkoušel jsem i příklad z tvého návodu): ?xml version='1.0' encoding=ISO-8859-1 standalone=no ? !DOCTYPE ServiceExceptionReport SYSTEM http://schemas.opengeospatial.net/wms/1.1.1/exception_1_1_1.dtd; ServiceExceptionReport version=1.1.1 ServiceException msWMSLoadGetMapParams(): WMS server error. Wrong number of arguments for BBOX. /ServiceException /ServiceExceptionReport Chci se tedy zeptat, jestli nevíš zdali je problém způsobený Monem, jestli je to nějaký momentální problém těch serverů, nebo čím to tedy je. On Mon, 18 Jan 2010 01:13:35 +0100, Lukas Kabrt lu...@kabrt.cz wrote: Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne. Martin Kupec Dalsi faze bude sehnat si od hanoje vektorizovane obrysy katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak nejsem schopen udelat sam) a pospojovat je na polygony a pridat jim podle polohy nazvy. S mapou od hanoje jsem si dneska hral a vysledek vypada celkem nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen jeste trochu doladit ... [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR [2] http://lkabrt.aspone.cz/osm/cuzk.zip ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- Petr Dlouhý ___ 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Hranice obcí
Podle me je moznost 1 spravne. Pokud neoznacime vsechna katastralni uzemi jako admin_level=10 tak nepujde do mapy zanest nazev k. u. a jeho identifikator. Mozna pro ne neni momentalne vyuziti, ale v budoucnu na ne mohou byt navazana nejaka dalsi data, nebo pujdou vyuzit pri nejakem dalsim importu. Jeste poznamka - pokud se hranice k. u. a obce shoduji, tak to jeste neznamena, ze se shoduji nazvy k. u. a obce. (napr. k.u. Hyncice u Broumova, obec Hyncice). ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne. Martin Kupec Dalsi faze bude sehnat si od hanoje vektorizovane obrysy katastralnich uzemi(nejak bojuju s GRASSem, takze si to nejak nejsem schopen udelat sam) a pospojovat je na polygony a pridat jim podle polohy nazvy. S mapou od hanoje jsem si dneska hral a vysledek vypada celkem nadejne, takze mapu s polygony snad budu schopny dodat. Chci to jen jeste trochu doladit ... [1] http://wiki.openstreetmap.org/wiki/Import_Adres_ČR [2] http://lkabrt.aspone.cz/osm/cuzk.zip ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Import adres z katastralni mapy
Zdravim, kdysi v lete jsem tady psal [1], jak zkousim importovat adresy a obrysy budov z katastralni mapy CUZK. Protoze jsem nemel prilis casu, tak jsem program pro import nedotahnul do konce. Ted jsem se k tomu vratil a do celkem pouzitelne podoby odelal aspon import adresnich bodu. Rozpoznavani obrysu budov se mi nepodarilo udelat natolik spolehlive, aby slo nejak rozumne pouzivat, takze to prozatim odkladam. Import jsem vyzkousel na uzemi ORP Broumov [2], jedna se asi o cca 40 obci / mestskych casti na 31 katastralnich uzemich - cca 270km2. Vysledky jsou nasledujici: Broumovsko - 3500 adresnich bodu (nalezena jednoznacna shoda mezi KM a databazi MVCR) - 170 bodu z KM, ke kterym se nepodarilo nalezt zaznam v databazi adres - 300 adres, ke kterym se nepodarilo najit bod v KM Broumov - 800 - 24 - 200 Mesto Broumov uvadim zvlast, protoze na jednom katastralnim uzemi jsou 4 mestske casti takze je potreba najit hranice mestkych casti rucne (napr. podle ulic). Navic se mi zda, ze je neco shnileho v databazi adres pro Broumov. Nevim, kde by mohlo byt 200 budov pro tech 200 adresnich bodu bez polohy. To se pri rucni kontrole snad prehlednout neda. Castou chybou je, ze v KM je uvedeno cislo evidencni a databazi adres cislo popisne. Na Broumovsku je to cca 50 pripadu. Pokud se podari zjistt, jaky zdroj je pravdivy, tak neni problem tyto chyby napravit. Ja jsem uploudoval pouze ty adresni body, pro ktere byla nalezena jendoznacna shoda. Jestli uplodovat i ty body, ke ktery se nepodarilo najit adresu v databazi MVCR (treba s tagem FIXME) zalezi na dohode. Jaky je na to vas nazor? Stalo by za to uchovavat nekde i seznam adres, ke kterym se nepodarilo najit bod v KM? Pokud chcete import vyzkouset sami, tak ctete dal. Pro provedeni importu je potreba 1) balicek programu ode me - lkabrt.aspone.cz/osm/cuzk.zip (potreba je .NET framework 3.5) pokud si nekdo chce prohlednou zdrojove kody lkabrt.aspone.cz/osm/cuzk-source.zip 2) databaze adresnich bodu [3] 3) zakreslene katastralni uzemi v OSM souboru (pouzil jsem vyrez z vektorizovne mapy od hanoje [4], kam jsem rucne doplnil relace a nazvy katastralnich uzemi) 4) trochu casu - jak vaseho, tak vaseho pocitace :-) Postup 1) stazeni katastralni mapy (staci definicni body budov) - program tile-downloader.exe parametry programu: -north, -south, -east, -west- definuje oblast ke stazeni -addressPoints - stahne definicni body budov -map- stahne katastralni mapu -output - adresar pro ulozeni stazenych souboru priklad: tile-downloader.exe -north 50.6647 -west 16.0285 -south 50.4902 -east 16.4517 - addressPoints -output data/broumovsko 2) nalezeni a rozpoznani adresnich bodu - program tile-processor.exe parametry programu: -tiles - adresar se stazenymi soubory -output - soubor pro ulozeni vysledku priklad: tile-processor.exe -tiles data/broumovsko -output data/broumovsko.csv Vystupem programu je CSV soubor se souradnicemi adresnich bodu a jejich popisem, tak jak ho rozpoznalo OCR 3) vytvoreni XML souboru, ktery definuje prirazeni mezi katastralnim uzemim a obci / casti obce z databaze adresnich bodu Prirazeni muze byt (podle toho, co jsem odpozoroval) 1:N nebo N:1 tzn. jedno katastralni uzemi muze tvorit vice casti obce nebo jedna obec / cast obce muze byt tvorena vice katastralnimi uzemimi format souboru je nasledujici: project territory name=Meziměstí district country-region=Královéhradecký kraj region=Broumov town=Meziměstí townDistrict=Meziměstí / /territory territory name=Starostín district country-region=Královéhradecký kraj region=Broumov town=Meziměstí townDistrict=Meziměstí / /territory territory name=Trutnov district country-region=Královéhradecký kraj region=Trutnov town=Trutnov townDistrict=Dolní předměstí / district country-region=Královéhradecký kraj region=Trutnov town=Trutnov townDistrict=Dolní Staré město / /territory territory name=Jívka district country-region=Královéhradecký kraj region=Trutnov town=Jívka / /territory /project atribut name u elementu territory odpovida nazvu katastralniho uzemi z OSM atributy elementu district definuji oblast / cast obce z databaze [2] country-region -kraj region -oblast town-obec townDistrict-cast 4)Prirazeni adres z databaze bodum z mapy - program merge-cuzk-db.exe parametry: -addressesDB- XML soubor s databazi adres [2] -territories- OSM soubor s definovanymi katasrtalnimi uzemimi -addressPoints - CSV soubor z bodu 2) -mappings - XML soubor z bodu 3) -output - definuje umisteni a jmeno souboru ([path]/[output- filename-prefix]) priklad: merge-cuzk-db.exe -mappings ms.map
Re: [Talk-cz] osm2pgsql pro win
Jinak receno, do win jsem si nahodil mapnika, funguje, ale nerenederuje mi cesty. Mel jsem podobny problem - mapnik renenderoval cesty oznacene track ale residental, primary, ... uz ne. Problem se vyskytnul, kdyz jsem data stahnul pomoci funkce export, ze stranky OSM, pokud jsem data stahnul pres JOSM, tak vsechno fungovalo. -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] osm2pgsql pro win
Kresli se nazvy ulic, potoky (sice ne spravne, ale kresli), budovy ... Presne takhle se to projevovalo a vyresil jsem to nahranim dat z jineho zdroje. Doufam, ze to bylo tak jak jsem psal ane obracene :-) Kazdopadne osm2pgsql mam ztazene z adresy http://tile.openstreetmap.org/osm2pgsql.zip a podarilo se mo to rozbehat. -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OpenTrackMap
O tomhle problému vím. Tento jev se vyskytuje všude na mřížce celých stupňů, podle které jsou děleny dlaždice výškové mapy. Tady je to ještě vpohodě, ale podívejte se třeba na Lysou Horu v Beskydech. Otázkou je jestli je to chyba ve vlastních SRTM datech nebo v procesu generování stínování... O tom, jak se generuje stinovani a vrstevnice nic moc nevim, ale myslim si, ze pokud by chyba byla v datech, tak by to ovlivnilo i vrstevnice. I ty jsou genegovany s SRTM dat, ne? -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OpenTrackMap
Že by se svítalo na lepší časy? http://www.ct24.cz/veda-a-technika/59617- nejucelenejsi-mapa-sveta-bude-ke-stazeni-na-internetu/ Viz. taky diskuze na t...@openstreetmap.org http://lists.openstreetmap.org/pipermail/talk/2009-June/038101.html -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Stavim, stavis, stavime - aneb budovy a adresni body z CUZK
na vektorizaci je prý relativně rychlý algoritmus bleskově vektorizovat na mnoho krátkých úseček a následně zkoušet 2 sousední úsečky spojovat do delších. Je však otázkou, jak si takový algoritmus poradí s ostrými rohy budov -- znám jej jen z aplikace, ve které zkosené rohy nevadí. Podobny algoritmus pouzivam pro vektorizaci a myslim ze funguje vcelku uspokojive. Vysldny vektor se vetsinou vejde do puvodni cary, ktera je tlusta nekolik px. On třeba existuje potrace[1] nebo autotrace[2]. potrace je stále vyvíjen, dává slušné výsledky a autor je komunikativní. Myslím, že by byl ochoten poradit s případnou úpravou algoritmu pro tento účel. Z potrace by se mozna dalo pouzit nektere algoritmy, ale vystup samotneho potrace mi prilis pouzitelny neprijde. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Stavim, stavis, stavime - aneb budovy a adresni body z CUZK
2009/6/29 Tomas Kolda ko...@web2net.cz: Potrace byl pouzit na vektorizaci UHUL lesu... Pouziva se velmi hezky a celou CR (100 000 * 70 000 pixelu nebo tak nejak) vypocital za par minut. Pouzival jsem ho jako knihovnu. Aha, tak to vypada, ze bych si mel rozsirit obzory a dat mu jeste sanci :-) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OpenTrackMap
Mam jednu pripominku k mape - nasel jsem misto, kde nejak nesedi stinovani - na mape je zobrazen vodorovny pruh, kteremu tam nic neodpovida. Jedna se v podstate o malickost, ale pri detailnim pohledu to kazi dojem. Jedna se o oblast severne od Malych Svatonovic, na openstreetmap je to priblizne http://www.openstreetmap.org/?lat=50.5387lon=16.0523zoom=14layers=B000FTF -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Stavim, stavis, stavime - aneb budovy a adresni body z CUZK
Zdravim, behem poslednich par dnu jsem si trochu hral s automatickym/poloautomatckym importem informaci z katastralni mapy. Co se mi podarilo: -- Stazeni dlazdic Nalezeni definicnich bodu budov (v mape oznaceny cervenou teckou a popisem - c.p., c.e, bez c.p./c.e.) Automaticke rozpoznani c.p./c.e Prozatimni export do OSM (pouze node v miste definichiho bodu a tag 'note' s rozpoznanym textem - hlavne pro kontrolu) Presnost rozpoznavani je hodne slusna - pokud se texty neprekryvaji tak temer stoprocentni. Program je mozne stahnou a vyzkouset z adresy http://lkabrt.aspone.cz/osm/cuzk-import.zip Program pro svuj beh potrebuje .NET 3.5, pro rozpoznavani textu je pouzita knihovna tesseract. Je to testovaci verze, zdrojaky vypadaji hrozne a rychlost je pro seriozni praci nepouzitelna, tak me prosim nekamenujte :-) Ve slusnem stadiu rozpracovani mam rozpoznani obrysu budov. Co je potraba dodelat: Zvysit rychlost - na tom se pracuje Aby bylo mozne nejak automaticky/poloautomaticky importovat adresni body tak je jim potreba priradit mesto/obec/mestskou cast ve ktere se nachazi a podle toho priradit nazev ulice a dalsi informace napr. UIR-ADR. Pokud jsem spravne pochopil situaci z prispevku v talk-cz, tak tohle je trochu problem. Z prehledove mapy CUZK se daji zjistit nazvy katastralnich uzemi, ale nevim jestli jejich hranice koresponduji s hranicemi obci. Hanoj tady nedavno psal, ze vektorizoval prehledove mapy z CUZK, ale bez nazvu katastralnich uzemi. Pokud by hranice katastralnich uzemi korespondovali s hranicemi obci/mestskych casti, ve kterych jsou c.p. jedinecna, tak by to slo vyuzit, i kdyby se nazvy katastralnich uzemi meli zadavat rucne - stejne nepredpokladam, ze by se importovala traba cela republika. Pro jednotlve adresni body jsem schopny rozpoznat i obrys budovy, ale to musim jeste doladit. Mam mnozinu definicnich bodu budov a mapu vektorizovanou na mnozinu vektoru (vektory na sebe navazuji) Pro kazdy z bodu se snazim najit polygon jehoz hranice jsou tvoreny temito vektory. Mam jeden primtivni zpusob, jak obalovy polygon ziskat, ale pokud mi poradite nejaky lepsi algoritmus, tak budu rad. (Muj algoritmus: vyberu vektor zacinajici nejbliz definicnimu bodu a z nej pokracuju dal a snazim se uzavrit cyklus, heuristika je takova, ze vzdy kdyz se da pokracovat vice smery, tak vybiram uzel, ktery je blize def, body budovy. Kdyz uzavru polygon, tak zkontroluju jestli je def. bod budovy opravdu uvnitr, jinak hledam dal / z jineho bodu) Jde o to, zda budovy do mapy pridavat, pripadne jak detailne - aby se velikost mapy nekolikanaspobne nezvysila. Na jednom miste jsem budovy kreslil rucne, docela podrobne a mapa hned vypada o tridu lip (http://www.openstreetmap.org/?lat=50.49736lon=16.10043zoom=16layers=B000FTF). Koukal jsem, ze treba v Praze jsou budovy take kresleny docela podrobne, takze ja bych byl pro. Rad si prectu vsechny napady, rady a pripominky. -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Stavim, stavis, stavime - aneb budovy a adresni body z CUZK
Jak se to ovládá ? Kde je dokumentace ? Je to jenom testovaci verze, takze dokumentace neni. Stazeni mapy z WMS CUZK: tile-downloader.exe [north] [west] [south] [east] [path] north, west, south, east definuje hranice oblasti, ktera se ma stahnout, path cesta kam se maji dlazdoce ulozit. Ukazka pouziti je v souboru downloader-sample.bat Pozor - nezadavat prilis velkou oblast, velikost jedne dlazdice je 0.005° a jeji rozliseni 4000x4000px. Pro kazdou dlazdici vyvvori 3 soubory - mapa s definicnimi body budov, katastralni mapa a soubor info. Rozpoznani definicnich bodu budov: tile-processor.exe [tile-path] tile-path cesta a nazev dlazdice mapy (pokud ma dlazdice nazev 'test' - soubory test-kn.png, test-budovy.png a test.info a je ulozena v adresari data, tak se zada 'data/test'). Priklad je v souboru processor-sample.bat Vystupem programu je soubor address.osm, ktery lze otevrit v JOSM. Ulozeny tam jsou pouze definicni body budov, ne jejich obrysy jejich rozpoznani je jeste pomalejsi, tak jsem to tam zatim nedaval. -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Zaverecne hlasovani o adresach
hlas pro 1) -- Lukas Kabrt ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Spolupráce na OSM
Ale podmínky povinné byly v nových pravidlech zakázány. Tudíž by to mohlo být pouze jako nepovinná podmínka a na tu se jak známo vykašle 99% lidí. Pokud vim, tak povinne podminky byly zakazany jen u tradicnich kesi. U mysterek je mozne i ted. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Začátečnické dotazy
Rad bych navazal na predchozi dotazy, protoze jsem v OpenStreetMap taky zacatenik. Jedna se mi predevsim o to, jak konkretne nektere veci kreslit do mapy a jak je znacit. Spolecna hranice ploch, plocha linie Na mape jsem vypozoroval, ze pokud vede cesta napr. po kraji lesa, tak nekde je to nakresleno jako dve linie, nekde jako jedna, kdy les a cesta sdili hranicni body. Podobna situace je u dvou sousedicich ploch napr. (zastavena oblast, les). Logicka se mi zda druha varinta a navic pri jejim pouziti bych rekl, ze vyrenederovana mapa vypada lip. Je to spravne? Jak to resit pokud sousedi dve linie (cesta, potok; cesta, elektricke vedeni), kreslit je oddelene? S tim souvisi dalsi otazka. Mnoho cest, ktere vedou lesem ho na mape deli na dve casti. je spravny postup ten les spojit do jednoho? Nevadi, ze takhle vnikaji hodne velke polygony? Oznaceni cest residental/service/track/unclassified Tady v tom mam trochu bordel. Jsou typicke priklady, kdy je to jasne (residenal - ulice ve meste, service - silnice v nejakem arealu atd) Ale jak treba oznacit sterkovou cestu ktera ve 3 km na samotu, kde stoji asi 20 domu? Unclassified, s dalsim tagem pro povrch? Nebo treba track? Jak treba oznacit cestu, ktera vede ridce zastavenou oblasti - co 100-200m jeden dum. Takovych cest je v okoli hromada a snazim se je znacit tak nejak podle citu, ale nekdy si moc jisty nejsem. Navic nektere tagy se mi zda duplicitni treba tracktype, surface a smoothness. Smoothnes vystihuje cestu nejlip z hlediska jeji pouzitelnosti ale poziti na mape jsem u nas snad nikde nevidel. Na druhou stranu, pokud vim, tak renendery na smoothnes neberou nejak moc ohledy. Takze polni cesta, kam klidne muzu osobakem bude stejne vykreslena jako vypleta lesni cesta, kde budu mit problemy s 4x4. Ktere z techle tagu pouzivat? Ani wiki v tohhle moc nepomuze. Diky za rady. 2009/6/14 Milan Zamazal p...@zamazal.org: Díky všem za odpovědi. Vyplývá mi z nich následující shrnutí: - Chybějící kusy silnic, ulice, sítě ulic lze obkreslit z ortofotomapy UHUL a/nebo katastrální mapy. V případě ulic lze následně doplnit čísla a názvy s pomocí Czechaddress. - Chybějící názvy ulic a sídel lze doplňovat na základě vlastní znalosti, případně z jiných zdrojů, s dostatečnou obezřetností vůči možnému vzniku chyb a záměn. - U nově, ale i dříve, zmapovaných věcí není na škodu dané místo osobně prolézt, zkontrolovat, doplnit body zájmu a celkově ověřit aktuální stav všeho. - Turistické, cyklistické, koňské a lyžařské stezky je nutno mapovat v terénu (dokud někdo neinfiltruje KČT:-). - Ostatní objekty všeho možného druhu lze v rámci možností obkreslovat ze zdrojů pro odvozování dat uvedených ve wiki, případně zjišťovat nebo doplňovat v terénu. - Obzvláště vhodné je zabývat se dobře známými místy (okolí bydliště, pracoviště, školy, chaty). V těchto případech se také k člověku obvykle dostanou informace jako že někde postavili novou ulici, most, stezku, čističku, otevřeli/zavřeli/přejmenovali/přesunuli hospodu, atd., takže je na takové zprávy možno promptně reagovat aktualizací mapy. - Mapovat lze cokoliv, pokud by měly být řečeny nějaké aktuální priority, tak to mohou být názvy ulic ve městech a dokončení silniční sítě. Ještě mám doplňující otázky: - Evidují se jakékoliv výškové informace? - Josm je na mém počítači v některých směrech dost pomalé, např. přechod mezi některými menu trvá až několik sekund. To je normální, nebo se mám pídit po závadě? ___ 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
