Dne 23.2.2010 22:29, Jan Bilak napsal(a): > 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. > 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 > _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
