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

[Talk-cz] Boundary

Vlákno 25.2. - 4.3.2010, počet zpráv: 46


25.2.2010 09:42:52 (#1)
gravatar

Mike

<mike at mikecrash.com>
196
Zdrav?m, pr?v? jsem dod?lal jednu v?c a v n?vaznosti na to bych pot?eboval v map? hranice okres?, obc? a K?. R?d bych se tedy pustil do importu, kter? se tady ned?vno ?e?il, pokud na tom u? n?kdo ned?l?. Pokud ne a m?l by z?jem, abych to dot?hl, mohl by mi doty?n? p?edat co m? a p??padn? v za??tku b?t ke konzultaci? D?ky Mike

25.2.2010 11:46:33 (#2)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 25.2.2010 9:42, Mike napsal(a): zobrazit citaci
> Zdrav?m, > > pr?v? jsem dod?lal jednu v?c a v n?vaznosti na to bych pot?eboval v map? > hranice okres?, obc? a K?. R?d bych se tedy pustil do importu, kter? se > tady ned?vno ?e?il, pokud na tom u? n?kdo ned?l?. Pokud ne a m?l by > z?jem, abych to dot?hl, mohl by mi doty?n? p?edat co m? a p??padn? v > za??tku b?t ke konzultaci? > > D?ky > > Mike >
Pokud vim, je to pripraveno, jen se to bude muset delat asi podobne jako probihajici import konfliktnich vodnich ploch => castecne ruco. Mozna by bylo zahodno to rozdelit po krajich/okresech. zobrazit citaci
> _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

25.2.2010 01:48:03 (#3)
gravatar

Mike

<mike at mikecrash.com>
196
A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e co jsem koukal stejn? nejsou moc p?esn?. Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit? [1] http://lkabrt.aspone.cz/osm/kucr.zip On 25.2.2010 11:46, jzvc wrote: zobrazit citaci
> Dne 25.2.2010 9:42, Mike napsal(a): >> Zdrav?m, >> >> pr?v? jsem dod?lal jednu v?c a v n?vaznosti na to bych pot?eboval v map? >> hranice okres?, obc? a K?. R?d bych se tedy pustil do importu, kter? se >> tady ned?vno ?e?il, pokud na tom u? n?kdo ned?l?. Pokud ne a m?l by >> z?jem, abych to dot?hl, mohl by mi doty?n? p?edat co m? a p??padn? v >> za??tku b?t ke konzultaci? >> >> D?ky >> >> Mike >> > > Pokud vim, je to pripraveno, jen se to bude muset delat asi podobne jako > probihajici import konfliktnich vodnich ploch => castecne ruco. Mozna by > bylo zahodno to rozdelit po krajich/okresech. > >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

25.2.2010 02:42:32 (#4)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
278 645
podle okres? by to ur?it? bylo dobr?, jsou okresy v?cem?n? hotov? (?steck? kraj, okol? prahy) a jsou okresy, kde nen? ??hnuto. J&D 2010/2/25 Mike <mike at mikecrash.com>: zobrazit citaci
> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? > > J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude > cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat > n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e > co jsem koukal stejn? nejsou moc p?esn?. > > Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit? > > [1] http://lkabrt.aspone.cz/osm/kucr.zip > > On 25.2.2010 11:46, jzvc wrote: >> Dne 25.2.2010 9:42, Mike napsal(a): >>> Zdrav?m, >>> >>> pr?v? jsem dod?lal jednu v?c a v n?vaznosti na to bych pot?eboval v map? >>> hranice okres?, obc? a K?. R?d bych se tedy pustil do importu, kter? se >>> tady ned?vno ?e?il, pokud na tom u? n?kdo ned?l?. Pokud ne a m?l by >>> z?jem, abych to dot?hl, mohl by mi doty?n? p?edat co m? a p??padn? v >>> za??tku b?t ke konzultaci? >>> >>> D?ky >>> >>> Mike >>> >> >> Pokud vim, je to pripraveno, jen se to bude muset delat asi podobne jako >> probihajici import konfliktnich vodnich ploch => castecne ruco. Mozna by >> bylo zahodno to rozdelit po krajich/okresech. >> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-- -- Ing. Jan Dud?k

25.2.2010 02:58:49 (#5)
gravatar

Mike

<mike at mikecrash.com>
196
Akor?t ?e??m to, jak to nav?zat, proto?e hranice jsou spole?n?, aby tam nebyly duplicity On 25.2.2010 14:42, Jan Dud?k wrote: zobrazit citaci
> podle okres? by to ur?it? bylo dobr?, jsou okresy v?cem?n? hotov? > (?steck? kraj, okol? prahy) a jsou okresy, kde nen? ??hnuto. > J&D > > 2010/2/25 Mike <mike at mikecrash.com>: >> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? >> >> J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude >> cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat >> n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e >> co jsem koukal stejn? nejsou moc p?esn?. >> >> Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit? >> >> [1] http://lkabrt.aspone.cz/osm/kucr.zip >> >> On 25.2.2010 11:46, jzvc wrote: >>> Dne 25.2.2010 9:42, Mike napsal(a): >>>> Zdrav?m, >>>> >>>> pr?v? jsem dod?lal jednu v?c a v n?vaznosti na to bych pot?eboval v map? >>>> hranice okres?, obc? a K?. R?d bych se tedy pustil do importu, kter? se >>>> tady ned?vno ?e?il, pokud na tom u? n?kdo ned?l?. Pokud ne a m?l by >>>> z?jem, abych to dot?hl, mohl by mi doty?n? p?edat co m? a p??padn? v >>>> za??tku b?t ke konzultaci? >>>> >>>> D?ky >>>> >>>> Mike >>>> >>> >>> Pokud vim, je to pripraveno, jen se to bude muset delat asi podobne jako >>> probihajici import konfliktnich vodnich ploch => castecne ruco. Mozna by >>> bylo zahodno to rozdelit po krajich/okresech. >>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > >

25.2.2010 03:53:52 (#6)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho?
Nejnovj?j?? verze je na adrese [1]. Co v map? je a nen?, co je zkontrolov?no a kde je?t? jsou n?jak? nejasnosti jsem psal do prispevku [2] tady na foru. zobrazit citaci
> J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude > cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat > n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e > co jsem koukal stejn? nejsou moc p?esn?.
Rozsekat to p??li? nep?jde, proto?e ways tvo??c? hranice jsou spole?n? pro v?ce ?zem?. Respektive nep?jde nahr?v?n? jednodu?e distribuovat jako u DIBAVODU. Mo?n? je mapu rozd?lit na v?ce ??st?, ??st v?dy nahr?t, pamatovat si jak? ID server jednotliv?m objekt?m p?i?adil a tyhle objekty znova neuplodovat. Ide?ln? by bylo nahr?t v?e nejednou, ale nev?m jestli je to technicky mo?n? (jedn? se o cca 1 milion bod?). M? n?kdo zku?enosti s tak velk?m importem? Jak t?eba prob?hal import les?? zobrazit citaci
> Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit?
Aktivit? se meze nekaldou :-) R?d kdy?tak pom??u ... [1] http://osm.kabrt.cz/home/kucr.zip?attredirects=0&d=1 [2] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html

25.2.2010 04:52:57 (#7)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 25.2.2010 15:53, Lukas Kabrt napsal(a): zobrazit citaci
>> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? >> > Nejnovj?j?? verze je na adrese [1]. Co v map? je a nen?, co je > zkontrolov?no a kde je?t? jsou n?jak? nejasnosti jsem psal do > prispevku [2] tady na foru. > > >> J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude >> cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat >> n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e >> co jsem koukal stejn? nejsou moc p?esn?. >> > Rozsekat to p??li? nep?jde, proto?e ways tvo??c? hranice jsou spole?n? > pro v?ce ?zem?. Respektive nep?jde nahr?v?n? jednodu?e distribuovat > jako u DIBAVODU. Mo?n? je mapu rozd?lit na v?ce ??st?, ??st v?dy > nahr?t, pamatovat si jak? ID server jednotliv?m objekt?m p?i?adil a > tyhle objekty znova neuplodovat. > > Ide?ln? by bylo nahr?t v?e nejednou, ale nev?m jestli je to technicky > mo?n? (jedn? se o cca 1 milion bod?). M? n?kdo zku?enosti s tak velk?m > importem? Jak t?eba prob?hal import les?? >
Melo by to jit, JOSM umi pri uploadu rict, ze bude changeset nahravat po castech a po jak velkych. Bude to ale trvat. Druha vec je, zda ze z toho JOSM neopupinkuje :D. Zkusim se na to mrknout. zobrazit citaci
> >> Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit? >> > Aktivit? se meze nekaldou :-) R?d kdy?tak pom??u ... > > [1] http://osm.kabrt.cz/home/kucr.zip?attredirects=0&d=1 > [2] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

25.2.2010 05:20:55 (#8)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> Melo by to jit, JOSM umi pri uploadu rict, ze bude changeset nahravat po > castech a po jak velkych. Bude to ale trvat. Druha vec je, zda ze z toho > JOSM neopupinkuje :D. Zkusim se na to mrknout.
Mam vyzkouseno, ze JOSM ten soubor nacte. Pracovat se s tim sice moc neda, ale otevrit jde, tak by ho snad mohl zvladnou i poslat na server. Jde spis o to jak osetrit, kdyby spadlo spojeni, JOSM nebo pocitac pri uplodu. Jestli jde JSOM rict aby pokracoval, tam kde, prestal (nebo aspon logovat co uz je nahrano). Aby se nahodou nestalo, ze bude 500000 duplicitnich nodu rozhazenych po CR ... -- Lukas

25.2.2010 05:41:59 (#9)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 25.2.2010 15:53, Lukas Kabrt napsal(a): zobrazit citaci
>> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? >> > Nejnovj?j?? verze je na adrese [1]. Co v map? je a nen?, co je > zkontrolov?no a kde je?t? jsou n?jak? nejasnosti jsem psal do > prispevku [2] tady na foru. >
Tak po zbeznem testu se stim prakticky neda pracovat :/ (JOSM to sotva udejcha). Pripominky: relace: type=multipolygon, ovsem vsechny soucasne hranicni relace (a nejen nase) pouzivaji type=boundary chybi administrativni centra, pokud vim, (asi)kazde ku ma urcenou obec/cast ke ktere nalezi. nejsou definovany vztahy mezi ku (mineno potomci/rodice, napr stat obsahuje kraje, ty obsahuji okresy ...) chtelo by to nejakou poznamku, zdroj je km, ale tohle by zaslouzilo jeste info ze jde o import/automaticke zpracovani ways: je pouze tag boundary=administrative, ale IMO by tam mel byt jeste admin_level. To co jsem opsal od ostatnich = lv cesty odpovida nejmensimu cislu = nejvyssi urovni pro kterou je hranici. Takze ways hranice statu by mely mit 2 atd. chtelo by to nejakou poznamku, zdroj je km, ale tohle by zaslouzilo jeste info ze jde o import/automaticke zpracovani Co se zpracovani tyce, v tomto rozsahu je nemozne to napojit do stavajicich dat, muselo by se to leda nahrat tak jak to je a pak to upravovat az z OSM. Varianta rozdeleni po okresech mi prijde celkem pruchozi, zpracovatel by ve vetsine pripadu resil maximalne napojeni hranic okresu a likvidaci jejich duplicit = maximalne desitky cest v jedne davce. IMO by varianta A(kompletni upload) byla vhodnejsi, muze na tom pak pracovat dost lidi zaroven a nejsou limitovani tim, ze musi najednou zpracovat cely okres. Za predpokladu ze bude mozno odlisit, co bylo uz upraveno/zkontrolovano a co je nedotceny import, jsem pro import a to i za cenu zduplikovani nekterych hranic. Ovsem pred importem by to chtelo jeste doplnit/zvazit vyse navrzene upravy. --- Konstatuji, ze rucne delane hranice jsou o fous presnejsi(napr vedou po spravne strane silnice ;) ), ale nic vyznamneho, kvalita dat je spickova. zobrazit citaci
>> J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude >> cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat >> n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e >> co jsem koukal stejn? nejsou moc p?esn?. >> > Rozsekat to p??li? nep?jde, proto?e ways tvo??c? hranice jsou spole?n? > pro v?ce ?zem?. Respektive nep?jde nahr?v?n? jednodu?e distribuovat > jako u DIBAVODU. Mo?n? je mapu rozd?lit na v?ce ??st?, ??st v?dy > nahr?t, pamatovat si jak? ID server jednotliv?m objekt?m p?i?adil a > tyhle objekty znova neuplodovat. > > Ide?ln? by bylo nahr?t v?e nejednou, ale nev?m jestli je to technicky > mo?n? (jedn? se o cca 1 milion bod?). M? n?kdo zku?enosti s tak velk?m > importem? Jak t?eba prob?hal import les?? > > >> Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit? >> > Aktivit? se meze nekaldou :-) R?d kdy?tak pom??u ... > > [1] http://osm.kabrt.cz/home/kucr.zip?attredirects=0&d=1 > [2] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

25.2.2010 05:48:46 (#10)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 25.2.2010 17:20, Lukas Kabrt napsal(a): zobrazit citaci
>> Melo by to jit, JOSM umi pri uploadu rict, ze bude changeset nahravat po >> castech a po jak velkych. Bude to ale trvat. Druha vec je, zda ze z toho >> JOSM neopupinkuje :D. Zkusim se na to mrknout. >> > Mam vyzkouseno, ze JOSM ten soubor nacte. Pracovat se s tim sice moc > neda, ale otevrit jde, tak by ho snad mohl zvladnou i poslat na > server. > > Jde spis o to jak osetrit, kdyby spadlo spojeni, JOSM nebo pocitac pri > uplodu. Jestli jde JSOM rict aby pokracoval, tam kde, prestal (nebo > aspon logovat co uz je nahrano). Aby se nahodou nestalo, ze bude > 500000 duplicitnich nodu rozhazenych po CR ... > -- > Lukas >
Toto se obavam nelze, bud to vyjde nebo ne. V kazdym pripade by to mel posilat nekdo s konektivitou garantovanou jinak nez DSL/UPC :D. Pokud je totiz vztah pocet bodu/cas linearni, tak to pofrci vic nez 2 dny vkuse. Leda ze by existovala moznost to poslat jako soubor nekam/nekomu na OSM s tim, ze to naimportuje nejak lokalne/offline. zobrazit citaci
> _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

25.2.2010 08:22:26 (#11)
gravatar

Pavel Machek

<pavel at ucw.cz>
1037 1226
Ahoj! zobrazit citaci
> > A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? > > Nejnovj?j?? verze je na adrese [1]. Co v map? je a nen?, co je > zkontrolov?no a kde je?t? jsou n?jak? nejasnosti jsem psal do > prispevku [2] tady na foru. > > > J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude > > cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat > > n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e > > co jsem koukal stejn? nejsou moc p?esn?. > > Rozsekat to p??li? nep?jde, proto?e ways tvo??c? hranice jsou spole?n? > pro v?ce ?zem?. Respektive nep?jde nahr?v?n? jednodu?e distribuovat > jako u DIBAVODU. Mo?n? je mapu rozd?lit na v?ce ??st?, ??st v?dy > nahr?t, pamatovat si jak? ID server jednotliv?m objekt?m p?i?adil a > tyhle objekty znova neuplodovat.
Co takhle nahrat nejdriv body, ktery jsou spolecny pro vic hran, pak ostatni body a hranice, pak relace...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

25.2.2010 08:28:14 (#12)
gravatar

Pavel Machek

<pavel at ucw.cz>
1037 1226
On Thu 2010-02-25 17:48:46, jzvc wrote: zobrazit citaci
> Dne 25.2.2010 17:20, Lukas Kabrt napsal(a): > >> Melo by to jit, JOSM umi pri uploadu rict, ze bude changeset nahravat po > >> castech a po jak velkych. Bude to ale trvat. Druha vec je, zda ze z toho > >> JOSM neopupinkuje :D. Zkusim se na to mrknout. > >> > > Mam vyzkouseno, ze JOSM ten soubor nacte. Pracovat se s tim sice moc > > neda, ale otevrit jde, tak by ho snad mohl zvladnou i poslat na > > server. > > > > Jde spis o to jak osetrit, kdyby spadlo spojeni, JOSM nebo pocitac pri > > uplodu. Jestli jde JSOM rict aby pokracoval, tam kde, prestal (nebo > > aspon logovat co uz je nahrano). Aby se nahodou nestalo, ze bude > > 500000 duplicitnich nodu rozhazenych po CR ... > > Toto se obavam nelze, bud to vyjde nebo ne. V kazdym pripade by to mel > posilat nekdo s konektivitou garantovanou jinak nez DSL/UPC :D. Pokud je > totiz vztah pocet bodu/cas linearni, tak to pofrci vic nez 2 dny vkuse. > Leda ze by existovala moznost to poslat jako soubor nekam/nekomu na OSM > s tim, ze to naimportuje nejak lokalne/offline.
Ono to stejne bude limitovany ne rychlosti linky, ale rychlosti serveru... Jinak .5M duplicitnich bodu by nebyl tak _strasnej_ pruser -- stale jeste jsou tu skripty na revert, nebo by se mohlo proste smazat vsechny body s danym source= tagem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

25.2.2010 08:39:22 (#13)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 25.2.2010 20:22, Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > > >>> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? >>> >> Nejnovj?j?? verze je na adrese [1]. Co v map? je a nen?, co je >> zkontrolov?no a kde je?t? jsou n?jak? nejasnosti jsem psal do >> prispevku [2] tady na foru. >> >> >>> J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude >>> cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat >>> n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e >>> co jsem koukal stejn? nejsou moc p?esn?. >>> >> Rozsekat to p??li? nep?jde, proto?e ways tvo??c? hranice jsou spole?n? >> pro v?ce ?zem?. Respektive nep?jde nahr?v?n? jednodu?e distribuovat >> jako u DIBAVODU. Mo?n? je mapu rozd?lit na v?ce ??st?, ??st v?dy >> nahr?t, pamatovat si jak? ID server jednotliv?m objekt?m p?i?adil a >> tyhle objekty znova neuplodovat. >> > Co takhle nahrat nejdriv body, ktery jsou spolecny pro vic hran, pak > ostatni body a hranice, pak relace...? > Pavel >
Tohle by ovsem musel nekdo napsat ne ? Protoze josm to posila bez IDcek => pokud bys chtel nasledne ty body zahrnout do cest, tak uz musis jejich IDcka znat.

25.2.2010 08:45:30 (#14)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Thu, Feb 25, 2010 at 05:41:59PM +0100, jzvc wrote: zobrazit citaci
> Dne 25.2.2010 15:53, Lukas Kabrt napsal(a): > IMO by varianta A(kompletni upload) byla vhodnejsi, muze na tom pak > pracovat dost lidi zaroven a nejsou limitovani tim, ze musi najednou > zpracovat cely okres. Za predpokladu ze bude mozno odlisit, co bylo uz > upraveno/zkontrolovano a co je nedotceny import, jsem pro import a to i > za cenu zduplikovani nekterych hranic. Ovsem pred importem by to chtelo > jeste doplnit/zvazit vyse navrzene upravy.
Navrhuji to zkusit cele importovat najednou. Duplicity veresit az nasledne. Ale doporucuji pridat nejaky specialni tag(napr. source:import_prehledka=zkontrolovat) A kdyz to nekdo projde, tak ten tag proste smaze z dane way/relace. Martin Kupec

25.2.2010 09:28:28 (#15)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Ja myslim, ze je celkem jednoduche rozdelit geometrie dle "krizovatek". Tyto krizovatky se pak muzou nahrat zvlast. Pote mezilehle ways (uz mozno paralelne) a nakonec nejake ty relace, ktere to spoji do okresu apod. Snad jsem to pochopil :) Tomas Martin Kupec napsal(a): zobrazit citaci
> On Thu, Feb 25, 2010 at 05:41:59PM +0100, jzvc wrote: > >> Dne 25.2.2010 15:53, Lukas Kabrt napsal(a): >> IMO by varianta A(kompletni upload) byla vhodnejsi, muze na tom pak >> pracovat dost lidi zaroven a nejsou limitovani tim, ze musi najednou >> zpracovat cely okres. Za predpokladu ze bude mozno odlisit, co bylo uz >> upraveno/zkontrolovano a co je nedotceny import, jsem pro import a to i >> za cenu zduplikovani nekterych hranic. Ovsem pred importem by to chtelo >> jeste doplnit/zvazit vyse navrzene upravy. >> > > Navrhuji to zkusit cele importovat najednou. Duplicity veresit > az nasledne. > Ale doporucuji pridat nejaky specialni tag(napr. > source:import_prehledka=zkontrolovat) > A kdyz to nekdo projde, tak ten tag proste smaze z dane > way/relace. > > Martin Kupec > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100225/a791b050/attachment.html>

25.2.2010 09:45:51 (#16)
gravatar

Martin Kupec

<magon at jkopava.cz>
36
On Thu, Feb 25, 2010 at 09:28:28PM +0100, Tomas Kolda wrote: zobrazit citaci
> Ja myslim, ze je celkem jednoduche rozdelit geometrie dle "krizovatek". > Tyto krizovatky se pak muzou nahrat zvlast. Pote mezilehle ways (uz > mozno paralelne) a nakonec nejake ty relace, ktere to spoji do okresu apod. > > Snad jsem to pochopil :)
Tam je jen problem, ze to rozdelis logicky na ruzne vrstvy a ty nahrajes zvlast, ale tim neumoznis prubezne opravovani dat. Ale toto by nemelo vadit. Jako technicke reseni nahrani takoveho mnozstvi dat je asi nejlepsi uploadovat postupne ways. A pak najednou vsechny relace(tech neni tolik). Akorat je treba po uploadnuti waye si zapamatovat ID koncovych bodu aby se dalo navazovat. Martin Kupec

26.2.2010 07:47:49 (#17)
gravatar

Mike

<mike at mikecrash.com>
196
D?ky, z tohoto jsem pr?v? vych?zel, ale nev?d?l jsem jak moc je to aktu?ln?. M?m sta?eno a za??n?m na tom d?lat. Rozkouskovat to bude nutnost, protoze JOSM to v?bec nenahr?l a Merkaator sice nahr?l, u zobrazil cel?, ale jak jsem zoomoval n?kam bl??, tak mu to trvalo ??m d?l d?le a? nakonec zamrznul ?pln?. Vid?l bych to tak, ?e to rozd?l?m po okresech a nap??u si progr?mek, kter? dok??e odd?lit duplicity. P?i uploadu mus?m m?t druh? progr?mek, kter? dok??e vz?t ID bod? a cest z OSM exportu a zm?nit je v jin?m souboru - asi detekce shodnosti polohy bod?. Takhle to postupn? naimportovat. Je?t? pot?ebuju zjistit, jak moc je tam bod?, jestli to nep?jde o?ezat. Co m?m zku?enost, tak v OSM jsou ?asto naprosto rovn? ?seky tvo?eny X zbyte?n?mi body, co? by m?lo j?t vymazat. On 25.2.2010 15:53, Lukas Kabrt wrote: zobrazit citaci
>> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? > > Nejnovj?j?? verze je na adrese [1]. Co v map? je a nen?, co je > zkontrolov?no a kde je?t? jsou n?jak? nejasnosti jsem psal do > prispevku [2] tady na foru. > >> J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude >> cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat >> n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e >> co jsem koukal stejn? nejsou moc p?esn?. > > Rozsekat to p??li? nep?jde, proto?e ways tvo??c? hranice jsou spole?n? > pro v?ce ?zem?. Respektive nep?jde nahr?v?n? jednodu?e distribuovat > jako u DIBAVODU. Mo?n? je mapu rozd?lit na v?ce ??st?, ??st v?dy > nahr?t, pamatovat si jak? ID server jednotliv?m objekt?m p?i?adil a > tyhle objekty znova neuplodovat. > > Ide?ln? by bylo nahr?t v?e nejednou, ale nev?m jestli je to technicky > mo?n? (jedn? se o cca 1 milion bod?). M? n?kdo zku?enosti s tak velk?m > importem? Jak t?eba prob?hal import les?? > >> Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit? > > Aktivit? se meze nekaldou :-) R?d kdy?tak pom??u ... > > [1] http://osm.kabrt.cz/home/kucr.zip?attredirects=0&d=1 > [2] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

26.2.2010 08:07:30 (#18)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 26.2.2010 7:47, Mike napsal(a): zobrazit citaci
> D?ky, z tohoto jsem pr?v? vych?zel, ale nev?d?l jsem jak moc je to > aktu?ln?. M?m sta?eno a za??n?m na tom d?lat. > > Rozkouskovat to bude nutnost, protoze JOSM to v?bec nenahr?l a Merkaator > sice nahr?l, u zobrazil cel?, ale jak jsem zoomoval n?kam bl??, tak mu > to trvalo ??m d?l d?le a? nakonec zamrznul ?pln?. >
JOSM to nacte vpohode, nevim kterou verzi pouzivas, ale posledni buildy urcite, musis si to spustit s parametrem a dat mu dost RAMky. Ja to poustim s gigem a nacte to. javaw.exe -jar -Xmx1024M josm-latest.jar Pokud to poustis bez parametru, tak to mas omezeny na 64MB RAM a to samozrejme nemuze stacit, kdyz jen ten xml ma 170MB. Rychlost zpracovani tomu samozrejme odpovida, na zoom si pockas ;D, ale udela to. Na zjednodusovani prakticky zapomen, vcera sem to trochu prosel, tak na mistech kde jsem se namatkou dival to spis chtelo body pridat, pokud bys to chtel srovnat presne na km. zobrazit citaci
> Vid?l bych to tak, ?e to rozd?l?m po okresech a nap??u si progr?mek, > kter? dok??e odd?lit duplicity. > P?i uploadu mus?m m?t druh? progr?mek, kter? dok??e vz?t ID bod? a cest > z OSM exportu a zm?nit je v jin?m souboru - asi detekce shodnosti polohy > bod?. Takhle to postupn? naimportovat. > Je?t? pot?ebuju zjistit, jak moc je tam bod?, jestli to nep?jde o?ezat. > Co m?m zku?enost, tak v OSM jsou ?asto naprosto rovn? ?seky tvo?eny X > zbyte?n?mi body, co? by m?lo j?t vymazat. > > > On 25.2.2010 15:53, Lukas Kabrt wrote: > >>> A ten soubor [1] je st?le aktu?ln? nebo existuje n?co nov?j??ho? >>> >> Nejnovj?j?? verze je na adrese [1]. Co v map? je a nen?, co je >> zkontrolov?no a kde je?t? jsou n?jak? nejasnosti jsem psal do >> prispevku [2] tady na foru. >> >> >>> J? bych to n?jak rozsekal, t?eba podle okres?, proto?e stejn? to bude >>> cht?t cel? proj?t a zkontrolovat. Mo?n? omezit po?et bod? a ud?lat >>> n?vaznost na hranice st?tu. St?vaj?c? hranice kraj? bych smazal, proto?e >>> co jsem koukal stejn? nejsou moc p?esn?. >>> >> Rozsekat to p??li? nep?jde, proto?e ways tvo??c? hranice jsou spole?n? >> pro v?ce ?zem?. Respektive nep?jde nahr?v?n? jednodu?e distribuovat >> jako u DIBAVODU. Mo?n? je mapu rozd?lit na v?ce ??st?, ??st v?dy >> nahr?t, pamatovat si jak? ID server jednotliv?m objekt?m p?i?adil a >> tyhle objekty znova neuplodovat. >> >> Ide?ln? by bylo nahr?t v?e nejednou, ale nev?m jestli je to technicky >> mo?n? (jedn? se o cca 1 milion bod?). M? n?kdo zku?enosti s tak velk?m >> importem? Jak t?eba prob?hal import les?? >> >> >>> Tak?e pokud na tom nikdo ned?l?, mohu se do toho pustit? >>> >> Aktivit? se meze nekaldou :-) R?d kdy?tak pom??u ... >> >> [1] http://osm.kabrt.cz/home/kucr.zip?attredirects=0&d=1 >> [2] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

26.2.2010 08:22:43 (#19)
gravatar

Mike

<mike at mikecrash.com>
196
zobrazit citaci
> JOSM to nacte vpohode, nevim kterou verzi pouzivas, ale posledni buildy > urcite, musis si to spustit s parametrem a dat mu dost RAMky. Ja to > poustim s gigem a nacte to. > javaw.exe -jar -Xmx1024M josm-latest.jar Pokud to poustis bez parametru, > tak to mas omezeny na 64MB RAM a to samozrejme nemuze stacit, kdyz jen > ten xml ma 170MB. Rychlost zpracovani tomu samozrejme odpovida, na zoom > si pockas ;D, ale udela to. >
d?ky za tip, pou?t?l jsem to bez parametr? zobrazit citaci
> Na zjednodusovani prakticky zapomen, vcera sem to trochu prosel, tak na > mistech kde jsem se namatkou dival to spis chtelo body pridat, pokud bys > to chtel srovnat presne na km. >
to je jedin? dob?e, budu m?t m?? pr?ce :)

26.2.2010 09:32:41 (#20)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> relace: > type=multipolygon, ovsem vsechny soucasne hranicni relace (a nejen nase) > pouzivaji type=boundary
To neni tak uplne pravda - vpostate vsechny hranice v Nemecku, Rakousku a Nizozemi jsou delane pomoci multipolygon. Proc jsem zvolil multipolygon jsem psal tady [1]. Pokud ale prevlada nazor, ze to ma byt boundary, tak se to klidne muze zmenit. zobrazit citaci
> chybi administrativni centra, pokud vim, (asi)kazde ku ma urcenou > obec/cast ke ktere nalezi.
Ano adminnistrativni centra byse mohli pridat, ale asi jenom pro relace obce, okres, kraj, CR. Administrativni centrum pro k.?. je podle m? nesmysl. Jde o to kde vz?t data. Pokud jsou u? administrativn? centra v map?, tak asi nebude probl?m si naj?t na ?zem? kter? obce se admin. centrum nach?z? a za?adit ho do p??slu?n? relace. zobrazit citaci
> nejsou definovany vztahy mezi ku (mineno potomci/rodice, napr stat > obsahuje kraje, ty obsahuji okresy ...)
Tady mam asi mezery, jak se to definuje? zobrazit citaci
> chtelo by to nejakou poznamku, zdroj je km, ale tohle by zaslouzilo > jeste info ze jde o import/automaticke zpracovani
ano, to by urcite chtelo. Jinak zdroj neni km, ale prehledky. A to mi pripomona ... jeste je potreba zmenit tag source na cuzk:prehledky, jak tady nekdo uz poznamenal. zobrazit citaci
> ways: > je pouze tag boundary=administrative, ale IMO by tam mel byt jeste > admin_level. To co jsem opsal od ostatnich = lv cesty odpovida > nejmensimu cislu = nejvyssi urovni pro kterou je hranici. Takze ways > hranice statu by mely mit 2 atd.
Vim, ze ways maji prirazene i admin_level, ale nebyl jsem si jisty jak mam chapat "admin_level=for the highest border" co pisou na wiki [2]. Stejne ale nechapu, proc ways musi mit prirazeny admin_level, kdyz ten je definovan v relaci. Prijde mi jako blbost prirazovat admin_level ceste, kdyz je soucasti vice relaci s ruznymi admin_level. zobrazit citaci
> IMO by varianta A(kompletni upload) byla vhodnejsi, ...
Taky si myslim, ze nahrat vse najednou je nejlepsi reseni [1] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html [2] http://wiki.openstreetmap.org/wiki/Relation:boundary -- Lukas

26.2.2010 09:52:25 (#21)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> Vid?l bych to tak, ?e to rozd?l?m po okresech a nap??u si progr?mek, > kter? dok??e odd?lit duplicity. > P?i uploadu mus?m m?t druh? progr?mek, kter? dok??e vz?t ID bod? a cest > z OSM exportu a zm?nit je v jin?m souboru - asi detekce shodnosti polohy > bod?. Takhle to postupn? naimportovat.
Jak o tom tak uva?uju, tak nejlep?? ?e?en? se mi zd? to zkusit uplodovat cel? najednou. Podle zku?enosti lid? co nahr?vali ??sti DIBAVODu, tak JOSM po?le data celkem rychle na server a pak ?ek? a? si to server "p?e?v?k?" a vr?t? odpove? (a to trv? mnohem d?le) Pokud by spadlo p?ipojen?/JOSM potom, co se odeslali vsechna data, tak by to melo byt v pohode. Server transakci uzavre automaticky akorat se o tom klient nedozvi. Pokud je to jinak, tak me opravte. Pokud bys to chtel delit na vic kusu, tak misto detekce polohy se mi zda lepsi nasledujici postup: - kazde entite priradit jedinecne zaporne ID (znaci, ze se jedna o nov? objekt) - tak uz to je v souboru kucr.osm - rozdelit mapu na vice casti (treba podle okresu) - zduplikuji se ways na hranicich (kazda way bude ve dvou souborech, ale bude m?t st?le svoje ID) - uplodovat cast, server jako odpoved vrati prirazena ID - v ostatn?ch souborech zm?nit z?porn? ID za skute?n? ID vr?cen? serverem - a tak porad dokola, uplodovat budeme ale pouze entity se z?porn?m ID -- Lukas

26.2.2010 10:41:28 (#22)
gravatar

Mike

<mike at mikecrash.com>
196
Takhle to mam na mysli, jen resim, jak to rozdelit, protoze osmosis selhalo, asi si budu muset na to neco napsat. Snad to nebude tak tezky, protoze zaklad mam uz napsany v jinem programu (MC Navi). Stejne tak jak zmenit ty ID - taky na to asi budu muset neco napsat. Nevite nekdo, jak stahnout z OSM jen relaci vcetne vsech podrizenych memberu? On 26.2.2010 9:52, Lukas Kabrt wrote: zobrazit citaci
>> Vid?l bych to tak, ?e to rozd?l?m po okresech a nap??u si progr?mek, >> kter? dok??e odd?lit duplicity. >> P?i uploadu mus?m m?t druh? progr?mek, kter? dok??e vz?t ID bod? a cest >> z OSM exportu a zm?nit je v jin?m souboru - asi detekce shodnosti polohy >> bod?. Takhle to postupn? naimportovat. > > Jak o tom tak uva?uju, tak nejlep?? ?e?en? se mi zd? to zkusit > uplodovat cel? najednou. Podle zku?enosti lid? co nahr?vali ??sti > DIBAVODu, tak JOSM po?le data celkem rychle na server a pak ?ek? a? si > to server "p?e?v?k?" a vr?t? odpove? (a to trv? mnohem d?le) Pokud by > spadlo p?ipojen?/JOSM potom, co se odeslali vsechna data, tak by to > melo byt v pohode. Server transakci uzavre automaticky akorat se o tom > klient nedozvi. Pokud je to jinak, tak me opravte. > > Pokud bys to chtel delit na vic kusu, tak misto detekce polohy se mi > zda lepsi nasledujici postup: > - kazde entite priradit jedinecne zaporne ID (znaci, ze se jedna o > nov? objekt) - tak uz to je v souboru kucr.osm > - rozdelit mapu na vice casti (treba podle okresu) - zduplikuji se > ways na hranicich (kazda way bude ve dvou souborech, ale bude m?t > st?le svoje ID) > > - uplodovat cast, server jako odpoved vrati prirazena ID > - v ostatn?ch souborech zm?nit z?porn? ID za skute?n? ID vr?cen? serverem > - a tak porad dokola, uplodovat budeme ale pouze entity se z?porn?m ID > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

26.2.2010 12:39:30 (#23)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 26.2.2010 9:32, Lukas Kabrt napsal(a): zobrazit citaci
>> relace: >> type=multipolygon, ovsem vsechny soucasne hranicni relace (a nejen nase) >> pouzivaji type=boundary >> > To neni tak uplne pravda - vpostate vsechny hranice v Nemecku, > Rakousku a Nizozemi jsou delane pomoci multipolygon. Proc jsem zvolil > multipolygon jsem psal tady [1]. Pokud ale prevlada nazor, ze to ma > byt boundary, tak se to klidne muze zmenit. > > >> chybi administrativni centra, pokud vim, (asi)kazde ku ma urcenou >> obec/cast ke ktere nalezi. >> > Ano adminnistrativni centra byse mohli pridat, ale asi jenom pro > relace obce, okres, kraj, CR. Administrativni centrum pro k.?. je > podle m? nesmysl. Jde o to kde vz?t data. Pokud jsou u? > administrativn? centra v map?, tak asi nebude probl?m si naj?t na > ?zem? kter? obce se admin. centrum nach?z? a za?adit ho do p??slu?n? > relace. > > >> nejsou definovany vztahy mezi ku (mineno potomci/rodice, napr stat >> obsahuje kraje, ty obsahuji okresy ...) >> > Tady mam asi mezery, jak se to definuje? > >
Relace se do nadrazene vlozi s oznacenim subarea, kdyztak se podivej jak je to ted. zobrazit citaci
>> chtelo by to nejakou poznamku, zdroj je km, ale tohle by zaslouzilo >> jeste info ze jde o import/automaticke zpracovani >> > ano, to by urcite chtelo. Jinak zdroj neni km, ale prehledky. A to mi > pripomona ... jeste je potreba zmenit tag source na cuzk:prehledky, > jak tady nekdo uz poznamenal. > > >> ways: >> je pouze tag boundary=administrative, ale IMO by tam mel byt jeste >> admin_level. To co jsem opsal od ostatnich = lv cesty odpovida >> nejmensimu cislu = nejvyssi urovni pro kterou je hranici. Takze ways >> hranice statu by mely mit 2 atd. >> > Vim, ze ways maji prirazene i admin_level, ale nebyl jsem si jisty jak > mam chapat "admin_level=for the highest > border" co pisou na wiki [2]. Stejne ale nechapu, proc ways musi mit > prirazeny admin_level, kdyz ten je definovan v relaci. Prijde mi jako > blbost prirazovat admin_level ceste, kdyz je soucasti vice relaci s > ruznymi admin_level. >
IMO proto, ze nekdy muzes potrebovat pracovat bez relaci ? Principielne muzes i potok/silnici/... udelat tak, ze tag potok/silnice/... priradis az relaci, ale presto maji vsechny cesty tagy potok/silnice/... a admin_lv je pokud dobre chapu neoddelitelnou soucasti tagu boundary. zobrazit citaci
> > >> IMO by varianta A(kompletni upload) byla vhodnejsi, ... >> > Taky si myslim, ze nahrat vse najednou je nejlepsi reseni > > > [1] http://lists.openstreetmap.org/pipermail/talk-cz/2010-February/004503.html > [2] http://wiki.openstreetmap.org/wiki/Relation:boundary > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

26.2.2010 12:50:01 (#24)
gravatar

Mike

<mike at mikecrash.com>
196
On 26.2.2010 9:32, Lukas Kabrt wrote: zobrazit citaci
>> relace: >> type=multipolygon, ovsem vsechny soucasne hranicni relace (a nejen nase) >> pouzivaji type=boundary > > To neni tak uplne pravda - vpostate vsechny hranice v Nemecku, > Rakousku a Nizozemi jsou delane pomoci multipolygon. Proc jsem zvolil > multipolygon jsem psal tady [1]. Pokud ale prevlada nazor, ze to ma > byt boundary, tak se to klidne muze zmenit. >
To maj? ale kv?li tomu, ?e maj? ?asto v hranic?ch d?ry, tak?e to d?laj? jako multipolygon. To my nem?me (nebo jo?), tak?e bych to rad?i p?ed?lal na boundary. Ale jinak z procesn?ho hlediska je to jedno.

26.2.2010 08:31:15 (#25)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> To maj? ale kv?li tomu, ?e maj? ?asto v hranic?ch d?ry, tak?e to d?laj? > jako multipolygon. To my nem?me (nebo jo?), tak?e bych to rad?i p?ed?lal > na boundary. Ale jinak z procesn?ho hlediska je to jedno.
P?r k.?. s d?rami je. Pak jsou des?tky obc? kde je ?zem? nesouvisl?. -- Lukas

27.2.2010 08:26:11 (#26)
gravatar

Pavel Machek

<pavel at ucw.cz>
1037 1226
On Fri 2010-02-26 10:41:28, Mike wrote: zobrazit citaci
> Takhle to mam na mysli, jen resim, jak to rozdelit, protoze osmosis > selhalo, asi si budu muset na to neco napsat. Snad to nebude tak tezky, > protoze zaklad mam uz napsany v jinem programu (MC Navi). > > Stejne tak jak zmenit ty ID - taky na to asi budu muset neco napsat. > > Nevite nekdo, jak stahnout z OSM jen relaci vcetne vsech podrizenych > memberu?
Co to opravdu prvni zkusit uploadnout najednou...? Kdyz se to nepovede, lze to zmatchovat podle polohy, a bude se muset neco napsat ale... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

27.2.2010 07:28:20 (#27)
gravatar

Mike Crash

<mike at mikecrash.com>
196
Uz mam skoro hotovy rozdelovani, ted se snazim pridat reference na podoblasti a admin center Mozna bych to zkusil uploadovat najednout, pokud ma JOSM rozdelovani do casti, tak by to nemusel byt takovy problem. Co se statni hranici? Tam je navaznost na okolni staty, takze tam vznikne gulas. Nejprijatelnejsi mi prijde, ze celou statni hranici nebudu uploadovat a pak se to rucne kolem dokola objede a pridaji cesty do relaci hrnicnich obci, okresu a kraju. Automaticky merge mi prijde nerealizovatelny. Pavel Machek wrote: zobrazit citaci
> On Fri 2010-02-26 10:41:28, Mike wrote: >> Takhle to mam na mysli, jen resim, jak to rozdelit, protoze osmosis >> selhalo, asi si budu muset na to neco napsat. Snad to nebude tak tezky, >> protoze zaklad mam uz napsany v jinem programu (MC Navi). >> >> Stejne tak jak zmenit ty ID - taky na to asi budu muset neco napsat. >> >> Nevite nekdo, jak stahnout z OSM jen relaci vcetne vsech podrizenych >> memberu? > > Co to opravdu prvni zkusit uploadnout najednou...? Kdyz se to > nepovede, lze to zmatchovat podle polohy, a bude se muset neco napsat > ale... > Pavel

27.2.2010 09:13:08 (#28)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 27.2.2010 19:28, Mike Crash napsal(a): zobrazit citaci
> Uz mam skoro hotovy rozdelovani, ted se snazim pridat reference na > podoblasti a admin center > > Mozna bych to zkusil uploadovat najednout, pokud ma JOSM rozdelovani do > casti, tak by to nemusel byt takovy problem. > > Co se statni hranici? Tam je navaznost na okolni staty, takze tam > vznikne gulas. Nejprijatelnejsi mi prijde, ze celou statni hranici > nebudu uploadovat a pak se to rucne kolem dokola objede a pridaji cesty > do relaci hrnicnich obci, okresu a kraju. Automaticky merge mi prijde > nerealizovatelny. > >
Hranici klido zduplikuj, IMO bude odost presnejsi nez stavajici. zobrazit citaci
> Pavel Machek wrote: > >> On Fri 2010-02-26 10:41:28, Mike wrote: >> >>> Takhle to mam na mysli, jen resim, jak to rozdelit, protoze osmosis >>> selhalo, asi si budu muset na to neco napsat. Snad to nebude tak tezky, >>> protoze zaklad mam uz napsany v jinem programu (MC Navi). >>> >>> Stejne tak jak zmenit ty ID - taky na to asi budu muset neco napsat. >>> >>> Nevite nekdo, jak stahnout z OSM jen relaci vcetne vsech podrizenych >>> memberu? >>> >> Co to opravdu prvni zkusit uploadnout najednou...? Kdyz se to >> nepovede, lze to zmatchovat podle polohy, a bude se muset neco napsat >> ale... >> Pavel >> > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

28.2.2010 09:34:45 (#29)
gravatar

Mike Crash

<mike at mikecrash.com>
196
no uz jsem se rozhodl, ze to asi uploadnu najednou, pokud to pujde, protoze rozdelovani s sebou nese vic problemu nez uzitku v soucasnosti mam pridana okresni a krajska mesta jako admin_center a ke hranicim obce prislusnou obec jako admin_center (par obci v mape chybi, dodela se rucne) jeste resim subarea - ma cenu delat ke vsemu subarea? udelal bych navaznost CR-kraje-okresy, ale ma cenu pokracovat dale -obce-KU ? Tech udaju tam bude moc a bude to vubec k necemu? jzvc wrote: zobrazit citaci
> Dne 27.2.2010 19:28, Mike Crash napsal(a): >> Uz mam skoro hotovy rozdelovani, ted se snazim pridat reference na >> podoblasti a admin center >> >> Mozna bych to zkusil uploadovat najednout, pokud ma JOSM rozdelovani do >> casti, tak by to nemusel byt takovy problem. >> >> Co se statni hranici? Tam je navaznost na okolni staty, takze tam >> vznikne gulas. Nejprijatelnejsi mi prijde, ze celou statni hranici >> nebudu uploadovat a pak se to rucne kolem dokola objede a pridaji cesty >> do relaci hrnicnich obci, okresu a kraju. Automaticky merge mi prijde >> nerealizovatelny. >> >> > > Hranici klido zduplikuj, IMO bude odost presnejsi nez stavajici. > >> Pavel Machek wrote: >> >>> On Fri 2010-02-26 10:41:28, Mike wrote: >>> >>>> Takhle to mam na mysli, jen resim, jak to rozdelit, protoze osmosis >>>> selhalo, asi si budu muset na to neco napsat. Snad to nebude tak tezky, >>>> protoze zaklad mam uz napsany v jinem programu (MC Navi). >>>> >>>> Stejne tak jak zmenit ty ID - taky na to asi budu muset neco napsat. >>>> >>>> Nevite nekdo, jak stahnout z OSM jen relaci vcetne vsech podrizenych >>>> memberu? >>>> >>> Co to opravdu prvni zkusit uploadnout najednou...? Kdyz se to >>> nepovede, lze to zmatchovat podle polohy, a bude se muset neco napsat >>> ale... >>> Pavel >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

28.2.2010 10:12:52 (#30)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> jeste resim subarea - ma cenu delat ke vsemu subarea? udelal bych > navaznost CR-kraje-okresy, ale ma cenu pokracovat dale -obce-KU ? > Tech udaju tam bude moc a bude to vubec k necemu?
Ja bych byl pro pridat i obce a KU, at jsou vsechny hranice v hierarchickem usporadani. Vyuzit se to da - napr. pokud vyberu okres, tak muzu zadat ze chci vybrat potomky relace a vyberou se mi vsechny obce v okrese. -- Lukas

1.3.2010 10:32:27 (#31)
gravatar

Jiri Parkan

<jparkan at gmail.com>
47
Ahoj, to uploadov?n? najednou bude m?t mo?n? jedno ?skal?, jeliko? to trv? dlouho, budou se tam n?jak? ?as povalovat neotagovan? body. Na n?kter? jsem te? narazil p?i kontrole rybn?k?, zaj?malo by m? co se stane, kdy? je n?kdo nezasv?cen? sma?e ne? se za?nou uploadovat waye. Parkis 2010/2/28 Mike Crash <mike at mikecrash.com>: zobrazit citaci
> no uz jsem se rozhodl, ze to asi uploadnu najednou, pokud to pujde, > protoze rozdelovani s sebou nese vic problemu nez uzitku > > v soucasnosti mam pridana okresni a krajska mesta jako admin_center a ke > hranicim obce prislusnou obec jako admin_center (par obci v mape chybi, > dodela se rucne) > > jeste resim subarea - ma cenu delat ke vsemu subarea? udelal bych > navaznost CR-kraje-okresy, ale ma cenu pokracovat dale -obce-KU ? > Tech udaju tam bude moc a bude to vubec k necemu? > > jzvc wrote: >> Dne 27.2.2010 19:28, Mike Crash napsal(a): >>> Uz mam skoro hotovy rozdelovani, ted se snazim pridat reference na >>> podoblasti a admin center >>> >>> Mozna bych to zkusil uploadovat najednout, pokud ma JOSM rozdelovani do >>> casti, tak by to nemusel byt takovy problem. >>> >>> Co se statni hranici? Tam je navaznost na okolni staty, takze tam >>> vznikne gulas. Nejprijatelnejsi mi prijde, ze celou statni hranici >>> nebudu uploadovat a pak se to rucne kolem dokola objede a pridaji cesty >>> do relaci hrnicnich obci, okresu a kraju. Automaticky merge mi prijde >>> nerealizovatelny. >>> >>> >> >> Hranici klido zduplikuj, IMO bude odost presnejsi nez stavajici. >> >>> Pavel Machek wrote: >>> >>>> On Fri 2010-02-26 10:41:28, Mike wrote: >>>> >>>>> Takhle to mam na mysli, jen resim, jak to rozdelit, protoze osmosis >>>>> selhalo, asi si budu muset na to neco napsat. Snad to nebude tak tezky, >>>>> protoze zaklad mam uz napsany v jinem programu (MC Navi). >>>>> >>>>> Stejne tak jak zmenit ty ID - taky na to asi budu muset neco napsat. >>>>> >>>>> Nevite nekdo, jak stahnout z OSM jen relaci vcetne vsech podrizenych >>>>> memberu? >>>>> >>>> Co to opravdu prvni zkusit uploadnout najednou...? Kdyz se to >>>> nepovede, lze to zmatchovat podle polohy, a bude se muset neco napsat >>>> ale... >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Pavel >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

1.3.2010 11:19:12 (#32)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> to uploadov?n? najednou bude m?t mo?n? jedno ?skal?, jeliko? to trv? > dlouho, budou se tam n?jak? ?as povalovat neotagovan? body. Na n?kter? > jsem te? narazil p?i kontrole rybn?k?, zaj?malo by m? co se stane, > kdy? je n?kdo nezasv?cen? sma?e ne? se za?nou uploadovat waye.
Zalezi na tom, jak se to bude uplodovat. Pokud se to bude nahravat cele v jenodnom requestu - lze nastavit v JOSM-latest, tak se changeset bere jako atomicka operace a na serveru se objevi az cely. Pokud jsem to spravne vypozoroval ... -- Lukas

1.3.2010 11:59:00 (#33)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 1.3.2010 11:19, Lukas Kabrt napsal(a): zobrazit citaci
>> to uploadov?n? najednou bude m?t mo?n? jedno ?skal?, jeliko? to trv? >> dlouho, budou se tam n?jak? ?as povalovat neotagovan? body. Na n?kter? >> jsem te? narazil p?i kontrole rybn?k?, zaj?malo by m? co se stane, >> kdy? je n?kdo nezasv?cen? sma?e ne? se za?nou uploadovat waye. >> > Zalezi na tom, jak se to bude uplodovat. Pokud se to bude nahravat > cele v jenodnom requestu - lze nastavit v JOSM-latest, tak se > changeset bere jako atomicka operace a na serveru se objevi az cely. > Pokud jsem to spravne vypozoroval ... > -- > Lukas >
To jo, ale v jednom req lze tusim maximalne 50k bodu, takze toto tak poslat nelze, josm umoznuje posilat po definovanem poctu - napr po 10k a ve vysledku to bude ???jeden??? changeset. Changeset se neuzavre automaticky pokud klient komunikuje a pokud to spravne chapu, dokud neni uzavren, tak data z nej nikdo dalsi nevidi. zobrazit citaci
> _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

1.3.2010 12:41:42 (#34)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> To jo, ale v jednom req lze tusim maximalne 50k bodu, takze toto tak > poslat nelze, josm umoznuje posilat po definovanem poctu - napr po 10k a > ve vysledku to bude ???jeden??? changeset. Changeset se neuzavre > automaticky pokud klient komunikuje a pokud to spravne chapu, dokud neni > uzavren, tak data z nej nikdo dalsi nevidi.
Na wiki [1] je napspano, ze 50 000 je limit na changeset. Pri pouziti JOSM-stable se uploduje entita po entite (predpokladam, ze volanim /api/0.6/[node|way|relation]/create). Mam odzkouseno, ze v tomhle pripade, se data ostatnim uzivatelum zobrazuji postupne, tak jak jsou uplodovana na server. (Lze vyzkouset treba tak, ze spustite upload, otevrete si svuj profil na OSM, podivate se na svoje editace a uvidite jak postupne pribyvaji zmeny do changesetu, co uplodujete) Pri poiziti JOSM-latest a nastaveni vse v jednom requestu (predpokladam, ze se vola /api/0.6/changeset/#id/upload) se zmeny na serveru projevi az po nahrani celeho souboru. Pozor, changeset uzavren byt nemusi! (Opet to lze vyzkouset. Spustit upload, podivat se na svoje editace v profilu - change set se objevi az pote co JOSM dokonci upload souboru. To ale jeste driv nez JOSM changeset zavre - pravdepodobne ceka na odpoved ze serveru - nekdy i dost dlouho, pokud JOSM v tehle fazi schodite, tak zmeny uz zustanou na serveru) Jde o to, zda server changeset uzavre po 50000 zmenach i kdyz se vse uploduje v jedno requestu. To se asi dozvime jedine tak, ze to zkusime. Jestli plati to co je na wiki, tak u 2. zpusobu je garantovano provedeni jako atomicka operace, takze nic neriskujeme. [1] http://wiki.openstreetmap.org/wiki/API_v0.6 -- Lukas

1.3.2010 03:11:49 (#35)
gravatar

Mike

<mike at mikecrash.com>
196
Tak mam odzkouseno - 50 tis. je limit changesetu, vic ani tuk, takze uz nahravam po castech, ale jde to pomalu. Prosim nemazte nikde prazdny nody, at mi tam na konci nechybi. Udelal jsem (skoro) kompletni navaznosti kraje-okresy-mesta-ku az na nejake vyjimky (chybejici obce, mismatch v nazvech), ktere budu resit rucne. Take hranice statu budu delat rucne, tam to asi jinak nepujde. Nedavno to probehlo na Slovensku a take delali statni hranice rucne. Nedaval jsem jen definice admin_center pro KU, ktere mi prijdou nesmyslne, i kdyz by tam sla placnout obec. Ale byla by to duplicita. Hotovo by to mohlo byt zitra, kdyz to pujde dobre. Jeden upload uz mi ale selhal, tak to budu muset nejak vyresit. Pak prijdou na radu rucni upravy. On 1.3.2010 12:41, Lukas Kabrt wrote: zobrazit citaci
>> To jo, ale v jednom req lze tusim maximalne 50k bodu, takze toto tak >> poslat nelze, josm umoznuje posilat po definovanem poctu - napr po 10k a >> ve vysledku to bude ???jeden??? changeset. Changeset se neuzavre >> automaticky pokud klient komunikuje a pokud to spravne chapu, dokud neni >> uzavren, tak data z nej nikdo dalsi nevidi. > > Na wiki [1] je napspano, ze 50 000 je limit na changeset. > > Pri pouziti JOSM-stable se uploduje entita po entite (predpokladam, ze > volanim /api/0.6/[node|way|relation]/create). Mam odzkouseno, ze v > tomhle pripade, se data ostatnim uzivatelum zobrazuji postupne, tak > jak jsou uplodovana na server. (Lze vyzkouset treba tak, ze spustite > upload, otevrete si svuj profil na OSM, podivate se na svoje editace a > uvidite jak postupne pribyvaji zmeny do changesetu, co uplodujete) > > Pri poiziti JOSM-latest a nastaveni vse v jednom requestu > (predpokladam, ze se vola /api/0.6/changeset/#id/upload) se zmeny na > serveru projevi az po nahrani celeho souboru. Pozor, changeset uzavren > byt nemusi! (Opet to lze vyzkouset. Spustit upload, podivat se na > svoje editace v profilu - change set se objevi az pote co JOSM dokonci > upload souboru. To ale jeste driv nez JOSM changeset zavre - > pravdepodobne ceka na odpoved ze serveru - nekdy i dost dlouho, pokud > JOSM v tehle fazi schodite, tak zmeny uz zustanou na serveru) > > Jde o to, zda server changeset uzavre po 50000 zmenach i kdyz se vse > uploduje v jedno requestu. To se asi dozvime jedine tak, ze to > zkusime. Jestli plati to co je na wiki, tak u 2. zpusobu je > garantovano provedeni jako atomicka operace, takze nic neriskujeme. > > [1] http://wiki.openstreetmap.org/wiki/API_v0.6 > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

1.3.2010 05:26:12 (#36)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> Tak mam odzkouseno - 50 tis. je limit changesetu, vic ani tuk,
A jak se to chova? Pokud se to uploduje v jednom requestu, tak to je to skutecne atomicka operace? Nebo to vezme prvnich 50000 zmen a ty ulozi? zobrazit citaci
> takze uz nahravam po castech, ale jde to pomalu.
Koukal jsem a drzim palce :-) -- Lukas

1.3.2010 08:00:28 (#37)
gravatar

Mike Crash

<mike at mikecrash.com>
196
D?l?m to pomoc? bulk_upload, ten otev?e changeset a nahr?v? po 1000 z?znamech najednou. Nekontroluje ale max. po?et, tak?e to mus?m ru?n? rozsekat. U? m?m 3 zka?en? uploady - internal sever error 500, ale to vy?e??m. M?m jen bobky z toho, co to ud?l? p?i uploadu cest, pokud bude n?jak? node chyb?t. Lukas Kabrt wrote: zobrazit citaci
>> Tak mam odzkouseno - 50 tis. je limit changesetu, vic ani tuk, > > A jak se to chova? Pokud se to uploduje v jednom requestu, tak to je > to skutecne atomicka operace? Nebo to vezme prvnich 50000 zmen a ty > ulozi? > > >> takze uz nahravam po castech, ale jde to pomalu. > > Koukal jsem a drzim palce :-) > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

2.3.2010 12:47:19 (#38)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> M?m jen bobky z toho, co to ud?l? p?i uploadu cest, pokud bude n?jak? > node chyb?t.
Obavam se, ze neco ve smyslu HTTP status code 409 (Conflict) nebo HTTP status code 412 (Precondition Failed) viz. wiki [1]. [1] http://wiki.openstreetmap.org/wiki/API_v0.6 -- Lukas

2.3.2010 03:10:21 (#39)
gravatar

Mike

<mike at mikecrash.com>
196
Co? to o?ek?v?m, ale jestli to bude jen na tu jednu cestu nebo to skon?? ?pln?, dnes ve?er se uvid? On 2.3.2010 0:47, Lukas Kabrt wrote: zobrazit citaci
>> M?m jen bobky z toho, co to ud?l? p?i uploadu cest, pokud bude n?jak? >> node chyb?t. > > Obavam se, ze neco ve smyslu HTTP status code 409 (Conflict) nebo HTTP > status code 412 (Precondition Failed) viz. wiki [1]. > > [1] http://wiki.openstreetmap.org/wiki/API_v0.6 > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

2.3.2010 03:46:17 (#40)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> Co? to o?ek?v?m, ale jestli to bude jen na tu jednu cestu nebo to skon?? > ?pln?, dnes ve?er se uvid?
Citace z wiki: Processing stops at the first error, so if there are multiple conflicts in one diff upload, only the first problem is reported. -- Lukas

2.3.2010 04:09:18 (#41)
gravatar

alik dolezal

<alik.dolezal at gmail.com>
12
zobrazit citaci
>>> M?m jen bobky z toho, co to ud?l? p?i uploadu cest, pokud bude n?jak? >>> node chyb?t.
Ahoj, m?m takovej nep??jemnej pocit, ?e v?m d?m mo?nost zjistit co se stane. P?i t?ech [1][2][3] dne?n?ch zm?n?ch se mi poda?ilo vymazat celkem 39 bod?. Jedn? se o ??sti hranic katastr?ln?ch ?zem? "Horn? Dubenky" a "Kali?t? u Horn?ch Dubenek" (13 nod?) a "Nov? Ves u T?e?ti" a "R?cov" (zbyl?ch 26 nod?). Jestli m??u n?jak pomoct vy?e?it tuhle moji botu tak dejte v?det (no m??u dodat id-?ka tech nod?, na to u? sem se koukal). Mus?m se taky omluvit za takov?hle nabour?v?n? va?eho importu, ve?te, ?e v tom opravdu nebyl zlej ?mysl. Ale? [1] http://www.openstreetmap.org/browse/changeset/4016866 [2] http://www.openstreetmap.org/browse/changeset/4015001 [3] http://www.openstreetmap.org/browse/changeset/4014850

2.3.2010 04:36:19 (#42)
gravatar

MP

<singularita at gmail.com>
306
On 02/03/2010, alik dolezal <alik.dolezal at gmail.com> wrote: zobrazit citaci
> >>> M?m jen bobky z toho, co to ud?l? p?i uploadu cest, pokud bude n?jak? > >>> node chyb?t. > > > Ahoj, > > m?m takovej nep??jemnej pocit, ?e v?m d?m mo?nost zjistit co se stane.
Nejsem si jist, jestli jsem p?i likvidaci duplicitn?ch rybn?k? (te? u? ale v datech ??dn? duplicitn? rybn?ky nejsou) taky ob?as nesmazal n?jak? ten node (jakmile jsem si tohle vl?kno p?e?etl, tak u? jsem si na to d?val pozor .... ). Mo?n? by to ?lo vy?e?it tak, ?e se st?hne dump z geofabrik, tam se vyparsuj? v?echny existuj?c? ID?ka nod? a porovnaj? se s ID?ky co jsou v datech k importu. Ty data kde n?jak? node chyb? by se daly do extra souboru (zbytek by bse mohl hned uploadnout) a mohly se pak vy?e?it zvl??? - t?eba n?jak p?ezna?it chyb?j?c? ID?ka na nov? ID a doplnit je tam, co? by snad mohlo j?t automaticky. P??padn? to nechat uploadovat jednotliv? po jednotliv?ch cest?ch. Martin

2.3.2010 09:03:16 (#43)
gravatar

Mike Crash

<mike at mikecrash.com>
196
No uz si s tim nejak poradim, trosku jsem s tim pocital :) Mel jsem zvolit jiny zpusob, ale mel jsem problem s tim, jak to cele rozdelit (trochu lenost). Ted se mi parsuji cesty a za chvili zacnu s importem cest, tak pak uz to snad bude OK Relace udelam az nakonec MP wrote: zobrazit citaci
> On 02/03/2010, alik dolezal <alik.dolezal at gmail.com> wrote: >>>>> M?m jen bobky z toho, co to ud?l? p?i uploadu cest, pokud bude n?jak? >> >>> node chyb?t. >> >> >> Ahoj, >> >> m?m takovej nep??jemnej pocit, ?e v?m d?m mo?nost zjistit co se stane. > > Nejsem si jist, jestli jsem p?i likvidaci duplicitn?ch rybn?k? (te? u? > ale v datech ??dn? duplicitn? rybn?ky nejsou) taky ob?as nesmazal > n?jak? ten node (jakmile jsem si tohle vl?kno p?e?etl, tak u? jsem si > na to d?val pozor .... ). > > Mo?n? by to ?lo vy?e?it tak, ?e se st?hne dump z geofabrik, tam se > vyparsuj? v?echny existuj?c? ID?ka nod? a porovnaj? se s ID?ky co jsou > v datech k importu. Ty data kde n?jak? node chyb? by se daly do extra > souboru (zbytek by bse mohl hned uploadnout) a mohly se pak vy?e?it > zvl??? - t?eba n?jak p?ezna?it chyb?j?c? ID?ka na nov? ID a doplnit je > tam, co? by snad mohlo j?t automaticky. P??padn? to nechat uploadovat > jednotliv? po jednotliv?ch cest?ch. > Martin > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

3.3.2010 07:07:09 (#44)
gravatar

Mike Crash

<mike at mikecrash.com>
196
Je?t? dod?m, ?e p?i chyb? je cel? po?adavek odm?tnut, ale p?edchoz? po?adavky v changesetu z?stanou. Info: Sou?asn? stav: nodes+ways nahr?ny a v map? p?edchoz? relace smaz?ny D?l?m: ma?u star? hranice N?sleduje: nahr?n? relac? (pot?ebuju dod?lat NUTS2 relace) oprava hranice s okoln?mi zem?mi Pros?m needitujte zat?m boundary, a? v tom nem?m bordel :) D?m zase v?d?t, jak to postupuje Lukas Kabrt wrote: zobrazit citaci
>> Co? to o?ek?v?m, ale jestli to bude jen na tu jednu cestu nebo to skon?? >> ?pln?, dnes ve?er se uvid? > > Citace z wiki: > Processing stops at the first error, so if there are multiple > conflicts in one diff upload, only the first problem is reported. > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

3.3.2010 09:58:07 (#45)
gravatar

Lukas Kabrt

<lukas at kabrt.cz>
92
zobrazit citaci
> N?sleduje: > nahr?n? relac? (pot?ebuju dod?lat NUTS2 relace)
NUTS 2 (regiony) v datech jsou. Tak jak je to na wiki s admin_level=4. Nahrana data jsem si prohlizel a narazil jsem na jeden problem. Vsechny ways, na ktere jsou koukal existuji ve dvou duplikatech. Way je vzdy tvorena stejnymi uzly, ale existuje ve dvou exemplarich. Oba dva pritom pochazi ze stejneho changesetu. Napriklad [1] a [2]. Koukal jsem nahodne po cele republice a vsude to bylo stejne. [1] http://www.openstreetmap.org/browse/way/51638208 [2] http://www.openstreetmap.org/browse/way/51639256 -- Lukas

4.3.2010 08:16:33 (#46)
gravatar

Mike Crash

<mike at mikecrash.com>
196
Hmm, to je divny, zkusim to omrknout co a jak a proc a kolik toho je Diky za upozorneni Lukas Kabrt wrote: zobrazit citaci
>> N?sleduje: >> nahr?n? relac? (pot?ebuju dod?lat NUTS2 relace) > > NUTS 2 (regiony) v datech jsou. Tak jak je to na wiki s admin_level=4. > > > Nahrana data jsem si prohlizel a narazil jsem na jeden problem. > Vsechny ways, na ktere jsou koukal existuji ve dvou duplikatech. Way > je vzdy tvorena stejnymi uzly, ale existuje ve dvou exemplarich. Oba > dva pritom pochazi ze stejneho changesetu. Napriklad [1] a [2]. Koukal > jsem nahodne po cele republice a vsude to bylo stejne. > > [1] http://www.openstreetmap.org/browse/way/51638208 > [2] http://www.openstreetmap.org/browse/way/51639256 > -- > Lukas > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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