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

jzvc jzvc na tpfree.fdns.net
Čtvrtek Září 30 16:37:06 UTC 2010


 Dne 30.9.2010 17:37, Jan Bilak napsal(a):
> 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

Problem je, ze toto neni adresa. Ve vetsine obci, ktere maji i sve
casti, je urcujici adresa ulice + cp + obec + psc. Z psc se da (pokud je
spravne) urcit cast obce. Cast obce (tu oficialni) spousta lidi ani
nezna. Klidne muzu uvest konkretni priklad, v Teplicich je cast Trnovany
a cast Sanov, ale existuje prostor, kteremu se "odjakziva" rika Sanov
II, presto, ze oficielne je soucasti mestske casti Trnovany. Vetsina
lidi ale vubec netusi ze bydli v Trnovanech, protoze za ty je oznacovana
starsi zastavba, nikoli sidliste na kopci.

> 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

Pokud existuje UID z nejake ofiko DB mel by v OSM byt v kazdem pripade,
da se pak snadno zjistovat rozdil, pripadne chyby ve vazbach (viz import
hranic, ktery se moc nezadaril v pripadech, kde jsou uzemi se
stejnym/podobnym nazvem. Spatne se tam navazaly na vyssi celky uzemi,
ktera realne byla uplne mimo okres/kraj.).

K is_in (a podobnym tagum) asi toliko, ze je to velmi obtizne
udrzovatelny, spis naprosto neudrzovatelny. Muselo by to byt prakticky
nad kazdym bodem/krivkou/relaci ... a co kdyz nejaky objekt prochazi
vice hranic ? Problem hranicnich objektu se da resit tim, ze objekty do
X metru od hranice budou pro ucely hledani/navigace/... zahrnuty do obou
celku. Ostatne nektere navigace to tak bezne delaji - napisu obec a
presto mi nabizi i ulice, ktere jsou v tesnem sousedstvi, ale v jine
obci. Proc bych jako uzivatel mel vedet, kudy jaka hranice vede, me
staci, kdyz vim kam priblizne chci jet a detail upresnim az dostanu na
vyber.


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





Další informace o konferenci talk-cz