Import chráněných území z EEA

23 zpráv
Zpět na přehled

Import chráněných území z EEA

23 zpráv PJLJLPL 7 účastníků 20 min čtení
  1. Jan Kučera kozuch82 na gmail.com #m25de27
    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
  2. "Petr Morávek [Xificurk]" xificurk na gmail.com #md0d65b
    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...
    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
  3. Lukas Kabrt lukas na kabrt.cz #mb86cd9
    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
  4. jzvc jzvc na tpfree.net #m93743a
    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.
  5. LM_1 flukas.robot+osm na gmail.com #m68de1a
    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>:
  6. jzvc jzvc na tpfree.net #m23ceec
    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.
  7. LM_1 flukas.robot+osm na gmail.com #md3e9bb
    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.
    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í".
  8. Pavel Machek pavel na ucw.cz #m48cc50
    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
  9. "Petr Morávek [Xificurk]" xificurk na gmail.com #m568dac
    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
  10. "Petr Morávek [Xificurk]" xificurk na gmail.com #m3cc39a
    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
  11. LM_1 flukas.robot+osm na gmail.com #m3a5f0c
    Ahoj
    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
    - 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
    - protect_class - ref - iucn_level - 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
    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
  12. "Petr Morávek [Xificurk]" xificurk na gmail.com #m844f5d
    - 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.
    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
    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
  13. Jan Kučera kozuch82 na gmail.com #m3a71ef
    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
  14. Jan Kučera kozuch82 na gmail.com #m770612
    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>:
  15. "Petr Morávek [Xificurk]" xificurk na gmail.com #md0c792
    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
    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
  16. LM_1 flukas.robot+osm na gmail.com #mca95f9
    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)
  17. Jan Kučera kozuch82 na gmail.com #m9a8a58
    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
  18. Libor Pechacek lpechacek na gmx.com #mbb07cc
    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)
  19. "Petr Morávek [Xificurk]" xificurk na gmail.com #m2dfb3f
    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
  20. Jan Kučera kozuch82 na gmail.com #m7dddc8
    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]"
  21. "Petr Morávek [Xificurk]" xificurk na gmail.com #m7e4efb
    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
  22. Jan Kučera kozuch82 na gmail.com #med0088
    Ahoj,
    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]"
  23. jzvc jzvc na tpfree.net #mf3969a
    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.
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.