separate file paths for different map sources

[GoogleCodeExporter]

What new or enhanced feature are you proposing?
I would like to use different file paths for different map sources. e.g.
the OpenCycleMap tiles should end up in a folder called
"opencyclemap_tiles", CloudMade in "cloudmade_tiles" and so on. (for google
maps it could stay "tiles")

What goal would this enhancement help you achieve?
I don't want to mix my OpenCycleMap tiles with all the others.

Original issue reported on code.google.com by webma...@esterbauer.com on 13 Jan 2010 at 3:03

[GoogleCodeExporter]

 Currently you can manually change the directory for the map tiles, that can be changed 
in the settings, please see attached image.

 I will add this as a new option in the settings

Original comment by heldersepu on 13 Jan 2010 at 3:13

• Changed state: Accepted

Attachments:

• settings.png

[GoogleCodeExporter]

I would suggest following implementation:
- set the dirnames in mapsConst for each mapsource and maptype (like there is 
for
map, terrain, sattelite)
- set the dirnames unique, so all sources could be intermixed in one Custom Maps
Directory
- Enhance select box in main window to contain all available layers. So select 
box
will have following items: Google: Maps, Google: Satelitte, Google: Terrain,
OpenStreetMap, CloudMate, Yahoo, ... (there will be 9 items, if I counted 
correctly)
- from settings panel "Change theme" "Select favourite map service will be 
removed"

What do you think about it?

Original comment by standa31...@gmail.com on 2 Mar 2010 at 9:23

[GoogleCodeExporter]

That sounds good to me!

We could use the existing MAP_SERVERS constant:
http://code.google.com/p/gmapcatcher/source/browse/trunk/src/mapConst.py

The path could be something like:
= DEFAULT_PATH + "/" + MAP_SERVERS[i] 
and inside that path we will have the same folders that we have right now 
(tiles, 
sat_tiles, ter_tiles) if they all are available. 

What I do not like is a loooong select box in main window with all layers....

Original comment by heldersepu on 2 Mar 2010 at 1:48

[GoogleCodeExporter]

Original comment by heldersepu on 2 Mar 2010 at 2:43

• Added labels: Milestone-Release0.64

[GoogleCodeExporter]

heldersepu: 
well Im reading it now. I put my patch in the trunk yesterday. 
what now ? :-/

IMHO - i like the way to select layer from one point and that's exactly, what 
you
don't like.

I got an idea:
- change schema setting so there will be listed all map services and all layers 
and
user will be able to select what mapSrevices/layers wants to have in select box 
in
main window.
So if somebody wants: google satellite, yahoo terrain a opencyclemap he/she just
select this services and those will be available in select box in main window.

Original comment by standa31...@gmail.com on 3 Mar 2010 at 10:13

[GoogleCodeExporter]

I had to admit, We had a good laugh with your code:
http://code.google.com/p/gmapcatcher/source/browse/trunk/src/mapConst.py

MAP_SERVICES = None
if (MAP_SERVICES is None):
    MAP_SERVICES = {}

That is very very funny!!

Original comment by heldersepu on 3 Mar 2010 at 1:30

[GoogleCodeExporter]

right. This could be shortened a little... ;)

Original comment by standa31...@gmail.com on 4 Mar 2010 at 11:09

[GoogleCodeExporter]

Not perfect layout - after r764 - I am aware of it. For small window sizes 
widgets
are crunched. I wanted to put changes into source code to make more smaller 
changes
and after each change check the functionality than make one huge change that 
will
brake something. "Aware" means - it requires some improvement, was in personal 
ToDo list.

- key bindings - thank you for pointing it. I wasn't aware of that. Have few 
words later.

- layers - the layers combo box before 764 was misleading. Some map services 
provide
all 3 types of layers. But many other don't and when such service is selected, 
user
sees 3 layers but in reality only 1 or 2 layers are provided by selected 
service and
other by something else. From this point of view were slightly misleading also
keybindings for switching layers.

In my opinion the option to select what map services & layers user wants to have
available in combo box will be good solution. In such circumstances I recommend 
to
change keybindings to something like "<ctrl> + number". With numbers 1,2...9,0 
for
layers 1 ... 10. If somebody wants to have more layers available in combo box, 
they
will not be directly accessible by keyboard. All layers will be accessible by
accessing combo box.

in r764 you wrote:
"- Backwards incompatibility with previously downloaded tiles"
backwards incompatibility? Where? Can you be more specific?
If you mean situation where: 
1. select map service something else than google
2. select storage "XY"
go to new version of gmapcatcher and open storage "XY" and now downloaded tiles 
are
seen as google
Well - this is incompatibility. I admit. But it is good it is this way. 
Because mistakes like (see below) can't happen any more. Well - it is good to 
have
such information propagated to users. If such message would be propagated, it 
could
be quite easy - just rename the directory to differnt name. I think that 
benefits of
having different names for different map services/layers is above this
incompatibility. I think this incompatibility was inevitable somewhere in the 
future.  
Bad old scenario:
"""
1. select storage "XX"
2. select map service for example Yahoo and download some tiles
3. select map service google and download several tiles
4. select map service OpenCycleMap and download several tiles
"""
Now I have 3 different services in single directory. From this point map 
services had
limited usability.

Maybe the misunderstanging is made by different understanding what "trunk" is 
for.
For me now it's just some place, where changes should be made and polished. 
After
each change there is no need to have everything tip-top but to be aware what is 
not
perfect and improve it in another small change. And once in a while new release 
will
be published.

I'll like to open an "Discussion" issue where I would like to somehow summarize
rules. For me and maybe for others. Rules - how to make changes, how and where 
to
provide changes to the source code, rules for name conventions of methods,
documentation of methods,... Maybe it's suitable for wiki page.

Good day to all. :)
standa.

Original comment by standa31...@gmail.com on 4 Mar 2010 at 11:58

[GoogleCodeExporter]

That is one long comment!

I personally do not agree with changes that affect existing functionality, what 
ever 
you do should be an option, just like SQLite.

- backwards incompatibility, what you call "Bad old scenario" is a desired 
functionality for others for example I like Google maps for my house:
 http://maps.google.com/maps?&q=12629+NW+13th+St+Sunrise+FL,+33323
but my parents house is not good in Google:
 http://maps.google.com/maps?&q=San+Nicol%C3%A1s+de+bari,+Cuba&z=14
now take a look in OpenStreetMap:
 http://www.openstreetmap.org/?lat=22.7867&lon=-81.9107&zoom=14

To some of us is very useful different map services in single directory.

And there is no misunderstanding about the trunk, the trunk is trunk and 
without the 
trunk there will be no branches :) 

Original comment by heldersepu on 5 Mar 2010 at 1:29

[GoogleCodeExporter]

Continuing at Issue 138.

Original comment by standa31...@gmail.com on 7 Mar 2010 at 10:38

[GoogleCodeExporter]

Original comment by heldersepu on 17 Apr 2010 at 2:07

• Added labels: Milestone-Release0.7

[GoogleCodeExporter]

Original comment by heldersepu on 25 Apr 2010 at 6:39

• Changed state: Done