« 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>
800
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>
1056 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>
800
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 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 > > >

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 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) Parkis 2010/2/22 Pavel Machek <pavel na 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 na 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 na 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 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)
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>
1056 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 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

23.2.2010 06:44:39 (#7)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 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 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

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

23.2.2010 09:38:41 (#9)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
327 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 na 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 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 >
-- -- 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 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 >> >> > > > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://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 na 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 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 > >

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 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://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 na 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 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 > >

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

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 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://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 na 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 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 > >

23.2.2010 10:33:52 (#17)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
327 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 na 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 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 > >
-- -- 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- dal?í ?ást --------------- HTML p?íloha byla odstran?na... URL: <https://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 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 >

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 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 >
------------- dal?í ?ást --------------- HTML p?íloha byla odstran?na... URL: <https://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>
1056 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>
1056 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ý

<mail at zby.cz>
53
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> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100301/efaf9a87/attachment.html>

8.3.2010 04:54:11 (#26)
gravatar

hanoj

<ehanoj at gmail.com>
718
To by bylo dobre, co trebas zalozit stranku na nasi wiki? hanoj 2010/3/1 Pavel Zbytovský <mail na 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 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.

8.3.2010 07:31:54 (#27)
gravatar

Pavel Pilát

<pavel.pilat at gmail.com>
88
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>
103
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 na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-- S pozdravem, Jirka Sedláček --- jirisedlacek na 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 na 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 na 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 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 >> > >

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

10.3.2010 09:46:57 (#32)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 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ý

<mail at zby.cz>
53
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> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://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>
327 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 na 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 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 > >
-- -- 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 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100426/a0adf9e3/attachment.html>

28.4.2010 04:45:28 (#37)
gravatar

Pavel Zbytovský

<mail at zby.cz>
53
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?" :-) ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://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ý

<mail at zby.cz>
53
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> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://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>
327 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 na 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 na 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 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 >> >> > > >

20.5.2010 03:50:49 (#43)
gravatar

Jan Dudík

<jan.dudik at gmail.com>
327 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 na 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 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 >
-- -- Ing. Jan Dudík

20.5.2010 04:27:02 (#44)
gravatar

Zdeněk Pražák

<ZPrazak at seznam.cz>
800
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 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 > > > > >

20.5.2010 09:21:24 (#45)
gravatar

Pavel Zbytovský

<mail at zby.cz>
53
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ý ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://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>
327 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