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

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

> 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> > wrote: > >> 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ě. > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

> On Tue, Sep 28, 2010 at 11:07:26AM +0200, Lukas Kabrt wrote: > >> 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. > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

> 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 :)

> 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. > > On Tue, 28 Sep 2010 11:07:26 +0200, Lukas Kabrt <lukas na kabrt.cz> wrote: > >> 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. > >

> 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. > > On Tue, 28 Sep 2010 12:12:18 +0200, Jakub Sykora <kubajz na kbx.cz> wrote: > >> 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 :) > > > -- > Petr Dlouhý > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

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

> > K

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

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

> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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. > > On Wed, 29 Sep 2010 06:51:55 +0200, Mike <mike na mikecrash.com> wrote: > >> 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 >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > >

> 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... > > > On 29.9.2010 7:54, Petr Dlouhý wrote: > >> 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. >> >> On Wed, 29 Sep 2010 06:51:55 +0200, Mike<mike na mikecrash.com> wrote: >> >> >>> 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 >>> >>> _______________________________________________ >>> 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 >

> ------------ Původní zpráva ------------ > Od: Mike <mike na mikecrash.com> > Předmět: Re: [Talk-cz] Import adresních bodů - Nekonzistence cuzk:km a > mvcr:adresa > Datum: 29.9.2010 08:45:25 > ---------------------------------------- > 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... > > > On 29.9.2010 7:54, Petr Dlouhý wrote: > > 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. > > > > On Wed, 29 Sep 2010 06:51:55 +0200, Mike <mike na mikecrash.com> wrote: > > > >> 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 > >> > >> _______________________________________________ > >> 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 > > >

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

> On Wed 2010-09-29 09:56:28, Petr Dlouhý wrote: >> 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 >

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

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

> 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

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

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

> 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 >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

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

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

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

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

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

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

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

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

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

> 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. > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

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

> On Mon, Oct 04, 2010 at 01:56:28PM +0200, Mike wrote: >> 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.

> 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

> On Mon, Oct 04, 2010 at 01:56:28PM +0200, Mike wrote: >> 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. > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

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

> On Tue, Oct 05, 2010 at 01:58:27PM +0200, Mike wrote: >> 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. > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz