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