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
