Zdravím, katastr zachycuje *právní* stav, nikoliv realitu. Takže je určitě hodně budouv, které jsou na mapách a ve skutečnosti neexistují (zrovna o víkendu jsme jezdili po zaniklých vesnicích v Českém lese a některé budovy stále ještě v mapách KN jsou) nebo ve skutečnosti existují, ale v mapách KN nejsou (buď černé stavby, nebo stavby, které nejsou předmětem evidence v katastru).
Uliční čáry jsou (budou). Jedná se o import ze ZABAGED. J. Veselý > ------------ Původní zpráva ------------ > Od: Jan Bilak <jan.bilak....@gmail.com> > Předmět: Re: [Talk-cz] Data RUIAN - výměnný formát > Datum: 25.6.2012 01:36:52 > ---------------------------------------- > >>(nebo jsou data nesprávná - např. jiný tvar obrys budovy). > > *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a > > vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat > > za standard. > Řekněme, že zde mohou např. fakticky existující budovy chybět > (postavené "načerno" apod.). V tak rozsáhlých informacích bych se > divil, kdyby to bylo opravdu bez chyb. Na druhou stranu jako základ to > určitě smysl má, protože je to (v daných oblastech) asi to nejlepší, > co máme. Ale s ručními zásahy je třeba počítat. > > > >> obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že > >> některá data budou lepší v OSM než v datech registru. Uliční čáry musí > >> nějak rozumně na sebe navazovat... > > *** Opravdu se jedná o uliční čáry, nebude to jen popisek? Já jsem v > > ukazkach nic nenašel > > Asi opravdu uliční čáry, viz třeba: > > <vf:Ulice><vf:Ulice > gml:id="UL.454281"><uli:Kod>454281</uli:Kod><uli:Nazev>Lešanská</uli:Nazev><uli:Obec><obi:Kod>554782</obi:Kod></uli:Obec><uli:PlatiOd>2011-07-01T00:00:00</uli:PlatiOd><uli:IdTransakce>0</uli:IdTransakce><uli:GlobalniIdNavrhuZmeny>0</uli:GlobalniIdNavrhuZmeny><uli:Geometrie><uli:DefinicniCara><gml:MultiCurve > gml:id="DUL.454281.X" srsName="urn:ogc:def:crs:EPSG::2065" > srsDimension="2"><gml:curveMember><gml:LineString > gml:id="DUL.454281"><gml:posList>738883.65 1048327.51 738848.15 > 1048382.19 738819.05 > 1048435.52</gml:posList></gml:LineString></gml:curveMember></gml:MultiCurve></uli:DefinicniCara></uli:Geometrie></vf:Ulice> > > > >> Které konrétní údaje z registru se budou do OSM importovat? > > *AdresniMisto (addr=*) > > *Stavebni objekt (building=*) > > *Ulice (name=*) > Já myslím, které vlastnosti těchto entit. Užitečné by bylo napojení na > registry pomocí IDček apod. > > > >> Jak se vypořádat se starými daty? > > *** Mno nebal bych se smazat a nahrat novou geometrii budov (pro > > source=cuzk:km) a ponechat pripadne tagy navic. > Což znamená namatchovat k nové budově tu starou, aby bylo možné > zkopírovat tagy. Otázka je, jak. Budovy nemusí být zakresleny přesně a > není jisté, že budou fungovat nějaké metody typy "X má průsečík s Y" > apod. > > > Dost digitalizaci je > > neduslednych co do geometrie tvaru (krizeni, nesdileni hran a nodu) > > nebo pokryti zdanlive hotoveho uzemi. > Také bude třeba kontrolovat, že node není sdílený s něčím jiným. Rovně > může dojít k nějakým nechtěným průsečíkům, pokud budova byla > nakreslena odlišně a obdobně jsou nakresleny i okolní objekty. > > S ulicemi, které mají návaznosti, bude také asi celkem problém. V > registrech je jen něco (nebo to prostě není ulice, ale něco fakticky > podobného). > > > Obdobne u adresnich bodu, coz je > > dano nedokoncenym importem a zdrojem dat. > Adresní body budou asi celkem v pohodě. > > > >> Za ideální cílový stav bych považovat navázání dat na registr kvůli > >> aktualizacím. > > *** To je zbozne prani, ktere se nam doposud nepovedlo, viz napr.: > > 1) adresni body obcas nekdo strka do POI ci polygonu building > > 2) admin_border se staly soucasti multipolygonu budov a ruznych preklepu... > > 3) import rek DIBAVOD, a lesu UHUL uz je prakticky neudrzovatelny s > originalem > Zatím ano, ale tady bych to neviděl jako nemožné. U entit bych > nechával v tagu návaznost na registr ve formě ID. Pak bude možné > automaticky detekovat, kde došlo k ruční úpravě a kde ne, stejně tak > ze změnových souborů bude možné snadno zjišťovat změny v registrech a > neupravované entity automaticky opravovat. U těch, kde byl proveden > manuální zásah, tak tam bude třeba asi ruční posouzení, ale toho bude > předpokládám málo. > > > > Takze nejvetsi otazkou je co s tim co uz v OSM je a jak nakladat s > > daty v budoucnosti. > Souhlas, proto považuji za nezbytné to nejprve prodiskutovat a vybrat > nějaké nejlepší řešení a pak jej implementovat. Adresy, obrysy budov > > > Honza > > _______________________________________________ > 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
