Windows maps download tool for MapThis! by in7ane

[in7ane]

Russoxley187, if you are downloading from Google Satellite or Google Hybrid (which downloads from satellite) - they ban your IP for a few hours if you get too many tiles from them.

[GIS]

Thanks for the update
I have test : 4x4, 16x16, 64x64. It is OK

Main Benefits:
- much faster PC to PSP transfer speed : YES YES YES YES
- smaller size on memory stick : YES YES
- faster than zip access times : YES YES

THX deniska & in7ane

[Russoxley187]

Like GIS said,

Its much better, ALOT faster and smaller...

I love it.
You guys are great...

[deniska]

in7ane, can we change the GPSFS spec a bit?
I propose to conver all 8 byte sections to 4 bytes (char[4] or int32 respectively)
With int32, we still should be able to adress files upto 4GB in size. Honestly, I am not even shure if curent sdk supports adressing larger files...
And we'll save 4 bytes per map tile...
Well, let me know what you think...

[in7ane]

deniska, if it's for coding convenience (eg. you are having to cast/convert int64s to int32s everywhere) then certainly. Then it's best to make the switch to int32 as soon as possible so people don't end up with too many int64 maps.

If for space - it's not really worth it, I tried a worst case scenario (msn map of east africa - all one color and only town names and very few main roads), with a 128x128 map 21844 tiles the file is 9057613 bytes a saving of 4 bytes per tile will only bring that down by 87376 bytes - just under a 1% saving.

Then there's having to reconvert maps for those who already made the jump (ok, just my laziness). And I'm still holding out for the up to 32GB memory sticks (FAT32 will actually prevent larger than 4GB files, so it would be a matter of spanning multiple files).

[deniska]

The entire GPSFS thingie is still just "work in progress" kind of thing...
Since I did not do an official release, I doubt that many people are actually using it.. so it's ok to change it at this stage..
I did some additional testing - the thing gets pretty sluggish on large maps (512x and more)
I did some SW optimizations (like caching the indexes into a table in memory, so I don't have to do 2 fseek and 2 reads) still fseek(s) over a large file take pretty long time... So perhaps we should consider splitting GPSFS file in to 100Mb chunks.

[Russoxley187]

I'm using it, but you are correct... It is kinda sluggisn on larger maps.
I thin I'm gonna gpo back to where i was before.
I'll wait until you release it officially.

[in7ane]

deniska, how about a small change to the setup like this then:

The IDX fields change to two int32's - the first containing the file number (0 to N) and the second the offset within that file.

And each file (GPSFS, GPSFS1 to GPSFSN) is 100MB (well, just over). Giving pretty much unlimited map size

Let me know what you think (alternatively to 100MB, can have it where there are always 100, or user definable number, GPSFS files of roughly equal size if smaller files provide a proportional speed improvement).

If the file-offset format above is ok - I think I can implement it pretty quickly.

[deniska]

Sounds good, let's do it..
As to the number of GPSFS files, let's make it always 5 no matter what what overall the map size is..
This way I can open all file descriptors right away, and keep them open...
Let's see how that works out...

[in7ane]

deniska, changes from the previous format:

There are now 5 files (GPSFS, GPSFS1, GPSFS2, GPSFS3, and GPSFS4) - at this stage latter ones will be missing for a 4 tile map (do you want empty files in that case? or just assume ridiculous maps don't get created).

The IDX fields have been split into IDXfile and IDXidx both being int32's (other numerics stay int64) IDXfile is 0 to 4 IDXidx has the same logic as before EXCEPT it resets to 0 for each new file - so (1) if the next IDX is 0 use file.length instead (2) if you were using idx > 0 to identify existing tiles that needs to be >= 0 now (yes, took me ages to find in my own code).

Is this ok, or were you thinking of different IDX/file logic?

http://homepage.mac.com/f.levin/psp/....15aGPSFS2.zip

Note: <-oGPSFS will decode the old GPSFS format.