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