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 <[email protected]>
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 <[email protected]>
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: [email protected])
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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-cz
_______________________________________________
Talk-cz mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-cz
--
Petr Dlouhý
_______________________________________________
Talk-cz mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-cz
