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: santi...@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."

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Odpovedet emailem