>>(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
