Laughing Man | # 21 | 2009-06-09, 20:21 | Report

Sorry, I used the wrong file ending (a bit of a newbie with that). But my database is in sqlite form.

Hmm I tried the (same) command again that gave me an error the first time and it works now. How odd. The only difference from before and then is a PC reboot (well shutdown at night and turn back on in the afternoon). *shrugs*

It works.

grog | # 22 | 2009-06-10, 14:54 | Report

Thanks for sharing the script, Sencer. Works great & lead me to finally convert to using SQL db's which I never bothered to before now. BUT , has anyone else noticed that the zoom levels seem to be off? With my old db I would normally zoom my maps to level 5 when walking, but now I find to get the same detail I have to go to 4 (somewhere between 3 & 4 actually). The names & labels also seem to be smaller (it's not just my eyes, which it could have been since I just has laser correction last week, but it's not)

Not a biggie, just curious. TX

Lord Raiden | # 23 | 2009-06-11, 01:37 | Report

Nah, I hadn't noticed anything different.

Laughing Man | # 24 | 2009-06-11, 02:27 | Report

Hmm, and I messed up my earlier post. I forgot to rename GStreet.db back to GStreet so the command works (regardless of if you put the database file first or last in commands) with a fresh file. But without a file it still says.

I'm positive I'm using an sqlite file though..Ubuntu shows it as "GDBM database (application/x-gdbm)".

Lord Raiden | # 25 | 2009-06-11, 04:28 | Report

If it's an older database, or was built with the previous version, then it's likely GDBM. I'd probably ask someone to include GDBM support in their script, but after the hell I went through trying to work with GDBM, I'm not gonna put anyone else through that. >.<

YoDude | # 26 | 2009-06-11, 09:31 | Report

This may be because "Double Pixels" was checked when the maps were downloaded.

An easy way to check this is to:
1. Determine what zoom level you are currently on.
2. Go to "Maps" > "Manage Maps" and select the "Zoom" tab.
3. Whatever Zoom level is checked automatically, should be the level that you manually download for your database.

That is, if you are used to a Double Pixel view and you set up your Zoom Steps to skip every other level you may think you need to download levels 2, 4, 6, 8, 10, and 12 manually.

Because Pixels are doubled, you really need to manually download levels 3, 5, 7, 9, 11, and 13.

Lord Raiden | # 27 | 2009-06-11, 18:07 | Report

Ok, I've been playing with this some and if you use the google URL, it works fine, but I prefer Virtual Earth maps, and yet when I put that URL in, it doesn't work. It's likely because of the formatting on the URL. Here's the Virtual Earth Street URL.

http://r0.ortho.tiles.virtualearth.n.../r%0s.png?g=45

Is there any way to get that to work with this script? Do I need to change the formatting of the URL or do I need to hack the script some?

EDIT: Nevermind. I just checked the Google maps, and evidently this version 2.95 they're pushing just utterly blows away the old VEstreets maps! Geez, what a switch! I guess I'll go back to Google Maps for now and skip VEstreets for a while. lol. Man, what a difference 9 months makes!

---

Last edited by Lord Raiden; 2009-06-11 at 18:27.

grog | # 28 | 2009-06-11, 19:29 | Report

I assume you're replying to my post about the perceived size. I don't see a 'Double Pixels' option. Or are you saying that only the odd (or even) levels are being downloaded & that when I zoom in & out MM is interpreting them as sequential levels (i.e. if I downloaded 2,4,6,8 then MM is treating them as 2,3,4,5)? I don't think I'm understanding properly 'cause that doesn't make any sense to me. Is that really what's happening? TX

Lord Raiden | # 29 | 2009-06-11, 19:35 | Report

Here's an idea for a much needed improvement. Multiple threads. Given the size of the files, I can easily do up to 20 download threads at the same time, so if there's a way to do more than one download thread at a time, that'd really speed up the work and get the db compilations done much quicker. Right now it's all sequential and that's making things slow. As I said, if it could be done in parallel, with up to 20 threads, that'd make downloading several gigs worth of maps a much quicker proposition.

And I know there's an easy way to do threading in Python. I just don't know offhand what it is, but I've seen other apps that use it.

Lord Raiden | # 30 | 2009-06-16, 03:58 | Report

Hey, I've been studying that script and I know how to make it do threading without actually doing threading. It's called building children. Here's how it works in principle. You start the program by doing the single line command like this:

./getmaps GStreet.db -children=20 -t 53.00000 -l -98.00000 -b 34.00000 -r -71.00000 -z 16 -z 14 -z 12 -z 10 -z 6 -z 8 -z 6

The -children=20 tells the script to do the build using 20 child processes. Leave that out, and the script goes into normal single process mode. But if you loaded it with the children option, it would in turn spawn child versions of the script where it calls a command line option to spawn another instance of itself instead of handling all the work itself. Thus the spawning command would be something like this:

./getmaps GStreet.db -child -range=1000-1500 -t 53.00000 -l -98.00000 -b 34.00000 -r -71.00000 -z 16 -z 14 -z 12 -z 10 -z 6 -z 8 -z 6

The -child option would tell the script that this is a child and to act accordingly. -range=xxx-xxx would tell it to only process map tiles 1000 through 1500 and then die. The script would then go to sleep after spawning all the processes and then wake up every so many seconds to see who was still alive. If any have exited, it spawns another process to replace it until all maps have been downloaded and the map file is built.

That way the script could process as many as 20x's as many maps and on high speed connections with fast machines you could do as many as 100 child processes, thus allowing you to build a database in record time.

That's just an idea for you to chew on. The choice is up to you.