Closed GoogleCodeExporter closed 9 years ago
Original comment by Marcus.W...@gmail.com
on 2 Oct 2012 at 8:27
This is partly a defect and partly an enhancement issue.
If loading saved data failed (for example due to a version change or a
corrupted file) this went unnoticed in the code, causing undeterminate
behaviour instead of showing the bounding box picker, further there was likely
a race condition between loading the data and determining the bounding box.
I'll be commiting fixes to these two issues shortly.
The above should greatly reduce the number of times that you get a zoomed out
map instead of the bounding box picker, in any case you can select "Download
other location" to get it.
What currently is still painful is being thrown back to a fully zoomed out map
when you haven't downloaded any data, this should be limited to the normal
minimum zoom possible and centered somewhere "reasonable".
Original comment by sp8...@gmail.com
on 28 Jul 2013 at 10:40
I've done some further work on this, including trying to get a handle on the
projection weirdness. For the later the reason for the projection problems is
clear (using an approximation for the projection based on projecting the
mid-screen coordinates, which naturally doesn't work if zoomed out to any
larger region). I haven't been able (yet) to get the solution (using non-approx
projection) to work at all zoom levels. In any case the last commits fix some
bugs and make the code more robust.
Original comment by sp8...@gmail.com
on 24 Aug 2013 at 3:59
Original comment by sp8...@gmail.com
on 15 Dec 2013 at 12:01
I've done some more work on this and related issues:
a) fix issue that the WGS84 coordinates in the bounding box did not match with
the region on the screen display (fixing this breaks the approx. projection
code, if somebody knows how this is supposed to work (mathematically), please
comment). This on the one hand allows non-approx projection code to work and
fixes the issue of not being able to pan up to the maximum latitude.
b) use non-approx projection for tile placement, this fixes the "stretching"
tiles issue, further improvements to the tile placement code
c) use non-approx projection code for drawing and input, this is likely to
result in a performance hit (subjectively I've not noticed anything on real
devices, but it is difficult to do a direct comparison), so it would be nice if
the approx. projecting code could be revived (see a))
Original comment by sp8...@gmail.com
on 30 Jan 2014 at 11:46
http://code.google.com/p/osmeditor4android/source/detail?r=682
Original comment by sp8...@gmail.com
on 23 Feb 2014 at 9:51
Original issue reported on code.google.com by
shaunmcd...@gmail.com
on 1 Oct 2012 at 3:57