PiRSquared17 / gmapcatcher

Automatically exported from code.google.com/p/gmapcatcher
0 stars 1 forks source link

Shared map data between gps softwares #301

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What new or enhanced feature are you proposing?

I'm currently travelling a lot (more than 6 months long) and I used GPS from 
iphone or bluetooth/usb receiver. Sadly, I used a lot of differents software to 
handle my gpx/maps and every one of them has its own set of map data which 
makes a big waste of space and time.
In my case, I use Gmapcatcher to fetch maps for offline use / search them 
(~/.googlemaps, tile format), gpsprune to check my gpx (but only 
openstreetmap)(no cache by default, user-configureable path, seems to be tile 
format), foxtrotgps to check against different map provider (~/Maps, tile), 
sometimes would have wanted to import whole openstreetmap planet.bin or maybe 
interact with other map software but no easy way (tried navit which has its own 
binary format, also gpxviewer).
Even if it is tile format for many, I'm not sure directories hierarchy is the 
same.

Please have an option to use a common repository/format for all these software 
so all could use the same data at the same time. (and it's valid for desktop 
AND smartphone too)

Thanks

What goal would this enhancement help you achieve?

Avoid duplicate set of data, waste of disk space, waste of time to download 
from multiple software.
Whatever developpers will do, users will want to use multiple software, so make 
it easier.
For example, at first use, if detect an existing map data folder, ask to use it 
or not.

Original issue reported on code.google.com by julien....@gmail.com on 29 Dec 2011 at 3:16

GoogleCodeExporter commented 9 years ago
Not a very clear idea of what/how to do it...
A common repository/format for all these software (iphone, gpsrune, foxtrotgps, 
navit, gpxviewer) Is that what you want??

Original comment by heldersepu on 29 Dec 2011 at 3:36

GoogleCodeExporter commented 9 years ago
By default, no change (creating choice for user)
If asked and/or detected, use a common format and location for map data

1- check which formats are supported by each software (in case of gmapcatcher: 
tiles or sqlite3) and if possible to customize path.

2- eventually add some format either for direct use, either for import/export 
(in case of gmapcatcher, a good addition would capacity to import and render 
planet.bin files or extract - PBF or OSM, see http://planet.openstreetmap.org/ 
and for exemple, 
http://ksmapper.blogspot.com/2011/08/simple-openstreetmap-tile-rendering.html). 
It will avoid the (bad) way of downloading too many tiles from osm server 
manually.

3- on first use of software, detect other "standard" map location/format (as 
mentioned previously) and asked user if want to keep separate or use one of the 
existing. Of course, advanced user can change this manually in preferences.

have submitted same bugs there:
https://sourceforge.net/tracker/?func=detail&aid=3466768&group_id=192994&atid=94
3644
https://bugs.launchpad.net/foxtrotgps/+bug/909562

Original comment by julien....@gmail.com on 29 Dec 2011 at 5:02

GoogleCodeExporter commented 9 years ago
on the gpsprune bug 
(http://sourceforge.net/tracker/?func=detail&aid=3466768&group_id=192994&atid=94
3644 2012-04-23 comment), it was said that gmapchatcher is using its own 
directory structure for saving files which is not the usual way of storing OSM 
(http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames).

A good improvement, at least for OSM Maps, would be able to switch to the 
"normal" way.

Another option to be able to download from customized tiles server as can be 
build from here
http://switch2osm.org/serving-tiles/manually-building-a-tile-server/

Original comment by julien....@gmail.com on 29 Apr 2012 at 3:34

GoogleCodeExporter commented 9 years ago
GMapCatcher has multiple repository types, (not all are based on folder/file 
structure) see the following screenshot:
http://code.google.com/p/gmapcatcher/source/browse/wiki/toolsRepos.png

If a user needs to be an "advanced user" to change a preference or edit a 
config file, that user should not be using Beta Open Source software! It should 
probably pay for a proprietary licence that comes with a Service-level 
agreement and local tech support.

To complete this enhancement request it will take a lot time, my estimate 40 to 
60 R&D hours, I personally do not see it worth it.

Original comment by heldersepu on 29 Apr 2012 at 3:01

GoogleCodeExporter commented 9 years ago
Sorry, didn't try with latest release. Mine only had files and sqlite3.

I don't agree on advanced user = not opensource ... can't say most linux/bsd 
users are not minimally advanced compared to basic computer user but you are 
the developper, so your choice.
Still thanks for the estimate time.

Original comment by julien....@gmail.com on 29 Apr 2012 at 7:06

GoogleCodeExporter commented 9 years ago
Sorry but you got it all wrong OR maybe my statement before was not too clear; 
it should be: Basic users should stay away from BETA Open Source software.

Original comment by heldersepu on 29 Apr 2012 at 7:37

GoogleCodeExporter commented 9 years ago
I do agree that we should change to the "normal" zoom-levels, they start 
normally from 0 (minimum zoom, maximum area) and go to 16 or higher. This way 
the data would be easier to use in other programs and also easier to add more 
maps. And I think most of our maps use the OSM-"standard" anyways.

I can look into this and see what kind of problems this change would cause.

Original comment by kipenros...@gmail.com on 2 Oct 2012 at 1:55

GoogleCodeExporter commented 9 years ago
Backwards Compatibility is my main concern!
We can add more tileRepos:
http://code.google.com/p/gmapcatcher/source/browse/#svn%2Ftrunk%2Fgmapcatcher%2F
tilesRepo
but not modify the existing one (unless there is a bug)

Original comment by heldersepu on 2 Oct 2012 at 2:03

GoogleCodeExporter commented 9 years ago
For OSM, http://josm.openstreetmap.de/wiki/SharedTileCache

Original comment by julien....@gmail.com on 2 Apr 2014 at 4:11

GoogleCodeExporter commented 9 years ago
@julien.t43 SharedTileCache sound like a good idea.
...but the main reason for this is to save space in the form of duplicated 
caches, to do that they need a network of computers, that defeats the main 
purpose of this application "offline map viewer" 
- if you have an "always on" internet access just use the maps directly 
(http://www.openstreetmap.org/)
- if you have an internal network without internet access, consider setting up 
your own tile server (https://github.com/mapbox/tilestream).
- IF you want TRUE offline capabilities use GMapCatcher

Original comment by heldersepu on 2 Apr 2014 at 5:18