Dne 26.6.2012 4:14, Jan Bilak napsal(a): > 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?
Jednoznacne neurci, navic trebas ja(a nejen ja) davam adresy primo na budovu. Adresni bod pouzivam jen v pripade, ze na miste budova uz nestoji, pripadne tam sou po ni uz jen stopy. <way id='37346514' timestamp='2009-12-07T13:50:31Z' uid='102554' user='Jezevec' visible='true' version='3' changeset='3316020'> <nd ref='435504008' /> <nd ref='435504010' /> <nd ref='435504011' /> <nd ref='435504013' /> <nd ref='435504015' /> <nd ref='435504016' /> <nd ref='435504008' /> <tag k='addr:conscriptionnumber' v='7' /> <tag k='addr:country' v='CZ' /> <tag k='addr:housenumber' v='7/4' /> <tag k='addr:street' v='Školní Park' /> <tag k='addr:streetnumber' v='4' /> <tag k='building' v='yes' /> <tag k='is_in' v='Novosedlice, Ústecký kraj, CZ' /> <tag k='source' v='cuzk:km' /> <tag k='source:addr' v='mvcr:adresa' /> </way> Slinkovat se to da tam kde mas uir_adr:ADRESA_KOD, to je asi celkem jednoznacny, u toho zbytku leda podle adresy, coz samo nebude 100%. Ta posledni varianta, kde je v housenum ? je jeste z doby pred tim, nez padla dohoda ze tam budou obe cisla (orientacni a popisny). Hromadne se to poustelo na celou mapu, takze vsude kde tam je ? to znamena, ze od ty doby tu adresu nikdo neaktualizoval. Proto sem psal, ze v zadnym pripade nejaky hromadny mazani, to by nadelalo vic skody nez uzitku. > > 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 _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz