> Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát.

> ------------ Původní zpráva ------------ > Od: Pavel Machek <pavel na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

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

> Bohužel se zdá že ano, všechny 4 changesety obsahují přes 10000 bodů. > Namátkou třeba http://osm.org/go/0JycpXo na 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> To by bylo dobre, co trebas zalozit stranku na nasi wiki?

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

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

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

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

>Jo, ID zachovat, muze se hodit.

>dohodnout na nejaky zpetny vazbe.

> >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?" :-) >

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

> 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ý 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

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

> ------------ Původní zpráva ------------ > Od: Pavel Zbytovský <mail na 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 na 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 na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > >

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