Does mkgmap or any other ‘converter’ preserve the ‘intermittent’ flag on waterways so that these can be identified (presumably using a typ file setting) in Garmin?
It depends on what you as the developer/compiler decide to put in for a style and what sort of line you put in your TYP file, usually a dashed blue line.
Thanks AlaskaDave,
I can do the typ file part (if I know the code{s} used for intermittent waterways), but I usually rely on one of the ‘automated’ service sites for the files with OSM data converted to garmin format (e.g. http://mapas.alternativaslibres.es/downloads.php)).
I can see in the cgsmapper manual that polyline code 0x26 is used for intermittent river. But is it also for intermittent stream?
It seems to me that the services I have tried are simply picking up river (0x1f) or stream (0x18) and not drilling down to the intermittent=yes tag (in OSM) to designate a different line code (for garmin).
I could ask them to include ‘whatever is needed’ to flag intermittent waterways, but that seems a bit vague. Can you (or anyone else more expert than a novice like me) give a more specific description of what to include in an OSM conversion style to give the capability to distinguish intermittent waterways (streams and rivers) from permanent ones in resulting garmin maps?
I have these rules in my lines style file:
waterway=river & natural!=water [0x18 resolution 18-20 continue]
waterway=river & natural!=water [0x1f resolution 21 continue]
waterway=canal & natural!=water [0x18 resolution 20-22 continue]
waterway=canal & natural!=water [0x1f resolution 24 continue]
waterway=stream & natural!=water [0x18 resolution 24 continue]
waterway=drain & natural!=water [0x18 resolution 24 continue]
waterway=* & intermittent=* [0x10017 resolution 18]
and the 0x10017 in my TYP file is a dashed blue line
Thanks AlaskaDave,
That is very helpful.
If I understand correctly, streams would only appear at the highest resolution (24 bits), but intermittent streams would appear at lower resolutions (from 18 bits up) - which seems strange to me so I probably have misunderstood.
Also, there is no way to distinguish between a river and a stream if they are intermittent, as both would use the same code 0x10017? (Rivers and streams are often set to have different line widths, when using codes 0x18 and 0x1f, at least in higher resolutions in your example).
Could one get around this using something like the example below?:
waterway=river [0x1f resolution 18 continue]
waterway=stream [0x18 resolution 20 continue]
waterway=river & intermittent=yes [0x26 resolution 20]
waterway=stream & intermittent=yes [0x10017 resolution 22]
Better try to use object 0x10A02 for intermittent streams, it works like 0x26 with proper default graphics and label.
Thanks popej,
Yes, it is much better to know and use the codes that will work with default graphics in garmin (no typ file): 0x10A02 for intermittent streams; 0x26 for intermittent rivers.
I have learned a lot in a short time (hopefully enough to ask for the rule to go in the styles used by those who provide the OSM ‘format conversion services’). I am much obliged to you and AlaskaDave for the information.
Looking a bit closer at zoom settings I used long ago (before OSM) to make hydrology and contour layers for my GPSr, a suitable suggestion might be:
waterway=river [0x1f resolution 18 continue]
waterway=stream [0x18 resolution 19 continue]
waterway=river & intermittent=yes [0x26 resolution 20]
waterway=stream & intermittent=yes [0x10A02 resolution 20]
I can’t help you about zoom levels. I only know enough about them to get into trouble. Those style rules I sent you were cobbled together from a bunch of sources and are in a constant state of change. I think popej is the one to pay attention to on this topic as he is way ahead of me. Not sure how my code for intermittent stream got to be 0x10017 - I changed it to 0x10A02.
I don’t have a special rule for intermittent rivers because I’ve yet to tag any.
In case it helps others, after some experimenting I found that the “continue” method puts the dashed lines over solid lines (hard to see if used with transparency), so it is better to use “!” in the style rule tests to exclude the intermittent streams from other streams.
Here is the text from my “lines” file within my simple waterway style:
waterway=river & intermittent!=yes [0x1f resolution 18]
waterway=stream & intermittent!=yes [0x18 resolution 19]
waterway=river & intermittent=yes [0x26 resolution 20]
waterway=stream & intermittent=yes [0x10A02 resolution 20]
Here is the corresponding typ file section (text version from TYPViewer):
[_line]
Type=0x18
;GRMN_TYPE: Water Features/STREAM/Small stream or creek/Non NT
UseOrientation=N
LineWidth=1
Xpm=“0 0 1 0”
“1 c #0095FF”
String1=0x04,stream
ExtendedLabels=N
[end]
[_line]
Type=0x1f
;GRMN_TYPE: Water Features/RIVER/Large stream or river/Non NT
UseOrientation=N
LineWidth=2
Xpm=“0 0 1 0”
“1 c #0095FF”
String1=0x04,river
ExtendedLabels=N
[end]
[_line]
Type=0x26
;GRMN_TYPE: Water Features/INTERMITTENT_STREAM/Intermittent or dry stream, creek, or ditch/Non NT
UseOrientation=N
Xpm=“32 2 2 1”
“! c #0095FF”
" c none"
"!!! !!! !!! !!! "
"!!! !!! !!! !!! "
;12345678901234567890123456789012
String1=0x00,river & intermittent=Yes
ExtendedLabels=N
[end]
[_line]
Type=0x10a02
;GRMN_TYPE: Water Features/INTERMITTENT_STREAM(NT)/Intermittent or dry stream, creek, or ditch/NT
UseOrientation=N
Xpm=“32 1 2 1”
“! c #0095FF”
" c none"
"!!! !!! !!! !!! "
;12345678901234567890123456789012
String1=0x04,stream & intermittent=Yes
ExtendedLabels=N
[end]
I was able to test this out (on osm data downloaded as test.osm) using mkgmap run from the following script:
java -Xmx1024m -ea -jar C:\Garmin\mkgmap\mkgmap.jar --mapname=17032016 --style-file=C:\Garmin\TYPs\Styles --style=Watr_Sty --output-dir=C:\Garmin\Maps\Temp C:\test.osm
then using MapSetToolKit (with transparency checked and a high draw priority because I wanted a waterways layer to put over other maps in my 60cx GPSr) to get the img file from mkgmap with the required typ settings into BaseCamp (from which it can be loaded into the GPSr).
It worked.
Rules are evaluated sequentially, you can simply use:
waterway=river & intermittent=yes [0x26 resolution 20]
waterway=river [0x1f resolution 18]
waterway=stream & intermittent=yes [0x10A02 resolution 20]
waterway=stream [0x18 resolution 19]
Thanks popej. Simpler is better. (I am on a steep part of the learning curve about mkgmap.)
One more note for novices like me: if your osm data file is too large, mkgmap will fail. The size depends on your system memory and settings, but for me using a netbook even 6900 kb was too large. It is easy to reach this file size if you combine data downloads (data layers) in JOSM, even if you limit the amount of downloaded data with filters built from waterway=* in the Overpass API server. Then you will need to use splitter before mkgmap. The scripts that worked for me were:
for splitter:
java -Xmx1024m -jar C:\Garmin\mkgmap\splitter-r429\splitter.jar C:\Temp\OSM\Waterways.osm --output-dir=C:\Temp\split > splitter.log
then for mkgmap:
java -Xmx1024m -ea -jar C:\Garmin\mkgmap\mkgmap.jar --mapname=17032016 --style-file=C:\Garmin\TYPs\Styles --style=Watr_Sty --output-dir=C:\Garmin\Maps\Temp -c C:\Temp\split\template.args
Of course you can adjust the available memory size (-XmX____m) and file paths to match those in your own computer.
Your netbook fails with a 6900 kilobyte file? That’s surprising.
I have been able to avoid using splitter by keeping the area I download relatively small. Even so I have been able to compile maps using .OSM files of about 600 Mb without problems. I have allocated an extra 1 Gb with the -XmX switch. My laptop has 8 Gb of ram and a fairly fast processor.
Hi AlaskaDave,
Yes, I am using a HP Mini5102 with just 2.0 GB RAM and an Intel Atom 1.66 GHz processor. Some people will say it is a miracle it still works at all! But even such a limited computer does the job just fine (with help from splitter on large datasets) using the scripts given above. As you say, it is generally even easier with more powerful computers.