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

[Talk-cz] Import DIBAVOD

Vlákno 22.2. - 20.5.2010, počet zpráv: 47


22.2.2010 06:59:05 (#1)
gravatar

Zdeněk Pražák

<ZPrazak at seznam.cz>
749
Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t.

22.2.2010 08:01:53 (#2)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Ahoj! zobrazit citaci
> Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t.
Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

22.2.2010 08:12:30 (#3)
gravatar

Zdeněk Pražák

<ZPrazak at seznam.cz>
749
Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta ?. 50932852, 50935613 a 50934642 Pra?k zobrazit citaci
> ------------ P?vodn? zpr?va ------------ > Od: Pavel Machek <pavel at ucw.cz> > P?edm?t: Re: [Talk-cz] Import DIBAVOD > Datum: 22.2.2010 08:03:14 > ---------------------------------------- > Ahoj! > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t. > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > znovu. > > Opravdu je duplicita v datech? > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

22.2.2010 08:13:36 (#4)
gravatar

Jiri Parkan

<jparkan at gmail.com>
47
Bohu?el se zd? ?e ano, v?echny 4 changesety obsahuj? p?es 10000 bod?. Nam?tkou t?eba http://osm.org/go/0JycpXo at U-- po otev?en? v potlachu je tam rybn?k 4x p?e sebe (a potlach na to upozor?uje ?erven?m blik?n?, tohle by se mi l?bilo i v JOSM) Parkis 2010/2/22 Pavel Machek <pavel at ucw.cz>: zobrazit citaci
> Ahoj! > >> Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t. > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > znovu. > > Opravdu je duplicita v datech? > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

22.2.2010 12:08:24 (#5)
gravatar

MP

<singularita at gmail.com>
306
On 22/02/2010, Jiri Parkan <jparkan at gmail.com> wrote: zobrazit citaci
> Bohu?el se zd? ?e ano, v?echny 4 changesety obsahuj? p?es 10000 bod?. > Nam?tkou t?eba http://osm.org/go/0JycpXo at U-- po otev?en? v potlachu je > tam rybn?k 4x p?e sebe (a potlach na to upozor?uje ?erven?m blik?n?, > tohle by se mi l?bilo i v JOSM)
JOSM to umi - staci mit plugin validator a duplicitni cesty (ty, jejichz nody maji stejne souradnice) to dokaze najit (a cervene zvyraznit) a kdyz se pak ty cesty ve validatoru vyberou a klikne se na "Fix" tak ze vsech duplicitnich cest zustane jenom ta nejstarsi. Pak spustit validaci znovu, vybrat "untagged and unconnected nodes" a zase dat "Fix". Potreti pak spravit "Duplicate nodes" a je to, extra data jsou na par kliknuti smazana :) Martin

22.2.2010 09:15:52 (#6)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219 February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181 February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082 February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel zobrazit citaci
> Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. > > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta ?. 50932852, 50935613 a 50934642 > > Pra?k > > ------------ P?vodn? zpr?va ------------ > > Od: Pavel Machek <pavel at ucw.cz> > > P?edm?t: Re: [Talk-cz] Import DIBAVOD > > Datum: 22.2.2010 08:03:14 > > ---------------------------------------- > > Ahoj! > > > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t. > > > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > > znovu. > > > > Opravdu je duplicita v datech? > > > > -- > > (english) http://www.livejournal.com/~pavelmachek > > (cesky, pictures) > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

23.2.2010 06:44:39 (#7)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Hi! (Unfortunately, talk is moderated, so the message probably waits in queue somewhere). Moderators, could you let the message through? Alternatively, can someone who is subscribed to talk just forward it? Pavel zobrazit citaci
> It seems that I created duplicate data when importing DIBAVOD; I > assumed that if connection died before closing transaction, no data > would be uploaded, and it seems it is not so :-(. > > Edits in question are: > > #3938287 February 21, 2010 20:50 dibavod, cast 41 > 11.985,48.587,17.993,50.959 (big) > #3938219 February 21, 2010 21:37 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > #3938181 February 21, 2010 21:30 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > #3938082 February 21, 2010 21:23 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > > ...they should be duplicates (if not, the biggest one should be left). > > Now, there are big fat warnings about revert scripts and I'd prefer > not to mess up the database even more. What is the best way to > proceed? > > Sorry for the mess, > Pavel > > > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. > > > > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta ?. 50932852, 50935613 a 50934642 > > > > Pra?k > > > ------------ P?vodn? zpr?va ------------ > > > Od: Pavel Machek <pavel at ucw.cz> > > > P?edm?t: Re: [Talk-cz] Import DIBAVOD > > > Datum: 22.2.2010 08:03:14 > > > ---------------------------------------- > > > Ahoj! > > > > > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t. > > > > > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > > > znovu. > > > > > > Opravdu je duplicita v datech? > > > > > > -- > > > (english) http://www.livejournal.com/~pavelmachek > > > (cesky, pictures) > > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

23.2.2010 08:41:54 (#8)
gravatar

MP

<singularita at gmail.com>
306
Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Tak doufejme, ze se toho pri tom revertu nesmaze vic nez se ma (aby aspon jedna kopie zustala) - validator to aspon dela deterministicky (z vice kopii jedne cesty ponecha tu s nejnizsim ID, tedy tu nejstarsi ...). Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: zobrazit citaci
> Hi! > > It seems that I created duplicate data when importing DIBAVOD; I > assumed that if connection died before closing transaction, no data > would be uploaded, and it seems it is not so :-(. > > Edits in question are: > > #3938287 February 21, 2010 20:50 dibavod, cast 41 > 11.985,48.587,17.993,50.959 (big) > #3938219 February 21, 2010 21:37 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > #3938181 February 21, 2010 21:30 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > #3938082 February 21, 2010 21:23 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > > ...they should be duplicates (if not, the biggest one should be left). > > Now, there are big fat warnings about revert scripts and I'd prefer > not to mess up the database even more. What is the best way to > proceed? > > Sorry for the mess, > > Pavel > > > > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. > > > > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta ?. 50932852, 50935613 a 50934642 > > > > Pra?k > > > ------------ P?vodn? zpr?va ------------ > > > Od: Pavel Machek <pavel at ucw.cz> > > > P?edm?t: Re: [Talk-cz] Import DIBAVOD > > > Datum: 22.2.2010 08:03:14 > > > ---------------------------------------- > > > Ahoj! > > > > > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t. > > > > > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > > > znovu. > > > > > > Opravdu je duplicita v datech? > > > > > > -- > > > (english) http://www.livejournal.com/~pavelmachek > > > (cesky, pictures) > > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

23.2.2010 09:38:41 (#9)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro cel? d?l :-(... J&D Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): zobrazit citaci
> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s > validatorem to jde rychle a vcelku automaticky...), takze nektere > rybniky tam jsou uz jen jednou. > > > Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, > kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z > dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej > (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky > dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 > duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich > bylo asi 32000) > > Takze duplicity od Medulove by taky asi chtely vyresit... > > Martin > > On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: >> Hi! >> >> ?It seems that I created duplicate data when importing DIBAVOD; I >> ?assumed that if connection died before closing transaction, no data >> ?would be uploaded, and it seems it is not so :-(. >> >> ?Edits in question are: >> >> ?#3938287 ? ? ? ? February 21, 2010 20:50 ? ? ? ? dibavod, cast 41 >> ?11.985,48.587,17.993,50.959 ? (big) >> ?#3938219 ? ? ? ?February 21, 2010 21:37 ? ? ? ? import dibavod, cast >> ?41 ? ? ?11.985,48.587,17.993,50.959 (big) >> ?#3938181 ? ? ? ?February 21, 2010 21:30 ? ? ? ? import dibavod, cast >> ?41 ? ? ?11.985,48.587,17.993,50.959 (big) >> ?#3938082 ? ? ? ?February 21, 2010 21:23 ? ? ? ? import dibavod, cast >> ?41 ? ? ?11.985,48.587,17.993,50.959 (big) >> >> ?...they should be duplicates (if not, the biggest one should be left). >> >> ?Now, there are big fat warnings about revert scripts and I'd prefer >> ?not to mess up the database even more. What is the best way to >> ?proceed? >> >> ?Sorry for the mess, >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Pavel >> >> >> ?> Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. >> ?> >> ?> Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta ?. 50932852, 50935613 a 50934642 >> ?> >> ?> Pra?k >> ?> > ------------ P?vodn? zpr?va ------------ >> ?> > Od: Pavel Machek <pavel at ucw.cz> >> ?> > P?edm?t: Re: [Talk-cz] Import DIBAVOD >> ?> > Datum: 22.2.2010 08:03:14 >> ?> > ---------------------------------------- >> ?> > Ahoj! >> ?> > >> ?> > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t. >> ?> > >> ?> > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze >> ?> > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to >> ?> > znovu. >> ?> > >> ?> > Opravdu je duplicita v datech? >> ?> > >> ?> > -- >> ?> > (english) http://www.livejournal.com/~pavelmachek >> ?> > (cesky, pictures) >> ?> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> ?-- >> ?(english) http://www.livejournal.com/~pavelmachek >> ?(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >
-- -- Ing. Jan Dud?k

23.2.2010 09:44:59 (#10)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dud?k napsal(a): zobrazit citaci
> Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel > jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro > cel? d?l :-(... > > J&D > > Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): > >> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s >> validatorem to jde rychle a vcelku automaticky...), takze nektere >> rybniky tam jsou uz jen jednou. >> >> >> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, >> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z >> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej >> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky >> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 >> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich >> bylo asi 32000) >> >> Takze duplicity od Medulove by taky asi chtely vyresit... >> >> Martin >> >> On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: >> >>> Hi! >>> >>> It seems that I created duplicate data when importing DIBAVOD; I >>> assumed that if connection died before closing transaction, no data >>> would be uploaded, and it seems it is not so :-(. >>> >>> Edits in question are: >>> >>> #3938287 February 21, 2010 20:50 dibavod, cast 41 >>> 11.985,48.587,17.993,50.959 (big) >>> #3938219 February 21, 2010 21:37 import dibavod, cast >>> 41 11.985,48.587,17.993,50.959 (big) >>> #3938181 February 21, 2010 21:30 import dibavod, cast >>> 41 11.985,48.587,17.993,50.959 (big) >>> #3938082 February 21, 2010 21:23 import dibavod, cast >>> 41 11.985,48.587,17.993,50.959 (big) >>> >>> ...they should be duplicates (if not, the biggest one should be left). >>> >>> Now, there are big fat warnings about revert scripts and I'd prefer >>> not to mess up the database even more. What is the best way to >>> proceed? >>> >>> Sorry for the mess, >>> >>> Pavel >>> >>> >>> > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. >>> > >>> > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta ?. 50932852, 50935613 a 50934642 >>> > >>> > Pra?k >>> > > ------------ P?vodn? zpr?va ------------ >>> > > Od: Pavel Machek <pavel at ucw.cz> >>> > > P?edm?t: Re: [Talk-cz] Import DIBAVOD >>> > > Datum: 22.2.2010 08:03:14 >>> > > ---------------------------------------- >>> > > Ahoj! >>> > > >>> > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem ?ty?ikr?t. >>> > > >>> > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze >>> > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to >>> > > znovu. >>> > > >>> > > Opravdu je duplicita v datech? >>> > > >>> > > -- >>> > > (english) http://www.livejournal.com/~pavelmachek >>> > > (cesky, pictures) >>> > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >>> >>> -- >>> (english) http://www.livejournal.com/~pavelmachek >>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> > > > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100223/7b429337/attachment.html>

23.2.2010 09:48:04 (#11)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): zobrazit citaci
> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM > uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat > save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? > > Tomas > > Jan Dud?k napsal(a): > > Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel > jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro > cel? d?l :-(... > > J&D > > Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): > > > Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s > validatorem to jde rychle a vcelku automaticky...), takze nektere > rybniky tam jsou uz jen jednou. > > > Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, > kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z > dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej > (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky > dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 > duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich > bylo asi 32000) > > Takze duplicity od Medulove by taky asi chtely vyresit... > > Martin > > On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: > > > Hi! > > ?It seems that I created duplicate data when importing DIBAVOD; I > ?assumed that if connection died before closing transaction, no data > ?would be uploaded, and it seems it is not so :-(. > > ?Edits in question are: > > ?#3938287 ? ? ? ? February 21, 2010 20:50 ? ? ? ? dibavod, cast 41 > ?11.985,48.587,17.993,50.959 ? (big) > ?#3938219 ? ? ? ?February 21, 2010 21:37 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > ?#3938181 ? ? ? ?February 21, 2010 21:30 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > ?#3938082 ? ? ? ?February 21, 2010 21:23 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > > ?...they should be duplicates (if not, the biggest one should be left). > > ?Now, there are big fat warnings about revert scripts and I'd prefer > ?not to mess up the database even more. What is the best way to > ?proceed? > > ?Sorry for the mess, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Pavel > > > ?> Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. > ?> > ?> Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta > ?. 50932852, 50935613 a 50934642 > ?> > ?> Pra?k > ?> > ------------ P?vodn? zpr?va ------------ > ?> > Od: Pavel Machek <pavel at ucw.cz> > ?> > P?edm?t: Re: [Talk-cz] Import DIBAVOD > ?> > Datum: 22.2.2010 08:03:14 > ?> > ---------------------------------------- > ?> > Ahoj! > ?> > > ?> > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem > ?ty?ikr?t. > ?> > > ?> > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > ?> > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > ?> > znovu. > ?> > > ?> > Opravdu je duplicita v datech? > ?> > > ?> > -- > ?> > (english) http://www.livejournal.com/~pavelmachek > ?> > (cesky, pictures) > ?> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > ?-- > ?(english) http://www.livejournal.com/~pavelmachek > ?(cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >

23.2.2010 09:52:57 (#12)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
No asi to tak neni, protoze by pak nevznikly ty duplikaty. Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se spravne pri uploadech chovat... Tomas Jan Bilak napsal(a): zobrazit citaci
> Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede > cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? > > Honza > > > Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): > >> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM >> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat >> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? >> >> Tomas >> >> Jan Dud?k napsal(a): >> >> Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel >> jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro >> cel? d?l :-(... >> >> J&D >> >> Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): >> >> >> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s >> validatorem to jde rychle a vcelku automaticky...), takze nektere >> rybniky tam jsou uz jen jednou. >> >> >> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, >> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z >> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej >> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky >> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 >> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich >> bylo asi 32000) >> >> Takze duplicity od Medulove by taky asi chtely vyresit... >> >> Martin >> >> On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: >> >> >> Hi! >> >> It seems that I created duplicate data when importing DIBAVOD; I >> assumed that if connection died before closing transaction, no data >> would be uploaded, and it seems it is not so :-(. >> >> Edits in question are: >> >> #3938287 February 21, 2010 20:50 dibavod, cast 41 >> 11.985,48.587,17.993,50.959 (big) >> #3938219 February 21, 2010 21:37 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> #3938181 February 21, 2010 21:30 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> #3938082 February 21, 2010 21:23 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> >> ...they should be duplicates (if not, the biggest one should be left). >> >> Now, there are big fat warnings about revert scripts and I'd prefer >> not to mess up the database even more. What is the best way to >> proceed? >> >> Sorry for the mess, >> >> Pavel >> >> >> > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. >> > >> > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta >> ?. 50932852, 50935613 a 50934642 >> > >> > Pra?k >> > > ------------ P?vodn? zpr?va ------------ >> > > Od: Pavel Machek <pavel at ucw.cz> >> > > P?edm?t: Re: [Talk-cz] Import DIBAVOD >> > > Datum: 22.2.2010 08:03:14 >> > > ---------------------------------------- >> > > Ahoj! >> > > >> > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem >> ?ty?ikr?t. >> > > >> > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze >> > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to >> > > znovu. >> > > >> > > Opravdu je duplicita v datech? >> > > >> > > -- >> > > (english) http://www.livejournal.com/~pavelmachek >> > > (cesky, pictures) >> > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> >> >> >> >> _______________________________________________ >> 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 >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100223/c10ca566/attachment.html>

23.2.2010 09:55:59 (#13)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ja vychazel z tohoto: Diff upload: POST /api/0.6/changeset/#id/upload With this API call files in the OsmChange format can be uploaded to the server. This is guaranteed to be running in a transaction. So either all the changes are applied or none. To upload an OSC file it has to conform to the OsmChange specification with the addition of a changeset and a version attribute for each element, except when you are creating an element where the version is not required as the server sets that for you. [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] Honza 2010/2/23 Tomas Kolda <kolda at web2net.cz>: zobrazit citaci
> No asi to tak neni, protoze by pak nevznikly ty duplikaty. > > Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se > spravne pri uploadech chovat... > > Tomas > > Jan Bilak napsal(a): > > Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede > cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? > > Honza > > > Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): > > > A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM > uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat > save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? > > Tomas > > Jan Dud?k napsal(a): > > Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel > jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro > cel? d?l :-(... > > J&D > > Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): > > > Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s > validatorem to jde rychle a vcelku automaticky...), takze nektere > rybniky tam jsou uz jen jednou. > > > Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, > kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z > dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej > (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky > dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 > duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich > bylo asi 32000) > > Takze duplicity od Medulove by taky asi chtely vyresit... > > Martin > > On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: > > > Hi! > > ?It seems that I created duplicate data when importing DIBAVOD; I > ?assumed that if connection died before closing transaction, no data > ?would be uploaded, and it seems it is not so :-(. > > ?Edits in question are: > > ?#3938287 ? ? ? ? February 21, 2010 20:50 ? ? ? ? dibavod, cast 41 > ?11.985,48.587,17.993,50.959 ? (big) > ?#3938219 ? ? ? ?February 21, 2010 21:37 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > ?#3938181 ? ? ? ?February 21, 2010 21:30 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > ?#3938082 ? ? ? ?February 21, 2010 21:23 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > > ?...they should be duplicates (if not, the biggest one should be left). > > ?Now, there are big fat warnings about revert scripts and I'd prefer > ?not to mess up the database even more. What is the best way to > ?proceed? > > ?Sorry for the mess, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Pavel > > > ?> Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. > ?> > ?> Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta > ?. 50932852, 50935613 a 50934642 > ?> > ?> Pra?k > ?> > ------------ P?vodn? zpr?va ------------ > ?> > Od: Pavel Machek <pavel at ucw.cz> > ?> > P?edm?t: Re: [Talk-cz] Import DIBAVOD > ?> > Datum: 22.2.2010 08:03:14 > ?> > ---------------------------------------- > ?> > Ahoj! > ?> > > ?> > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem > ?ty?ikr?t. > ?> > > ?> > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > ?> > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > ?> > znovu. > ?> > > ?> > Opravdu je duplicita v datech? > ?> > > ?> > -- > ?> > (english) http://www.livejournal.com/~pavelmachek > ?> > (cesky, pictures) > ?> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > ?-- > ?(english) http://www.livejournal.com/~pavelmachek > ?(cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > > > > > _______________________________________________ > 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 > >

23.2.2010 10:08:19 (#14)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 23.2.2010 21:55, Jan Bilak napsal(a): zobrazit citaci
> Ja vychazel z tohoto: > > Diff upload: POST /api/0.6/changeset/#id/upload > > With this API call files in the OsmChange format can be uploaded to > the server. This is guaranteed to be running in a transaction. So > either all the changes are applied or none. > To upload an OSC file it has to conform to the OsmChange specification > with the addition of a changeset and a version attribute for each > element, except when you are creating an element where the version is > not required as the server sets that for you. > > [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] > > Honza > >
Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce byla uzavrena => melo by to by duplicitni komplet a teoreticky by melo jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. Nektere typy chyb by tomu nasvedcovaly. BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. zobrazit citaci
> 2010/2/23 Tomas Kolda <kolda at web2net.cz>: > >> No asi to tak neni, protoze by pak nevznikly ty duplikaty. >> >> Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se >> spravne pri uploadech chovat... >> >> Tomas >> >> Jan Bilak napsal(a): >> >> Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede >> cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? >> >> Honza >> >> >> Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): >> >> >> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM >> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat >> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? >> >> Tomas >> >> Jan Dud?k napsal(a): >> >> Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel >> jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro >> cel? d?l :-(... >> >> J&D >> >> Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): >> >> >> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s >> validatorem to jde rychle a vcelku automaticky...), takze nektere >> rybniky tam jsou uz jen jednou. >> >> >> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, >> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z >> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej >> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky >> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 >> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich >> bylo asi 32000) >> >> Takze duplicity od Medulove by taky asi chtely vyresit... >> >> Martin >> >> On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: >> >> >> Hi! >> >> It seems that I created duplicate data when importing DIBAVOD; I >> assumed that if connection died before closing transaction, no data >> would be uploaded, and it seems it is not so :-(. >> >> Edits in question are: >> >> #3938287 February 21, 2010 20:50 dibavod, cast 41 >> 11.985,48.587,17.993,50.959 (big) >> #3938219 February 21, 2010 21:37 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> #3938181 February 21, 2010 21:30 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> #3938082 February 21, 2010 21:23 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> >> ...they should be duplicates (if not, the biggest one should be left). >> >> Now, there are big fat warnings about revert scripts and I'd prefer >> not to mess up the database even more. What is the best way to >> proceed? >> >> Sorry for the mess, >> >> Pavel >> >> >> > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. >> > >> > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta >> ?. 50932852, 50935613 a 50934642 >> > >> > Pra?k >> > > ------------ P?vodn? zpr?va ------------ >> > > Od: Pavel Machek <pavel at ucw.cz> >> > > P?edm?t: Re: [Talk-cz] Import DIBAVOD >> > > Datum: 22.2.2010 08:03:14 >> > > ---------------------------------------- >> > > Ahoj! >> > > >> > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem >> ?ty?ikr?t. >> > > >> > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze >> > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to >> > > znovu. >> > > >> > > Opravdu je duplicita v datech? >> > > >> > > -- >> > > (english) http://www.livejournal.com/~pavelmachek >> > > (cesky, pictures) >> > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

23.2.2010 10:15:22 (#15)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Tak jsem to asi vykoukal. Ja jsem si 0.6 jeste necetl, coz je mozna skoda. Naposledy jsem delal lesy a to byla verze 0.5. Ty soubory co jsem posilal se totiz dali udelat velmi rychle pomoci toho diff upload. Mozna JOSMu vadilo, ze v xml bylo <osm version='0.5'..... Netusim. JOSM to dela po jednom nodu v changesetu a nakonec po jedne line. To je samozrejmne 10000 requestu a to trva tu hodinu. Pak je tam napsano: To avoid stale open changesets a mechanism is implemented to automatically close changesets upon one of the following three conditions: * More than 50.000 edits on a single changeset See more specific limits <http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits> * The changeset has been open for more than 24 hours * There have been no changes/API calls related to a changeset in 1 hour (i.e. idle timeout) Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten diff upload. No aspon vime jak se to asi ma priste delat. Tomas jzvc napsal(a): zobrazit citaci
> Dne 23.2.2010 21:55, Jan Bilak napsal(a): > >> Ja vychazel z tohoto: >> >> Diff upload: POST /api/0.6/changeset/#id/upload >> >> With this API call files in the OsmChange format can be uploaded to >> the server. This is guaranteed to be running in a transaction. So >> either all the changes are applied or none. >> To upload an OSC file it has to conform to the OsmChange specification >> with the addition of a changeset and a version attribute for each >> element, except when you are creating an element where the version is >> not required as the server sets that for you. >> >> [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] >> >> Honza >> >> >> > > Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce > byla uzavrena => melo by to by duplicitni komplet a teoreticky by melo > jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim > nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset > je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. > Nektere typy chyb by tomu nasvedcovaly. > > BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca > 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. > > >> 2010/2/23 Tomas Kolda <kolda at web2net.cz>: >> >> >>> No asi to tak neni, protoze by pak nevznikly ty duplikaty. >>> >>> Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se >>> spravne pri uploadech chovat... >>> >>> Tomas >>> >>> Jan Bilak napsal(a): >>> >>> Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede >>> cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? >>> >>> Honza >>> >>> >>> Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): >>> >>> >>> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM >>> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat >>> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? >>> >>> Tomas >>> >>> Jan Dud?k napsal(a): >>> >>> Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel >>> jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro >>> cel? d?l :-(... >>> >>> J&D >>> >>> Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): >>> >>> >>> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s >>> validatorem to jde rychle a vcelku automaticky...), takze nektere >>> rybniky tam jsou uz jen jednou. >>> >>> >>> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, >>> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z >>> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej >>> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky >>> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 >>> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich >>> bylo asi 32000) >>> >>> Takze duplicity od Medulove by taky asi chtely vyresit... >>> >>> Martin >>> >>> On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: >>> >>> >>> Hi! >>> >>> It seems that I created duplicate data when importing DIBAVOD; I >>> assumed that if connection died before closing transaction, no data >>> would be uploaded, and it seems it is not so :-(. >>> >>> Edits in question are: >>> >>> #3938287 February 21, 2010 20:50 dibavod, cast 41 >>> 11.985,48.587,17.993,50.959 (big) >>> #3938219 February 21, 2010 21:37 import dibavod, cast >>> 41 11.985,48.587,17.993,50.959 (big) >>> #3938181 February 21, 2010 21:30 import dibavod, cast >>> 41 11.985,48.587,17.993,50.959 (big) >>> #3938082 February 21, 2010 21:23 import dibavod, cast >>> 41 11.985,48.587,17.993,50.959 (big) >>> >>> ...they should be duplicates (if not, the biggest one should be left). >>> >>> Now, there are big fat warnings about revert scripts and I'd prefer >>> not to mess up the database even more. What is the best way to >>> proceed? >>> >>> Sorry for the mess, >>> >>> Pavel >>> >>> >>> > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. >>> > >>> > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta >>> ?. 50932852, 50935613 a 50934642 >>> > >>> > Pra?k >>> > > ------------ P?vodn? zpr?va ------------ >>> > > Od: Pavel Machek <pavel at ucw.cz> >>> > > P?edm?t: Re: [Talk-cz] Import DIBAVOD >>> > > Datum: 22.2.2010 08:03:14 >>> > > ---------------------------------------- >>> > > Ahoj! >>> > > >>> > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem >>> ?ty?ikr?t. >>> > > >>> > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze >>> > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to >>> > > znovu. >>> > > >>> > > Opravdu je duplicita v datech? >>> > > >>> > > -- >>> > > (english) http://www.livejournal.com/~pavelmachek >>> > > (cesky, pictures) >>> > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >>> >>> -- >>> (english) http://www.livejournal.com/~pavelmachek >>> (cesky, pictures) >>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >> _______________________________________________ >> 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 >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100223/6161efcc/attachment.html>

23.2.2010 10:29:00 (#16)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ted jsem to asi uplne nepochopil. V JSOM lze nejak nastavit, jestli pouzije API metodu "diff upload", aby nahral vsechno v jednom changesetu a transakci nebo to delal nejak jinak? Osobne bych cekal, ze ten alternativni postup je pro ten webovy editor a JOSM bude pouzivat vzdy "diff upload". Tedy vse pekne v transakci a jednom changesetu. Tedy, pokud se to vejde do toho limitu poctu zmen. Honza 2010/2/23 Tomas Kolda <kolda at web2net.cz>: zobrazit citaci
> Tak jsem to asi vykoukal. Ja jsem si 0.6 jeste necetl, coz je mozna skoda. > Naposledy jsem delal lesy a to byla verze 0.5. Ty soubory co jsem posilal se > totiz dali udelat velmi rychle pomoci toho diff upload. Mozna JOSMu vadilo, > ze v xml bylo <osm version='0.5'..... Netusim. > > JOSM to dela po jednom nodu v changesetu a nakonec po jedne line. To je > samozrejmne 10000 requestu a to trva tu hodinu. > > Pak je tam napsano: > To avoid stale open changesets a mechanism is implemented to automatically > close changesets upon one of the following three conditions: > > More than 50.000 edits on a single changeset See more specific limits > The changeset has been open for more than 24 hours > There have been no changes/API calls related to a changeset in 1 hour (i.e. > idle timeout) > > Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli > lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten > diff upload. > > No aspon vime jak se to asi ma priste delat. > > Tomas > > > jzvc napsal(a): > > Dne 23.2.2010 21:55, Jan Bilak napsal(a): > > > Ja vychazel z tohoto: > > Diff upload: POST /api/0.6/changeset/#id/upload > > With this API call files in the OsmChange format can be uploaded to > the server. This is guaranteed to be running in a transaction. So > either all the changes are applied or none. > To upload an OSC file it has to conform to the OsmChange specification > with the addition of a changeset and a version attribute for each > element, except when you are creating an element where the version is > not required as the server sets that for you. > > [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] > > Honza > > > > > Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce > byla uzavrena => melo by to by duplicitni komplet a teoreticky by melo > jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim > nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset > je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. > Nektere typy chyb by tomu nasvedcovaly. > > BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca > 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. > > > > 2010/2/23 Tomas Kolda <kolda at web2net.cz>: > > > > No asi to tak neni, protoze by pak nevznikly ty duplikaty. > > Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se > spravne pri uploadech chovat... > > Tomas > > Jan Bilak napsal(a): > > Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede > cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? > > Honza > > > Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): > > > A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM > uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat > save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? > > Tomas > > Jan Dud?k napsal(a): > > Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel > jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro > cel? d?l :-(... > > J&D > > Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): > > > Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s > validatorem to jde rychle a vcelku automaticky...), takze nektere > rybniky tam jsou uz jen jednou. > > > Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, > kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z > dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej > (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky > dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 > duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich > bylo asi 32000) > > Takze duplicity od Medulove by taky asi chtely vyresit... > > Martin > > On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: > > > Hi! > > It seems that I created duplicate data when importing DIBAVOD; I > assumed that if connection died before closing transaction, no data > would be uploaded, and it seems it is not so :-(. > > Edits in question are: > > #3938287 February 21, 2010 20:50 dibavod, cast 41 > 11.985,48.587,17.993,50.959 (big) > #3938219 February 21, 2010 21:37 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > #3938181 February 21, 2010 21:30 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > #3938082 February 21, 2010 21:23 import dibavod, cast > 41 11.985,48.587,17.993,50.959 (big) > > ...they should be duplicates (if not, the biggest one should be left). > > Now, there are big fat warnings about revert scripts and I'd prefer > not to mess up the database even more. What is the best way to > proceed? > > Sorry for the mess, > > Pavel > > > > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. > > > > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta > ?. 50932852, 50935613 a 50934642 > > > > Pra?k > > > ------------ P?vodn? zpr?va ------------ > > > Od: Pavel Machek <pavel at ucw.cz> > > > P?edm?t: Re: [Talk-cz] Import DIBAVOD > > > Datum: 22.2.2010 08:03:14 > > > ---------------------------------------- > > > Ahoj! > > > > > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem > ?ty?ikr?t. > > > > > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > > > znovu. > > > > > > Opravdu je duplicita v datech? > > > > > > -- > > > (english) http://www.livejournal.com/~pavelmachek > > > (cesky, pictures) > > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > > > > > _______________________________________________ > 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 > > > > > > _______________________________________________ > 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 > >

23.2.2010 10:33:52 (#17)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
M? bohu?el spadl cel? syst?m z d?vodu jin?ho programu, tak?e nepom??u. J&D 2010/2/23 Tomas Kolda <kolda at web2net.cz>: zobrazit citaci
> No asi to tak neni, protoze by pak nevznikly ty duplikaty. > > Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se > spravne pri uploadech chovat... > > Tomas > > Jan Bilak napsal(a): > > Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede > cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? > > Honza > > > Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): > > > A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM > uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat > save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? > > Tomas > > Jan Dud?k napsal(a): > > Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel > jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro > cel? d?l :-(... > > J&D > > Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): > > > Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s > validatorem to jde rychle a vcelku automaticky...), takze nektere > rybniky tam jsou uz jen jednou. > > > Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, > kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z > dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej > (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky > dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 > duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich > bylo asi 32000) > > Takze duplicity od Medulove by taky asi chtely vyresit... > > Martin > > On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: > > > Hi! > > ?It seems that I created duplicate data when importing DIBAVOD; I > ?assumed that if connection died before closing transaction, no data > ?would be uploaded, and it seems it is not so :-(. > > ?Edits in question are: > > ?#3938287 ? ? ? ? February 21, 2010 20:50 ? ? ? ? dibavod, cast 41 > ?11.985,48.587,17.993,50.959 ? (big) > ?#3938219 ? ? ? ?February 21, 2010 21:37 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > ?#3938181 ? ? ? ?February 21, 2010 21:30 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > ?#3938082 ? ? ? ?February 21, 2010 21:23 ? ? ? ? import dibavod, cast > ?41 ? ? ?11.985,48.587,17.993,50.959 (big) > > ?...they should be duplicates (if not, the biggest one should be left). > > ?Now, there are big fat warnings about revert scripts and I'd prefer > ?not to mess up the database even more. What is the best way to > ?proceed? > > ?Sorry for the mess, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Pavel > > > ?> Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. > ?> > ?> Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta > ?. 50932852, 50935613 a 50934642 > ?> > ?> Pra?k > ?> > ------------ P?vodn? zpr?va ------------ > ?> > Od: Pavel Machek <pavel at ucw.cz> > ?> > P?edm?t: Re: [Talk-cz] Import DIBAVOD > ?> > Datum: 22.2.2010 08:03:14 > ?> > ---------------------------------------- > ?> > Ahoj! > ?> > > ?> > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem > ?ty?ikr?t. > ?> > > ?> > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze > ?> > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to > ?> > znovu. > ?> > > ?> > Opravdu je duplicita v datech? > ?> > > ?> > -- > ?> > (english) http://www.livejournal.com/~pavelmachek > ?> > (cesky, pictures) > ?> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > ?-- > ?(english) http://www.livejournal.com/~pavelmachek > ?(cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 > > > > > > _______________________________________________ > 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

23.2.2010 10:57:15 (#18)
gravatar

MP

<singularita at gmail.com>
306
zobrazit citaci
> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM > uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat > save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim?
Pokud se pouziuva diff upload tak se nova ID priradi az na konci a JOSM se o nich dozvi az pote, co si server vsechno prebere a ty ID vrati zpatky .... takze pokud spojeni vyhnije pote co bylo vse odeslano na server, ale predtim, nez JOSM dostane zpet nova IDcka, tak server to tam vse sice uspesne nacpe, ale po vyhnilem spojeni uz nevrati nova ID a JOSM se pak tvari, ze to cele selhalo. A kdyz to clovek "zkusi znovu" tak tam uz cpe druhou kopii .... Martin

23.2.2010 11:31:06 (#19)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Tak jsem to zkusil. Ten diff upload asi chodi jen na devel verzi JOSM. Ted jsem uploadnul svuj posledni soubor a trvalo to asi 10 minut. Data tam byli za par sekund, ale ten commit trosku trval. Nejdriv mi to prislo dlouhe tak jsem dal cancel. Na podruhe jsem vydrzel. Duplicita tam neni. Takze na tohle asi bylo lepsi pouzit JOSM devel verzi. Tomas MP napsal(a): zobrazit citaci
>> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM >> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat >> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? >> > > Pokud se pouziuva diff upload tak se nova ID priradi az na konci a > JOSM se o nich dozvi az pote, co si server vsechno prebere a ty ID > vrati zpatky .... takze pokud spojeni vyhnije pote co bylo vse > odeslano na server, ale predtim, nez JOSM dostane zpet nova IDcka, tak > server to tam vse sice uspesne nacpe, ale po vyhnilem spojeni uz > nevrati nova ID a JOSM se pak tvari, ze to cele selhalo. A kdyz to > clovek "zkusi znovu" tak tam uz cpe druhou kopii .... > > Martin > > _______________________________________________ > 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/20100223/ad01d7ba/attachment.html>

24.2.2010 09:46:22 (#20)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 23.2.2010 22:29, Jan Bilak napsal(a): zobrazit citaci
> Ted jsem to asi uplne nepochopil. V JSOM lze nejak nastavit, jestli > pouzije API metodu "diff upload", aby nahral vsechno v jednom > changesetu a transakci nebo to delal nejak jinak? > > Osobne bych cekal, ze ten alternativni postup je pro ten webovy editor > a JOSM bude pouzivat vzdy "diff upload". Tedy vse pekne v transakci a > jednom changesetu. Tedy, pokud se to vejde do toho limitu poctu zmen. > > Honza > >
Pokud to funguje, tak je to default volba - vse v jednom pozadavku. Da se to zmenit na "kazdou zmenu jako samostatny pozadavek" nebo vybrat pocet zmen v pozadavku. Je to aktualne v tabu advanced pri uploadu zmen. JOSM tusim protestuje, pokud by pocet zmen byl prilis velky, tak si vynuti zmenu tohodle nastaveni. zobrazit citaci
> 2010/2/23 Tomas Kolda <kolda at web2net.cz>: > >> Tak jsem to asi vykoukal. Ja jsem si 0.6 jeste necetl, coz je mozna skoda. >> Naposledy jsem delal lesy a to byla verze 0.5. Ty soubory co jsem posilal se >> totiz dali udelat velmi rychle pomoci toho diff upload. Mozna JOSMu vadilo, >> ze v xml bylo <osm version='0.5'..... Netusim. >> >> JOSM to dela po jednom nodu v changesetu a nakonec po jedne line. To je >> samozrejmne 10000 requestu a to trva tu hodinu. >> >> Pak je tam napsano: >> To avoid stale open changesets a mechanism is implemented to automatically >> close changesets upon one of the following three conditions: >> >> More than 50.000 edits on a single changeset See more specific limits >> The changeset has been open for more than 24 hours >> There have been no changes/API calls related to a changeset in 1 hour (i.e. >> idle timeout) >> >> Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli >> lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten >> diff upload. >> >> No aspon vime jak se to asi ma priste delat. >> >> Tomas >> >> >> jzvc napsal(a): >> >> Dne 23.2.2010 21:55, Jan Bilak napsal(a): >> >> >> Ja vychazel z tohoto: >> >> Diff upload: POST /api/0.6/changeset/#id/upload >> >> With this API call files in the OsmChange format can be uploaded to >> the server. This is guaranteed to be running in a transaction. So >> either all the changes are applied or none. >> To upload an OSC file it has to conform to the OsmChange specification >> with the addition of a changeset and a version attribute for each >> element, except when you are creating an element where the version is >> not required as the server sets that for you. >> >> [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] >> >> Honza >> >> >> >> >> Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce >> byla uzavrena => melo by to by duplicitni komplet a teoreticky by melo >> jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim >> nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset >> je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. >> Nektere typy chyb by tomu nasvedcovaly. >> >> BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca >> 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. >> >> >> >> 2010/2/23 Tomas Kolda <kolda at web2net.cz>: >> >> >> >> No asi to tak neni, protoze by pak nevznikly ty duplikaty. >> >> Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se >> spravne pri uploadech chovat... >> >> Tomas >> >> Jan Bilak napsal(a): >> >> Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede >> cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? >> >> Honza >> >> >> Dne 23. ?nora 2010 21:44 Tomas Kolda <kolda at web2net.cz> napsal(a): >> >> >> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM >> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat >> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? >> >> Tomas >> >> Jan Dud?k napsal(a): >> >> Jo, to je mo?n? ??st 91 mi spadla chvilku po za??tku imortu, myslel >> jsem ,?e se sta?ilo p?en?st jen p?r kousk? a zat?m to vypad? na skoro >> cel? d?l :-(... >> >> J&D >> >> Dne 23. ?nora 2010 20:41 MP <singularita at gmail.com> napsal(a): >> >> >> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s >> validatorem to jde rychle a vcelku automaticky...), takze nektere >> rybniky tam jsou uz jen jednou. >> >> >> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, >> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z >> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej >> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky >> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700 >> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich >> bylo asi 32000) >> >> Takze duplicity od Medulove by taky asi chtely vyresit... >> >> Martin >> >> On 22/02/2010, Pavel Machek <pavel at ucw.cz> wrote: >> >> >> Hi! >> >> It seems that I created duplicate data when importing DIBAVOD; I >> assumed that if connection died before closing transaction, no data >> would be uploaded, and it seems it is not so :-(. >> >> Edits in question are: >> >> #3938287 February 21, 2010 20:50 dibavod, cast 41 >> 11.985,48.587,17.993,50.959 (big) >> #3938219 February 21, 2010 21:37 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> #3938181 February 21, 2010 21:30 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> #3938082 February 21, 2010 21:23 import dibavod, cast >> 41 11.985,48.587,17.993,50.959 (big) >> >> ...they should be duplicates (if not, the biggest one should be left). >> >> Now, there are big fat warnings about revert scripts and I'd prefer >> not to mess up the database even more. What is the best way to >> proceed? >> >> Sorry for the mess, >> >> Pavel >> >> >> > Pokud jsem se d?val na n?kolik rybn?k?, tak v?echny byly nahr?ny 4x. >> > >> > Nap??klad Trub?rn? rybn?k - cesta ?. 50937312 je nahr?n je?t? jako cesta >> ?. 50932852, 50935613 a 50934642 >> > >> > Pra?k >> > > ------------ P?vodn? zpr?va ------------ >> > > Od: Pavel Machek <pavel at ucw.cz> >> > > P?edm?t: Re: [Talk-cz] Import DIBAVOD >> > > Datum: 22.2.2010 08:03:14 >> > > ---------------------------------------- >> > > Ahoj! >> > > >> > > > Nam?tkou jsem zjistil, ?e Pavel nahr?l omylem ??st ?. 41 celkem >> ?ty?ikr?t. >> > > >> > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze >> > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to >> > > znovu. >> > > >> > > Opravdu je duplicita v datech? >> > > >> > > -- >> > > (english) http://www.livejournal.com/~pavelmachek >> > > (cesky, pictures) >> > > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

24.2.2010 09:48:49 (#21)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 23.2.2010 23:31, Tomas Kolda napsal(a): zobrazit citaci
> Tak jsem to zkusil. Ten diff upload asi chodi jen na devel verzi JOSM. > Ted jsem uploadnul svuj posledni soubor a trvalo to asi 10 minut. Data > tam byli za par sekund, ale ten commit trosku trval. Nejdriv mi to > prislo dlouhe tak jsem dal cancel. Na podruhe jsem vydrzel. Duplicita > tam neni. Takze na tohle asi bylo lepsi pouzit JOSM devel verzi. > > Tomas
Tu jsem pouzil ja, ostatni ji pouzivam (pokud zrovna nezbuchne) prakticky vzdy, ale i tak mi to prislo pomale. zobrazit citaci
> > MP napsal(a): >>> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM >>> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by >>> stacit dat >>> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se >>> mylim? >>> >> >> Pokud se pouziuva diff upload tak se nova ID priradi az na konci a >> JOSM se o nich dozvi az pote, co si server vsechno prebere a ty ID >> vrati zpatky .... takze pokud spojeni vyhnije pote co bylo vse >> odeslano na server, ale predtim, nez JOSM dostane zpet nova IDcka, tak >> server to tam vse sice uspesne nacpe, ale po vyhnilem spojeni uz >> nevrati nova ID a JOSM se pak tvari, ze to cele selhalo. A kdyz to >> clovek "zkusi znovu" tak tam uz cpe druhou kopii .... >> >> Martin >> >> _______________________________________________ >> 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 >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100224/ccf7a052/attachment.html>

25.2.2010 03:25:25 (#22)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Tue 2010-02-23 22:57:15, MP wrote: zobrazit citaci
> > A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM > > uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat > > save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? > > Pokud se pouziuva diff upload tak se nova ID priradi az na konci a > JOSM se o nich dozvi az pote, co si server vsechno prebere a ty ID > vrati zpatky .... takze pokud spojeni vyhnije pote co bylo vse > odeslano na server, ale predtim, nez JOSM dostane zpet nova IDcka, tak > server to tam vse sice uspesne nacpe, ale po vyhnilem spojeni uz > nevrati nova ID a JOSM se pak tvari, ze to cele selhalo. A kdyz to > clovek "zkusi znovu" tak tam uz cpe druhou kopii ....
...a kdyz se mezi tim podiva, jestli to tam uz nahodou neni, tak mu server rekne ze neni, protoze stale jeste uklada :-(. Takze jeste jednou sorry za duplicity. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

25.2.2010 03:32:07 (#23)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Tue 2010-02-23 22:08:19, jzvc wrote: zobrazit citaci
> Dne 23.2.2010 21:55, Jan Bilak napsal(a): > > Ja vychazel z tohoto: > > > > Diff upload: POST /api/0.6/changeset/#id/upload > > > > With this API call files in the OsmChange format can be uploaded to > > the server. This is guaranteed to be running in a transaction. So > > either all the changes are applied or none. > > To upload an OSC file it has to conform to the OsmChange specification > > with the addition of a changeset and a version attribute for each > > element, except when you are creating an element where the version is > > not required as the server sets that for you. > > > > [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] > > Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce > byla uzavrena => melo by to by duplicitni komplet a teoreticky by melo > jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim > nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset > je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. > Nektere typy chyb by tomu nasvedcovaly. > > BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca > 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin.
Ono to vypadalo tak ze to behem par vterin poslalo ten megabyte, a pak se nic nedelo -- server zrejme 30 minut ukladal do databaze... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1.3.2010 12:01:48 (#24)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Jen pro informaci, data jsou v nekterych miste ponekud (vice) zastarala, me napriklad do Teplic import umistil (nekonfliktni) vodni plochu, ktera tam uz dobre 10, mozna 15let neni (koupaliste Anger). To jen az se budete divit, ze mate za domem rybnik, ktery jste nikdy nevideli :D.

1.3.2010 11:13:44 (#25)
gravatar

Pavel Zbytovský

<zbytovsky at gmail.com>
222 458
Tohle je hloup?, tak? jsem u sebe potkal r?zn? podivn? nebo i nepravdiv? data. Je mo?n? to n?kam hl?sit, aby si to v DIBAVODu opravili? 2010/3/1 jzvc <jzvc at tpfree.fdns.net> zobrazit citaci
> Jen pro informaci, data jsou v nekterych miste ponekud (vice) zastarala, > me napriklad do Teplic import umistil (nekonfliktni) vodni plochu, ktera > tam uz dobre 10, mozna 15let neni (koupaliste Anger). To jen az se > budete divit, ze mate za domem rybnik, ktery jste nikdy nevideli :D. > > > _______________________________________________ > 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/20100301/efaf9a87/attachment.html>

8.3.2010 04:54:11 (#26)
gravatar

hanoj

<ehanoj at gmail.com>
713
To by bylo dobre, co trebas zalozit stranku na nasi wiki? hanoj 2010/3/1 Pavel Zbytovsk? <mail at zby.cz>: zobrazit citaci
> Tohle je hloup?, tak? jsem u sebe potkal r?zn? podivn? nebo i nepravdiv? > data. > > Je mo?n? to n?kam hl?sit, aby si to v DIBAVODu opravili? > > > > 2010/3/1 jzvc <jzvc at tpfree.fdns.net> >> >> Jen pro informaci, data jsou v nekterych miste ponekud (vice) zastarala, >> me napriklad do Teplic import umistil (nekonfliktni) vodni plochu, ktera >> tam uz dobre 10, mozna 15let neni (koupaliste Anger). To jen az se >> budete divit, ze mate za domem rybnik, ktery jste nikdy nevideli :D.

8.3.2010 07:31:54 (#27)
gravatar

Pavel Pilát

<pavel.pilat at gmail.com>
64
Import dibavod je fajn, kolem Napajedel si to u? kontroluju. Jen p?em??l?m, pro? je to otagov?no jako landuse=reservoir, ale ur?it? to d?vod m?. Pouze tady kolem m? je to sam? mrtv? rameno a sp?? natural=water... Pontiac_CZ

9.3.2010 12:45:31 (#28)
gravatar

Frettie

<frettie at gmail.com>
101
Souhlas?m, taky na to te? kouk?m a je to kr?sn?, a? budu m?t v?c ?asu, tak zkontroluju p?esnost, ale tak podle oka je to b?je?n?. Mimojin?, koukal jsem, ?e u? pokro?ili i katastry, taky WOW. JS. 2010/3/8 Pavel Pil?t <pavel.pilat at gmail.com>: zobrazit citaci
> Import dibavod je fajn, kolem Napajedel si to u? kontroluju. Jen > p?em??l?m, pro? je to otagov?no jako landuse=reservoir, ale ur?it? to > d?vod m?. Pouze tady kolem m? je to sam? mrtv? rameno a sp?? > natural=water... > > Pontiac_CZ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-- S pozdravem, Jirka Sedl??ek --- jirisedlacek at gmail.com

9.3.2010 05:44:50 (#29)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
Ahoj, pravd?podobn? v DIBAVODU ta informace nebyla, tak?e nezb?v?, ne? to ru?n? zm?nit. On Mon, 08 Mar 2010 19:31:54 +0100, Pavel Pil?t <pavel.pilat at gmail.com> wrote: zobrazit citaci
> Import dibavod je fajn, kolem Napajedel si to u? kontroluju. Jen > p?em??l?m, pro? je to otagov?no jako landuse=reservoir, ale ur?it? to > d?vod m?. Pouze tady kolem m? je to sam? mrtv? rameno a sp?? > natural=water... > > Pontiac_CZ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouh?

10.3.2010 07:02:50 (#30)
gravatar

Tomáš Kolda

<kolda at web2net.cz>
133
Ano je to tak. Zatim se importoval soubor DIBAVOD nadrze. Zadne dalsi rozliseni nebylo, takze se dalo reservoir. Tomas Dne 9.3.2010 5:44, Petr Dlouh? napsal(a): zobrazit citaci
> Ahoj, > > pravd?podobn? v DIBAVODU ta informace nebyla, tak?e nezb?v?, ne? to ru?n? > zm?nit. > > On Mon, 08 Mar 2010 19:31:54 +0100, Pavel Pil?t<pavel.pilat at gmail.com> > wrote: > > >> Import dibavod je fajn, kolem Napajedel si to u? kontroluju. Jen >> p?em??l?m, pro? je to otagov?no jako landuse=reservoir, ale ur?it? to >> d?vod m?. Pouze tady kolem m? je to sam? mrtv? rameno a sp?? >> natural=water... >> >> Pontiac_CZ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > >

10.3.2010 09:20:08 (#31)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 8.3.2010 19:31, Pavel Pil?t napsal(a): zobrazit citaci
> Import dibavod je fajn, kolem Napajedel si to u? kontroluju. Jen > p?em??l?m, pro? je to otagov?no jako landuse=reservoir, ale ur?it? to > d?vod m?. Pouze tady kolem m? je to sam? mrtv? rameno a sp?? > natural=water... >
Protoze se to z te hromady dat neda urcit. U tech par souboru co sem delal sem to v pripade ze slo napriklad o ricni breh pretagoval. Ale coz, ono se to casem nejak spravi, hlavne ze je co opravovat :D. zobrazit citaci
> Pontiac_CZ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

10.3.2010 09:46:57 (#32)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Mon 2010-03-08 04:54:11, hanoj wrote: zobrazit citaci
> To by bylo dobre, co trebas zalozit stranku na nasi wiki?
Ma to cenu psat na wiki? Ja bych si predstavoval ze se zastarala data proste smazou... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

10.3.2010 09:54:55 (#33)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 10.3.2010 21:46, Pavel Machek napsal(a): zobrazit citaci
> On Mon 2010-03-08 04:54:11, hanoj wrote: > >> To by bylo dobre, co trebas zalozit stranku na nasi wiki? >> > Ma to cenu psat na wiki? Ja bych si predstavoval ze se zastarala data > proste smazou... > Pavel > >
Tj, ale bylo to mysleno tak, ze by se zdroji mohlo rict, ze tam maj stary data a jaky, a necht si to opravi.

26.4.2010 09:18:04 (#34)
gravatar

Pavel Zbytovský

<zbytovsky at gmail.com>
222 458
Ahoj, pokusil jsem se importovat data z areas_conflict_170.xml, ale narazil jsem docela na probl?m. Kontroloval jsem data podle Cenie a p?ev??n? v?t?ina n?dr?? byla zv?t?en?ch nebo jinak z?sadn? upraven?ch. V?echny n?dr?e tam samoz?ejm? jsou z m?stn?ch survey. P?esto?e jsou hodn? st??len? od oka, tak ale v?ce odpov?daj? skute?nosti (cenii) ne? z toho dibavodu. Te? co s t?m. *Jednak z hlediska importu* - podle Cenie lze jen kontrolovat, tak?e jsem zachov?val bu? jeden nebo druh?, podle toho, kter? byl aktu?ln?j??. Co? ov?em znamenalo, ?e jsem skoro v?ude nechal ty star?. Je vhodn? zachov?vat i to ID?ko u t?ch "aktu?ln?j??ch" tvar?? Jednak tak? co *z hlediska datasetu* - v?t?ina n?dr?? neodpov?daj? skute?nosti a trouf?m si ??ct, ?e mnoho t?ch nekonfliktn?ch bude taky hodn? vedle. T?eba: * id:105040060017 - ?patn? tvar n?dr?e * id:105040070003 - ?patn? tvar n?dr?e, chyb? name=Ct?nick? rybn?k * id:105040060019 - ?patn? tvar n?dr?e, chyb? name=Biologick? rybn?k * id:105040060018 - ?patn? tvar n?dr?e * id:105040060002 - ?patn? tvar n?dr?e R?d bych, kdyby se n?m povedlo vr?tit n?jak? updaty zp?t do dibavodu, byla by to p?kn? uk?zka, ?e se ??ad?m vyplat? otev?rat data, proto?e komunita je schopna nab?dnout velkou kontroln? s?lu a hodnotu nazp?t. Stejn? ty konfliktn? importy v?echny ru?n? proch?z?me, tak?e pro n?s by to nebyla pr?ce nav?c. U? v??e jsme s t?m tady nic moc kloudn?ho nevymysleli. Nev?te, kdo to vlastn? s ??adem komunikoval, asi by bylo rozumn? aby s ??adem mailoval p??padn? on. A je?t? mimochodem, jak je na tom import potok? a ?ek? wiki str?nka se o n?m nezmi?uje. Hezk? den v?m v?em, Pavel Zbytovsk? aka zbycz 2010/3/10 jzvc <jzvc at tpfree.fdns.net> zobrazit citaci
> Dne 10.3.2010 21:46, Pavel Machek napsal(a): > > On Mon 2010-03-08 04:54:11, hanoj wrote: > > > >> To by bylo dobre, co trebas zalozit stranku na nasi wiki? > >> > > Ma to cenu psat na wiki? Ja bych si predstavoval ze se zastarala data > > proste smazou... > > > Pavel > > > > > Tj, ale bylo to mysleno tak, ze by se zdroji mohlo rict, ze tam maj > stary data a jaky, a necht si to opravi. > > _______________________________________________ > 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/20100426/775a5c67/attachment.html>

26.4.2010 09:50:44 (#35)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
S?m jsem naimportoval asi 30 areas,, v jednom souboru jsem z 20 n?dr?? nechal 15 p?vodn?ch, proto?e byly zjevn? podobn?j?? skute?nosti. Jednalo se tu??m o oblast n?kde mezi Tachovem a M. L?zn?mi. J&D 2010/4/26 Pavel Zbytovsk? <mail at zby.cz>: zobrazit citaci
> Ahoj, > > pokusil jsem se importovat data z areas_conflict_170.xml, ale narazil jsem > docela na probl?m. Kontroloval jsem data podle Cenie a p?ev??n? v?t?ina > n?dr?? byla zv?t?en?ch nebo jinak z?sadn? upraven?ch. V?echny n?dr?e tam > samoz?ejm? jsou z m?stn?ch survey. P?esto?e jsou hodn? st??len? od oka, tak > ale v?ce odpov?daj? skute?nosti (cenii) ne? z toho dibavodu. > > Te? co s t?m. Jednak z hlediska importu - podle Cenie lze jen kontrolovat, > tak?e jsem? zachov?val bu? jeden nebo druh?, podle toho, kter? byl > aktu?ln?j??. Co? ov?em znamenalo, ?e jsem skoro v?ude nechal ty star?.? Je > vhodn? zachov?vat i to ID?ko u t?ch "aktu?ln?j??ch" tvar?? > > Jednak tak? co z hlediska datasetu - v?t?ina n?dr?? neodpov?daj? skute?nosti > a trouf?m si ??ct, ?e mnoho t?ch nekonfliktn?ch bude taky hodn? vedle. > T?eba: > * id:105040060017 - ?patn? tvar n?dr?e > * id:105040070003 - ?patn? tvar n?dr?e, chyb? name=Ct?nick? rybn?k > * id:105040060019 - ?patn? tvar n?dr?e, chyb? name=Biologick? rybn?k > * id:105040060018 - ?patn? tvar n?dr?e > * id:105040060002 - ?patn? tvar n?dr?e > > R?d bych, kdyby se n?m povedlo vr?tit n?jak? updaty zp?t do dibavodu, byla > by to p?kn? uk?zka, ?e se ??ad?m vyplat? otev?rat data, proto?e komunita je > schopna nab?dnout velkou kontroln? s?lu a hodnotu nazp?t. Stejn? ty > konfliktn? importy v?echny ru?n? proch?z?me, tak?e pro n?s by to nebyla > pr?ce nav?c. > > U? v??e jsme s t?m tady nic moc kloudn?ho nevymysleli. Nev?te, kdo to > vlastn? s ??adem komunikoval, asi by bylo rozumn? aby s ??adem mailoval > p??padn? on. > > > A je?t? mimochodem, jak je na tom import potok? a ?ek? wiki str?nka se o n?m > nezmi?uje. > > Hezk? den v?m v?em, > Pavel Zbytovsk? aka zbycz > > > 2010/3/10 jzvc <jzvc at tpfree.fdns.net> >> >> Dne 10.3.2010 21:46, Pavel Machek napsal(a): >> > On Mon 2010-03-08 04:54:11, hanoj wrote: >> > >> >> To by bylo dobre, co trebas zalozit stranku na nasi wiki? >> >> >> > Ma to cenu psat na wiki? Ja bych si predstavoval ze se zastarala data >> > proste smazou... >> > >> > Pavel >> > >> > >> Tj, ale bylo to mysleno tak, ze by se zdroji mohlo rict, ze tam maj >> stary data a jaky, a necht si to opravi. >> >> _______________________________________________ >> 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

26.4.2010 11:44:41 (#36)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 26.4.2010 21:18, Pavel Zbytovsk? napsal(a): zobrazit citaci
> Ahoj, > > pokusil jsem se importovat data z areas_conflict_170.xml, ale narazil jsem > docela na probl?m. Kontroloval jsem data podle Cenie a p?ev??n? v?t?ina > n?dr?? byla zv?t?en?ch nebo jinak z?sadn? upraven?ch. V?echny n?dr?e tam > samoz?ejm? jsou z m?stn?ch survey. P?esto?e jsou hodn? st??len? od oka, tak > ale v?ce odpov?daj? skute?nosti (cenii) ne? z toho dibavodu. > > Te? co s t?m. *Jednak z hlediska importu* - podle Cenie lze jen kontrolovat, > tak?e jsem zachov?val bu? jeden nebo druh?, podle toho, kter? byl > aktu?ln?j??. Co? ov?em znamenalo, ?e jsem skoro v?ude nechal ty star?. Je > vhodn? zachov?vat i to ID?ko u t?ch "aktu?ln?j??ch" tvar?? >
Jo, ID zachovat, muze se hodit. zobrazit citaci
> Jednak tak? co *z hlediska datasetu* - v?t?ina n?dr?? neodpov?daj? > skute?nosti a trouf?m si ??ct, ?e mnoho t?ch nekonfliktn?ch bude taky hodn? > vedle. T?eba: > * id:105040060017 - ?patn? tvar n?dr?e > * id:105040070003 - ?patn? tvar n?dr?e, chyb? name=Ct?nick? rybn?k > * id:105040060019 - ?patn? tvar n?dr?e, chyb? name=Biologick? rybn?k > * id:105040060018 - ?patn? tvar n?dr?e > * id:105040060002 - ?patn? tvar n?dr?e >
Nekonflikni napriklad udelaly vodu tam, kde uz desiky let zadna neni, dibavod ma poradne zastaraly data. Zatim sem to nechal byt, prave proto, ze by nebylo od veci se snima nako dohodnout na nejaky zpetny vazbe. zobrazit citaci
> R?d bych, kdyby se n?m povedlo vr?tit n?jak? updaty zp?t do dibavodu, byla > by to p?kn? uk?zka, ?e se ??ad?m vyplat? otev?rat data, proto?e komunita je > schopna nab?dnout velkou kontroln? s?lu a hodnotu nazp?t. Stejn? ty > konfliktn? importy v?echny ru?n? proch?z?me, tak?e pro n?s by to nebyla > pr?ce nav?c. > > U? v??e jsme s t?m tady nic moc kloudn?ho nevymysleli. Nev?te, kdo to > vlastn? s ??adem komunikoval, asi by bylo rozumn? aby s ??adem mailoval > p??padn? on. > > > A je?t? mimochodem, jak je na tom import potok? a ?ek? wiki str?nka se o n?m > nezmi?uje. >
Pokud vim, tak toto (vodni plochy) byl prakticky jeden soubor prohnanej pres detektor kolizi a rozparcelovanej po unosnym poctu 20/soubor. S vodnimi toky to bude mozna horsi, protoze detekovat kolize bude asi tezsi, takze pocitam ze to bude vic rucni prace. zobrazit citaci
> Hezk? den v?m v?em, > Pavel Zbytovsk? aka zbycz > > > 2010/3/10 jzvc <jzvc at tpfree.fdns.net> > > >> Dne 10.3.2010 21:46, Pavel Machek napsal(a): >> >>> On Mon 2010-03-08 04:54:11, hanoj wrote: >>> >>> >>>> To by bylo dobre, co trebas zalozit stranku na nasi wiki? >>>> >>>> >>> Ma to cenu psat na wiki? Ja bych si predstavoval ze se zastarala data >>> proste smazou... >>> >>> >> Pavel >> >>> >>> >> Tj, ale bylo to mysleno tak, ze by se zdroji mohlo rict, ze tam maj >> stary data a jaky, a necht si to opravi. >> >> _______________________________________________ >> 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 >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100426/a0adf9e3/attachment.html>

28.4.2010 04:45:28 (#37)
gravatar

Pavel Zbytovský

<zbytovsky at gmail.com>
222 458
zobrazit citaci
>Jo, ID zachovat, muze se hodit.
Napsal jsem to na wiki, chyb? tam je?t? link na n?jakou ?vodn? konferu.. Pro n?koho kdo do probl?mu t?eba te? vstoupil tam prost? chyb? trocha informac?. zobrazit citaci
>dohodnout na nejaky zpetny vazbe.
lep?? by to bylo v?d?t te?, kdy? u? to stejn? mus?me proch?zet ru?n?. Co bude v osm datech za p?r m?s?c? u? nen? tak spolehliv? ... "m??eme reportovat chyb?j?c? rybn?k nebo ho n?kdo smazal omylem?" :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100428/b3bf1f6a/attachment.html>

4.5.2010 10:42:08 (#38)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
Pavel Zbytovsk? p??e v St 28. 04. 2010 v 16:45 +0200: zobrazit citaci
> >Jo, ID zachovat, muze se hodit. > > Napsal jsem to na wiki, chyb? tam je?t? link na n?jakou ?vodn? > konferu.. Pro n?koho kdo do probl?mu t?eba te? vstoupil tam prost? > chyb? trocha informac?. > > >dohodnout na nejaky zpetny vazbe. > > lep?? by to bylo v?d?t te?, kdy? u? to stejn? mus?me proch?zet ru?n?. > Co bude v osm datech za p?r m?s?c? u? nen? tak spolehliv? ... "m??eme > reportovat chyb?j?c? rybn?k nebo ho n?kdo smazal omylem?" :-) >
Existuje u? n?kde datab?ze nebo str?nka pro zad?v?n? chybn?ch dat v DIBAVOD, p??padn? n?jak? zp?sob, jak to odtagovat p??mo v map?? Narazil jsem na dva rybn??ky v m?stech, kde dnes stoj? domy (zat?m ov??eno pouze podle ortofoto): http://www.openstreetmap.org/?lat=49.085642&lon=14.71834&zoom=18&layers=B000FTF ________________________________________________________________________ Stanislav Brabec http://www.penguin.cz/~utx

19.5.2010 09:46:13 (#39)
gravatar

Pavel Zbytovský

<zbytovsky at gmail.com>
222 458
Napsal jsem na wiki n?vrh, jak bychom ta chybn? data mohli syst?mov? ozna?it: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD P?edpokl?d?m, ?e wiki zas tolik lid? ne?te, tak?e m??eme je?t? vymyslet zm?nu - klidn? to tam upravte, ale p?ijde mi to takto funk?n?. Pavel Zbytovsk? 2010/5/4 Stanislav Brabec <utx at penguin.cz> zobrazit citaci
> Pavel Zbytovsk? p??e v St 28. 04. 2010 v 16:45 +0200: > > >Jo, ID zachovat, muze se hodit. > > > > Napsal jsem to na wiki, chyb? tam je?t? link na n?jakou ?vodn? > > konferu.. Pro n?koho kdo do probl?mu t?eba te? vstoupil tam prost? > > chyb? trocha informac?. > > > > >dohodnout na nejaky zpetny vazbe. > > > > lep?? by to bylo v?d?t te?, kdy? u? to stejn? mus?me proch?zet ru?n?. > > Co bude v osm datech za p?r m?s?c? u? nen? tak spolehliv? ... "m??eme > > reportovat chyb?j?c? rybn?k nebo ho n?kdo smazal omylem?" :-) > > > > Existuje u? n?kde datab?ze nebo str?nka pro zad?v?n? chybn?ch dat > v DIBAVOD, p??padn? n?jak? zp?sob, jak to odtagovat p??mo v map?? > > Narazil jsem na dva rybn??ky v m?stech, kde dnes stoj? domy (zat?m > ov??eno pouze podle ortofoto): > > http://www.openstreetmap.org/?lat=49.085642&lon=14.71834&zoom=18&layers=B000FTF > > > ________________________________________________________________________ > Stanislav Brabec > http://www.penguin.cz/~utx <http://www.penguin.cz/%7Eutx> > > > _______________________________________________ > 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/20100519/432c70b8/attachment.html>

19.5.2010 10:15:46 (#40)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
Pavel Zbytovsk? p??e v St 19. 05. 2010 v 21:46 +0200: zobrazit citaci
> Napsal jsem na wiki n?vrh, jak bychom ta chybn? data mohli syst?mov? > ozna?it: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD > > P?edpokl?d?m, ?e wiki zas tolik lid? ne?te, tak?e m??eme je?t? > vymyslet zm?nu - klidn? to tam upravte, ale p?ijde mi to takto > funk?n?.
Je?t? vymyslet zp?sob, jak vyzna?it, ?e vodn? plocha ji? neexistuje. Odstranit hlavn? tag, a zbytek ponechat, a smazat p?i p???t?m importu? ________________________________________________________________________ Stanislav Brabec http://www.penguin.cz/~utx

20.5.2010 08:29:44 (#41)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
V?m o m?st?, kde byl v importu rybn?k, ale v OSM ani ve skute?nosti u? nen?. D? se n?jak rozumn? zjistit historie oblasti? historie na OSM mi toti? uk??e i zm?ny stovky kilometr? daleko. A d? se naj?t jak vypadala oblast k ur?it?mu datu, v?etn? smazan?ch v?c?? J&D 2010/5/19 Stanislav Brabec <utx at penguin.cz>: zobrazit citaci
> Pavel Zbytovsk? p??e v St 19. 05. 2010 v 21:46 +0200: >> Napsal jsem na wiki n?vrh, jak bychom ta chybn? data mohli syst?mov? >> ozna?it: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD >> >> P?edpokl?d?m, ?e wiki zas tolik lid? ne?te, tak?e m??eme je?t? >> vymyslet zm?nu - klidn? to tam upravte, ale p?ijde mi to takto >> funk?n?. > > Je?t? vymyslet zp?sob, jak vyzna?it, ?e vodn? plocha ji? neexistuje. > Odstranit hlavn? tag, a zbytek ponechat, a smazat p?i p???t?m importu? > > > ________________________________________________________________________ > Stanislav Brabec > http://www.penguin.cz/~utx > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-- -- Ing. Jan Dud?k

20.5.2010 10:56:08 (#42)
gravatar

jzvc

<jzvc at tpfree.fdns.net>
180
Dne 20.5.2010 8:29, Jan Dud?k napsal(a): zobrazit citaci
> V?m o m?st?, kde byl v importu rybn?k, ale v OSM ani ve skute?nosti u? > nen?. D? se n?jak rozumn? zjistit historie oblasti? historie na OSM mi > toti? uk??e i zm?ny stovky kilometr? daleko. > A d? se naj?t jak vypadala oblast k ur?it?mu datu, v?etn? smazan?ch v?c?? >
Melo by jit stahnout changesety ktere nejak zasahovaly do vybrane oblasti, pokud je dotycny alespon trochu komentuje, tak se da zjistit ktery to byl. zobrazit citaci
> J&D > > 2010/5/19 Stanislav Brabec <utx at penguin.cz>: > >> Pavel Zbytovsk? p??e v St 19. 05. 2010 v 21:46 +0200: >> >>> Napsal jsem na wiki n?vrh, jak bychom ta chybn? data mohli syst?mov? >>> ozna?it: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD >>> >>> P?edpokl?d?m, ?e wiki zas tolik lid? ne?te, tak?e m??eme je?t? >>> vymyslet zm?nu - klidn? to tam upravte, ale p?ijde mi to takto >>> funk?n?. >>> >> Je?t? vymyslet zp?sob, jak vyzna?it, ?e vodn? plocha ji? neexistuje. >> Odstranit hlavn? tag, a zbytek ponechat, a smazat p?i p???t?m importu? >> >> >> ________________________________________________________________________ >> Stanislav Brabec >> http://www.penguin.cz/~utx >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > >

20.5.2010 03:50:49 (#43)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
Jen?e to je ten probl?m, ?e changesety pro na?i vesnici o 500 obyvatel?ch jsou ?asto typu "robotick? oprava n?z? vesnic v cel?m rakousku" [1], tak?e i v?c star? jen p?r dn? u? je na n?kolik?t? str?nce s histori? (nav?c tam medle d??v b?valo datum, a te? ne), kter? je nav?c neskute?n? pomal?. T?eba tenhle konkr?tn? asi dohledat dok??u, proto?e to byla moje editace, ale p?iznejme si, kdo z n?s podrobn? popisuje zm?ny? zvl??? kdy? d?l?m najednou v?t?? oblast nap??u t?eba "?B a okol?" ... [1] http://www.openstreetmap.org/history?bbox=14.49229%2C48.925727%2C14.497805%2C48.928504 J&D Dne 20. kv?tna 2010 10:56 jzvc <jzvc at tpfree.fdns.net> napsal(a): zobrazit citaci
> Dne 20.5.2010 8:29, Jan Dud?k napsal(a): >> V?m o m?st?, kde byl v importu rybn?k, ale v OSM ani ve skute?nosti u? >> nen?. D? se n?jak rozumn? zjistit historie oblasti? historie na OSM mi >> toti? uk??e i zm?ny stovky kilometr? daleko. >> A d? se naj?t jak vypadala oblast k ur?it?mu datu, v?etn? smazan?ch v?c?? >> > > Melo by jit stahnout changesety ktere nejak zasahovaly do vybrane > oblasti, pokud je dotycny alespon trochu komentuje, tak se da zjistit > ktery to byl. > >> J&D >> >> 2010/5/19 Stanislav Brabec <utx at penguin.cz>: >> >>> Pavel Zbytovsk? p??e v St 19. 05. 2010 v 21:46 +0200: >>> >>>> Napsal jsem na wiki n?vrh, jak bychom ta chybn? data mohli syst?mov? >>>> ozna?it: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD >>>> >>>> P?edpokl?d?m, ?e wiki zas tolik lid? ne?te, tak?e m??eme je?t? >>>> vymyslet zm?nu - klidn? to tam upravte, ale p?ijde mi to takto >>>> funk?n?. >>>> >>> Je?t? vymyslet zp?sob, jak vyzna?it, ?e vodn? plocha ji? neexistuje. >>> Odstranit hlavn? tag, a zbytek ponechat, a smazat p?i p???t?m importu? >>> >>> >>> ________________________________________________________________________ >>> Stanislav Brabec >>> http://www.penguin.cz/~utx >>> >>> >>> _______________________________________________ >>> 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

20.5.2010 04:27:02 (#44)
gravatar

Zdeněk Pražák

<ZPrazak at seznam.cz>
749
Dob?e, projdu tedy mnou importovan? konfliktn? oblasti a dopln?m tagy u zm?n?n?ch rybn?k? a neexistuj?c? rybn?ky Pra??k zobrazit citaci
> ------------ P?vodn? zpr?va ------------ > Od: Pavel Zbytovsk? <mail at zby.cz> > P?edm?t: Re: [Talk-cz] Import DIBAVOD > Datum: 19.5.2010 21:47:11 > ---------------------------------------- > Napsal jsem na wiki n?vrh, jak bychom ta chybn? data mohli syst?mov? > ozna?it: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD > > P?edpokl?d?m, ?e wiki zas tolik lid? ne?te, tak?e m??eme je?t? vymyslet > zm?nu - klidn? to tam upravte, ale p?ijde mi to takto funk?n?. > > > Pavel Zbytovsk? > > 2010/5/4 Stanislav Brabec <utx at penguin.cz> > > > Pavel Zbytovsk? p??e v St 28. 04. 2010 v 16:45 +0200: > > > >Jo, ID zachovat, muze se hodit. > > > > > > Napsal jsem to na wiki, chyb? tam je?t? link na n?jakou ?vodn? > > > konferu.. Pro n?koho kdo do probl?mu t?eba te? vstoupil tam prost? > > > chyb? trocha informac?. > > > > > > >dohodnout na nejaky zpetny vazbe. > > > > > > lep?? by to bylo v?d?t te?, kdy? u? to stejn? mus?me proch?zet ru?n?. > > > Co bude v osm datech za p?r m?s?c? u? nen? tak spolehliv? ... "m??eme > > > reportovat chyb?j?c? rybn?k nebo ho n?kdo smazal omylem?" :-) > > > > > > > Existuje u? n?kde datab?ze nebo str?nka pro zad?v?n? chybn?ch dat > > v DIBAVOD, p??padn? n?jak? zp?sob, jak to odtagovat p??mo v map?? > > > > Narazil jsem na dva rybn??ky v m?stech, kde dnes stoj? domy (zat?m > > ov??eno pouze podle ortofoto): > > > > > http://www.openstreetmap.org/?lat=49.085642&lon=14.71834&zoom=18&layers=B000FTF > > > > > > ________________________________________________________________________ > > Stanislav Brabec > > http://www.penguin.cz/~utx <http://www.penguin.cz/%7Eutx> > > > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > >

20.5.2010 09:21:24 (#45)
gravatar

Pavel Zbytovský

<zbytovsky at gmail.com>
222 458
zobrazit citaci
> > V?m o m?st?, kde byl v importu rybn?k, ale v OSM ani ve skute?nosti u? > nen?. D? se n?jak rozumn? zjistit historie oblasti? historie na OSM mi > toti? uk??e i zm?ny stovky kilometr? daleko. > A d? se naj?t jak vypadala oblast k ur?it?mu datu, v?etn? smazan?ch v?c?? > > J&D >
Jedin? co by mohlo poslou?it je http://www.web2net.cz/osm/dibavod/ - vyt?hnout si "svou" oblast a pod?vat se co p?ibylo do "pr?zdn?ch" - bezkonfliktn?ch m?st. Bohu?el v OSM se ned? ulo?it informace, ?e tam rybn?k u? nen?, tak?e nikdo po??dn? nev?, jestli tam b?val nebo jen nebyl je?t? zmapov?n. Ot?zkou je jestli pou??vat t?eba reservoir=no :-))) Jasn?, ?e nepou??vat, ale tohle je nedo?e?eno - kdy? mapper sma?e v m?st? bydli?t? t?eba bar?k, proto?e ho v?era zbourali, m??e z?tra p?ij?t dobr? du?e a namapovat ho znovu podle km+uhul. Jedin? ?e?en? m? napad? m?sto smazan?ho objektu hned d?t alespo? village_green, to dobrou du?i upozorn?, ?e tu n?co nehraje. A je?t? jedna my?lenka - necht?lo by to n?jak dat?m z dibavodu p?ipsat, ?e byla n?k?m ov??ena? Vlastn? v?echny konfliktn? (ru?n? importy) status ov??enosti maj?, kdy?to ten automatick? (bezkonfliktn?) import m??e b?t m?sty dost vedle. Hmm, to je asi blbost, to bychom nakonec mohli ka?d?mu objektu d?vat atribut vy?aduje kontrolu, ale kdo by to d?lal? :) Hezk? den, Pavel Zbytovsk? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100520/afc7b9b2/attachment.html>

20.5.2010 09:29:38 (#46)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
277 645
Ov?em to by muselo b?t poznat, kter? pakl?k je kter? oblast. a zkou?et hledat zkusmo, ve kter?m z n?kolika set soubor? je ten konkr?tn? rybn?k... Nav?c to byl ur?it? z nekonfliktn?ho importu, vzhledem ke skute?nosti, ?e na tom m?st? dnes je silnice... zobrazit citaci
> > Jedin? co by mohlo poslou?it je http://www.web2net.cz/osm/dibavod/ - > vyt?hnout si "svou" oblast a pod?vat se co p?ibylo do "pr?zdn?ch" - > bezkonfliktn?ch m?st. Bohu?el v OSM se ned? ulo?it informace, ?e tam rybn?k > u? nen?, tak?e nikdo po??dn? nev?, jestli tam b?val nebo jen nebyl je?t? > zmapov?n. Ot?zkou je jestli pou??vat t?eba reservoir=no :-))) >

20.5.2010 11:14:05 (#47)
gravatar

Vojta

<vts.vts at gmail.com>
29

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