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