Ahoj, jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.:
<node id="296674495" lat="48.9631350" lon="14.5119948" version="2" changeset="1965423" user="Radomír Černoch" uid="51295" timestamp="2009-07-28T14:56:31Z"> <tag k="addr:conscriptionnumber" v="2030" /> <tag k="addr:housenumber" v="2030/1" /> <tag k="addr:postcode" v="37006" /> <tag k="addr:street" v="U pramene" /> <tag k="addr:streetnumber" v="1" /> <tag k="source:addr" v="uir_adr" /> <tag k="uir_adr:ADRESA_KOD" v="23398671" /> </node> <node id="1496603658" lat="48.8736400" lon="14.6758775" version="1" changeset="9784174" user="Petr1868" uid="72020" timestamp="2011-11-09T19:54:47Z"> <tag k="addr:conscriptionnumber" v="13" /> <tag k="addr:country" v="CZ" /> <tag k="addr:housenumber" v="13" /> <tag k="is_in" v="Třebeč, Borovany, Jihočeský kraj, CZ" /> <tag k="source:addr" v="mvcr:adresa" /> <tag k="source:loc" v="cuzk:km" /> </node> <node id="33705330" lat="49.7021197" lon="17.0731786" version="12" changeset="5435557" user="NE2" uid="207745" timestamp="2010-08-08T17:43:41Z"> <tag k="addr:city" v="Litovel" /> <tag k="addr:conscriptionnumber" v="678" /> <tag k="addr:country" v="CZ" /> <tag k="addr:housenumber" v="678/1" /> <tag k="addr:postcode" v="78401" /> <tag k="addr:street" v="Mlýnská" /> <tag k="addr:streetnumber" v="1" /> <tag k="is_in" v="Litovel, Olomoucký kraj, CZ" /> <tag k="name" v="Penzion U starého mlýna" /> <tag k="source:addr" v="mvcr:adresa" /> <tag k="tourism" v="hotel" /> <tag k="url" v="http://ustarehomlyna.cz" /> </node> <node id="283050015" lat="50.1039117" lon="14.5115490" version="2" changeset="1984279" user="Radomír Černoch" uid="51295" timestamp="2009-07-30T12:44:24Z"> <tag k="addr:housenumber" v="?/66" /> <tag k="addr:streetnumber" v="66" /> <tag k="created_by" v="Potlatch 0.10b" /> </node> Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Je vidět, že některé adresní body obsahují i doplňkové informace, které bude třeba zachovat. Tedy nějaké globální mazání a import adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle toho se nějak zachovat. Honza Dne 25. června 2012 12:16 jzvc <j...@tpfree.net> napsal(a): > Dne 25.6.2012 0:35, hanoj napsal(a): >>> (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. > Tak to pozor, km sice pouzivam jako jeden z primarnich zdroju, ale > vzdycky minimalne kontroluju, jestli tam ta budova +- opravdu stoji. A > pripadu kdy v km budova je, ale fyzicky tam neni po budove ani pamatky > (= ani ruiny), pripadne naopak, budova si na miste vesele stoji, zato po > ni ani pamatky neni v km (a to vcetne toho, ze budova ma i vlastni cp) > nejsou zadnou vyjimkou, narazim na takove pri kazde editaci mapy. Zrovna > tento tyden sem odmazaval zborene budovy, ktere v km vesele stale jsou > (a to jsou zborene uz minimalne par let). > > => > > 1) zadny zbesily import a rozhodne ne zadne mazani v OSM. > > 2) optimalne vygenerovani nejake kolizni mapy (wms/tms server) aby sla > dat na podkres editoru. > 3) IMo by bodnul nastroj, kterej by byl schopnej nejak slinkovat > existujici budovy - rekneme s nejakym rozpalem hranic +- 1m? a > ohranicene plochy +- 10%? Cisla by samo chtelo vyhodnotit na zaklade > uspesnosti => pokud zbude nejaky nepatrny % budov, ty se daj poresit > rucne. Pokud se budova vejde to tohodle rozpalu (IMO vsechny vyrobeny > tracerem), tak se da prohlasit, ze to je "ona", priradit ji prislusny ID > a posunout jeji hranice tak, aby to sedelo presne na km. > > > Co se aktualizaci tyce - pokud dojde ke zmene v km a neni zadna zmena na > strane osm, tak asi neni co resit - aktualizace v osm. Pokud ke zmene > dojde opacne, tak dost pochybuju ze nekdo zmeni neco v km. Pokud je > zmena oboustrana, tak asi leda tak, ze nekdo koukne do osm a bud > prohlasi, ze se to ma syncnou s km nebo prohlasi, ze data sou spravne v > osm (a nejakym marknutim objektu ho vyradi ze synchronizace). > > >> >>> 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 >> >>> Které konrétní údaje z registru se budou do OSM importovat? >> *AdresniMisto (addr=*) >> *Stavebni objekt (building=*) >> *Ulice (name=*) >> >>> 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. Dost digitalizaci je >> neduslednych co do geometrie tvaru (krizeni, nesdileni hran a nodu) >> nebo pokryti zdanlive hotoveho uzemi. Obdobne u adresnich bodu, coz je >> dano nedokoncenym importem a zdrojem dat. >> >> >>> 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 >> >> Takze nejvetsi otazkou je co s tim co uz v OSM je a jak nakladat s >> daty v budoucnosti. >> >> >> ha >> hanoj >> >> _______________________________________________ >> 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