vazby?

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

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

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

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.

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, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> 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

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?

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

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

       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?

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.

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

       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.

       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?

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

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?

*** 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, 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:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> 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, 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.

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 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, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> 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

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:

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?

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.

- 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

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.

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

On Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> 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".

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 .

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

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

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.

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 Fri, 30 Oct 2009 13:20:04 +0100, Petr Stehlik <pstehlik na sophics.cz> 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

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.

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.

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

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?

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.

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

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

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.

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.

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?

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