Garmin Map Images

[+ibycus]

Just thinking about this in another thread....

It would be really cool if one could get pocket query data in a Garmin IMG format. This would let people upload the data to their Garmin GPS in a format that didn't occupy their waypoint memory (instead it would go in to map memory). The tools are out there to do this conversion, but right now its really cumbersome to do it.

 

For reference a Garmin GPSMap 60CS can hold roughly about 3,000,000 waypoints in a point of interest map (as opposed to 1,000 in waypoint memory).

[+Lux]

For reference a Garmin GPSMap 60CS can hold roughly about 3,000,000 waypoints in a point of interest map (as opposed to 1,000 in waypoint memory).

Now that is some serious geocaching.

[+sbell111]

wow.

 

Sounds like a GSAK request to me...

[+Lux]

On a serious note though, it would be nice to move my found caches to the POI database. But yeah I agree it belongs in the gsak realm.

[Jeremy]

Sounds like a GSAK request to me...

Actually getting to the guts of it, this would seem to be a GPSBabel request.

 

Interesting. There's even a sourceforge project about this:

 

http://sourceforge.net/projects/garmin-img

[+ibycus]

I would be really cool if GSAK could do this, but I think it might be a little outside what Clyde able to put in (would require lots of work on his part to decode the format etc).

What I was thinking was that the gc.com might be able to come to a licensing arrangement with the makers of the program that will do this, and then provide that functionality via the website. IIRC gc.com uses SHP files behind the scenes to store cache data, and the main program used (cgpsmapper), can take in shape files directly...

The author of the cgpsmapper allows anyone to use basically the full version of the program (which is required if you're going to index the data so that it is searchable) if the maps created are published to their website. Problem is though that you aren't allowed to publish gc.com pocket queries to their website, so you're stuck with an unindexed map...

[+sbell111]

I would be really cool if GSAK could do this, but I think it might be a little outside what Clyde able to put in (would require lots of work on his part to decode the format etc). ...

Its all gibblygobblygook to me, but it looks like that work has already been done in the link that Jeremy provided.

[+ibycus]

Sounds like a GSAK request to me...

Actually getting to the guts of it, this would seem to be a GPSBabel request.

 

Interesting. There's even a sourceforge project about this:

 

http://sourceforge.net/projects/garmin-img

Oooh very cool,

 

I hadn't seen that. I'll have to have a closer look....

[robertlipe]

Take a look at the threads on the Magellan Explorist units to see how well uneditable lists of geocaches in your unit go over with caches. You can't mark them found to get them off the map and you can't use Garmin's geocache mode on them. The geek in me is intrigued (and impressed at the reverse engineering exercise) but building custom maps - and that's what this really is - that contain your caching database strikes me as more more of a barroom bet ("stupid geek tricks") thing than anything terribly useful.

 

I've done a little bit of power caching and never really considered the 1000 limit a problem worth dumping a couple hundred developer hours to solve.

 

/me turns hat around from geek and occaisional power cacher to GPSBabel guy

 

If you feel strongly about it, the GPSBabel guy accepts patches (that meet various suitability requirements, etc.) and offers for contract work. :-)

[+ibycus]

Yep, the uneditable aspect of it definitely sucks, but there are some legitimate uses of it that do really help things out.

 

1. A map of found caches. This is important when going out an hiding a new cache, to make sure you're staying within the 160m guideline (personally I've never run in to this problem, as I tend to hide in areas where the 160m guideline almost doesn't need to be consulted, but some areas of Calgary are getting kind of busy, and you might run up against it). Another good reason to have a map of found caches is if you're in an area, and think, 'ya know, I've cached here before. Now where was that cache again?'. Again, not terribly useful there but still useful.

2. To have a cache map of your city/state/province on your GPS for those times when you spontaneously find yourself in another city, and think, man I bet there is a cache there.

3. I have a feeling that while the 1000 closest unfound caches is probably generally enough for most areas, there are people who do travel quite a bit, or live in very cache dense areas that may be running up against this limit. I recently took a trip up to Edmonton with a bunch of guys, and of the people there, I was the only one who (a) didn't store found caches on their GPS and ( wasn't getting really close to running out of waypoints.

 

That being said, I do agree that it probably isn't worth the effort involved in adding it from scratch (although maybe some of the sample code they have there could be incorporated?). My thought with it as a website feature was that gc.com could come to some arrangement with the guys that already have the ability to read/write these files.

[+Renegade Knight]

This has seriouse potential. You don't need to edit the file. But you do need to be able to update it at will and generate new maps. 10,000 waypoints would also help solve the same problem.

[+Right Wing Wacko]

I would probably not use this for current caches, as I would want them to be editable in the field.

 

I do see a use for user created Points of Interest, as well as perhaps keeping a database of Found Caches. I typically don't load found caches into my GPS since that number alone would fill up the GPS. There have been times while out caching with friends that it would be handy to have those available.

[robertlipe]

Your examples are poster children for the Magellan SD storage model. :-) Those are _way_ easier to manipulate than ripping apart maps and uploading them to your unit again.

 

I took a look at the reference source. Don't think for a moment that it's ready to drop in for use in a project like this. It's impressive for what it does (dumping the contents of one of those little squiggly map pieces that are glommed together in mapsource) but that's a long way from being able to handle the multiple piece components that's actually used in the units and further still from being able to edit and write them.

 

From the README:

    This is a first-cut at extracting information

    from an IMG file and the code was written to help me understand how

    that is done.  With a more complete picture of the IMG format, I

    can re-architect, but for now it will stay in this sloppy, evolutionary

    state.

 

  - It should go without saying that this code is not suitable for

    inclusion in 3rd-party applications.  It's an instructive tool

    only.

 

Don't let me discourage anyone that wants to run with this, but it's doubleplus nontrivial.

[Jeremy]

Don't let me discourage anyone that wants to run with this, but it's doubleplus nontrivial.

I should have put a disclaimer in there that the link was just something I found during a google search.

[+as77]

See also a list of links at http://yukongis.ca/bin/view/Main/HackGarmin

[+ibycus]

Its the best resource I've seen on the subject though (I've had a look at the Karmin docs thanked in the intro, and I couldn't make heads or tails of them).

Bear in mind that a lot of the features discussed in the format document that aren't really required for a pure POI map. I'll probably take some time to look at it in more detail during my *copious* amounts of free time (for those of you who want to try it out, have a look here. on how to do it with existing tools.