Command-line Yaouh! clone

[rhn]

On Thu, 23 Apr 2009 15:45:28 +0200, Helge Hafting <helge.hafting at hist.no>
wrote:
> Risto H. Kurppa wrote:
>> On Thu, Apr 23, 2009 at 4:11 PM, Helge Hafting <helge.hafting at hist.no>
>> wrote:
>>>> These here sound good to me to have around (in Yaouh, too)
>>>> * skipping files modified recently
>>> How recent would that be?
>>> I run yaouh to get the latest tiles where I have updated the map. Of
>>> course, this is often the same tiles as I refreshed a couple of days
>>> earlier. So I think this has to be optional. Some kind of uses need to
>>> check fairly new tiles.

I use the program in exactly the same way. Skipping files is not for sake
of less transfer, but for less time spent on contacting remote servers
(that's the same reason why I believe deleting files long unused is
necessary). As of now, skipping files one day old is completely sufficient
for me. Unless you do many updates every day and the tile server gets
updated quicker than in my area.
The value should be adjustable (including 0) in my opinion.

>> 
>>>> * forcing download empty tiles
>>> What does that mean?
>> 

The current version treats the empty files (size 0) left by tangoGPS as
ones needed to download "by force", that is, not checking for the server
modification date.

>> For example download every tile that has 2 (or 3 or four) neighbors
>> downloaded to 'fill the gaps' in the map.
>> 

That's an interesting idea... unfortunately, the program would need to be
rewritten because it uses recursive traversal of dictionaries now (and I
think Yaouh! does so, too).

> Ah, excellent!
> It'd also be nice to have an option for automatically "zooming out".
> That is, if I have a bunch of tiles at zoom 15 (downloaded using 
> tangogps perhaps) then I want the zoom 14 tiles covering the same area, 
> as well as the zoom 13 tiles, and so on all the way up to the top.
> 
> Of course, the number of tiles quickly gets lower as one goes up, and 
> usually hits a tile that is there already after a few levels.
> 

I think this will be the next thing I implement when I get some free time.

> Another thing that'd be nice to have, is duplicate tile detection.
> There are a lot of "sea" tiles, "empty land" tiles, and probably some 
> tiles containing only forest or similiar. This could save lots of space, 
> but not download time. It'd still be necessary to check if "empty land" 
> suddenly isn't empty anymore.

Is it really that good? Thousands of tiles wold be necessary to make any
real difference, even if the internal storage of a Freerunner is used. A
few megabytes saved when a few hundred is laying there isn't worth the
trouble. Imagine storing modify dates for each sea tile independently when
they are all symlinked to the same file (if you want to use the skipping
functionality mentioned above to save time).

-- 
Cheers,
rhn