Closed GoogleCodeExporter closed 8 years ago
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
Attachments:
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
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
Original comment by heldersepu
on 2 Mar 2010 at 2:43
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
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
right. This could be shortened a little... ;)
Original comment by standa31...@gmail.com
on 4 Mar 2010 at 11:09
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
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
Continuing at Issue 138.
Original comment by standa31...@gmail.com
on 7 Mar 2010 at 10:38
Original comment by heldersepu
on 17 Apr 2010 at 2:07
Original comment by heldersepu
on 25 Apr 2010 at 6:39
Original issue reported on code.google.com by
webma...@esterbauer.com
on 13 Jan 2010 at 3:03