> Zdar, > > teď si stěžoval autor Navitu, že v OSM mu chybí vazby mezi objekty: > > - do kterého města patří daná ulice > - do kterého státu patří dané město > - které PSČ patří ke kterému městu/ulicím > - a je-li daná ulice typu urban nebo rural (nevím, co tím přesně myslí, > ale prý kvůli tomu vymyslel rural=yes, což já nikdy nikde nemapoval) > > měl jsem pocit, že ty vazby tam někde máme, že snad czechaddress plugin > něco takového přidává? Aha, už jsem to našel: > > "is_in" = "Zlín, Zlínský kraj, CZ" > > To nevypadá jako zápis vhodný pro strojové zpracování. Něco lepšího by > nebylo? > > Petr >

> ja osobne si myslim ze by melo byt jen is_in=zlin, node zlin by mel > byt is_in=zlinsky kraj a node zlinskeho kraje by melo byt is_in=cz, > coz by generovalo krasne stromecky, ale je to naivni predstava:)

> Zdar, > > teď si stěžoval autor Navitu, že v OSM mu chybí vazby mezi objekty: > > - do kterého města patří daná ulice > - do kterého státu patří dané město > - které PSČ patří ke kterému městu/ulicím > - a je-li daná ulice typu urban nebo rural (nevím, co tím přesně myslí, > ale prý kvůli tomu vymyslel rural=yes, což já nikdy nikde nemapoval) > > měl jsem pocit, že ty vazby tam někde máme, že snad czechaddress plugin > něco takového přidává? Aha, už jsem to našel: > > "is_in" = "Zlín, Zlínský kraj, CZ" > > To nevypadá jako zápis vhodný pro strojové zpracování. Něco lepšího by > nebylo? > > Petr > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> > wrote: > > Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi > posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, > protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako > hranice města, hranice státu a další hranice oblastí. Už tag is_in, který > se používá u obcí mi přijde nadbytečný.

>> Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi >> posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, >> protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako >> hranice města, hranice státu a další hranice oblastí. Už tag is_in, který >> se používá u obcí mi přijde nadbytečný.

>        Neni spis nadbytecna hranice mesta? Mi prijde skoro lepsi, a >        hlavne jednodussi na zmapovani pridavat k silnicim flags >        "is_in" a v posprocessingu kolem takovychto silnic udelat >        polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta >        nejspis neni uplne dulezita informace, mestu mohou patrit i >        rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou >        a zobrazovanim zastavene oblasti.

> On Fri, Oct 30, 2009 at 01:29:42PM +0100, Petr Dlouhý wrote: >> On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> >> wrote: >> >> Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi >> posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, >> protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako >> hranice města, hranice státu a další hranice oblastí. Už tag is_in, >> který >> se používá u obcí mi přijde nadbytečný. > Neni spis nadbytecna hranice mesta? Mi prijde skoro lepsi, a > hlavne jednodussi na zmapovani pridavat k silnicim flags > "is_in" a v posprocessingu kolem takovychto silnic udelat > polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta > nejspis neni uplne dulezita informace, mestu mohou patrit i > rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou > a zobrazovanim zastavene oblasti. > > Martin Kupec

> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> >        Neni spis nadbytecna hranice mesta? Mi prijde skoro lepsi, a > >        hlavne jednodussi na zmapovani pridavat k silnicim flags > >        "is_in" a v posprocessingu kolem takovychto silnic udelat > >        polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta > >        nejspis neni uplne dulezita informace, mestu mohou patrit i > >        rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou > >        a zobrazovanim zastavene oblasti. > *** to jste mne docela rozesmal... nastudovat si administrativni > cleneni a majetkopravni vztahy v katastru nemovitosti?

> >> Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi > >> posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, > >> protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako > >> hranice města, hranice státu a další hranice oblastí. Už tag is_in, který > >> se používá u obcí mi přijde nadbytečný. > *** samozrejme...

>> >        hlavne jednodussi na zmapovani pridavat k silnicim flags >> >        "is_in" a v posprocessingu kolem takovychto silnic udelat >> >        polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta >> >        nejspis neni uplne dulezita informace, mestu mohou patrit i >> >        rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou >> >        a zobrazovanim zastavene oblasti. >> *** to jste mne docela rozesmal... nastudovat si administrativni >> cleneni a majetkopravni vztahy v katastru nemovitosti? >        Priznavam ze netusim jak funguje katastr nemovitosti. Ale prijde >        mi ze hranice mesta nebude kopirovat hranici zastavby. Minimalne >        u nas vim ze mestu patrilo pole za mestem, a ted se z nej delala >        prumyslova zona. A to pole bych asi nechtel mit zarazene do >        mesta(teda tez jiz ano, uz tam stavi fabriku).

>> >> Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi >> >> posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, >> >> protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako >> >> hranice města, hranice státu a další hranice oblastí. Už tag is_in, který >> >> se používá u obcí mi přijde nadbytečný. >> *** samozrejme... > > nepochopil jsem, je-li to odpoved na moji puvodni otazku, a jaka odpoved > to vlastne je. > > Muzu se jeste jednou zeptat, ma-li OSM nejake moznosti, jak tyto vazby > dnes vyjadrit - ano-li, tak jak, ne-li, tak co s tim muzeme udelat?

> *** dnes mame aparat administrativnich hranic, ktere jednoznacne mohou > rozlisovat spravni uzemi a tedy napr. i hranice obce, kraje, statu. > boundary=administrative

> is_in je pro mne jen takova historicka berlicka.

> >> >        hlavne jednodussi na zmapovani pridavat k silnicim flags > >> >        "is_in" a v posprocessingu kolem takovychto silnic udelat > >> >        polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta > >> >        nejspis neni uplne dulezita informace, mestu mohou patrit i > >> >        rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou > >> >        a zobrazovanim zastavene oblasti. > >> *** to jste mne docela rozesmal... nastudovat si administrativni > >> cleneni a majetkopravni vztahy v katastru nemovitosti? > >        Priznavam ze netusim jak funguje katastr nemovitosti. Ale prijde > >        mi ze hranice mesta nebude kopirovat hranici zastavby. Minimalne > >        u nas vim ze mestu patrilo pole za mestem, a ted se z nej delala > >        prumyslova zona. A to pole bych asi nechtel mit zarazene do > >        mesta(teda tez jiz ano, uz tam stavi fabriku). > > nejprve si ujasneme pojmy, abychom si rozumeli ve vychodiscich: > *** zastavene uzemi obce vs. katastralni (spravni) uzemi obce > *** spravni pusobnost obce vs. vlastnictvi/majetek obce

>        Aneb je treba asi resit dva problemy: >        1. Jakemu mestu patri jaka ulice, popripade jake ulici patri >        jaky popisny bod. Tento problem musi resit navigace. >        2. Nejak byt schopni vykreslit zastavenou oblast jako polygon a >        nejlip tomu priradit jmenovku mesta, kteremu to patri. Toto resi >        Ivo a letecka mapa. > >        Prvni problem je nejlepe resitelny administrativnimi hranicemi, >        je nerendundantni a je treba pridat relativne malo hranic, vudci >        pridavani tagu kazde ulici.

>        Druhy problem by se asi dal resit tak, ze se vyresi prvni a pak >        se vezmou ulic/domy z dane oblasti a kolem nich se udela >        konvexni obal, coz by melo jit jednoduchym algoritmem.

>        Otazka tedy zni...da se nekde sehnat zdroj ktery popise >        administrativni hranice? A jestli ke kazdemu administrativnimu >        celku pridame hranici, tak uz to asi bude chtit nejak rozclenit >        do vrstev, to tusim bylo neco na cem se pracuje, ale netusim v >        jakem je stavu.

> *** ano mame prehledky CUZK. Automatizovane vektorizovane, jen je > potreba, aby nekdo udelal OCR, spojil to dohromady, vygeneroval > relace, rucne zacistil. Muzete pomoci?

> Zdar, > > te? si st??oval autor Navitu, ?e v OSM mu chyb? vazby mezi objekty: > > - do kter?ho m?sta pat?? dan? ulice > - do kter?ho st?tu pat?? dan? m?sto

> - kter? PS? pat?? ke kter?mu m?stu/ulic?m > - a je-li dan? ulice typu urban nebo rural (nev?m, co t?m p?esn? mysl?, > ale pr? kv?li tomu vymyslel rural=yes, co? j? nikdy nikde nemapoval) > > m?l jsem pocit, ?e ty vazby tam n?kde m?me, ?e snad czechaddress plugin > n?co takov?ho p?id?v?? Aha, u? jsem to na?el: > > "is_in" = "Zl?n, Zl?nsk? kraj, CZ" > > To nevypad? jako z?pis vhodn? pro strojov? zpracov?n?. N?co lep??ho by > nebylo?

> On Fri, Oct 30, 2009 at 02:14:43PM +0100, hanoj wrote: > > *** dnes mame aparat administrativnich hranic, ktere jednoznacne mohou > > rozlisovat spravni uzemi a tedy napr. i hranice obce, kraje, statu. > > boundary=administrative > Toto zni jako pekne reseni, ale je pro nas dulezite > administrativni zacleneni, nebo velikost zastavene oblasti? > > Aneb je treba asi resit dva problemy: > 1. Jakemu mestu patri jaka ulice, popripade jake ulici patri > jaky popisny bod. Tento problem musi resit navigace.

> 2. Nejak byt schopni vykreslit zastavenou oblast jako polygon a > nejlip tomu priradit jmenovku mesta, kteremu to patri. Toto resi > Ivo a letecka mapa.

> On Fri, 30 Oct 2009 13:37:20 +0100, Martin Kupec <magon na jkopava.cz> wrote: > > > On Fri, Oct 30, 2009 at 01:29:42PM +0100, Petr Dlouh? wrote: > >> On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> > >> wrote: > >> > >> Ano, mysl?m, ?e by to m?lo b?t zpracov?no strojov?, a to a? ve f?zi > >> posprocessingu, tedy by tyto informace nem?li b?t p??mou sou??st? OSM, > >> proto?e jsou tam duplicitn?. Sou??st? OSM by m?li b?t pouze data jako > >> hranice m?sta, hranice st?tu a dal?? hranice oblast?. U? tag is_in, > >> kter? > >> se pou??v? u obc? mi p?ijde nadbyte?n?. > > Neni spis nadbytecna hranice mesta? Mi prijde skoro lepsi, a > > hlavne jednodussi na zmapovani pridavat k silnicim flags > > "is_in" a v posprocessingu kolem takovychto silnic udelat > > polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta > > nejspis neni uplne dulezita informace, mestu mohou patrit i > > rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou > > a zobrazovanim zastavene oblasti. > > > > Martin Kupec > > To si nemysl?m. > P?edev??m bude velk? probl?m uhl?dat, aby byli v?echny ulice > otagovan?.

> M?lokdo (speci?ln? ne nov??ci) bude myslet na to, ?e kdy? d?l? ulici, tak > mus? je?t? doplnit, kam pat??. Pokud budou dv? m?sta propojen?, tak se > p?isp?vatel mus? zab?vat t?m, kde kter? m?sto je v moment?, kdy pouze chce > nakreslit n?kolik ulic. N?kolikr?t se mi stalo, ?e se m?sto, kter? jsem > hledal nena?lo, proto?e nem?lo vypln?n? is_in tagy, a to je m?st p?r > oproti po?tu ulic. > Nav?c je probl?m s ov??itelnost?, proto?e pokud tam n?kdo omylem nap??e > sousedn? m?sto, tak si toho pravd?podobn? nikdo nev?imne, a pokud ano, tak > bude muset slo?it? zji??ovat jestli ulice pat?? do m?sta, nebo do sousedn? > vesnice.

> On Fri 2009-10-30 13:20:04, Petr Stehlik wrote: > > Zdar, > > > > te? si st??oval autor Navitu, ?e v OSM mu chyb? vazby mezi objekty: > > > > - do kter?ho m?sta pat?? dan? ulice > > - do kter?ho st?tu pat?? dan? m?sto > > U vsech ceskych mest/vesnic jsem jednou dodelal is_in tag -- presne > kvuli navitu.

> > "is_in" = "Zl?n, Zl?nsk? kraj, CZ" > > > > To nevypad? jako z?pis vhodn? pro strojov? zpracov?n?. N?co lep??ho by > > nebylo? > > O nicem nevim, neco by to chtelo. is_in relaci?

> On Fri, Oct 30, 2009 at 01:29:42PM +0100, Petr Dlouhý wrote: > >> On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> >> wrote: >> >> Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi >> posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, >> protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako >> hranice města, hranice státu a další hranice oblastí. Už tag is_in, který >> se používá u obcí mi přijde nadbytečný. >> > Neni spis nadbytecna hranice mesta? Mi prijde skoro lepsi, a > hlavne jednodussi na zmapovani pridavat k silnicim flags > "is_in" a v posprocessingu kolem takovychto silnic udelat > polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta > nejspis neni uplne dulezita informace, mestu mohou patrit i > rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou > a zobrazovanim zastavene oblasti. > > Martin Kupec > >

> _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Pavel Machek píše v So 31. 10. 2009 v 19:42 +0100: > >> On Fri 2009-10-30 13:20:04, Petr Stehlik wrote: >> >>> Zdar, >>> >>> te? si st??oval autor Navitu, ?e v OSM mu chyb? vazby mezi objekty: >>> >>> - do kter?ho m?sta pat?? dan? ulice >>> - do kter?ho st?tu pat?? dan? m?sto >>> >> U vsech ceskych mest/vesnic jsem jednou dodelal is_in tag -- presne >> kvuli navitu. >> > > zkusim mu to tedy takto podat. Ovsem ptal se jeste na ulice, tam jsme > bezradni? boundary=administrative jsem nikdy v mape nevidel - to je > nejaky viditelny polygon okolo obce ci casti obce? > >

>>> "is_in" = "Zl?n, Zl?nsk? kraj, CZ" >>> >>> To nevypad? jako z?pis vhodn? pro strojov? zpracov?n?. N?co lep??ho by >>> nebylo? >>> >> O nicem nevim, neco by to chtelo. is_in relaci? >> > > spis jsem mel na mysli, ze seznam hodnot oddelenych carkami, kdy navic > neni zrejme, co je co... Ale ted jsem v mape zahledl is_in:country_code, > to vypadalo pro strojove zpracovani precejen lepe. > > Petr > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> >>> - do kter?ho m?sta pat?? dan? ulice > >>> - do kter?ho st?tu pat?? dan? m?sto > >>> > >> U vsech ceskych mest/vesnic jsem jednou dodelal is_in tag -- presne > >> kvuli navitu. > >> > > > > zkusim mu to tedy takto podat. Ovsem ptal se jeste na ulice, tam jsme > > bezradni? boundary=administrative jsem nikdy v mape nevidel - to je > > nejaky viditelny polygon okolo obce ci casti obce? > > > > > Boundary administrative vetsinou videt normalne je ;)

> Vzhledem k ucelu, co takhle algoritmus ktery najde nejblizsi place ? > Minemo ze ulice patri obci (name) ktera je nejbliz.

>>        Aneb je treba asi resit dva problemy: >>        1. Jakemu mestu patri jaka ulice, popripade jake ulici patri >>        jaky popisny bod. Tento problem musi resit navigace. >>        2. Nejak byt schopni vykreslit zastavenou oblast jako polygon a >>        nejlip tomu priradit jmenovku mesta, kteremu to patri. Toto resi >>        Ivo a letecka mapa. >> >>        Prvni problem je nejlepe resitelny administrativnimi hranicemi, >>        je nerendundantni a je treba pridat relativne malo hranic, vudci >>        pridavani tagu kazde ulici. > *** ano. byva zvykem to takto resit. > >>        Druhy problem by se asi dal resit tak, ze se vyresi prvni a pak >>        se vezmou ulic/domy z dane oblasti a kolem nich se udela >>        konvexni obal, coz by melo jit jednoduchym algoritmem. > *** zastavene uzemi obce je plovouci urbanisticky termin. Nema jasnou > definici v mape, respektive dale existuje jeste termin nezastavitelne > uzemi, nezastavene uzemi. > Je to zajimava knedla v mape, zvlaste pokud nemam zakresleny stavebni > objekty. Dnes pro zastavene uzemi pouzivame landuse=residential, coz > je trochu nestastne, nebo pro urbanizovanou krajinu je mozno vymyslet > dalsich X landuse. > Tim chci rici ano, ale problem je trosicku komplikovejsi uz od > definice, pres tagovani az po provedeni. > >>        Otazka tedy zni...da se nekde sehnat zdroj ktery popise >>        administrativni hranice? A jestli ke kazdemu administrativnimu >>        celku pridame hranici, tak uz to asi bude chtit nejak rozclenit >>        do vrstev, to tusim bylo neco na cem se pracuje, ale netusim v >>        jakem je stavu. > *** ano mame prehledky CUZK. Automatizovane vektorizovane, jen je > potreba, aby nekdo udelal OCR, spojil to dohromady, vygeneroval > relace, rucne zacistil. Muzete pomoci? > > > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Existuje mapa katastrálních území ve formátech shx/dwg, z toho by se > dala velká část administrativních hranic získat. Mělo by to být > PD-czech-gov

> Existuje mapa katastrálních území ve formátech shx/dwg, z toho by se > dala velká část administrativních hranic získat. Mělo by to být > PD-czech-gov > > J&D > > Dne 30. října 2009 14:45 hanoj <ehanoj na gmail.com> napsal(a): >>> Aneb je treba asi resit dva problemy: >>> 1. Jakemu mestu patri jaka ulice, popripade jake ulici patri >>> jaky popisny bod. Tento problem musi resit navigace. >>> 2. Nejak byt schopni vykreslit zastavenou oblast jako polygon a >>> nejlip tomu priradit jmenovku mesta, kteremu to patri. Toto resi >>> Ivo a letecka mapa. >>> >>> Prvni problem je nejlepe resitelny administrativnimi hranicemi, >>> je nerendundantni a je treba pridat relativne malo hranic, vudci >>> pridavani tagu kazde ulici. >> *** ano. byva zvykem to takto resit. >> >>> Druhy problem by se asi dal resit tak, ze se vyresi prvni a pak >>> se vezmou ulic/domy z dane oblasti a kolem nich se udela >>> konvexni obal, coz by melo jit jednoduchym algoritmem. >> *** zastavene uzemi obce je plovouci urbanisticky termin. Nema jasnou >> definici v mape, respektive dale existuje jeste termin nezastavitelne >> uzemi, nezastavene uzemi. >> Je to zajimava knedla v mape, zvlaste pokud nemam zakresleny stavebni >> objekty. Dnes pro zastavene uzemi pouzivame landuse=residential, coz >> je trochu nestastne, nebo pro urbanizovanou krajinu je mozno vymyslet >> dalsich X landuse. >> Tim chci rici ano, ale problem je trosicku komplikovejsi uz od >> definice, pres tagovani az po provedeni. >> >>> Otazka tedy zni...da se nekde sehnat zdroj ktery popise >>> administrativni hranice? A jestli ke kazdemu administrativnimu >>> celku pridame hranici, tak uz to asi bude chtit nejak rozclenit >>> do vrstev, to tusim bylo neco na cem se pracuje, ale netusim v >>> jakem je stavu. >> *** ano mame prehledky CUZK. Automatizovane vektorizovane, jen je >> potreba, aby nekdo udelal OCR, spojil to dohromady, vygeneroval >> relace, rucne zacistil. Muzete pomoci? >> >> >> hanoj >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > >

> Dobry vecer vespolek! > > > A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve > > ktery je zemi? > > Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, > ve kterych objekty z daneho uzemi lezi?

> > Ne ne, to nebude fungovat. > > > > Takze jo, predstavuju si, ze u kazdy ulice bude > > is_in=<jmeno_mesta> a u kazdyho mesta pak bude is_in=CR . > > Prijde mi hloupe udrzovat v mape informace, ktere jsou z principu > redundantni -- pokud je prislusnost k mestu definovana jako lezeni > uvnitr hranice mesta, ma byt reprezentovana tou hranici, ne nejakymi > odvozenymi atributy. Ty se preci mohou kdykoliv dopocitat podle > potreby.

> On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> > wrote: > > Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi > posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, > protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako > hranice města, hranice státu a další hranice oblastí. Už tag is_in, který > se používá u obcí mi přijde nadbytečný. > >> Zdar, >> >> teď si stěžoval autor Navitu, že v OSM mu chybí vazby mezi objekty: >> >> - do kterého města patří daná ulice >> - do kterého státu patří dané město >> - které PSČ patří ke kterému městu/ulicím >> - a je-li daná ulice typu urban nebo rural (nevím, co tím přesně myslí, >> ale prý kvůli tomu vymyslel rural=yes, což já nikdy nikde nemapoval) >> >> měl jsem pocit, že ty vazby tam někde máme, že snad czechaddress plugin >> něco takového přidává? Aha, už jsem to našel: >> >> "is_in" = "Zlín, Zlínský kraj, CZ" >> >> To nevypadá jako zápis vhodný pro strojové zpracování. Něco lepšího by >> nebylo? >> >> Petr >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > >

> Martin Kupec napsal(a): > > On Fri, Oct 30, 2009 at 01:29:42PM +0100, Petr Dlouhý wrote: > > > >> On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> > >> wrote: > >> > >> Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi > >> posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, > >> protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako > >> hranice města, hranice státu a další hranice oblastí. Už tag is_in, který > >> se používá u obcí mi přijde nadbytečný. > >> > > Neni spis nadbytecna hranice mesta? Mi prijde skoro lepsi, a > > hlavne jednodussi na zmapovani pridavat k silnicim flags > > "is_in" a v posprocessingu kolem takovychto silnic udelat > > polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta > > nejspis neni uplne dulezita informace, mestu mohou patrit i > > rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou > > a zobrazovanim zastavene oblasti. > > > > Martin Kupec > > > > > Zdravim, > > me tedy prijde na realizaci jednodussi algoritmus zjistujici, zda je > neco uvnitr nejakeho polygonu. Nemluve o tom, ze hranice statu je > polygon, stejne jako hranice kraje, okresu ... . Chcete kazdou cesticku, > kazdy bod oznacovat "is_in=CR" ? To je preci nesmysl. Me by prislo > logicke, aby se toto urcovalo vyhradne na zaklade zacleneni do struktury > polygonu "boundary".

> A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve > ktery je zemi?

> Ne ne, to nebude fungovat. > > Takze jo, predstavuju si, ze u kazdy ulice bude > is_in=<jmeno_mesta> a u kazdyho mesta pak bude is_in=CR .

> Dobry vecer vespolek! > > >> A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve >> ktery je zemi? >> > > Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, > ve kterych objekty z daneho uzemi lezi? > > >> Ne ne, to nebude fungovat. >> >> Takze jo, predstavuju si, ze u kazdy ulice bude >> is_in=<jmeno_mesta> a u kazdyho mesta pak bude is_in=CR . >> > > Prijde mi hloupe udrzovat v mape informace, ktere jsou z principu > redundantni -- pokud je prislusnost k mestu definovana jako lezeni > uvnitr hranice mesta, ma byt reprezentovana tou hranici, ne nejakymi > odvozenymi atributy. Ty se preci mohou kdykoliv dopocitat podle potreby. > > Have a nice fortnight >

> On Tue 2009-11-03 18:46:02, Martin Mares wrote: >> Dobry vecer vespolek! >> >>> A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve >>> ktery je zemi? >> Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, >> ve kterych objekty z daneho uzemi lezi? > > To co se tu navrhuje ale nejsou relace, nybrz polygon okolo. > >>> Ne ne, to nebude fungovat. >>> >>> Takze jo, predstavuju si, ze u kazdy ulice bude >>> is_in=<jmeno_mesta> a u kazdyho mesta pak bude is_in=CR . >> Prijde mi hloupe udrzovat v mape informace, ktere jsou z principu >> redundantni -- pokud je prislusnost k mestu definovana jako lezeni >> uvnitr hranice mesta, ma byt reprezentovana tou hranici, ne nejakymi >> odvozenymi atributy. Ty se preci mohou kdykoliv dopocitat podle >> potreby. > > Trochu hloupe to je, ale zase nemusi kazdy implementovat vypocet > znova (coz by bylo taky ne-chytre). > > 'Kdykoliv dopocitat' bohuzel neni vubec trivialni -- presne pro to ze > tu hranicii vubec nemusim mit ve stazenych datech. Navic veci jako > navit funguji offline a konveruji mezi ruznymi formaty...

> > Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, > > ve kterych objekty z daneho uzemi lezi? > > To co se tu navrhuje ale nejsou relace, nybrz polygon okolo.

> A nebo jeste jinak -- predstavuju si, ze kdyz mam adresni bod, ziskam > jeho plnou adresu nekolika malo dotazy... ('v jake je relaci? aha, bod > je v relaci k ulici. V jakych ze ta je relacich? aha, tady je mestska > cast a za ni mesto)... a ne tim ze stahnu uplne nesouvisejici body z > 10x10 km okoli a hledam hranice. Ktera tam potencielne neni -- to pak > stahnu cely svet?

> On Sat 2009-10-31 23:50:06, jzvc wrote: > >> Martin Kupec napsal(a): >> >>> On Fri, Oct 30, 2009 at 01:29:42PM +0100, Petr Dlouhý wrote: >>> >>> >>>> On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> >>>> wrote: >>>> >>>> Ano, myslím, že by to mělo být zpracováno strojově, a to až ve fázi >>>> posprocessingu, tedy by tyto informace neměli být přímou součástí OSM, >>>> protože jsou tam duplicitní. Součástí OSM by měli být pouze data jako >>>> hranice města, hranice státu a další hranice oblastí. Už tag is_in, který >>>> se používá u obcí mi přijde nadbytečný. >>>> >>>> >>> Neni spis nadbytecna hranice mesta? Mi prijde skoro lepsi, a >>> hlavne jednodussi na zmapovani pridavat k silnicim flags >>> "is_in" a v posprocessingu kolem takovychto silnic udelat >>> polygony a to prohlasit za uzemi mesta. Katastralni uzemi mesta >>> nejspis neni uplne dulezita informace, mestu mohou patrit i >>> rozlehla okolni pole. Tohle by i resilo problem s leteckou mapou >>> a zobrazovanim zastavene oblasti. >>> >>> Martin Kupec >>> >>> >>> >> Zdravim, >> >> me tedy prijde na realizaci jednodussi algoritmus zjistujici, zda je >> neco uvnitr nejakeho polygonu. Nemluve o tom, ze hranice statu je >> polygon, stejne jako hranice kraje, okresu ... . Chcete kazdou cesticku, >> kazdy bod oznacovat "is_in=CR" ? To je preci nesmysl. Me by prislo >> logicke, aby se toto urcovalo vyhradne na zaklade zacleneni do struktury >> polygonu "boundary". >> > > A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve > ktery je zemi? > > Ne ne, to nebude fungovat. > > Takze jo, predstavuju si, ze u kazdy ulice bude > is_in=<jmeno_mesta> a u kazdyho mesta pak bude is_in=CR . > Pavel > >

> jen podotykam, ze tag is_in pro ulici je problematicky jeste z duvodu, > ze existuji situace, kde je jedna ulice jednoho nazvu soucasti vice > obci. Jinak drzet i u online navigace geopoliticke deleni na urovni > statu lokalne mi prijde vice nez vhodne. Hranice se precijen kazdy den > nemeni. Takze zjistit v jakem state se zrovna nachazim = podivat se > uvnitr jake hranice prave jsou souradnice z GPS. > Offline navigace si muze potrebna data dopocitat kdykoli, tam bych > nevidel vubec zadny problem.

> Pavel Machek napsal(a): > > On Tue 2009-11-03 18:46:02, Martin Mares wrote: > >> Dobry vecer vespolek! > >> > >>> A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve > >>> ktery je zemi? > >> Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, > >> ve kterych objekty z daneho uzemi lezi? > > > > To co se tu navrhuje ale nejsou relace, nybrz polygon okolo. > > > >>> Ne ne, to nebude fungovat. > >>> > >>> Takze jo, predstavuju si, ze u kazdy ulice bude > >>> is_in=<jmeno_mesta> a u kazdyho mesta pak bude is_in=CR . > >> Prijde mi hloupe udrzovat v mape informace, ktere jsou z principu > >> redundantni -- pokud je prislusnost k mestu definovana jako lezeni > >> uvnitr hranice mesta, ma byt reprezentovana tou hranici, ne nejakymi > >> odvozenymi atributy. Ty se preci mohou kdykoliv dopocitat podle > >> potreby. > > > > Trochu hloupe to je, ale zase nemusi kazdy implementovat vypocet > > znova (coz by bylo taky ne-chytre). > > > > 'Kdykoliv dopocitat' bohuzel neni vubec trivialni -- presne pro to ze > > tu hranicii vubec nemusim mit ve stazenych datech. Navic veci jako > > navit funguji offline a konveruji mezi ruznymi formaty... > > A specialne pro offline navigaci s konverzi formatu tam ty atributy > nejsou potreba. Konverzni algoritmus ma dost casu a prenosovky na to, > aby si stahnul tu (napr.) Ceskou Republiku celou a dopocital si to v

> Ahoj! > > > > Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, > > > ve kterych objekty z daneho uzemi lezi? > > > > To co se tu navrhuje ale nejsou relace, nybrz polygon okolo. > > A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji > s danym uzemim neprazdny prunik?

> > jen podotykam, ze tag is_in pro ulici je problematicky jeste z duvodu, > > ze existuji situace, kde je jedna ulice jednoho nazvu soucasti vice > > obci. Jinak drzet i u online navigace geopoliticke deleni na urovni > > statu lokalne mi prijde vice nez vhodne. Hranice se precijen kazdy den > > nemeni. Takze zjistit v jakem state se zrovna nachazim = podivat se > > uvnitr jake hranice prave jsou souradnice z GPS. > > Offline navigace si muze potrebna data dopocitat kdykoli, tam bych > > nevidel vubec zadny problem. > > Tohle by slo udelat treba tak, ze se z planet dumpu (pripadne z dumpu, > kde je alespon cely stat, jako napriklad dumpy ceske republiky) udela > vycuc jen hranic (cimz by pak ten soubor mel vcelku rozumnou velikost) > a nekde se zpublikuje. Tenhle soubor s hranicemi by pak sel pouzit v > navigaci pokud si tam chce slovek nacpat mensi kus nez jeden stat (v > dumpech statu jsou i hranice kolem toho dotycneho statun a nic > "vetsiho" uz v datech neexistuje - hranice kontinentu tam myslim > nejsou a hranice zemekoule je jeden "ctverec", ktery si kazdy muze > vygenerovat sam :). Navic pokud se cela hranice nachazi vne stazene > oblasti, tak navigace ji nemusi resit - proste vsechny adresy se > nachazi v jednom state/meste, at uz je to cokoliv, neni pak potreba > resit problem typu ze ulice Prazska je v skoro kazdem vetsim meste ci > vesnici ve stredoceskem kraji.

> > A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji > > s danym uzemim neprazdny prunik? > > Stacilo, ale on to AFAIK neumi.

> > > A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji > > > s danym uzemim neprazdny prunik? > > > > Stacilo, ale on to AFAIK neumi. > > > A neni lepsi to ten protokol naucit, misto abychom zavadeli ruzne > berlicky v podobe tagovani vsech objektu atributem is_in?

> Ahoj, > > na hlavní stránce (http://www.openstreetmap.org/) se dnes objevil nový > druh hledání - Nominatim (http://nominatim.openstreetmap.org/). Toto > hledání dává výsledky ve tvaru například "Horoměřice, Praha, Praha-západ, > Středočeský kraj, Česká Republika". Vzhledem k tomu, že žádná s těch > informací není v bodu Horoměřic obsažena (kromě České Republiky) usuzuji, > že si je stránka sama spočítala na základě hranic oblastí. > > Nominatim musí mít tyto informace uloženy v databázi, takže by neměl být > problém databázi exportovat do nějakého použitelného formátu a použít pro > účely navigací nebo jakýchkoliv dalších aplikací. > >

> Potvrzuju, pocita to nejspis (spravne) z hranic. > Test proveden hledanim Rtyně nad Bílinou > http://nominatim.openstreetmap.org/details.php?place_id=253868 (ma > definovany administrativni hranice) a Komořany > http://nominatim.openstreetmap.org/details.php?place_id=2003330 (nema > napr okres a ve vypisu taky chybi). Co je zajimave, ze u te Rtyne je > zahrnuto napr Usti (s timto polygonem > http://nominatim.openstreetmap.org/details.php?place_id=1710213), coz > je spatne (cely ten polygon je nesmysl). Ten polygon je nejak > generovany, rozhodne neni v mape. Takze algoritmus zdaleka neni > optimalni. Vypada to, ze pokud jde o administrative, obkresli hranice. > Pokud jde o obec, pokusi se to nejak ? odhadnout. Du zjistit, zda se mu > da nejak predhodit konkretni spravna hranice obce. > > Vidim tam taky jednu chybku ;), v pripade administrative zobrazi mapu > odzoomovanou tak, ze neni nic videt (hranice). > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Jinak na <http://wiki.openstreetmap.org/wiki/Nominatim> je popsáno, jak se > dají výsledky hledání stahovat v XML, což by bylo ideální pro další > použití v různých aplikacích. Akorát se mi nepodařilo získat všechny > výsledky pro nějakou oblast. > >

> On Wed, 11 Nov 2009 21:12:10 +0100, jzvc <jzvc na tpfree.fdns.net> wrote: > > >> Potvrzuju, pocita to nejspis (spravne) z hranic. >> Test proveden hledanim Rtyně nad Bílinou >> http://nominatim.openstreetmap.org/details.php?place_id=253868 (ma >> definovany administrativni hranice) a Komořany >> http://nominatim.openstreetmap.org/details.php?place_id=2003330 (nema >> napr okres a ve vypisu taky chybi). Co je zajimave, ze u te Rtyne je >> zahrnuto napr Usti (s timto polygonem >> http://nominatim.openstreetmap.org/details.php?place_id=1710213), coz >> je spatne (cely ten polygon je nesmysl). Ten polygon je nejak >> generovany, rozhodne neni v mape. Takze algoritmus zdaleka neni >> optimalni. Vypada to, ze pokud jde o administrative, obkresli hranice. >> Pokud jde o obec, pokusi se to nejak ? odhadnout. Du zjistit, zda se mu >> da nejak predhodit konkretni spravna hranice obce. >> >> Vidim tam taky jednu chybku ;), v pripade administrative zobrazi mapu >> odzoomovanou tak, ze neni nic videt (hranice). >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > >

> Existuje mapa katastrálních území ve formátech shx/dwg, z toho by se > dala velká část administrativních hranic získat. Mělo by to být > PD-czech-gov

> Ahoj, > > mohl bys prosím rozvést kde se dají taková data získat, a jestli jsou > opravdu public domain? > Na > <http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998&MENUID=0&AKCE=DOC:30-ZU_DM_HRAN> > se dají podobná data koupit - nejsou tedy, předpokládám, pod public domain. > > Teď jsou výsledky hledání závislé na hranicích jednotlivých správních > územích v mapě. Je pravděpodobné, že se toho v budoucnu bude využívat i v > navigacích a jiných aplikacích. Bylo by tedy dobré hranice do mapy > importovat (pokud to licence umožňuje), a to buď přes OCR přehledek, a > nebo ze souboru, o kterém si mluvil.

> Admin hranice z prehledek se snazim importovat. Jde to > pomalu(nemam tolik casu co jsem doufal a grass mi hazi klacky > pod nohy), ale doufam ze se to v blizke budoucnosti povede. > Martin Kupec

> Je možné nějakým způsobem pomoct? > > On Fri, 13 Nov 2009 09:44:09 +0100, Martin Kupec <magon na jkopava.cz> wrote: > >> Admin hranice z prehledek se snazim importovat. Jde to >> pomalu(nemam tolik casu co jsem doufal a grass mi hazi klacky >> pod nohy), ale doufam ze se to v blizke budoucnosti povede. >> Martin Kupec