[Talk-cz] Import DIBAVOD
Tomas Kolda
kolda na web2net.cz
Úterý Únor 23 21:15:22 UTC 2010
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):
> 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>
Další informace o konferenci talk-cz