« zpět na výpis měsíce |

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

Vlákno 28.9. - 5.10.2010, počet zpráv: 38


28.9.2010 09:18:32 (#1)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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ý

28.9.2010 09:47:45 (#2)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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> wrote: zobrazit citaci
> 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ý

28.9.2010 10:13:16 (#3)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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ý

28.9.2010 11:07:26 (#4)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
96
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. -- Lukas 2010/9/28 Petr Dlouhý <petr.dlouhy na email.cz>: zobrazit citaci
> 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 >

28.9.2010 11:27:18 (#5)
gravatar

Ondrej Zajicek

<santiago at crfreenet.org>
8
On Tue, Sep 28, 2010 at 11:07:26AM +0200, Lukas Kabrt wrote: zobrazit citaci
> 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. -- 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." ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100928/3662da81/attachment.sig>

28.9.2010 12:12:18 (#6)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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 Dne 28.9.2010 11:27, Ondrej Zajicek napsal(a): zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100928/eac77f33/attachment.html>

28.9.2010 12:27:33 (#7)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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.
-- Petr Dlouhý

28.9.2010 12:34:24 (#8)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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ý

28.9.2010 12:40:54 (#9)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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 Dne 28.9.2010 12:27, Petr Dlouhý napsal(a): zobrazit citaci
> 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. > >

28.9.2010 12:47:14 (#10)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
96
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 -- Lukas 2010/9/28 Petr Dlouhý <petr.dlouhy na email.cz>: zobrazit citaci
> 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 >

28.9.2010 03:38:22 (#11)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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: zobrazit citaci
> 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). zobrazit citaci
> 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. zobrazit citaci
> > K
-- Petr Dlouhý

29.9.2010 06:51:55 (#12)
gravatar

Mike

<mike at mikecrash.com>
198
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 On 28.9.2010 9:18, Petr Dlouhý wrote: zobrazit citaci
> 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. >

29.9.2010 07:29:11 (#13)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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> wrote: zobrazit citaci
> 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.
-- Petr Dlouhý

29.9.2010 07:54:12 (#14)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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
-- Petr Dlouhý

29.9.2010 08:45:00 (#15)
gravatar

Mike

<mike at mikecrash.com>
198
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: zobrazit citaci
> 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 > >

29.9.2010 09:18:02 (#16)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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... Dne 29.9.2010 08:45, Mike napsal(a): zobrazit citaci
> 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 >

29.9.2010 09:56:28 (#17)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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é. zobrazit citaci
> ------------ 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 > > >
Petr Dlouhý petr.dlouhy na email.cz

29.9.2010 11:07:02 (#18)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
On Wed 2010-09-29 09:56:28, Petr Dlouhý wrote: zobrazit citaci
> 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

30.9.2010 12:53:56 (#19)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 29.9.2010 23:07, Pavel Machek napsal(a): zobrazit citaci
> 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 >
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.

30.9.2010 03:27:54 (#20)
gravatar

Ondrej Zajicek

<santiago at crfreenet.org>
8
On Thu, Sep 30, 2010 at 12:53:56PM +0200, jzvc wrote: zobrazit citaci
> > 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." ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100930/6528097f/attachment.sig>

30.9.2010 04:16:59 (#21)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
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): zobrazit citaci
> 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 > >

30.9.2010 04:48:17 (#22)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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: zobrazit citaci
> 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ý

30.9.2010 05:37:56 (#23)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
Ahoj, zobrazit citaci
> 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í. zobrazit citaci
> 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>: zobrazit citaci
> 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 >

30.9.2010 06:37:06 (#24)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 30.9.2010 17:37, Jan Bilak napsal(a): zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> > 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

30.9.2010 08:02:38 (#25)
gravatar

Ondrej Zajicek

<santiago at crfreenet.org>
8
On Thu, Sep 30, 2010 at 06:37:06PM +0200, jzvc wrote: zobrazit citaci
> 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. zobrazit citaci
> 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. -- 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." ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100930/b29b300e/attachment.sig>

30.9.2010 09:49:39 (#26)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
151
zobrazit citaci
> 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>: zobrazit citaci
> 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. >

1.10.2010 08:17:39 (#27)
gravatar

Mike

<mike at mikecrash.com>
198
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: zobrazit citaci
>> 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 >

1.10.2010 11:18:17 (#28)
gravatar

Ondrej Zajicek

<santiago at crfreenet.org>
8
On Fri, Oct 01, 2010 at 08:17:39PM +0200, Mike wrote: zobrazit citaci
> 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." ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20101001/634ab293/attachment.sig>

2.10.2010 11:08:23 (#29)
gravatar

Petr Morávek

<xificurk at gmail.com>
169
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>: zobrazit citaci
> 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í

2.10.2010 01:21:48 (#30)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 2.10.2010 11:08, Petr Morávek napsal(a): zobrazit citaci
> 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 ;-). zobrazit citaci
> 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." >>

3.10.2010 04:16:36 (#31)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
345 733
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): zobrazit citaci
> 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

4.10.2010 01:56:28 (#32)
gravatar

Mike

<mike at mikecrash.com>
198
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. On 1.10.2010 23:18, Ondrej Zajicek wrote: zobrazit citaci
> 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

4.10.2010 03:47:18 (#33)
gravatar

Ondrej Zajicek

<santiago at crfreenet.org>
8
On Mon, Oct 04, 2010 at 01:56:28PM +0200, Mike wrote: zobrazit citaci
> 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. -- 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." ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20101004/11dc607a/attachment.sig>

4.10.2010 05:15:21 (#34)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
Ondrej Zajicek napsal(a): zobrazit citaci
> 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.
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 ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20101004/60efb260/attachment.sig>

4.10.2010 07:58:41 (#35)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj!! zobrazit citaci
> 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
Ze to prijde neznamena ze adresa byla dobre. Posta je schopna dorucit ledacos, vcetne: Dr. Jindrich Urbanec, Praha nebo <jmeno/prijmeni>, ten velky dum u koleji pobliz ul XX, Ceske Budejovice Maji dokonce specialni oddeleni, ktery nakonec dopis otevre (!) a podle obsahu se pokusi ho nekam inteligentne dorucit. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.10.2010 01:58:27 (#36)
gravatar

Mike

<mike at mikecrash.com>
198
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 On 4.10.2010 15:47, Ondrej Zajicek wrote: zobrazit citaci
> 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

5.10.2010 03:02:55 (#37)
gravatar

Ondrej Zajicek

<santiago at crfreenet.org>
8
On Tue, Oct 05, 2010 at 01:58:27PM +0200, Mike wrote: zobrazit citaci
> 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. -- 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." ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20101005/db3231b2/attachment.sig>

5.10.2010 03:39:52 (#38)
gravatar

Mike

<mike at mikecrash.com>
198
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. On 5.10.2010 15:02, Ondrej Zajicek wrote: zobrazit citaci
> 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

« zpět na výpis měsíce