Ahoj, provedl jsem vektorizaci prehledky katastranich uzemi (KU) z katastrani mapy z WMS CUZK: * PNG S-JTSK [1] * OSM WGS84 [2], doporucuji prohlizet v JOSM-NG [7] * ESRI Shapefile WGS84 [3] * ESRI Shapefile S-JTSK [4] Jedna se o hole _linie_ hranic katastralnich uzemi, ze kterych je mozno vytvorit[6]: * katastralni uzemi * obce (LAU 2) * okresy (LAU 1) * kraje (NUTS 3) * CR (statni hranice) Namety pro vas: * Za predpokladu, ze zdroj WMS CUZK je uznany jako legalni, muzeme se zamyslet, zda to neuploadovat do OSM. Povsimnete si ze soucasna statni hranice je uz hodne popropojovana s admin. hran. jinych statu, lecos se bude muset rucne docistovat. * V datech neni zadna informace o nazvu KU, je jich cca 16 tisic, resit pomoci OCR z vrstvy popisu WMS? * Neni vytvoren zadny multipolygon, lze to zautomatizovat? * Mozna to dost zaplaca mapu. Proto by se mohlo pockat na API 0.7, kde by se mohla objevit moznost vrstev (napr. administrativni hranice, topografie), nebo vylouskat z toho jen dilci casti (obce, kraje). * bugy viz [5] PS: postup [5] ha hanoj [1] http://osm.templ.net/kucr.png [2] http://osm.templ.net/kucr.osm.bz2 [3] http://osm.templ.net/kucr.shp_jtsk.tar.bz2 [4] http://osm.templ.net/kucr.shp_wgs84.tar.bz2 [5] http://wiki.openstreetmap.org/wiki/User:Hanoj/grass [6] http://www.czso.cz/csu/rso.nsf/i/schema_soustavy [7] http://shell.sh.cvut.cz/~nenik/josm-ng.jar

zobrazit citaci Tohle je spis zalezitost editoru (editr dostane vsechny data, ale ty co mne "nezajimaji" tak si je schovam) - cili tlacit na autory JOSM, Merkaartoru, Potlatche a dalsich aby to tam docpali. Proste by se definovalo par vrstev (reky, budovy, katastralni uzemi) + specialni vrstva "zbytek", clovek by si pak vybral co chce videt a editovat Martin

zobrazit citaci *** mas pravdu ze u relativne pozicovanych nodu je podpora pouze ze strany editoru asi vhodnejsi, nicmene API je dobry generalni rozkaz. Psani editoru je kazdeho vec. *** ale proc bych mel stahovat ze serveru vsechno, kdyz to potrebuji jen neco? V OSM jiz dnes jsou tematicky oddelena data, ktera by mozno lze drzet v nezavislych vrstvach a lepe udrzovat jejich konzistenci (napr. boundary, landuse, relief, vrstevnice od zbytku). V GIS editorech se nikdy needituje vsechno jako v JOSM, ale jen predmetna vrstva jednoho datoveho typu, zbytek se podklada pro ilustraci a orientaci kontextu. ha hanoj

zobrazit citaci Proč bych stahoval všechno a pak filtroval, když si můžu stahnout jen to co potřebuji. Tím pádem se zmenší objem přenášených dat. ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net/v2/

On Mon, 22 Jun 2009 14:49:50 +0200, Petr Schonmann <PSBOX na seznam.cz> wrote: zobrazit citaci Na to je tady XAPI, ne? Možná mu chybí podpora složitějších dotazů, ale už teď slouží tomuto účelu dobře. -- Petr Dlouhý

hanoj píše v Po 22. 06. 2009 v 00:02 +0200: zobrazit citaci Rozhodující jsou otázky, zda: 1) Může všechna data dočistit jeden člověk? 2) Existuje rozumný způsob, jak bez OSM práci rozložit mezi více lidí? Bojím se, že na obě otázky je záporná odpověď. zobrazit citaci Stálo by to za pokus. Úspěch totiž znamená zelenou i pro adresy. Pokud byste OCRkem prohnal nejdříve adresy, můžu nabídnout automatické odhadnutí chybovosti. zobrazit citaci Ano, rád s tím pomůžu. Klidně mi napište. zobrazit citaci Nepletu-li se, administrativní hranice většinou kříží jen velká města; ve zbytku země prochází skrz lesy a pole, kde to tak nevadí. Navíc už dnes zavazí oblasti 'landuse=*'. Osobně bych tedy byl spíše pro import a postupné doplňování jmen KU spolu s tím, jak se postupně doplňuje mapa. Nemám však silný názor. Díky za kus práce, Radek Černoch

zobrazit citaci *** samozrejme zalezi v jake fazi automatizace a uplnosti to docistovat zobrazit citaci *** napadlo me teoreticka reseni pro georeferencovane OCR, ale ja se k tomu dostanu nekdy... za dlouho. Snad kdyby se tim chtel bavit nekdo jiny... zobrazit citaci *** o ano, vsak pisu. Ale vytvaret multipolygony bez name a ref zatim asi nema smysl. Zatim je to cely takovy polotovar. hanoj