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

Čtvrtek Září 30 15:37:56 UTC 2010

Ahoj,

> 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í.

Jak se to vezme. Pokud bychom se chtěli vyhnout duplicitám, tak v
adrese patrně stačí:
- část obce
- číslo domovní
- ulice (náměstí, ..., obecně UVP)
- číslo orientační

Každá část obce pak jednoznačně patří do nějaké obce. Obec patří do
okresy atp. Přesně podle toho schematu:
http://forms.mpsv.cz/uir/prohlizec/prohlizec.html

Obec pak lze zjistit přes část obce.

A pokud bychom duplicity považovali z nějakého důvodu užitečné, tak by
bylo dobré jasně prohlásit takové údaje za duplicity (jakési
sekundární vyjádření informací, které jsou primárně vyjádřené nějak
jinak), a které se budou aktualizovat automaticky podle primárního
vyjádření informací a tak bude zaručena konzistence dat a snadnost
aktualizací.

> Doplňovat tam celý strom mi ale přijde trochu zbytečné.

Mít v OSM informace o všech objektech, které jsou v UIR-ADR mi přijde
poměrně užitečné. Nakonec OSM chápu jako takovou DB, do které se
importují všechna užitečná geo data, která jsou licenčně dostupná. A
když tam budou ty objekty, tak by tam měly být i jejich vzájemné
vztahy. Zda ten vztah bude primárně vyjádřen hranicí nebo atributem
"patří_do", to je už je věc jiná a zde by podle mne mělo záležet na
tom, jak je daný vztah primárně definovaný (např. nějakým zákonem,
opatřením ČSÚ apod.). Sekundárně může být vyjádřen i jinak, ale
sekundární vyjádření lze již doplňovat automaticky z primárního
vyjádření. Takový postup podle mne usnadní aktualizace.

Honza

2010/9/30 Petr Dlouhý <petr.dlouhy na email.cz>:
> 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ý
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>