Welcome to GPSFileDepot!

Main Menu

Map making workflow advice please

Started by Avon, May 06, 2016, 04:38:46 PM

Previous topic - Next topic


Hi guys, I'm incredibly new to all of this so please go easy!

First of all, a huge thank you to the folks responsible for the How to Create Garmin Topo's walk through.  It's the reason why i've signed up - i'd be in a world of hurt without your help.

So my goal is not necessarily to upload my maps to a Garmin device, but to (hopefully) print them into books and make them available as offline maps for phones and tablets. I'm particularly interested in creating maps (prettied up by yours truly) which mark historical areas within my state in Australia.

I've been busy downloading the relevant Spacial Data and have even spoken to the appropriate 'authorities' about copyright concerns, which there is no issue.  So my question is, is the Garmin Topo workflow the best bet for me?  As a graphic artist I like the idea of holding onto shape files for as long as possible, so should i convert to polish?

Any tips or advice will be greatly appreciated.  I had a (somewhat successful) attempt using TileMill on the Mac a couple of years back, but thought this is a more 'professional' option?  As i said i'm only VERY new so please go easy!!  :P



The workflow is some "extra". I would recommend reading it but then just keep them in QGIS and change the properties there.  Once the properties are changed you can set colors and all that look way way better than Garmin. Additionally, the "print" function actually allows you to build book pages.

So, short of it, read the tutorials to see how QGIS works but don't do the actual "extract" for Garmin. Just use the same concept but set the properties (double click the layer on the layers tab).
Dan Blomberg
Administrator - GPSFileDepot
GPS Units: Garmin Dakota 20, Garmin GPSMap 60csx, Nuvi 255W, Nuvi 250W, ForeRunner 110, Fenix 2, Tactix Bravo, Foretrex 401
See/Download My Maps!


Thanks so much Dan - amazing advice!

I'm sure i'll have some more questions down there track, but for now i'm very grateful that i have an overview of the whole process. The last thing i wanted to do is head off 'experimenting' again only to find that i'm working in the wrong software or with the wrong files.

My hat definitely goes off to you guys.  I thought i was fairly computer savvy until i discovered your crazily complex world.  Wow...   :o


Dan has done a terrific job with his tutorials, but they are very specific to Garmin's vector map format. From what you describe, you want to make raster imagery (basically, "pictures") which is something completely different.

The .mp format is rapidly on its way to becoming a dinosaur and is only relevant to maps for Garmin devices (which you might also argue are headed in the same direction, LOL). It has no relevance to what you are doing. There is no value to vector data with attributes when all you want to create is a picture.

I use Globalmapper, not QGIS (although I have played with it a bit). But I think Dan's advice is correct. Learn how to use the features of the program to make a map that looks nice on your screen. But skip the rest, you don't need to know anything about making Garmin maps.

I am moving away from Garmin's format myself and making raster imagery for smarphone/tablet apps such as Galileo and Oruxmaps. Have come a long way with this over the past couple years, but since this site is dedicated to Garmin it really isn't the right place to discuss this. Raster imagey offers a lot of stylistic possibilities not available in Garmin's format, but of course the price is some very large files. :)


IMHO raster maps are very outdated technology. For a phone I would rather go to OSM and Mapsforge format and create vector maps for Locus and Orux. This can be tricky, I don't think there is any tutorial for that process.

There are other programs for Android, which are somehow related to Garmin format, for example Navitel or 7-ways. I haven't done maps for these programs, but maybe it would be possible to use polish format as an input.


Raster maps will always be the newest technology because it is just a picture and it can represent anything.  ;D

But I understand the point that vector imagery is more compact/efficient, and since it is rendered "on the fly" the placement of labels, etc. are optimized for your screen in real time. I need to learn more about OSM, had a look at this a year or two ago when we discussed it before. As you say, it is difficult to get started due to lack of step by step tutorials. Finally decided it was just more than I wanted to get into. I am also on iOS so I can't use Orux or Locus (although I have an android tablet).

But some things require raster imagery, like aerial photos and shaded terrain (although I suppose terrain can be generated from DEM data in realtime). I have been making maps from aerial imagery from different time periods recently. I have one map that covers the whole state of New Jersey at 6 foot per pixel resolution. It is about 8GB. I have another map that covers an area of about 25 miles x 25 miles near my home at the resolution of 1 foot per pixel. It is about a 5GB file. :)

But storage is getting cheaper and faster. I have a 128gb iPhone 6s Plus, it uses really fast flash memory, I think access speed is in the neighborhood of 800MBytes/sec and it also has a laptop class CPU. Raster imagery works very nicely on this platform, zooming and scrolling is very fast.

But the OP in this thread wants to make printed paper maps. That is pretty much the definition of raster imagery. ;)


Raster is a picture and it is what we need when looking at a map. But a map in raster format has many flows, it takes a lot memory, it is not scalable, has no support for search or info attached to objects, no possibility to tweak its look at user side and so on.

While local storage can be available for raster, you should think about bandwidth too. Many services, which provide raster maps on-line, forces transfer limits, because of bandwidth limitation. I think OP can consider this too, if he wants to share his maps. I think raster maps are like 10-100 times bigger than vector equivalent.


Quote from: popej on May 07, 2016, 09:17:25 AMBut a map in raster format has many flows, it takes a lot memory, it is not scalable

I won't argue with most of this, there are obvious advantages to vector based maps. If there were better software available, I would use it on smartphones. Eventually I'll get around to understanding the OSM stuff.

Regarding "scalability", that works very well with modern raster formats and I have better control than I would with Garmin's vector format. The modern formats store map tiles in a database which is very efficient and permits huge file sizes. Each zoom level of these maps can be unique.

So, for my raster based topo, I have 5 completely separate maps specifically rendered at 6, 12, 24, 48 and 96 feet per pixel (levels 16, 15, 14, 13 and 12). I have tweaked the details of each map to be appropriate for the zoom scale. On the gps, the user doesn't need to know anything about this, the correct map is automatically chosen as you zoom in/out.


I know about layered raster maps. The advantage of raster format is that it is easy to create software to present maps for end users. Probably this is the main reason for its popularity. But IMHO it is still not worth using, when there are available programs and tools for vector maps.

OSM data is a big database, currently about 30GB in compressed format. Vector maps created from these data are like 0.5-2 times this size. OSM world map available in raster format is over 1200GB.

There are many tools for processing OSM data, which allows to create maps in multiple formats. For me the most interesting are OsmAnd format, Mapsforge format used by Lokus and Orux, Garmin format. The same tools can be used to create maps form other data sources, since it is quite easy to convert common vector files (SHP, GML etc.) to OSM XML.

Indrid Cold

Please stay on topic to the op. Start a new thread if you want to argue raster vs vector. >:(


Hello guys - thank you SO MUCH for the info. 

Being new to all of this it took me a while to get up to speed with everything mentioned, as well as the raster vs vector debate.

Purely from a design point of view... Wouldn't I be better off keeping as much of the data in vector for as long as possible, until i HAVE to rasterize it for my chosen output? 

Also, now that you have me thinking more about my final product, i'd like to print everything (including elevation) in vector, but for my offline maps i'd like to have satellite imagery as an optional overlay, which i guess forces me to use some sort of tiling app?  In the past i used MBTiles which worked fairly well, but i haven't used any the others mentioned in this thread so will definitely doing my homework.

Thanks again to everyone for taking the time to respond.


Yes, your source files would normally be in vector format. All of mine are GlobalMapper .gmp files. I do quite a bit with shapefiles as well. Shapefiles have an associated .dbf database file that contains the attribute data. I have developed some complex techniques to manipulate this data with a relational database for doing things such as choosing line style/color/thickness based on zoom level, road density, etc.

I also use GlobalMapper for the raster imagery source files, either as .tif or .gmp files. For making maps for smartphones/tablets, I have a somewhat complicated workflow. I am running geoserver on my LAN and put my raster imagery into it. Geoserver is a very cool open source WMS server based on Java:

This lets me create the "layered raster maps" discussed earlier in this thread (maps with varying amount of detail based on zoom level. I then use Mobile Atlas Creator (another open source Java program) to build the map to use on the phone or tablet. The advantage here is that you can create maps in almost any format very easily:

Took me awhile to figure this all out, but now that it's working the system is very flexible and can create maps to for a variety of iOS and Android apps .


Excellent - great to know i'm on the right track!

I've been downloading 'vector' spatial data which happen to be ESRI shapefiles, which I now realise contain semi-populated .dbf files! This is definitely what i'm looking for.

However at this stage it seems as though i may have to 'reverse engineer' a vector layer from a bunch of raster files.  Is there a recommended workflow/software for that? 

As if i don't have enough homework from this thread already...  :o


You can do almost anything with the data in the .dbf files - delete fields, re-name them, add fields, change the data in the fields. Then you export it back to a file with the same name and it will replace the attributes in the original file(s).

But just remember, do NOT delete any records and do NOT change the sort order. The .dbf file must contain the same number of records in the same order as the original or it will not match up with the entities in the .shp file.

Don't really understand the part about reverse-engineering raster imagery. Do you want to just use it as a background and manually trace features for your map? Or do you actually want to use software to turn a raster image into polygons?

I do both of these regularly and just use GlobalMapper as it is well-suited for both. I'm sure there are open source alternatives, but I haven't looked for them.


Thanks again Boyd - VERY juicy info re. deleting records and/or changing sort order.  I'm glad you warned me.

I have a bunch of older raster maps which i'd like to join then trace the relevant historical features in order to create a new vector layer.  I expect it to take a while, but think it will be worth the effort.  I've only just started playing around in QGIS tonight and it looks promising.

If you say GlobalMapper has a 'raster to poly' type function i'll definitely give that a good look as any option to speed up the process would definitely be worth while.

EDIT: Googling "Digitizing Map Data" will turned up some really good tracing tutorials for QGIS.  Looks like the fun part is over - now i just need to put in the hours.