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

Petr Dlouhý petr.dlouhy na email.cz
Čtvrtek Září 30 14:48:17 UTC 2010


Ahoj,

mám pocit, že Nominatim si ten strom bez problému generuje z dat, takže
pro většinu běžných použití to bohatě stačí. Napojení na úřední databáze
pomocí čísel je samozřejmě víc než vhodné udělat v každém případě.

Jak už jsem napsal dvakrát, tak si myslím, že název obce je součástí
adresy, a měl by bít součástí adresního bodu. Jednak kvůli problémům s
přesností hranic obce, jednak kvůli rozdílům v úředních databázích, ale
především kvůli tomu, že z dat není jasné, který nadřazený celek má
vlastně na té adrese být a u částí obce v datech vůbec není.
Doplňovat tam celý strom mi ale přijde trochu zbytečné.


On Thu, 30 Sep 2010 16:16:59 +0200, Jan Bilak <jan.bilak.osm na gmail.com>
wrote:

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


-- 
Petr Dlouhý




Další informace o konferenci talk-cz