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

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

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

> 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

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

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

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

> 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

> 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

>> - valid_from - pro rok vytvoření > Použil bych spíš start_date, je rozšířenější.

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

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

> 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

> 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

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

> 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

> 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

> 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

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

> 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

> Mám aspoň revertovat ty dva changesety s nody, nebo už se to řeší jinak?

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

> 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