« zpět na výpis měsíce |

[Talk-cz] Czech Republic (mala ale nase)

Vlákno 22.6. - 25.6.2009, počet zpráv: 7


22.6.2009 12:02:05 (#1)
gravatar

hanoj

<ehanoj at gmail.com>
714
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

22.6.2009 12:23:53 (#2)
gravatar

MP

<singularita at gmail.com>
306
zobrazit citaci
> * 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).
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

22.6.2009 02:42:12 (#3)
gravatar

hanoj

<ehanoj at gmail.com>
714
zobrazit citaci
> > ?* 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). > > 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
*** 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

22.6.2009 02:49:50 (#4)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
zobrazit citaci
> > * 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). > > 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
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 at seznam.cz http://fatbozz.towerofglass.net/v2/

22.6.2009 05:51:22 (#5)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
On Mon, 22 Jun 2009 14:49:50 +0200, Petr Schonmann <PSBOX at seznam.cz> wrote: 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.
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?

23.6.2009 01:16:25 (#6)
gravatar

Radomir Cernoch

<radomir.cernoch at gmail.com>
139
hanoj p??e v Po 22. 06. 2009 v 00:02 +0200: zobrazit citaci
> 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.
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
> * V datech neni zadna informace o nazvu KU, je jich cca 16 tisic, > resit pomoci OCR z vrstvy popisu WMS?
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
> * Neni vytvoren zadny multipolygon, lze to zautomatizovat?
Ano, r?d s t?m pom??u. Klidn? mi napi?te. zobrazit citaci
> * 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).
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

25.6.2009 02:47:23 (#7)
gravatar

hanoj

<ehanoj at gmail.com>
714
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??.
*** samozrejme zalezi v jake fazi automatizace a uplnosti to docistovat zobrazit citaci
> > * V datech neni zadna informace o nazvu KU, je jich cca 16 tisic, > > resit pomoci OCR z vrstvy popisu WMS? > > 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.
*** 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
> > * Neni vytvoren zadny multipolygon, lze to zautomatizovat? > > Ano, r?d s t?m pom??u. Klidn? mi napi?te.
*** o ano, vsak pisu. Ale vytvaret multipolygony bez name a ref zatim asi nema smysl. Zatim je to cely takovy polotovar. hanoj

« zpět na výpis měsíce