[Talk-cz] Import adresních bodů - Nekonzistence cuzk:km a mvcr:adresa

Jan Bilak jan.bilak.osm na gmail.com
Čtvrtek Září 30 14:16:59 UTC 2010


Ahoj,

souhlasím. Hranice mají tu výhodu, že je lze dobře vykreslovat na
mapě. Z stromového/svazového (dále budu psát jen o stromu, i když
možná by šlo obecně o svaz kvůli městským částem a částem obcí apod.)
by se pro vykreslení musela hranice vždy počítat - jinak si nedovedu
představit nějaké rozumné vykreslení na mapě (barvení budov apod. není
myslím dobrý nápad).

Stromovou strukturu poskytuje v rozumné podobě UIR-ADR. Tato DB se i
průběžně aktualizuje a je tedy vhodné si udržovat na ni vazby. A to
ideálně před ty kódy, které jsou v této DB. Nevím, kdo je vymyslel
(asi jsou to nějaké číselníky statistického úřadu), ale hojně se
používají (např. katastr, ARES apod.). A tyto kódy bych tedy navrhoval
doplnit ke všem objektům (krajům, obcím, částem obce, budovám, ...),
kde to bude možné. Usnadní se tak mimo jiné i možnost automatické
aktualizace OSM podle UIR-ADR.

Když budou data jak ve formě hranice, tak ve formě stromu/svazu, tak
to znamená duplicity v datech a spoustu problémů při změnách. Otázka
je, zda ty změny jsou tady tak časté, aby mělo smysl na tím uvažovat.
Ideální by podle mne bylo, mít jako primární jeden způsob uchování
vztahů mezi objekty pro každou dvojici typů objektů. Tedy např.
stanovit, že vztahy mezi objekty (budovami) a částmi obce bude
primárně ve formě stromu a hranice částí obcí se budou dopočítávat. Na
dopočítávání by se udělala nějaká utilitka. Dopočítávání až při
kreslení ... nevím, zda je reálné, ale obecně nějaké dopočítávané
"cache" informace v OSM obecně nepovažuji za špatné - jen je třeba s
nimi tak zacházet.

Hierarchie UIR-ADR je znázorněna tady a stejná hierarchie by neškodila v OSM:
http://forms.mpsv.cz/uir/prohlizec/prohlizec.html


S těmi SVJčky máš asi pravdu - koukal jsem namátkově na několik SVJ.
Získat automaticky polohu dalších vchodů (čísel popisných) si nedovedu
moc představit - tedy nevím, z čeho. Ale zjistit čísla popisná, která
tvoří jednu "budovu" v katastru, není takový problém - a to právě z
katastru nemovitostí. Otázka ale je, jak je to licencí těchto dat.
Pokud by to šlo legálně využít, tak nějaká data mohu dodat (mám toho
tady poměrně hodně předzpracovaného).

Honza


Dne 30. září 2010 15:27 Ondrej Zajicek <santiago na crfreenet.org> napsal(a):
> On Thu, Sep 30, 2010 at 12:53:56PM +0200, jzvc wrote:
>> > A jinak jo, v is_in muze byt cela hierarchie.
>> >                                                                     Pavel
>> >
>> Jak bylo receno, je to z historickych duvodu, ale u nove vkladanych dat
>> bych to tam necpal, postrada to smysl. Ony se casem aplikace naucej
>> pouzivat hranice a pak bude mozny to odstranit.
>
> Je otazka, zda ma kvuli takovym vecem smysl pouzivat hranice, zda by
> nebylo mnohem lepsi mit nekde zvlast hierarchicka data ve forme stromu
> nebo svazu, ktere by aplikace pouzivaly pro urceni nadrazenych celku.
> Reseni vyuzivajici geometrickou hranici ma nevyhody jednak kvuli
> nekonzistenci dat (napr. zmineny problem s objekty blizko hranice,
> kde je nekonzistence mezi hranici v OSM a u uradu. Opravit tag urcujici
> nadrazeny celek je jednoduche, ale opravit hranici (bez vhodneho zdroje
> dat slouziciho jako podklad) je vyrazne komplikovanejsi.
>
> Krom toho reseni skrz hranice nemusi byt v nekterych pripadech vubec
> mozne - AFAIK casti obce (v ramci obce) nejsou vymezene hranicema, ale
> ciste formalnim rozdelenim objektu (budov), aby platila jedinecnost
> cisla popisneho/evidencniho v ramci casti obce. V nekterych obcich (co
> jsem si vsiml v KN) treba budovy s cislem popisnym jsou rozdelene na
> casti obce podle toho kde lezi, ale skoro vsechny budovy s cislem
> evidencnim jsou prirazene k 'hlavni' casti obce.
>
>
> Druhy problem je, ze jak addr:city, tak ani is_in (v soucasne podobe
> ziskane importem adres) neni v nekterych pripadech dostatecny. is_in
> (generovany importem adres z CUZK a KN) obsahuje cast obce, obec a kraj,
> jenze jmena obci jsou unikatni jen v ramci okresu a i v ramci kraju
> existuje par set kolizi. Mam napsany programek na validaci importovanych
> adres v OSM, ale na tomhle selhava. Mozna by bylo dobre zavest nejaky
> cesky specificky atribut udavajici kod casti obce unikatni v CZ (treba
> ten pouzivany v registru CUZK, nebo nektery jiny oficialni) a udavat ho
> u adresnich bodu v CZ. To by dost usnadnilo validaci a pripadne
> pozdejsi automaticke udrzovani konzistence s daty CUZK ci automaticke
> upravy osatnich tagu adres na zaklade dat z CUZK.
>
>
> Jinak jeste je tu jeden nesouvisejici problem s importama adres z CUZK a
> KN. Vypada to, ze kdyz se druzstevni domy konvertovaly na SVJ, tak v KN
> je pro ne jen jeden adresni bod (s jednim c.p.), prestoze realne jde o
> vic c.p. . Tohle generuje znacnou cast nenalezenych adres z CUZK. Je otazka,
> zda by slo tohle nejak (polo)automaticky opravit.
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'SanTiago' Zajicek (email: santiago na crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkykkFoACgkQw1GB2RHercM1bwCggryRcfkF9vRNsXTvLN6eZATH
> tSAAn2w1BZFut/oM1H+GOuH5ExgtyOlO
> =72yT
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>




Další informace o konferenci talk-cz