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

[Talk-cz] Import chráněných území z EEA

Vlákno 15.2. - 22.3.2012, počet zpráv: 23


15.2.2012 07:10:32 (#1)
gravatar

Jan Kučera

<kozuch82 at gmail.com>
23
Zdravím, chystám se k plošnému importu chráněných území z EEA - tedy NPR, NPP atd. CHKO jsou již hotové. Dataset pro celou Evropu je dostupný zde: http://www.eea.europa.eu/data-and-maps/data/nationally-designated-areas-national-cdda-5 jedná se o soubor CDDA_v9_polygons.zip Jedná se o shapefile, který má hezká metadata. Předpokládám, že máme u nás pouze minimum těchto území zpamovaných a duplicity budou tedy spíše vyjímkou a bude možné je časem pořešit. Snad nikdo nepředloží výrazně závažný důvod bránící importu. Zdravím, Kozuch

15.2.2012 10:10:46 (#2)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
Jan Kučera wrote: zobrazit citaci
> CHKO jsou již hotové.
Páráda, na pár místech jsem si už všiml, teď koukám i na další místa... zobrazit citaci
> Dataset pro celou Evropu je dostupný zde: > > http://www.eea.europa.eu/data-and-maps/data/nationally-designated-areas-national-cdda-5 > jedná se o soubor CDDA_v9_polygons.zip > > Jedná se o shapefile, který má hezká metadata. Předpokládám, že máme u > nás pouze minimum těchto území zpamovaných a duplicity budou tedy > spíše vyjímkou a bude možné je časem pořešit. > > Snad nikdo nepředloží výrazně závažný důvod bránící importu.
Já bych měl pár připomínek/námětů obecně k importu a tagování. 1) Tag name na cestách - je zbytečné a dokonce bych řekl nežádoucí dávat tag name na cestu hranice, ten patří na relaci. Už třeba proto, že části hranic jsou sdílené více oblastmi stejného druhu. 2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená hranice mezi CHKO Železné hory a Žďárské vrchy. (Námět pro ty, co se nudí: sloučení s cestami administrativních hranic na úsecích, které jsou totožné). 3) Více metadat - když už tam jsou taková pěkná metadata, použijme je; inspirace pro tagování [1]. A stejným způsobem je i doplnit zpětně i na CHKO a NP. Co si myslím, že by bylo dobré: - ref tagy pro snažší aktualizace v budoucnosti - důsledně používat protection_title=NP,CHKO,NPP,... (samozřejmě celými slovy) a pravděpodobně to vyhodit z tagu name. - tag protect_class - vymyslet tag, do kterého by se dal rok vyhlášení 4) Mysleme trochu do budoucna - zdá se, že tento datový zdroj bude udržován mimo OSM i v budoucnosti. Zkusme provést import tak, aby jej bylo možné v budoucnosti snadno aktualizovat. 5) Detekce duplicit - i když jich (asi) nebude mnoho, tak by nám import měl dát alespoň jejich seznam, aby bylo jasné co a kde opravovat. 6) Provést import tak, jak by se mělo - pod spešl účtem. 7) Je na zváženou, zda s importem ještě chvíli nepočkat a provést jej až po změně licence, aby někdo nechtěně čerstvou cestu "neotrávil" licenčně nekompatibilním uzlem, relaci cestou apod. Zdraví, Petr Morávek aka Xificurk [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area ------------- další část --------------- A non-text attachment was scrubbed... Name: xificurk.vcf Type: text/x-vcard Size: 212 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120215/2137fe1f/attachment.vcf> ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120215/2137fe1f/attachment.sig>

15.2.2012 10:43:41 (#3)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
93
zobrazit citaci
> 2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic > přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a > přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená > hranice mezi CHKO Železné hory a Žďárské vrchy. > (Námět pro ty, co se nudí: sloučení s cestami administrativních hranic > na úsecích, které jsou totožné).
Hranice CHKO a asi i dalších chráněných území (aspoň těch velkoplošných) jsou definované nejen pomocí administrativních hranic, ale i různými přírodními hranicemi - řeka, silnice apod. Průběh hranice je určený ve vyhlášce o zřízení daného chráněného území - příklad [1] IMHO nejčistší řešení by bylo chráněná do OSM přidat jako relace, kde členové té relace by byli objekty (silnice, řeky, administrativní hranice), tak jak jsou definované v příslušné vyhlášce. [1] old.ochranaprirody.cz/res/data/012/002287.pdf

15.2.2012 11:29:25 (#4)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 15.2.2012 22:43, Lukas Kabrt napsal(a): zobrazit citaci
>> 2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic >> přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a >> přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená >> hranice mezi CHKO Železné hory a Žďárské vrchy. >> (Námět pro ty, co se nudí: sloučení s cestami administrativních hranic >> na úsecích, které jsou totožné). > Hranice CHKO a asi i dalších chráněných území (aspoň těch > velkoplošných) jsou definované nejen pomocí administrativních hranic, > ale i různými přírodními hranicemi - řeka, silnice apod. Průběh > hranice je určený ve vyhlášce o zřízení daného chráněného území - > příklad [1] > > IMHO nejčistší řešení by bylo chráněná do OSM přidat jako relace, kde > členové té relace by byli objekty (silnice, řeky, administrativní > hranice), tak jak jsou definované v příslušné vyhlášce.
Tohle by prave bylo dost nestastny, protoze se to pak blbe modifikuje. Silnice muze byt trebas z ruznych duvodu posunuta, ale to (predpokladam) nezmeni hranici chko. Vubec nemluve o tom, ze je to jen virtualni hranice => melo by to mit svoji caru se kterou lze pripadne nezavisle hybat. Je to stejny jako administrativni hranice, tam se taky kvuli udrzbe zavrhlo pouziti trebas potoku a je to samostatna cara, ac hranice vede trebas v ose vodniho toku. Jenze jinde vede po brehu a s chko to bude podobny ... + samozrejme pokud budu chtit tu hranici nejak vyuzit, trebas pro nejaky overlay, tak vazne nechci aby se mi zaroven s tim postahovali trebas znacky natagovane k silnici. Zkratka nemixoval bych v relacich fyzicke a virtualni objekty mapy. zobrazit citaci
> > [1] old.ochranaprirody.cz/res/data/012/002287.pdf > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

15.2.2012 11:52:44 (#5)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Souhlasím s body 1-6 Petra Morávka a s Lukášem Kabrtem. Pokud je oblast definována zákonem jako jdoucí potokem/břehem/středem silnice/podél administrativní hranice tak by měla využívat tyto prvky jako svou hranici i v OSM. To znamená ,že v relaci (multipolygonu) bude potok nebo část multipolygonu waterway=riverbank. Pokud jde po silnici, tak bude obsahovat silnici nebo jinou hranici. Naopak pokud jde po břehu/kraji silnice tak by rozhodně neměla být nijak napojena na vlastní čáru toku nebo silnice. Důvodem je, že hranice bude následovat osud těchto prvků - při změně toku potoka nebo trasy silnice se pohne i hranice oblasti. Platí to samozřejmě i pro administrativní hranice, které jsou z definice tvořeny potokem. Úplně jiná situace by byla, kdyby byla hranice definována souřadnicemi a náhodou šla podél něčeho, potom není spojování na místě. V závislosti na přesnosti dat by nebylo od věci uvažovat o použití tvarů pro zpřesnění těch cest/potoků... @jzvc: Pokud budeš chtít hranici využít tak máš informace o tom, co tu hranici tvoří, to s tím dost silně souvisí (i když se to nemusí vždy hodit). Tagy vztahující se k oblasti by samozřejmě měly být jen na tom multipolygonu, na čárách jen servisní (source...) a označení hranice (silnice, plot) Protože jde o evropská data, budou pravděpodobně k dispozici ve více zemích, bylo by proto vhodné se podívat jestli už někdo něco neimportoval a pokud ano tak použít hotové nástroje a zachovat konzistentní tagování. Pokud ne tak oznámit import i zahraničně, aby to mohl udělat zahraniční importér stejně. Lukáš Matějka (LM_1) 2012/2/15 jzvc <jzvc na tpfree.net>: zobrazit citaci
> Dne 15.2.2012 22:43, Lukas Kabrt napsal(a): >>> 2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic >>> přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a >>> přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená >>> hranice mezi CHKO Železné hory a Žďárské vrchy. >>> (Námět pro ty, co se nudí: sloučení s cestami administrativních hranic >>> na úsecích, které jsou totožné). >> Hranice CHKO a asi i dalších chráněných území (aspoň těch >> velkoplošných) jsou definované nejen pomocí administrativních hranic, >> ale i různými přírodními hranicemi - řeka, silnice apod. Průběh >> hranice je určený ve vyhlášce o zřízení daného chráněného území - >> příklad [1] >> >> IMHO nejčistší řešení by bylo chráněná do OSM přidat jako relace, kde >> členové té relace by byli objekty (silnice, řeky, administrativní >> hranice), tak jak jsou definované v příslušné vyhlášce. > Tohle by prave bylo dost nestastny, protoze se to pak blbe modifikuje. > Silnice muze byt trebas z ruznych duvodu posunuta, ale to (predpokladam) > nezmeni hranici chko. Vubec nemluve o tom, ze je to jen virtualni > hranice => melo by to mit svoji caru se kterou lze pripadne nezavisle > hybat. Je to stejny jako administrativni hranice, tam se taky kvuli > udrzbe zavrhlo pouziti trebas potoku a je to samostatna cara, ac hranice > vede trebas v ose vodniho toku. Jenze jinde vede po brehu a s chko to > bude podobny ... > > + samozrejme pokud budu chtit tu hranici nejak vyuzit, trebas pro nejaky > overlay, tak vazne nechci aby se mi zaroven s tim postahovali trebas > znacky natagovane k silnici. > > Zkratka nemixoval bych v relacich fyzicke a virtualni objekty mapy. > >> >> [1] old.ochranaprirody.cz/res/data/012/002287.pdf >> >> _______________________________________________ >> 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

16.2.2012 12:54:52 (#6)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 15.2.2012 23:52, LM_1 napsal(a): zobrazit citaci
> Souhlasím s body 1-6 Petra Morávka a s Lukášem Kabrtem. > Pokud je oblast definována zákonem jako jdoucí potokem/břehem/středem > silnice/podél administrativní hranice tak by měla využívat tyto prvky > jako svou hranici i v OSM. > > To znamená ,že v relaci (multipolygonu) bude potok nebo část > multipolygonu waterway=riverbank. Pokud jde po silnici, tak bude > obsahovat silnici nebo jinou hranici. > > Naopak pokud jde po břehu/kraji silnice tak by rozhodně neměla být > nijak napojena na vlastní čáru toku nebo silnice. > > Důvodem je, že hranice bude následovat osud těchto prvků - při změně > toku potoka nebo trasy silnice se pohne i hranice oblasti. Platí to > samozřejmě i pro administrativní hranice, které jsou z definice > tvořeny potokem. > > Úplně jiná situace by byla, kdyby byla hranice definována souřadnicemi > a náhodou šla podél něčeho, potom není spojování na místě. > > > V závislosti na přesnosti dat by nebylo od věci uvažovat o použití > tvarů pro zpřesnění těch cest/potoků... > > > @jzvc: Pokud budeš chtít hranici využít tak máš informace o tom, co tu > hranici tvoří, to s tím dost silně souvisí (i když se to nemusí vždy > hodit). > > > Tagy vztahující se k oblasti by samozřejmě měly být jen na tom > multipolygonu, na čárách jen servisní (source...) a označení hranice > (silnice, plot) > > Protože jde o evropská data, budou pravděpodobně k dispozici ve více > zemích, bylo by proto vhodné se podívat jestli už někdo něco > neimportoval a pokud ano tak použít hotové nástroje a zachovat > konzistentní tagování. Pokud ne tak oznámit import i zahraničně, aby > to mohl udělat zahraniční importér stejně. > > Lukáš Matějka (LM_1)
Problem je prave trebas to, pokud ty hranice nekdo bude casem chtit automaticky ze zdroje aktualizovat = v pripade pouziti silnice, potoka ... nerealne. Navic, to tak nelze ani importovat, musel bys to nasledne komplet rucne predelat, coz anuluje smysl importu. Nehlede na to, sem nejaky to chko zakresloval a klickuje to ruzne podel silnic, okraju lesa, hranic administrativnich celku ... a nekde to vede klido prostredkem pole ... Kde to vedlo soubezne s admin hranicema, tak tam sem je vyuzil, ale i to je dost sporny. zobrazit citaci
> > > 2012/2/15 jzvc <jzvc na tpfree.net>: >> Dne 15.2.2012 22:43, Lukas Kabrt napsal(a): >>>> 2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic >>>> přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a >>>> přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená >>>> hranice mezi CHKO Železné hory a Žďárské vrchy. >>>> (Námět pro ty, co se nudí: sloučení s cestami administrativních hranic >>>> na úsecích, které jsou totožné). >>> Hranice CHKO a asi i dalších chráněných území (aspoň těch >>> velkoplošných) jsou definované nejen pomocí administrativních hranic, >>> ale i různými přírodními hranicemi - řeka, silnice apod. Průběh >>> hranice je určený ve vyhlášce o zřízení daného chráněného území - >>> příklad [1] >>> >>> IMHO nejčistší řešení by bylo chráněná do OSM přidat jako relace, kde >>> členové té relace by byli objekty (silnice, řeky, administrativní >>> hranice), tak jak jsou definované v příslušné vyhlášce. >> Tohle by prave bylo dost nestastny, protoze se to pak blbe modifikuje. >> Silnice muze byt trebas z ruznych duvodu posunuta, ale to (predpokladam) >> nezmeni hranici chko. Vubec nemluve o tom, ze je to jen virtualni >> hranice => melo by to mit svoji caru se kterou lze pripadne nezavisle >> hybat. Je to stejny jako administrativni hranice, tam se taky kvuli >> udrzbe zavrhlo pouziti trebas potoku a je to samostatna cara, ac hranice >> vede trebas v ose vodniho toku. Jenze jinde vede po brehu a s chko to >> bude podobny ... >> >> + samozrejme pokud budu chtit tu hranici nejak vyuzit, trebas pro nejaky >> overlay, tak vazne nechci aby se mi zaroven s tim postahovali trebas >> znacky natagovane k silnici. >> >> Zkratka nemixoval bych v relacich fyzicke a virtualni objekty mapy. >> >>> [1] old.ochranaprirody.cz/res/data/012/002287.pdf >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

16.2.2012 02:17:02 (#7)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
zobrazit citaci
> Problem je prave trebas to, pokud ty hranice nekdo bude casem chtit > automaticky ze zdroje aktualizovat = v pripade pouziti silnice, potoka > ... nerealne.
Nereálné bych si tvrdit neodvážil, komplikované určitě. Ale data v OSM by měla být především přesná a celistvá, ne sbírka nezávislých importů. Pro takový případ by snad bylo lepší použít původní data. zobrazit citaci
> Navic, to tak nelze ani importovat, musel bys to nasledne > komplet rucne predelat, coz anuluje smysl importu.
Neimportují se jen tvary, ale i další (hezká) data, Importem se vytvoří multipolygony, u kterých je už snadné změnit část trasy. Každopádně to je dobrý první stupeň. Dosažení ideálního stavu bude vyžadovat ještě hodně práce, s tím souhlasím. Možná by nebylo od věci zkopírovat do nějakého komentáře popis průchodu hranice, aby byl po ruce při zpřesňování. Krátce po příchodu k OSM jsem se ptal, jaká přesnost úprav je požadována. Nejlepší odpověď byla "Tak aby mapa byla přesnější než před editací". zobrazit citaci
> Nehlede na to, sem > nejaky to chko zakresloval a klickuje to ruzne podel silnic, okraju > lesa, hranic administrativnich celku ... a nekde to vede klido > prostredkem pole ... Kde to vedlo soubezne s admin hranicema, tak tam > sem je vyuzil, ale i to je dost sporny.

17.2.2012 08:13:25 (#8)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
Ahoj! zobrazit citaci
> 7) Je na zváženou, zda s importem ještě chvíli nepočkat a provést jej až > po změně licence, aby někdo nechtěně čerstvou cestu "neotrávil" licenčně > nekompatibilním uzlem, relaci cestou apod.
OSM uz zakazal pristup vsem kdo nesloushlasili s CL/OdBL. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

17.2.2012 10:02:40 (#9)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
Pavel Machek wrote: zobrazit citaci
> Ahoj! > >> 7) Je na zváženou, zda s importem ještě chvíli nepočkat a provést jej až >> po změně licence, aby někdo nechtěně čerstvou cestu "neotrávil" licenčně >> nekompatibilním uzlem, relaci cestou apod. > > OSM uz zakazal pristup vsem kdo nesloushlasili s CL/OdBL. > Pavel
To sice ano, ale s daty, která "půjdou pryč" se dá stále manipulovat, tzn. je tu možnost přidat uzel, který brzo zmizí do cesty/cestu do relace. Petr Morávek aka Xificurk ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120217/f5a000ce/attachment.sig>

19.2.2012 03:09:34 (#10)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
Ahoj, koukal jsem na současný stav a tagování... tady je pár mých postřehů. V OSM jsou chráněná území momentálně tagována převážně třemi způsoby leisure=nature_reserve, boundary=national_park a potom novější obecnější způsob boundary=protected_area (bohužel oficiální mapnik zatím nekreslí). Navrhoval bych se přidržet systému boundary=protected_area [1] s použitím dalších tagů: - protection_title - celými slovy NP, CHKO, NPR, PR, NPP, PP; toto označení by pak už nemělo být v tagu name (s výjimkou NP?) - protect_class - ref - iucn_level - valid_from - pro rok vytvoření Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik renderovat) boundary=national_park. Ještě pár dalších věcí k NP: Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba na Šumavě ochranné pásmo je CHKO. Současný stav zmapování NP: * KRNAP Relace obsahovala mix cest hranic bez/s ochranného pásma; prozatím jsem relaci upravil tak, aby to aspoň byl platný polygon - ponechal jsem kompletnější hranice včtně ochranného pásma. Je potřeba upřesnit hranice ochranného pásma především okolo Vrchlabí, Některé cesty pro hranici vnitřních zón v databázi jsou, ale není jich moc. * Podyjí V OSM je dvakrát: - Nová relace (hranice včetně ochranného pásma). - Rozdělaný polygon (hranice bez ochranného pásma), kde chybí díra na Čížov, který je jen v ochranném pásmu. * Šumava, České Švýcarsko Vypadají celkem kompletně. Zdraví, Petr Morávek aka Xificurk [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120219/9b7b7a35/attachment.sig>

19.2.2012 04:31:05 (#11)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Ahoj zobrazit citaci
> Ahoj, > koukal jsem na současný stav a tagování... tady je pár mých postřehů. > > V OSM jsou chráněná území momentálně tagována převážně třemi způsoby > leisure=nature_reserve, boundary=national_park a potom novější obecnější > způsob boundary=protected_area (bohužel oficiální mapnik zatím nekreslí). > Navrhoval bych se přidržet systému boundary=protected_area [1] s > použitím dalších tagů:
Jsem pro zobrazit citaci
>  - protection_title - celými slovy NP, CHKO, NPR, PR, NPP, PP; toto > označení by pak už nemělo být v tagu name (s výjimkou NP?)
To by mělo záležet na názvu parku, většinou by tam asi to označení zůstalo zobrazit citaci
>  - protect_class >  - ref >  - iucn_level >  - valid_from - pro rok vytvoření
Použil bych spíš start_date, je rozšířenější. zobrazit citaci
> Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik > renderovat) boundary=national_park.
Když se budou dělat změny kvůli kompatibilitě s mapnikem tak nebude mít mapnik moc motivaci být měněn. zobrazit citaci
> > Ještě pár dalších věcí k NP: > Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl > pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné > pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba > na Šumavě ochranné pásmo je CHKO.
Na wiki je to popsané (site_zone), přidržel bych se toho zobrazit citaci
> > Současný stav zmapování NP: > * KRNAP > Relace obsahovala mix cest hranic bez/s ochranného pásma; prozatím jsem > relaci upravil tak, aby to aspoň byl platný polygon - ponechal jsem > kompletnější hranice včtně ochranného pásma. > Je potřeba upřesnit hranice ochranného pásma především okolo Vrchlabí, > Některé cesty pro hranici vnitřních zón v databázi jsou, ale > není jich moc. > > * Podyjí > V OSM je dvakrát: > - Nová relace (hranice včetně ochranného pásma). > - Rozdělaný polygon (hranice bez ochranného pásma), kde chybí díra na > Čížov, který je jen v ochranném pásmu. > > * Šumava, České Švýcarsko > Vypadají celkem kompletně. > > Zdraví, > Petr Morávek aka Xificurk > > [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
Lukáš Matějka

19.2.2012 10:54:21 (#12)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
LM_1 wrote: zobrazit citaci
>> - valid_from - pro rok vytvoření > Použil bych spíš start_date, je rozšířenější.
V kombinaci s boundary=protected_area není... Můj návrh byl motivován zmínkou daného tagu na wiki a jeho použitím při podobném importu ve Francii. zobrazit citaci
>> Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik >> renderovat) boundary=national_park. > Když se budou dělat změny kvůli kompatibilitě s mapnikem tak nebude > mít mapnik moc motivaci být měněn.
V tomhle jsem osobně opravdu na vážkách - ty čtyři parky v ČR to vážně nevytrhnou (narozdíl od stovek dalších chráněných území)... prozatím by se aspoň vykraslovaly, jakožto nejdůležitější chráněná území v ČR, a po změně stylu pro mapnik by stačilo jen změnit boundary=national_park -> boundary=protected_area zobrazit citaci
>> Ještě pár dalších věcí k NP: >> Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl >> pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné >> pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba >> na Šumavě ochranné pásmo je CHKO. > Na wiki je to popsané (site_zone), přidržel bych se toho
Osobně moc nerozumím tomu popisu na wiki a jak konkrétně ho převést do praxe, pokud mi to po lopatě někdo vysvětlí (a ukáže, že se to takto vážně aspoň trochu používá), tak to uvítám. Zdraví, Petr Morávek aka Xificurk ------------- další část --------------- A non-text attachment was scrubbed... Name: xificurk.vcf Type: text/x-vcard Size: 212 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120219/338f3668/attachment.vcf> ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120219/338f3668/attachment.sig>

19.2.2012 11:31:51 (#13)
gravatar

Jan Kučera

<kozuch82 at gmail.com>
23
Zdravím, s většinou, co bylo dosud řečeno, souhlasím. Na wiki jsem vytvořil stránku o importu http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas s návrhy mých překladů EEA shapefile tagů do OSM. Osobně bych byl pro to natagovat tak, aby se to vše vykreslovalo (national_park), ale to je dosti brutální řešení. Rendering protected_area by bylo potřeba urgentně pořešit, osobně jsem měl za to, že se již renderuje úplně stejně jako "national_park" - viděl jsem v tom jistou výhodu oproti "spamovacímu" tagu NR, který dává plošně text "NR" do území, myslel jsem, že to bylo výsledkem přirozeného vývoje v této oblasti. Bohužel dle mých krátkých zkušeností jsou změny nastavení mapniku asi těžko průchozí, že? Chtělo by to alespoň zatlačit ne nějakého patřičného kret*na, co to má nahoře nastarosti... Kozuch

19.2.2012 11:40:08 (#14)
gravatar

Jan Kučera

<kozuch82 at gmail.com>
23
PS. Nerenderuje se náhodou protected_area podle následujícího klíče? http://wiki.openstreetmap.org/wiki/Protected_Area_Rendering#Protected_Areas 2012/2/19 Jan Kučera <kozuch82 na gmail.com>: zobrazit citaci
> Zdravím, > > s většinou, co bylo dosud řečeno, souhlasím. Na wiki jsem vytvořil > stránku o importu > > http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas > > s návrhy mých překladů EEA shapefile tagů do OSM. Osobně bych byl pro > to natagovat tak, aby se to vše vykreslovalo (national_park), ale to > je dosti brutální řešení. Rendering protected_area by bylo potřeba > urgentně pořešit, osobně jsem měl za to, že se již renderuje úplně > stejně jako "national_park" - viděl jsem v tom jistou výhodu oproti > "spamovacímu" tagu NR, který dává plošně text "NR" do území, myslel > jsem, že to bylo výsledkem přirozeného vývoje v této oblasti. Bohužel > dle mých krátkých zkušeností jsou změny nastavení mapniku asi těžko > průchozí, že? Chtělo by to alespoň zatlačit ne nějakého patřičného > kret*na, co to má nahoře nastarosti... > > Kozuch

20.2.2012 12:07:44 (#15)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
Jan Kučera wrote: zobrazit citaci
> Zdravím, > > s většinou, co bylo dosud řečeno, souhlasím. Na wiki jsem vytvořil > stránku o importu > > http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas
Měl bych pár připomínek: eea:cdda:sitecode - nahradil bych něčím jako 'ref:cdda' eea:cdda:objectid - nevím jestli je nutné... stejně bude výsledek jako relace a rozdělení na jednotlivé cesty se pravděpodobně s časem změní. eea:cdda:parentiso - je zbytečné, kde se daná oblast nachází vyplývá přímo z její polohy. area:ha - je zbytečné, rozloha je dána vymezením geometrie start_date - na zváženou, viz odpověď LM_1 zobrazit citaci
> Rendering protected_area by bylo potřeba > urgentně pořešit, osobně jsem měl za to, že se již renderuje úplně > stejně jako "national_park" - viděl jsem v tom jistou výhodu oproti > "spamovacímu" tagu NR, který dává plošně text "NR" do území, myslel > jsem, že to bylo výsledkem přirozeného vývoje v této oblasti. Bohužel > dle mých krátkých zkušeností jsou změny nastavení mapniku asi těžko > průchozí, že? Chtělo by to alespoň zatlačit ne nějakého patřičného > kret*na, co to má nahoře nastarosti...
Asi nejrychlejším řešením (které zvažuji i v souvislosti s double-renderingem názvů KÚ, obcí atd.) je poslat přímo návrh na změnu stylu jako pull-request na githubu [1]. [1] https://github.com/openstreetmap/mapnik-stylesheets ------------- další část --------------- A non-text attachment was scrubbed... Name: xificurk.vcf Type: text/x-vcard Size: 212 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120220/a6627403/attachment.vcf> ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120220/a6627403/attachment.sig>

20.2.2012 12:53:21 (#16)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
start_date v. valid_from Nejde o to, že jeden je lepší nebo horší, podle mě jsou tak asi nastejno, takže bych se přiklonil na stranu aktuálního vítěze. Jde o to, že dva různé klíče popisují tu stejnou věc bez dalšího důvodu. Pro boundary=protected_area nejsou na taginfo statistiky, ale pro protection_title je to ve prospěch start_date 2000 : 500 Myslím, že start_date by tam určitě být mělo a valid_from kdyžtak přidat jenom navíc kvůli kompatibilitě s tím Fr. importem (ale ideálně jen start_date) Dočasný tag pro mapnik bych nepoužíval, ale když jsou to jen čtyři parky tak je to opravdu celkem jedno. site_zone se používá málo (9×), ale zdá se, že je to jediný zdokumentovaný a používaný klíč, takže nejlepší volba. Jestli tomu dobře rozumím tak, by tam měly být vnořené multipolgony označující ty zóny a všechny by měly být členem nadřazené relace kvůli seskupení. Najít na mapě to neumím. Lukáš Matějka (LM_1)

18.3.2012 12:26:06 (#17)
gravatar

Jan Kučera

<kozuch82 at gmail.com>
23
Ahojte, bohužel jsem při pokusu o import další části chr. území narazil na softwarové problémy - JOSM nebyl schopen dokončit import cca 12000 uzlů najednou (zkošeno několikrát). Možná to bylo tím, že jsem rozdělil import na části po cca 2000 uzlech. Kdosi mi pak na help.osm.org doporučil importovat pouze v celku, tedy vše najednou, nicméně to jsem zkoušel v úplných začátcích a úspěšnost byla takřka 0%. Zkusil jsem skript bulk_upload_sax.py (http://wiki.openstreetmap.org/wiki/Bulk_upload.py) na Xubuntu 11.10 - ten se mi choval pro změnu zase dosti šíleně a z mého .osm souboru o 12k uzlech vykouzlil dva changesety po cca 25k uzlech (viz http://www.openstreetmap.org/user/Kozuch-EEA/edits - pravděpodobně budu muset revertovat...) ... nechápu, kde ty uzly vzal. Nevíte někdo, co s tím? Jaký SW používáte pro importy? Zdravím, Kozuch Dne 20. února 2012 12:53 LM_1 <flukas.robot+osm na gmail.com> napsal(a): zobrazit citaci
> start_date v. valid_from > Nejde o to, že jeden je lepší nebo horší, podle mě jsou tak asi > nastejno, takže bych se přiklonil na stranu aktuálního vítěze. Jde o > to, že dva různé klíče popisují tu stejnou věc bez dalšího důvodu. Pro > boundary=protected_area nejsou na taginfo statistiky, ale pro > protection_title je to ve prospěch start_date 2000 : 500 > Myslím, že start_date by tam určitě být mělo a valid_from kdyžtak > přidat jenom navíc kvůli kompatibilitě s tím Fr. importem (ale ideálně > jen start_date) > > Dočasný tag pro mapnik bych nepoužíval, ale když jsou to jen čtyři > parky tak je to opravdu celkem jedno. > > site_zone se používá málo (9×), ale zdá se, že je to jediný > zdokumentovaný a používaný klíč, takže nejlepší volba. Jestli tomu > dobře rozumím tak, by tam měly být vnořené multipolgony označující ty > zóny a všechny by měly být členem nadřazené relace kvůli seskupení. > Najít na mapě to neumím. > > Lukáš Matějka (LM_1) > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

20.3.2012 02:45:42 (#18)
gravatar

Libor Pechacek

<lpechacek at gmx.com>
68
Ja jsem na posledni kolo importu adresnich bodu s uspechem pouzil bulk_upload.py, coz je, jak jsem porozumel, predchudce bulk_upload_sax.py. Trochu jsem ho musel ohackovat, aby se vyporadal s cestinou v komentarich a par dalsich drobnosti. Viz patch. HTH, Libor Index: bulk_upload.py =================================================================== --- bulk_upload.py (Revision 26712) +++ bulk_upload.py (Arbeitskopie) @@ -1,4 +1,4 @@ -#!/usr/bin/python +#!/usr/bin/python -W ignore::DeprecationWarning:httplib2 # -*- coding: utf-8 -*- # # @@ -65,7 +65,7 @@ def __init__(self,user,password,idMap,tags={}): self.httpObj = httplib2.Http() - self.httpObj.add_credentials(user,password) + self.httpObj.add_credentials(user,password,'api.openstreetmap.org') self.idMap = idMap self.tags = tags self.createChangeset() @@ -97,6 +97,11 @@ id=elem.attrib['id'] if self.idMap[type].has_key(id): continue + + # Work around a JOSM bug + if int(id) < 0 and elem.attrib.has_key('action') and elem.attrib['action'] == 'modify': + del elem.attrib['action'] + # # If elem contains nodes, ways or relations as a child # then the ids need to be remapped. @@ -377,7 +382,7 @@ idMap = IdMap(options.infile + ".db") tags = { 'created_by': user_agent, - 'comment': options.comment + 'comment': unicode(options.comment, "utf-8") } importProcessor = ImportProcessor(options.user,options.password,idMap,tags) importProcessor.parse(options.infile) On Sun 18-03-12 12:26:06, Jan Kučera wrote: zobrazit citaci
> Ahojte, > > bohužel jsem při pokusu o import další části chr. území narazil na > softwarové problémy - JOSM nebyl schopen dokončit import cca 12000 > uzlů najednou (zkošeno několikrát). Možná to bylo tím, že jsem > rozdělil import na části po cca 2000 uzlech. Kdosi mi pak na > help.osm.org doporučil importovat pouze v celku, tedy vše najednou, > nicméně to jsem zkoušel v úplných začátcích a úspěšnost byla takřka > 0%. > > Zkusil jsem skript bulk_upload_sax.py > (http://wiki.openstreetmap.org/wiki/Bulk_upload.py) na Xubuntu 11.10 - > ten se mi choval pro změnu zase dosti šíleně a z mého .osm souboru o > 12k uzlech vykouzlil dva changesety po cca 25k uzlech (viz > http://www.openstreetmap.org/user/Kozuch-EEA/edits - pravděpodobně > budu muset revertovat...) ... nechápu, kde ty uzly vzal. Nevíte někdo, > co s tím? > > Jaký SW používáte pro importy? > > Zdravím, > Kozuch > > Dne 20. února 2012 12:53 LM_1 <flukas.robot+osm na gmail.com> napsal(a): > > start_date v. valid_from > > Nejde o to, že jeden je lepší nebo horší, podle mě jsou tak asi > > nastejno, takže bych se přiklonil na stranu aktuálního vítěze. Jde o > > to, že dva různé klíče popisují tu stejnou věc bez dalšího důvodu. Pro > > boundary=protected_area nejsou na taginfo statistiky, ale pro > > protection_title je to ve prospěch start_date 2000 : 500 > > Myslím, že start_date by tam určitě být mělo a valid_from kdyžtak > > přidat jenom navíc kvůli kompatibilitě s tím Fr. importem (ale ideálně > > jen start_date) > > > > Dočasný tag pro mapnik bych nepoužíval, ale když jsou to jen čtyři > > parky tak je to opravdu celkem jedno. > > > > site_zone se používá málo (9×), ale zdá se, že je to jediný > > zdokumentovaný a používaný klíč, takže nejlepší volba. Jestli tomu > > dobře rozumím tak, by tam měly být vnořené multipolgony označující ty > > zóny a všechny by měly být členem nadřazené relace kvůli seskupení. > > Najít na mapě to neumím. > > > > Lukáš Matějka (LM_1) > > > > _______________________________________________ > > 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
--

20.3.2012 10:25:17 (#19)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
Jan Kučera wrote: zobrazit citaci
> Ahojte, > > bohužel jsem při pokusu o import další části chr. území narazil na > softwarové problémy - JOSM nebyl schopen dokončit import cca 12000 > uzlů najednou (zkošeno několikrát). Možná to bylo tím, že jsem > rozdělil import na části po cca 2000 uzlech. Kdosi mi pak na > help.osm.org doporučil importovat pouze v celku, tedy vše najednou, > nicméně to jsem zkoušel v úplných začátcích a úspěšnost byla takřka > 0%. > > Zkusil jsem skript bulk_upload_sax.py > (http://wiki.openstreetmap.org/wiki/Bulk_upload.py) na Xubuntu 11.10 - > ten se mi choval pro změnu zase dosti šíleně a z mého .osm souboru o > 12k uzlech vykouzlil dva changesety po cca 25k uzlech (viz > http://www.openstreetmap.org/user/Kozuch-EEA/edits - pravděpodobně > budu muset revertovat...) ... nechápu, kde ty uzly vzal. Nevíte někdo, > co s tím? > > Jaký SW používáte pro importy? > > Zdravím, > Kozuch
UIR-ZSJ jsem importoval pomocí vlastní pythoní knihovny [1], ale to byly changesety řádově o stovkách uzlů (a pokud si dobře vzpomínám, tak upload trval klidně i minuty). Ono je v podstatě jedno, jaký software se použije. To podstatné je, že musí udržet otevřené HTTP spojení dostatečně dlouho než to API přežvýká. Imho by bylo nejrozumější to uploadovat po menších částech, ale jednotlivé části stále jako "diff upload". "Menších" tak, aby jednotlivé uploady proběhly v rozumném čase, tzn. řádově asi ty stovky nodů. Jako "diff upload" z toho důvodu, aby se v mapě nejdřív neobjevily jen samotné uzly, do kterých by mohl někdo hrábnout a způsobit tak selhání uploadu cest. Rozdělení na menší části už nesouvisí s uploadem... otázkou je, jakou strukturu mají data? Patří každý uzel jen do jedné cesty (krom koncových)? Je možné to nějak rozsekat (teď neřeším technické provedení, jen možnost)? Petr Morávek aka Xificurk [1] https://github.com/xificurk/osmapis ------------- další část --------------- A non-text attachment was scrubbed... Name: xificurk.vcf Type: text/x-vcard Size: 212 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120320/1f912045/attachment.vcf> ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120320/1f912045/attachment.sig>

21.3.2012 09:34:52 (#20)
gravatar

Jan Kučera

<kozuch82 at gmail.com>
23
Ahoj, jednalo se o import tohoto souboru: http://www.2shared.com/file/GAH9id2X/CR_final_UTF-8_NPP_2.html tento skript http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload_sax.py vyhodil tento output http://pastebin.com/5eQTe1Bv s vysledkem techto 2 changesetu http://www.openstreetmap.org/user/Kozuch-EEA/edits Chapu, ze by bylo lepsi udelat diff, ale momentalne neznam cestu, jak z .osm souboru takovy diff udelat... respektive jak to rozsekat na uploady treba po jednotlivych relacich... Kozuch Dne 20. března 2012 22:25 "Petr Morávek [Xificurk]" <xificurk na gmail.com> napsal(a): zobrazit citaci
> Jan Kučera wrote: >> Ahojte, >> >> bohužel jsem při pokusu o import další části chr. území narazil na >> softwarové problémy - JOSM nebyl schopen dokončit import cca 12000 >> uzlů najednou (zkošeno několikrát). Možná to bylo tím, že jsem >> rozdělil import na části po cca 2000 uzlech. Kdosi mi pak na >> help.osm.org doporučil importovat pouze v celku, tedy vše najednou, >> nicméně to jsem zkoušel v úplných začátcích a úspěšnost byla takřka >> 0%. >> >> Zkusil jsem skript bulk_upload_sax.py >> (http://wiki.openstreetmap.org/wiki/Bulk_upload.py) na Xubuntu 11.10 - >> ten se mi choval pro změnu zase dosti šíleně a z mého .osm souboru o >> 12k uzlech vykouzlil dva changesety po cca 25k uzlech (viz >> http://www.openstreetmap.org/user/Kozuch-EEA/edits - pravděpodobně >> budu muset revertovat...) ... nechápu, kde ty uzly vzal. Nevíte někdo, >> co s tím? >> >> Jaký SW používáte pro importy? >> >> Zdravím, >> Kozuch > > UIR-ZSJ jsem importoval pomocí vlastní pythoní knihovny [1], ale to byly > changesety řádově o stovkách uzlů (a pokud si dobře vzpomínám, tak > upload trval klidně i minuty). > > Ono je v podstatě jedno, jaký software se použije. To podstatné je, že > musí udržet otevřené HTTP spojení dostatečně dlouho než to API přežvýká. > > Imho by bylo nejrozumější to uploadovat po menších částech, ale > jednotlivé části stále jako "diff upload". > "Menších" tak, aby jednotlivé uploady proběhly v rozumném čase, tzn. > řádově asi ty stovky nodů. > Jako "diff upload" z toho důvodu, aby se v mapě nejdřív neobjevily jen > samotné uzly, do kterých by mohl někdo hrábnout a způsobit tak selhání > uploadu cest. > > Rozdělení na menší části už nesouvisí s uploadem... otázkou je, jakou > strukturu mají data? Patří každý uzel jen do jedné cesty (krom > koncových)? Je možné to nějak rozsekat (teď neřeším technické provedení, > jen možnost)? > > Petr Morávek aka Xificurk > > [1] https://github.com/xificurk/osmapis > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

21.3.2012 10:11:58 (#21)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
Jan Kučera wrote: zobrazit citaci
> Ahoj, > > jednalo se o import tohoto souboru: > http://www.2shared.com/file/GAH9id2X/CR_final_UTF-8_NPP_2.html > > tento skript > http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload_sax.py > > vyhodil tento output > http://pastebin.com/5eQTe1Bv > > s vysledkem techto 2 changesetu > http://www.openstreetmap.org/user/Kozuch-EEA/edits > > Chapu, ze by bylo lepsi udelat diff, ale momentalne neznam cestu, jak > z .osm souboru takovy diff udelat... respektive jak to rozsekat na > uploady treba po jednotlivych relacich... > > Kozuch
Mohl bych se na to podívat a zkusit to nějak rozsekat a uploadovat, ale teď toho mám až nad hlavu... nejdřív se k tomu dostanu za pár týdnů. Mám aspoň revertovat ty dva changesety s nody, nebo už se to řeší jinak? Petr Morávek aka Xificurk ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120321/06a2bb50/attachment.sig>

22.3.2012 09:52:21 (#22)
gravatar

Jan Kučera

<kozuch82 at gmail.com>
23
Ahoj, zobrazit citaci
> Mám aspoň revertovat ty dva changesety s nody, nebo už se to řeší jinak?
ano, prosím revertovat. díky! Dne 21. března 2012 22:11 "Petr Morávek [Xificurk]" <xificurk na gmail.com> napsal(a): zobrazit citaci
> Jan Kučera wrote: >> Ahoj, >> >> jednalo se o import tohoto souboru: >> http://www.2shared.com/file/GAH9id2X/CR_final_UTF-8_NPP_2.html >> >> tento skript >> http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload_sax.py >> >> vyhodil tento output >> http://pastebin.com/5eQTe1Bv >> >> s vysledkem techto 2 changesetu >> http://www.openstreetmap.org/user/Kozuch-EEA/edits >> >> Chapu, ze by bylo lepsi udelat diff, ale momentalne neznam cestu, jak >> z .osm souboru takovy diff udelat... respektive jak to rozsekat na >> uploady treba po jednotlivych relacich... >> >> Kozuch > > Mohl bych se na to podívat a zkusit to nějak rozsekat a uploadovat, ale > teď toho mám až nad hlavu... nejdřív se k tomu dostanu za pár týdnů. > > Mám aspoň revertovat ty dva changesety s nody, nebo už se to řeší jinak? > > > Petr Morávek aka Xificurk > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

22.3.2012 11:11:50 (#23)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 18.3.2012 12:26, Jan Kučera napsal(a): zobrazit citaci
> Ahojte, > > bohužel jsem při pokusu o import další části chr. území narazil na > softwarové problémy - JOSM nebyl schopen dokončit import cca 12000 > uzlů najednou (zkošeno několikrát). Možná to bylo tím, že jsem > rozdělil import na části po cca 2000 uzlech. Kdosi mi pak na > help.osm.org doporučil importovat pouze v celku, tedy vše najednou, > nicméně to jsem zkoušel v úplných začátcích a úspěšnost byla takřka > 0%.
Osobne mam po nemilych zkusenostech nastaven JOSM na 500 kousku jednim vrzem, jeste se mi nestalo ze by to padlo a to sem tam posilal i cca 5 000 zmen. Pokud sem posilal trebas 1500 zmen najednou, trvalo to nasobne dele nez 3x 500. A jak znamo, cim dyl neco trva, tim vetsi pravdepodobnost, ze se neco podela ... Vetsi mnoztvi zmen ale bude asi vhodnejsi rozdelit i do vice changesetu. zobrazit citaci
> Zkusil jsem skript bulk_upload_sax.py > (http://wiki.openstreetmap.org/wiki/Bulk_upload.py) na Xubuntu 11.10 - > ten se mi choval pro změnu zase dosti šíleně a z mého .osm souboru o > 12k uzlech vykouzlil dva changesety po cca 25k uzlech (viz > http://www.openstreetmap.org/user/Kozuch-EEA/edits - pravděpodobně > budu muset revertovat...) ... nechápu, kde ty uzly vzal. Nevíte někdo, > co s tím? > > Jaký SW používáte pro importy? > > Zdravím, > Kozuch > > Dne 20. února 2012 12:53 LM_1 <flukas.robot+osm na gmail.com> napsal(a): >> start_date v. valid_from >> Nejde o to, že jeden je lepší nebo horší, podle mě jsou tak asi >> nastejno, takže bych se přiklonil na stranu aktuálního vítěze. Jde o >> to, že dva různé klíče popisují tu stejnou věc bez dalšího důvodu. Pro >> boundary=protected_area nejsou na taginfo statistiky, ale pro >> protection_title je to ve prospěch start_date 2000 : 500 >> Myslím, že start_date by tam určitě být mělo a valid_from kdyžtak >> přidat jenom navíc kvůli kompatibilitě s tím Fr. importem (ale ideálně >> jen start_date) >> >> Dočasný tag pro mapnik bych nepoužíval, ale když jsou to jen čtyři >> parky tak je to opravdu celkem jedno. >> >> site_zone se používá málo (9×), ale zdá se, že je to jediný >> zdokumentovaný a používaný klíč, takže nejlepší volba. Jestli tomu >> dobře rozumím tak, by tam měly být vnořené multipolgony označující ty >> zóny a všechny by měly být členem nadřazené relace kvůli seskupení. >> Najít na mapě to neumím. >> >> Lukáš Matějka (LM_1) >> >> _______________________________________________ >> 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

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