2008/12/18 Shaun McDonald <span dir="ltr"><<a href="mailto:shaun@shaunmcdonald.me.uk">shaun@shaunmcdonald.me.uk</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 18 Dec 2008, at 08:56, maning sambale wrote:<br>
<br>
> In short:<br>
><br>
> Mappers need not worry about changing mapping habits.  Editing is the<br>
> way it is (unlike the transition from API 0.4 to 0.5!), you're just<br>
> encourage to explain your edit session via changeset comments<br>
><br>
> This is what I usually do:<br>
> 1. Download a manageable chunk via OSMXAPI.<br>
<br>
</div>Is the OSMXAPI ready to return version numbers? [For devs to answer]<br>
<div class="Ih2E3d"><br>
><br>
> 2. Edit via JOSM for a full 4-5 hours.<br>
> 3. Then upload via my dial-up (10 kbps) connection.<br>
> 4. Sleep.<br>
><br>
> What if someone edited a few ways?  Does it invalidate my whole<br>
> changeset/edit session? Or just the modified node/way/relation?<br>
<br>
</div>It will invalidate just the modified node/way/relation.<br>
With JOSM in 0.6 there will be diff uploads, which means that all the<br>
changes are sent at one time. This does mean that the whole change<br>
will be rejected, if one node has been modified before you have<br>
uploaded. As the upload is done as a single request, less bandwidth<br>
hence time will be required. I don't know what the speedup is. The<br>
speedup is likely to depend on the network connection.<br>
<font color="#888888"><br>
</font></blockquote><div><br>If the API specifies which particular objects in the change were a problem, it would be good if JOSM gave the option of downloading just those objects and performing conflict resolution rather than just failing... Not got a clue how hard that would be to implement though...<br>
<br>The speedup will be pretty sizable for high latency links such as many of those in asia when transfering more than a few modification... I'd guess Maning being on a dialup link in asia will probably see a pretty decent speed up as compression should take care of most of the size of the change and being sent in one go should remove most of the time taken in establishing new connections...<br>
<br>With an rtt of 250ms, creating 100 nodes in 0.5 would take at least 750ms per node or 75 seconds for the 100 nodes at one connection per node plus transfer time... in 0.6 this should be reduced to 3 connections, so 2.25 seconds plus transfer time... I'd guess Maning's rtt is somewhat higher than 250ms though in which case he'd save even more, as I will with my best case rtt of 320ms to the API...<br>
<br>Of course this assumes that JOSM isn't reusing connections, which I think is true and it also assumes that I'm not making silly mistakes or missing things...<br></div></div><br>d<br>