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

Petr Dlouhý petr.dlouhy na email.cz #m72e6d6 28. 9. 2010 9:18

Ahoj, co znamená poznámka "Nekonzistence cuzk:km a mvcr:adresa"? Například u obce Libčice nad Vltavou se nepřiřadí is_in ani názvy ulic, přestože v souboru adresy.xml normálně jsou.

Petr Dlouhý petr.dlouhy na email.cz #m0e2516 28. 9. 2010 9:47

Ahoj, tak v Libčicích se mi to už podařilo vyřešit - asi je nějaká chyba v tom skriptu, protože když jsem si udělal soubor, ve kterém byly jen ty Libčice, tak se to přiřadilo správně. On Tue, 28 Sep 2010 09:18:32 +0200, Petr Dlouhý <petr.dlouhy na email.cz>

Petr Dlouhý petr.dlouhy na email.cz #m3c786c 28. 9. 2010 10:13

Ahoj, tak se zdá, že problém je hlubší. V dalších obcích to sice přiřazuje is_in, ale stejně to dělá tu nekonzistenci (a nepřiřazuje název ulice) i přesto, že dané adresy v databázi jsou. Zkoušel jsem to na Černošicích, a také pomůže, pokud se udělá soubor adres jen pro touto obci. Když jsem zkoušel stáhnout nekonzistentní adresy pro celou ČR pomocí XAPI, tak jich bylo velké množství. Falešné nekonzistence se vyskytují asi vždy jen v určitých obcích. Asi bude nutné nějakým způsobem ty adresní body doplnit, nebo dané obce přeimportovat. On Tue, 28 Sep 2010 09:47:45 +0200, Petr Dlouhý <petr.dlouhy na email.cz>

Lukas Kabrt lukas na kabrt.cz #me2d026 28. 9. 2010 11:07

Ahoj, zkousel jsem problem reprodukovat na Libcicich a zda se mi, ze vse funguje spravne - at uz sobory generuju jakkoli (pres soubor __merge.bat, vlastni soubor jen pro Libcice nebo se souborem adres jenom pro Libcice). V souboru fixme se objevi 5 adres u kterych je "Nekonzistence cuzk:km a mvcr:adresa" a ty opravdu v databazi adres nejsou. Jinak poznamka "Nekonzistence cuzk:km a mvcr:adresa" obecne znamena, ze v katastralni mape je objekt s cp./ce., ke kteremu se nenasel protejsek v databazi adres.

Ondrej Zajicek santiago na crfreenet.org #me3e5fa 28. 9. 2010 11:27

Ahoj, Jinak poznamka "Nekonzistence cuzk:km a mvcr:adresa" obecne znamena, ze v katastralni mape je objekt s cp./ce., ke kteremu se nenasel protejsek v databazi adres.

Jinak tyto chyby se nekdy objevuji u objektu na hranici katastralnich uzemi, kde skript pro budovu urci jine katastralni uzemi a jinou obec nez ve ktere je evidovan v databazi adres.

signature.asc

Jakub Sykora kubajz na kbx.cz #m9fdbe7 28. 9. 2010 12:12

To by zrovna sedelo - v KU Cernosic je totiz treba takovy hezky priklad - Dolni Brezany-Lhota-Zalepy a Ohrobec-Karov a katastralni uzemi tam probiha klikate pres ulice :) K

Petr Dlouhý petr.dlouhy na email.cz #m1341cc 28. 9. 2010 12:27

Ahoj, možná mám nějakou jinou verzi programu merge (mám z 23. února), protože mi to body s nekonzistencí nestrká do souboru fixme, ale do toho s adresami, které jsou v pořádku. Druhou možnou příčinou může být to, že program spouštím přes Mono na Linuxu.

Petr Dlouhý petr.dlouhy na email.cz #mf7f734 28. 9. 2010 12:34

Ahoj, to může být příčinou části bodů s nekozistencí, ale ta chyba o které mluvím způsobí, že jsou nekonzistentní všechny body v dané obci. Navíc se odstraní tím, že udělám vlastní soubor adresy.xml, ve které je jen ta daná obec.

Jakub Sykora kubajz na kbx.cz #mf387b7 28. 9. 2010 12:40

No na linuxu je to vubec chutovka :) Uz jen prekodovani vsech jmen souboru a uprava bataku, tak aby sly spustit mi zabralo docela dost casu... Ale jinak diky Petre, zrovna se kocham svymi oblibenymi obcemi, jak jsou pekne zaadresobodovane :) K

Lukas Kabrt lukas na kabrt.cz #mb67fe3 28. 9. 2010 12:47

S tou verzi programu to muze byt ono ... ja pouzivam verzi z 27.2. a funguje mi to bez problemu. Protoze program nemam v SVN, tak uz nedohledam co se zmenilo. Kazdopadne aktualizoval jsem program na webu [1], nejakymi zmatky tam byla verze z 23. 2. [1] http://osm.kabrt.cz/home/adresy.zip?attredirects=0&d=1

Petr Dlouhý petr.dlouhy na email.cz #m6144ed 28. 9. 2010 15:38

Tak s novější verzí to funguje bez problémů. Otázka je jakým způsobem aktualizovat špatně uploadované body. Myslím, že jsem nebyl sám, kdo to tam takhle špatně uploadoval. Na wikistránce o importu adres mi chybí informace o tom, jak rozdělovat obce v případě, že má více částí (a někdy je nutné rozdělovat i obce, které nejsou označené podtržítkem). Rozdělování je největší práce spojená s importem a možná by stálo za to nějakým způsobem hranice částí uchovat pro případné budoucí aktualizace. Vzhledem k tomu, že jsem ale hranice kreslil tak, aby to vyšlo (a občas jsem se možná netrefil, takže jsou některé adresní body v jiné části obce - to se týká především evidenčních čísel), tak se mi nechce to uploadovat do OSM (navíc je problém s pojmenováním).

S tou verzi programu to muze byt ono ... ja pouzivam verzi z 27.2. a funguje mi to bez problemu. Protoze program nemam v SVN, tak uz nedohledam co se zmenilo. Kazdopadne aktualizoval jsem program na webu [1], nejakymi zmatky tam byla verze z 23. 2. No na linuxu je to vubec chutovka :) Uz jen prekodovani vsech jmen souboru a uprava bataku, tak aby sly spustit mi zabralo docela dost casu...

S těmi baty zas tak moc práce není (v porovnání s rozdělováním obcí na části).

Ale jinak diky Petre, zrovna se kocham svymi oblibenymi obcemi, jak jsou pekne zaadresobodovane :)

Praha-západ už je snad celá, ale budu to muset ještě zkontrolovat, a také opravit ty obce, u nichž se projevila ta chyba. Nechtělo se mi čekat, takže jsem tam uploadoval ta stará data. Nejméně v obci Jílové u Prahy ale mezitím vyměnili katastrální mapu za novější, takže tam došlo k většímu množství změn (většina bodů se přinejmenším pohnula). Tam by bylo dobré to předělat s novými daty.

Tak s novější verzí to funguje bez problémů. Otázka je jakým způsobem aktualizovat špatně uploadované body. Myslím, že jsem nebyl sám, kdo to tam takhle špatně uploadoval. Na wikistránce o importu adres mi chybí informace o tom, jak rozdělovat obce v případě, že má více částí (a někdy je nutné rozdělovat i obce, které nejsou označené podtržítkem). Rozdělování je největší práce spojená s importem a možná by stálo za to nějakým způsobem hranice částí uchovat pro případné budoucí aktualizace. Vzhledem k tomu, že jsem ale hranice kreslil tak, aby to vyšlo (a občas jsem se možná netrefil, takže jsou některé adresní body v jiné části obce - to se týká především evidenčních čísel), tak se mi nechce to uploadovat do OSM (navíc je problém s pojmenováním). On Tue, 28 Sep 2010 12:47:14 +0200, Lukas Kabrt <lukas na kabrt.cz> wrote:

S tou verzi programu to muze byt ono ... ja pouzivam verzi z 27.2. a funguje mi to bez problemu. Protoze program nemam v SVN, tak uz nedohledam co se zmenilo. Kazdopadne aktualizoval jsem program na webu [1], nejakymi zmatky tam byla verze z 23. 2.

On Tue, 28 Sep 2010 12:40:54 +0200, Jakub Sykora <kubajz na kbx.cz> wrote:

No na linuxu je to vubec chutovka :) Uz jen prekodovani vsech jmen souboru a uprava bataku, tak aby sly spustit mi zabralo docela dost casu...

S těmi baty zas tak moc práce není (v porovnání s rozdělováním obcí na části).

Ale jinak diky Petre, zrovna se kocham svymi oblibenymi obcemi, jak jsou pekne zaadresobodovane :)

Praha-západ už je snad celá, ale budu to muset ještě zkontrolovat, a také opravit ty obce, u nichž se projevila ta chyba. Nechtělo se mi čekat, takže jsem tam uploadoval ta stará data. Nejméně v obci Jílové u Prahy ale mezitím vyměnili katastrální mapu za novější, takže tam došlo k většímu množství změn (většina bodů se přinejmenším pohnula). Tam by bylo dobré to předělat s novými daty.

K

-- Petr Dlouhý

Mike mike na mikecrash.com #m7d732d 29. 9. 2010 6:51

Ahoj, proč je tam tag is_in místo addr:city ? Přijde mi to nekonzistentní, když všechny ostatní věci jako ulice atd. jsou pomocí addr:xxxx a jediné město je pomocí is_in. V OSM je opravdu zmatek... Mike

Petr Dlouhý petr.dlouhy na email.cz #m1116fd 29. 9. 2010 7:29

Ahoj, v nové verzi dochází k jedné zvláštní věci - v souboru fixme se vyskytují body označené jako duplicity, které tam jsou pouze jednou. Jedná se o chybu, nebo jsem něco nepochopil? Nemůže jít například o body, které se označí jako duplicita, ale pak se sloučí do jednoho protože jsou blízko sebe? Takový bod se vyskytuje například v obci Všenory. On Tue, 28 Sep 2010 15:38:22 +0200, Petr Dlouhý <petr.dlouhy na email.cz>

Petr Dlouhý petr.dlouhy na email.cz #maf705f 29. 9. 2010 7:54

Ahoj, řekl bych, že to bude mít historické důvody. Bylo by ale asi dobré té předělat. Tag is_in jsem nikdy moc nepochopil, obzvláště když máme importované hranice a funguje Nominatim. U adresních bodů je to ale něco jiného, tam je město tak nějak součástí té adresy.

Mike mike na mikecrash.com #mc5ccf4 29. 9. 2010 8:45

Nevadí mi, že tam to město je uvedené, to se v mnoha případech může hodit, jen nechápu, proč je tam is_in místo addr:city? Argument z historických důvodů neobstojí, když je tu fungující adresování již dlouho: http://wiki.openstreetmap.org/wiki/Addr Podle mne by to měl importér přetagovat...

Jakub Sykora kubajz na kbx.cz #m3f08e1 29. 9. 2010 9:18

Podle me is_in slouzi k trochu jinemu ucelu nez addr:city. Citim to tak, ze v is_in muze byt klidne cela hierarchie - Europe,Czechia,Lhota,Kotehulky a v addr:city jen Lhota-Kotehulky...

Petr Dlouhý petr.dlouhy na email.cz #m57fbca 29. 9. 2010 9:56

Myslel jsem to stejně, jen s tím, že tag is_in je podle mě k ničemu. U adres má smysl město uvádět, protože je součástí té adresy, a pomocí Nominatimu by se mohla najít část města, když v adrese má být uvedené celé město (nebo naopak). Uvádět celou hierarchii je možná už zbytečné.

mvcr:adresa ---------------------------------------- Nevadí mi, že tam to město je uvedené, to se v mnoha případech může hodit, jen nechápu, proč je tam is_in místo addr:city? Argument z historických důvodů neobstojí, když je tu fungující adresování již dlouho: http://wiki.openstreetmap.org/wiki/Addr Podle mne by to měl importér přetagovat...
Ahoj, řekl bych, že to bude mít historické důvody. Bylo by ale asi dobré té předělat. Tag is_in jsem nikdy moc nepochopil, obzvláště když máme importované hranice a funguje Nominatim. U adresních bodů je to ale něco jiného, tam je město tak nějak součástí té adresy.
Ahoj, proč je tam tag is_in místo addr:city ? Přijde mi to nekonzistentní, když všechny ostatní věci jako ulice atd. jsou pomocí addr:xxxx a jediné město je pomocí is_in. V OSM je opravdu zmatek... Mike

Petr Dlouhý petr.dlouhy na email.cz

Pavel Machek pavel na ucw.cz #m08da44 29. 9. 2010 23:07

Myslel jsem to stejně, jen s tím, že tag is_in je podle mě k ničemu. U adres má smysl město uvádět, protože je součástí té adresy, a pomocí Nominatimu by se mohla najít část města, když v adrese má být uvedené celé město (nebo naopak). Uvádět celou hierarchii je možná už zbytečné.

No, is_in se hodi kvuli navigacim -- teda hlavne u ulic a mest. Prosim nechte ho tam, tusim ze je starsi nez addr:city a tim padem ho zna vic programu. A jinak jo, v is_in muze byt cela hierarchie. Pavel

jzvc jzvc na tpfree.fdns.net #m72a423 30. 9. 2010 12:53

Myslel jsem to stejně, jen s tím, že tag is_in je podle mě k ničemu. U adres má smysl město uvádět, protože je součástí té adresy, a pomocí Nominatimu by se mohla najít část města, když v adrese má být uvedené celé město (nebo naopak). Uvádět celou hierarchii je možná už zbytečné.
No, is_in se hodi kvuli navigacim -- teda hlavne u ulic a mest. Prosim nechte ho tam, tusim ze je starsi nez addr:city a tim padem ho zna vic programu. 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.

Ondrej Zajicek santiago na crfreenet.org #m60ff08 30. 9. 2010 15:27

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.

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."

signature.asc

Jan Bilak jan.bilak.osm na gmail.com #m8e7719 30. 9. 2010 16:16

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

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

Petr Dlouhý petr.dlouhy na email.cz #m1f316e 30. 9. 2010 16:48

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>

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>
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.

-- Petr Dlouhý

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ý

Jan Bilak jan.bilak.osm na gmail.com #m0d44bd 30. 9. 2010 17:37

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ý <petr.dlouhy na email.cz>:

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ý <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

jzvc jzvc na tpfree.fdns.net #m7e777c 30. 9. 2010 18:37

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.

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

Ondrej Zajicek santiago na crfreenet.org #m7ade7e 30. 9. 2010 20:02

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.

To je mozna pripad vetsich mest rozdelenych na casti obce. V obcich typu 'nekolik blizkych vesnic' je tomu spis naopak - bezne se pouziva jmeno casti obce (odpovidajici jedne vesnici), oficialni nazev cele obce se vyuziva pouze v oficialnich zalezitostech.

Z psc se da (pokud je spravne) urcit cast obce.

To AFAIK nejde. Jedno PSC urcite muze pokryvat mista lezici v ruznych casti obce. Nevim, co presne PSC urcuje, tipoval bych ze postu, ktera obsluhuje danou oblast, takze obecne asi nesouvisi s administrativnim clenenim.

signature.asc

Jan Bilak jan.bilak.osm na gmail.com #m7bdfb3 30. 9. 2010 21:49

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.

Dobře, ale co tím chceš říct? Co je to adresa? Všechny informace o daném místě? Minimální množství údajů, které identifikuje dané místo? Nevím a o pojmy stejně nejde. Je jasné, že pro danou adresu musí jít lehce zjistit všechno, co je možné - část obce, obec, okres, kraj, psč, stát, ... prostě všechno. Ale neznamená to automaticky, že ty všechny informace musí být u daného adresního nodu. Obdobné je to třeba v relačních (typicky SQL) databázích, které se typicky navrhují ve 3. normální formě, která víceméně kromě jiného volně řečeno říká, že jedna informace tam má být zanesena pouze jednou. Ústupky z normální formy se typicky dělají pouze z výkonostních důvodů. A i v SQL databázích jsou nástroje pro výkonostní optimalizaci bez narušení normální formy - např. materializované pohledy. Tedy jde vlastně u uchování duplicitních dat v nějakém tvaru, který je výhodný pro rychlou práci, a který se automaticky aktualizuje podle primárních údajů v tabulkách. A obdobně bych si dovedl představit, že "automat" bude doplňovat např. obec k adresnímu místu a to tak, že se podívá na adresní místo, do jaké části obce patří. A pak na danou část obce, do jaké obce tato část obce patří. A co s případy, kde si lidé myslí něco jiného než je oficiální rozdělení? Nevím. Buď to ignorovat - proč zanášet do OSM nepravdivé informace? Nebo to tam zapsat jako nějaký jiný tag typu "nezanedbatelná skupina lidí si myslí, že tohle je ..., i když to není pravda", což pak může nějaká aplikace využít pro nějaké hledání. Honza 2010/9/30 jzvc <jzvc na tpfree.fdns.net>:

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.

Dobře, ale co tím chceš říct? Co je to adresa? Všechny informace o daném místě? Minimální množství údajů, které identifikuje dané místo? Nevím a o pojmy stejně nejde. Je jasné, že pro danou adresu musí jít lehce zjistit všechno, co je možné - část obce, obec, okres, kraj, psč, stát, ... prostě všechno. Ale neznamená to automaticky, že ty všechny informace musí být u daného adresního nodu. Obdobné je to třeba v relačních (typicky SQL) databázích, které se typicky navrhují ve 3. normální formě, která víceméně kromě jiného volně řečeno říká, že jedna informace tam má být zanesena pouze jednou. Ústupky z normální formy se typicky dělají pouze z výkonostních důvodů. A i v SQL databázích jsou nástroje pro výkonostní optimalizaci bez narušení normální formy - např. materializované pohledy. Tedy jde vlastně u uchování duplicitních dat v nějakém tvaru, který je výhodný pro rychlou práci, a který se automaticky aktualizuje podle primárních údajů v tabulkách. A obdobně bych si dovedl představit, že "automat" bude doplňovat např. obec k adresnímu místu a to tak, že se podívá na adresní místo, do jaké části obce patří. A pak na danou část obce, do jaké obce tato část obce patří. A co s případy, kde si lidé myslí něco jiného než je oficiální rozdělení? Nevím. Buď to ignorovat - proč zanášet do OSM nepravdivé informace? Nebo to tam zapsat jako nějaký jiný tag typu "nezanedbatelná skupina lidí si myslí, že tohle je ..., i když to není pravda", což pak může nějaká aplikace využít pro nějaké hledání. Honza 2010/9/30 jzvc <jzvc na tpfree.fdns.net>:

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.

Mike mike na mikecrash.com #m6feae5 1. 10. 2010 20:17

To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším. Z adresního bodu beru jen housenumber a street, nic víc. Původně jsem používal i ostatní, ale nakonec jsem od toho upustil.

To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším. Z adresního bodu beru jen housenumber a street, nic víc. Původně jsem používal i ostatní, ale nakonec jsem od toho upustil. On 09/30/2010 09:49 PM, Jan Bilak wrote:

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.
Dobře, ale co tím chceš říct? Co je to adresa? Všechny informace o daném místě? Minimální množství údajů, které identifikuje dané místo? Nevím a o pojmy stejně nejde. Je jasné, že pro danou adresu musí jít lehce zjistit všechno, co je možné - část obce, obec, okres, kraj, psč, stát, ... prostě všechno. Ale neznamená to automaticky, že ty všechny informace musí být u daného adresního nodu. Obdobné je to třeba v relačních (typicky SQL) databázích, které se typicky navrhují ve 3. normální formě, která víceméně kromě jiného volně řečeno říká, že jedna informace tam má být zanesena pouze jednou. Ústupky z normální formy se typicky dělají pouze z výkonostních důvodů. A i v SQL databázích jsou nástroje pro výkonostní optimalizaci bez narušení normální formy - např. materializované pohledy. Tedy jde vlastně u uchování duplicitních dat v nějakém tvaru, který je výhodný pro rychlou práci, a který se automaticky aktualizuje podle primárních údajů v tabulkách. A obdobně bych si dovedl představit, že "automat" bude doplňovat např. obec k adresnímu místu a to tak, že se podívá na adresní místo, do jaké části obce patří. A pak na danou část obce, do jaké obce tato část obce patří. A co s případy, kde si lidé myslí něco jiného než je oficiální rozdělení? Nevím. Buď to ignorovat - proč zanášet do OSM nepravdivé informace? Nebo to tam zapsat jako nějaký jiný tag typu "nezanedbatelná skupina lidí si myslí, že tohle je ..., i když to není pravda", což pak může nějaká aplikace využít pro nějaké hledání. Honza 2010/9/30 jzvc <jzvc na tpfree.fdns.net>:
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.
_______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

Ondrej Zajicek santiago na crfreenet.org #m02443c 1. 10. 2010 23:18

To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším.

Tak ti to nebude fungovat v mnoha vesnicich, kde ulice pojmenovane nejsou, ale obsahuji nekolik casti obce s castecne se prekryvajicimi cisly.

signature.asc

Petr Morávek xificurk na gmail.com #m095783 2. 10. 2010 11:08

Hned na začátek se přiznám, že nevím co se má správně psát do adresy... Když jsem se to před časem snažil dohledat na webu pošty tak jsem moc neuspěl. Ale s tím členěním je to strašný bordel, protože č.p. je unikátní v rámci části obce a jméno ulice jestli se nepletu v rámci obce. Hranice části obce nejsou geografické, ale určeny přímo množinou adresních bodů. Ve městech se k tomu přidávají městské části, které můžou obsahovat více části obce, často jen jejich určitý díl, takže jedna část obce se dělí mezi více městských části. Podobně zmatené je psč, které je na tomto členění nezávislé a mám takový pocit, že opět může obsahovat jen určitý díl části obce... Třeba k nám na vesnici, co máme chalupu, běžně chodí dopisy s adresou tvaru "{část obce} {č.p.}, pošta {úplně jiná obec}, {psč}", naopak ve městě jsem neviděl že by tam někdo psal část obce nebo městskou část (leda že je to nějaká "anektovaná" vesnička na okraji). Řešení tohodle chaosu v osm bude chtít asi trochu pečlivější rozbor a přemýšlení než jen otázka, zda dávat is_in nebo addr:city. Petr 01/10/2010, Ondrej Zajicek <santiago na crfreenet.org>:

To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším.
Tak ti to nebude fungovat v mnoha vesnicich, kde ulice pojmenovane nejsou, ale obsahuji nekolik casti obce s castecne se prekryvajicimi cisly.

-- Odesláno z mobilního zařízení

Hned na začátek se přiznám, že nevím co se má správně psát do adresy... Když jsem se to před časem snažil dohledat na webu pošty tak jsem moc neuspěl. Ale s tím členěním je to strašný bordel, protože č.p. je unikátní v rámci části obce a jméno ulice jestli se nepletu v rámci obce. Hranice části obce nejsou geografické, ale určeny přímo množinou adresních bodů. Ve městech se k tomu přidávají městské části, které můžou obsahovat více části obce, často jen jejich určitý díl, takže jedna část obce se dělí mezi více městských části. Podobně zmatené je psč, které je na tomto členění nezávislé a mám takový pocit, že opět může obsahovat jen určitý díl části obce... Třeba k nám na vesnici, co máme chalupu, běžně chodí dopisy s adresou tvaru "{část obce} {č.p.}, pošta {úplně jiná obec}, {psč}", naopak ve městě jsem neviděl že by tam někdo psal část obce nebo městskou část (leda že je to nějaká "anektovaná" vesnička na okraji). Řešení tohodle chaosu v osm bude chtít asi trochu pečlivější rozbor a přemýšlení než jen otázka, zda dávat is_in nebo addr:city. Petr 01/10/2010, Ondrej Zajicek <santiago na crfreenet.org>:

On Fri, Oct 01, 2010 at 08:17:39PM +0200, Mike wrote:
To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším.
Tak ti to nebude fungovat v mnoha vesnicich, kde ulice pojmenovane nejsou, ale obsahuji nekolik casti obce s castecne se prekryvajicimi cisly. -- 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."

-- Odesláno z mobilního zařízení

jzvc jzvc na tpfree.fdns.net #mfa7247 2. 10. 2010 13:21

Hned na začátek se přiznám, že nevím co se má správně psát do adresy... Když jsem se to před časem snažil dohledat na webu pošty tak jsem moc neuspěl. Ale s tím členěním je to strašný bordel, protože č.p. je unikátní v rámci části obce a jméno ulice jestli se nepletu v rámci obce. Hranice části obce nejsou geografické, ale určeny přímo množinou adresních bodů. Ve městech se k tomu přidávají městské části, které můžou obsahovat více části obce, často jen jejich určitý díl, takže jedna část obce se dělí mezi více městských části. Podobně zmatené je psč, které je na tomto členění nezávislé a mám takový pocit, že opět může obsahovat jen určitý díl části obce... Třeba k nám na vesnici, co máme chalupu, běžně chodí dopisy s adresou tvaru "{část obce} {č.p.}, pošta {úplně jiná obec}, {psč}", naopak ve městě jsem neviděl že by tam někdo psal část obce nebo městskou část (leda že je to nějaká "anektovaná" vesnička na okraji). Řešení tohodle chaosu v osm bude chtít asi trochu pečlivější rozbor a přemýšlení než jen otázka, zda dávat is_in nebo addr:city. Petr

Tenhle chaos je proste dan historicky a obavam se, ze to nikdo nevyresi. Realne totiz neni ani CP schopna poskytnout seznam existujicich PSC - tedy naprosto trivialni vec. To co maji na webu ke stazeni je neuplny a navic to obsahuje spoustu chyb. Mel sem totiz tu cest s adresami pracovat nekolik let (tisk, trizeni ... hromadnych zasilek do ruznych zemi) a pokud nekde existuje bordel, tak v CR naprosto dokonalej. Napr ve Fr jsou schopni z adresy rict i to, kterej postak bude zasilku dorucovat. Samozrejme ze lidi si vetsinou poradej a proto vam korespondence dorazi i v pripade, ze je adresa neuplna nebo jinak spatne udana. Otazka zni, zda a pripadne jak tenhle chaos dostat do OSM ;-).

Dne 2.10.2010 11:08, Petr Morávek napsal(a):

Hned na začátek se přiznám, že nevím co se má správně psát do adresy... Když jsem se to před časem snažil dohledat na webu pošty tak jsem moc neuspěl. Ale s tím členěním je to strašný bordel, protože č.p. je unikátní v rámci části obce a jméno ulice jestli se nepletu v rámci obce. Hranice části obce nejsou geografické, ale určeny přímo množinou adresních bodů. Ve městech se k tomu přidávají městské části, které můžou obsahovat více části obce, často jen jejich určitý díl, takže jedna část obce se dělí mezi více městských části. Podobně zmatené je psč, které je na tomto členění nezávislé a mám takový pocit, že opět může obsahovat jen určitý díl části obce... Třeba k nám na vesnici, co máme chalupu, běžně chodí dopisy s adresou tvaru "{část obce} {č.p.}, pošta {úplně jiná obec}, {psč}", naopak ve městě jsem neviděl že by tam někdo psal část obce nebo městskou část (leda že je to nějaká "anektovaná" vesnička na okraji). Řešení tohodle chaosu v osm bude chtít asi trochu pečlivější rozbor a přemýšlení než jen otázka, zda dávat is_in nebo addr:city. Petr

Tenhle chaos je proste dan historicky a obavam se, ze to nikdo nevyresi. Realne totiz neni ani CP schopna poskytnout seznam existujicich PSC - tedy naprosto trivialni vec. To co maji na webu ke stazeni je neuplny a navic to obsahuje spoustu chyb. Mel sem totiz tu cest s adresami pracovat nekolik let (tisk, trizeni ... hromadnych zasilek do ruznych zemi) a pokud nekde existuje bordel, tak v CR naprosto dokonalej. Napr ve Fr jsou schopni z adresy rict i to, kterej postak bude zasilku dorucovat. Samozrejme ze lidi si vetsinou poradej a proto vam korespondence dorazi i v pripade, ze je adresa neuplna nebo jinak spatne udana. Otazka zni, zda a pripadne jak tenhle chaos dostat do OSM ;-).

01/10/2010, Ondrej Zajicek <santiago na crfreenet.org>:
On Fri, Oct 01, 2010 at 08:17:39PM +0200, Mike wrote:
To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším.
Tak ti to nebude fungovat v mnoha vesnicich, kde ulice pojmenovane nejsou, ale obsahuji nekolik casti obce s castecne se prekryvajicimi cisly. -- 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."

Jan Dudík jan.dudik na gmail.com #m59b269 3. 10. 2010 16:16

Jen na okraj - vlastní poznatek. Dům, stojící po léta na okraji města, asi 50 m od silnice. Adresu měl čp. + ona ulice. Po mnoha letech byla postavena nová ulice, takže ten dům teď stjí v ní. Všechny domy v té nové ulici mají (podle registru) adresu Schartova, jen tento původní je stále ČSL Armády... J&D

Hned na začátek se přiznám, že nevím co se má správně psát do adresy... Když jsem se to před časem snažil dohledat na webu pošty tak jsem moc neuspěl. Ale s tím členěním je to strašný bordel, protože č.p. je unikátní v rámci části obce a jméno ulice jestli se nepletu v rámci obce. Hranice části obce nejsou geografické, ale určeny přímo množinou adresních bodů. Ve městech se k tomu přidávají městské části, které můžou obsahovat více části obce, často jen jejich určitý díl, takže jedna část obce se dělí mezi více městských části. Podobně zmatené je psč, které je na tomto členění nezávislé a mám takový pocit, že opět může obsahovat jen určitý díl části obce... Třeba k nám na vesnici, co máme chalupu, běžně chodí dopisy s adresou tvaru "{část obce} {č.p.}, pošta {úplně jiná obec}, {psč}", naopak ve městě jsem neviděl že by tam někdo psal část obce nebo městskou část (leda že je to nějaká "anektovaná" vesnička na okraji). Řešení tohodle chaosu v osm bude chtít asi trochu pečlivější rozbor a přemýšlení než jen otázka, zda dávat is_in nebo addr:city. Petr 01/10/2010, Ondrej Zajicek <santiago na crfreenet.org>:
To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším.
Tak ti to nebude fungovat v mnoha vesnicich, kde ulice pojmenovane nejsou, ale obsahuji nekolik casti obce s castecne se prekryvajicimi cisly.
-- Odesláno z mobilního zařízení

-- -- Ing. Jan Dudík

Jen na okraj - vlastní poznatek. Dům, stojící po léta na okraji města, asi 50 m od silnice. Adresu měl čp. + ona ulice. Po mnoha letech byla postavena nová ulice, takže ten dům teď stjí v ní. Všechny domy v té nové ulici mají (podle registru) adresu Schartova, jen tento původní je stále ČSL Armády... J&D Dne 2. října 2010 11:08 Petr Morávek <xificurk na gmail.com> napsal(a):

Hned na začátek se přiznám, že nevím co se má správně psát do adresy... Když jsem se to před časem snažil dohledat na webu pošty tak jsem moc neuspěl. Ale s tím členěním je to strašný bordel, protože č.p. je unikátní v rámci části obce a jméno ulice jestli se nepletu v rámci obce. Hranice části obce nejsou geografické, ale určeny přímo množinou adresních bodů. Ve městech se k tomu přidávají městské části, které můžou obsahovat více části obce, často jen jejich určitý díl, takže jedna část obce se dělí mezi více městských části. Podobně zmatené je psč, které je na tomto členění nezávislé a mám takový pocit, že opět může obsahovat jen určitý díl části obce... Třeba k nám na vesnici, co máme chalupu, běžně chodí dopisy s adresou tvaru "{část obce} {č.p.}, pošta {úplně jiná obec}, {psč}", naopak ve městě jsem neviděl že by tam někdo psal část obce nebo městskou část (leda že je to nějaká "anektovaná" vesnička na okraji). Řešení tohodle chaosu v osm bude chtít asi trochu pečlivější rozbor a přemýšlení než jen otázka, zda dávat is_in nebo addr:city. Petr 01/10/2010, Ondrej Zajicek <santiago na crfreenet.org>:
On Fri, Oct 01, 2010 at 08:17:39PM +0200, Mike wrote:
To je naprosto běžný, že si lidi myslí, že je to součást nějaké obce a ona je to už jiná. Mám s tím vlastní zkušenost - v mém rodném městě jsem něco podobného zjistil až když jsem dělal adresy do OSM :) Adresa je jedinečná a vždy musí platit relace město-(ulice - pokud je)-číslo, relevantní je jen UIR, smyšlenosti lidí tam nemají co dělat. Prozradím, jak to dělám v mcnavi - najdu hranice státu, pak hranice obce a přiřadím je podle polohy ke státu, pak najdu ulice a přiřadím je podle polohy k obci a pak najdu adresní bod a přiřadím ho podle polohy k obci a podle jména k ulici. Části obce neřeším.
Tak ti to nebude fungovat v mnoha vesnicich, kde ulice pojmenovane nejsou, ale obsahuji nekolik casti obce s castecne se prekryvajicimi cisly. -- 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."
-- Odesláno z mobilního zařízení _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

-- -- Ing. Jan Dudík

Mike mike na mikecrash.com #me04fd3 4. 10. 2010 13:56

Máš nějaký příklad? Pokud tam nejsou ulice pojmenované, tak prostě beru jen čísla, nevšiml jsem si, že by někde byly zduplikovaný čísla, ale asi bych se na to měl podívat. Třeba Soběslav má také několik částí, čísla se duplikují, ale součástí je vždy za lomítkem část obce (třeba 200/III), takže ve výsledku žádná duplikace.

Ondrej Zajicek santiago na crfreenet.org #m8209f8 4. 10. 2010 15:47

Máš nějaký příklad?

Tak treba obec Mladonovice v okrese Chrudim. Sklada se z nekolika casti obce (Mladonovice, Pohled, Zbyhnevice a dalsi) a ve vsech techto uvedenych castech je dum s c.p. 2 a 4. Protoze jde o vesnice, nikde nejsou jmena ulic.

signature.asc

"Petr Morávek [Xificurk]" xificurk na gmail.com #mb7eb69 4. 10. 2010 17:15

Máš nějaký příklad?
Tak treba obec Mladonovice v okrese Chrudim. Sklada se z nekolika casti obce (Mladonovice, Pohled, Zbyhnevice a dalsi) a ve vsech techto uvedenych castech je dum s c.p. 2 a 4. Protoze jde o vesnice, nikde nejsou jmena ulic.

Takových případů bude spousta, protože jak jsem již psal výše - č.p. jsou jedinečná v rámci "části obce", nikoliv "obce" a na mnoha místech nejsou pojmenované ulice. Další vtip je v tom, že "městké části" často obsahují jen díly několika "částí obce", takže v jedné "městské části" mohou být celkem bez problému domy se shodnými č.p., ale tam už to není takový problém, protože jsou pojmenované ulice (doufám všude). Petr

signature.asc

Mike mike na mikecrash.com #mf37fa7 5. 10. 2010 13:58

V tom případě při absenci ulice asi budu muset vytvořit fiktivní ulici z části obce. Jenže jaký je tag pro část obce? Podle [1] nic takového není. Možná by se to mohlo řešit na úrovni OSM tak, že se do addr:street dá prostě část obce nebo se zavede třeba addr:quarter jako čtvrť? [1] http://wiki.openstreetmap.org/wiki/Addr

Ondrej Zajicek santiago na crfreenet.org #mcb6fcc 5. 10. 2010 15:02

V tom případě při absenci ulice asi budu muset vytvořit fiktivní ulici z části obce. Jenže jaký je tag pro část obce?

Nevim, zda existuje nejaky samotny tag, ale adresy importovane od OSM z katastralnich map a dat z MVCR to maji jako prvni polozku v is_in tagu.

signature.asc

Mike mike na mikecrash.com #mf15f8a 5. 10. 2010 15:39

Jenže adresy kdekoliv jinde než v ČR to nemají, takže je to na nic. Musí to fungovat pro celý svět a ne jen lokálně. Navíc is_in je používané tag různorodě, že taky použít nejde.