[Talk-cz] Data RUIAN - výměnný formát

Jan Bilak jan.bilak.osm na gmail.com
Úterý Červen 26 02:14:04 UTC 2012


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 <jzvc na 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 na openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz




Další informace o konferenci talk-cz