Help from the style file gurus
Hello list, Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected. The following are my style rules for trunk roads: #lines file excerpt: highway=trunk & (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk & oneway!=* [0x02 resolution 16 stop] highway=trunk & (oneway=yes | oneway=true) [0x123 resolution 16 stop] #overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10 Applying these rules results in one-way bridges having the bridge styling, but no one-way symbols (see attached screenshot; the fact that the railway is plotted on top of the bridge is quite another problem). Can a style guru point me towards where I'm going wrong? Question #2 =========== Does the stop/continue system work across style files? In other words, if I've got a polygon that is tagged: sport=tennis barrier=fence And in my style files I've got: #lines barrier=fence [0x2d resolution 23 default_name 'Fence'] #polygons sport=* [0x19 resolution 23] mkgmap by default will process the lines file first and plot the fence. It will not then process the polygons file, so all I see in the resulting map is a fence. Can I use continue/stop (once I've learned how to use it properly) to plot both the fence and the area? Thanks, -- Charlie
Bump...has no-one else managed to solve how to represent one-way bridges? Charlie Ferrero wrote:
Hello list,
Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected.
The following are my style rules for trunk roads:
#lines file excerpt: highway=trunk & (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk & oneway!=* [0x02 resolution 16 stop] highway=trunk & (oneway=yes | oneway=true) [0x123 resolution 16 stop]
#overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10
Applying these rules results in one-way bridges having the bridge styling, but no one-way symbols (see attached screenshot; the fact that the railway is plotted on top of the bridge is quite another problem).
Can a style guru point me towards where I'm going wrong?
Question #2 =========== Does the stop/continue system work across style files? In other words, if I've got a polygon that is tagged: sport=tennis barrier=fence
And in my style files I've got: #lines barrier=fence [0x2d resolution 23 default_name 'Fence'] #polygons sport=* [0x19 resolution 23]
mkgmap by default will process the lines file first and plot the fence. It will not then process the polygons file, so all I see in the resulting map is a fence. Can I use continue/stop (once I've learned how to use it properly) to plot both the fence and the area?
Thanks,
-- Charlie
Charlie Ferrero schrieb am 02.01.2010 15:44:
Bump...has no-one else managed to solve how to represent one-way bridges?
In my style it is working ok to represent both bridges and oneway symbols at the same time. As far as I can see, your style also looks ok. Perhaps you can try one things, for finding the problem: 1. Enlarge your oneway symbol, so that it will be visible when the trunk is drawn on top of it. Rigth now I can not tell, whether the oneway symbol is not created at all, or whether the draw ordering is not working as expected.
Question #2 =========== Does the stop/continue system work across style files?
As far as I know, mkgmap will only create a polygon or a line from a single element. But my knowledge might be outdated. To bypass such a problem I use multiple layers in my map. In the lower layer I draw all polygons, and in an upper layer I can draw the lines without any interferrence. Gruss Torsten
On 02.01.2010 15:44, Charlie Ferrero wrote:
Bump...has no-one else managed to solve how to represent one-way bridges?
Charlie Ferrero wrote:
Hello list,
Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected.
The following are my style rules for trunk roads:
#lines file excerpt: highway=trunk& (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk& oneway!=* [0x02 resolution 16 stop] highway=trunk& (oneway=yes | oneway=true) [0x123 resolution 16 stop]
#overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10
This code is rubbish (or 10x more complicated then needed).
Use instead: highway=trunk& (bridge=yes | bridge=true) [0x12 resolution 16 continue] highway=trunk& (oneway=yes | oneway=true) [0x10 resolution 16 continue] highway=trunk [0x02 resolution 16]
Applying these rules results in one-way bridges having the bridge styling, but no one-way symbols (see attached screenshot; the fact that the railway is plotted on top of the bridge is quite another problem).
There is no possibility to influence what line is drawn on top of another. Also Mapsource does it in the opposite order to many (but not all ) GPS units.
Can a style guru point me towards where I'm going wrong?
Question #2 =========== Does the stop/continue system work across style files? In other words, if I've got a polygon that is tagged: sport=tennis barrier=fence
And in my style files I've got: #lines barrier=fence [0x2d resolution 23 default_name 'Fence'] #polygons sport=* [0x19 resolution 23]
mkgmap by default will process the lines file first and plot the fence. It will not then process the polygons file, so all I see in the resulting map is a fence. Can I use continue/stop (once I've learned how to use it properly) to plot both the fence and the area?
Yes, but be careful. You will get many duplicate polygons if you don't severly watch out.
Thanks,
Felix Hartmann wrote:
On 02.01.2010 15:44, Charlie Ferrero wrote:
Bump...has no-one else managed to solve how to represent one-way bridges?
Charlie Ferrero wrote:
Hello list,
Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected.
The following are my style rules for trunk roads:
#lines file excerpt: highway=trunk& (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk& oneway!=* [0x02 resolution 16 stop] highway=trunk& (oneway=yes | oneway=true) [0x123 resolution 16 stop]
#overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10
This code is rubbish (or 10x more complicated then needed).
Use instead:
highway=trunk& (bridge=yes | bridge=true) [0x12 resolution 16 continue] highway=trunk& (oneway=yes | oneway=true) [0x10 resolution 16 continue] highway=trunk [0x02 resolution 16]
Thanks for the suggestion. Unfortunately it doesn't work properly (see screenshots) but it has helped me figure out what's going wrong: even though the continue keyword is there, the rule matching seems to stop at the first match. I am using mkgmap r1455 - is there some command switch that I've missed that I must use to get continue to work properly? -- Charlie
On 03.01.2010 11:20, Charlie Ferrero wrote:
Felix Hartmann wrote:
On 02.01.2010 15:44, Charlie Ferrero wrote:
Bump...has no-one else managed to solve how to represent one-way bridges?
Charlie Ferrero wrote:
Hello list,
Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected.
The following are my style rules for trunk roads:
#lines file excerpt: highway=trunk& (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk& oneway!=* [0x02 resolution 16 stop] highway=trunk& (oneway=yes | oneway=true) [0x123 resolution 16 stop]
#overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10
This code is rubbish (or 10x more complicated then needed).
Use instead:
highway=trunk& (bridge=yes | bridge=true) [0x12 resolution 16 continue] highway=trunk& (oneway=yes | oneway=true) [0x10 resolution 16 continue] highway=trunk [0x02 resolution 16]
Thanks for the suggestion. Unfortunately it doesn't work properly (see screenshots) but it has helped me figure out what's going wrong: even though the continue keyword is there, the rule matching seems to stop at the first match.
I am using mkgmap r1455 - is there some command switch that I've missed that I must use to get continue to work properly?
ups, switch it around. make bridge=yes & highway=trunk; oneway=yes & highway=trunk .....
Felix Hartmann wrote:
On 03.01.2010 11:20, Charlie Ferrero wrote:
Felix Hartmann wrote:
On 02.01.2010 15:44, Charlie Ferrero wrote:
Bump...has no-one else managed to solve how to represent one-way bridges?
Charlie Ferrero wrote:
Hello list,
Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected.
The following are my style rules for trunk roads:
#lines file excerpt: highway=trunk& (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk& oneway!=* [0x02 resolution 16 stop] highway=trunk& (oneway=yes | oneway=true) [0x123 resolution 16 stop]
#overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10
This code is rubbish (or 10x more complicated then needed).
Use instead:
highway=trunk& (bridge=yes | bridge=true) [0x12 resolution 16 continue] highway=trunk& (oneway=yes | oneway=true) [0x10 resolution 16 continue] highway=trunk [0x02 resolution 16]
Thanks for the suggestion. Unfortunately it doesn't work properly (see screenshots) but it has helped me figure out what's going wrong: even though the continue keyword is there, the rule matching seems to stop at the first match.
I am using mkgmap r1455 - is there some command switch that I've missed that I must use to get continue to work properly?
ups, switch it around. make bridge=yes & highway=trunk; oneway=yes & highway=trunk .....
Thank you Felix, this works! -- Charlie
Quoting Charlie Ferrero <charlie@cferrero.net>:
Felix Hartmann wrote:
On 03.01.2010 11:20, Charlie Ferrero wrote:
Felix Hartmann wrote:
On 02.01.2010 15:44, Charlie Ferrero wrote:
Bump...has no-one else managed to solve how to represent one-way bridges?
Charlie Ferrero wrote:
Hello list,
Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected.
The following are my style rules for trunk roads:
#lines file excerpt: highway=trunk& (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk& oneway!=* [0x02 resolution 16 stop] highway=trunk& (oneway=yes | oneway=true) [0x123 resolution 16 stop]
#overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10
This code is rubbish (or 10x more complicated then needed).
Use instead:
highway=trunk& (bridge=yes | bridge=true) [0x12 resolution 16 continue] highway=trunk& (oneway=yes | oneway=true) [0x10 resolution 16 continue] highway=trunk [0x02 resolution 16]
Thanks for the suggestion. Unfortunately it doesn't work properly (see screenshots) but it has helped me figure out what's going wrong: even though the continue keyword is there, the rule matching seems to stop at the first match.
I am using mkgmap r1455 - is there some command switch that I've missed that I must use to get continue to work properly?
ups, switch it around. make bridge=yes & highway=trunk; oneway=yes & highway=trunk .....
Thank you Felix, this works!
--
Incidentally, could you explain why the tag order matters? -- Charlie
Charlie Ferrero escribió:
Felix Hartmann wrote:
On 03.01.2010 11:20, Charlie Ferrero wrote:
Felix Hartmann wrote:
On 02.01.2010 15:44, Charlie Ferrero wrote:
Bump...has no-one else managed to solve how to represent one-way bridges?
Charlie Ferrero wrote:
Hello list,
Question #1 =========== I am using the overlays style file in combination with a TYP file to define custom styles for one-way streets (overlaid blue arrows in the direction of the one-way, type 0x10), and for bridges (two parallel lines outside the road, type 0x12). This all works fine. Where I'm stuck is when I have a one-way street that is also a bridge. I had assumed that the stop/continue system would help me here, but sadly it doesn't work as I expected.
The following are my style rules for trunk roads:
#lines file excerpt: highway=trunk& (bridge=yes | bridge=true) [0x111 resolution 16 continue] highway=trunk& oneway!=* [0x02 resolution 16 stop] highway=trunk& (oneway=yes | oneway=true) [0x123 resolution 16 stop]
#overlays file excerpt: 0x111: 0x02, 0x12 0x123: 0x02, 0x10
This code is rubbish (or 10x more complicated then needed).
Use instead:
highway=trunk& (bridge=yes | bridge=true) [0x12 resolution 16 continue] highway=trunk& (oneway=yes | oneway=true) [0x10 resolution 16 continue] highway=trunk [0x02 resolution 16]
Thanks for the suggestion. Unfortunately it doesn't work properly (see screenshots) but it has helped me figure out what's going wrong: even though the continue keyword is there, the rule matching seems to stop at the first match.
I am using mkgmap r1455 - is there some command switch that I've missed that I must use to get continue to work properly?
ups, switch it around. make bridge=yes & highway=trunk; oneway=yes & highway=trunk .....
Thank you Felix, this works!
I've also been trying to get bridges drawn on my maps, but they are not working in MapSource (look fine in gps). I have used both overlays and continue approaches, but none of them gives good result in MapSource (6.13.7). I've been comparing my maps with openmtb-spain map (thines.typ) from Felix, which shows nice bridges in MapSource and I have almost the same definition for bridges on typ file, i.e. color mode 6-1 common color (line only or transparent bitmap), rendering of slanted lines skewing, extended labels, no custom colors, no label (invisible). The only differences are bitmap height and line color, which I think should not have any effect on the matter. Also Charlie's TYP file has similar bridges definition. For the overlays, lines styles file used has the following rules: (bridge=yes | bridge=true) & highway=motorway [0x121 road_class=4 road_speed=6 resolution 12] (bridge=yes | bridge=true) & highway=trunk [0x122 road_class=3 road_speed=5 resolution 16] (bridge=yes | bridge=true) & highway=primary [0x123 road_class=3 road_speed=5 resolution 18] (bridge=yes | bridge=true) & highway=secondary [0x124 road_class=2 road_speed=4 resolution 20] (bridge=yes | bridge=true) & highway=tertiary [0x125 road_class=1 road_speed=3 resolution 20] and the overlays: 0x121: 0x01, 0x2c 0x122: 0x02, 0x2d 0x123: 0x03, 0x2d 0x124: 0x04, 0x2d 0x125: 0x05, 0x2e For the "continue" approach I've used these rules: (bridge=yes | bridge=true) & highway=motorway [0x2c resolution 12 continue] highway=motorway & (maxspeed>129 | maxspeed=none) [0x01 road_class=4 road_speed=7 resolution 12] highway=motorway & maxspeed>100 [0x01 road_class=4 road_speed=6 resolution 12] highway=motorway & maxspeed>80 [0x01 road_class=4 road_speed=5 resolution 12] highway=motorway & maxspeed>60 [0x01 road_class=3 road_speed=4 resolution 12] highway=motorway & maxspeed<61 [0x01 road_class=3 road_speed=3 resolution 12] highway=motorway [0x01 road_class=4 road_speed=6 resolution 12] Have you any clue how to get my bridges drawn in MapSource? What am I doing wrong? Regards, Carlos
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead.
Quoting Felix Hartmann <extremecarver@googlemail.com>:
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead.
Different versions of MapSource also behave differently. Since upgrading to the latest version, I cannot get it to plot bridge/tunnel casings at all, but it worked fine on the older version. Unfortunately there seems to be no way to download old versions of MapSource from the Garmin website. In any case, the plotting speed is immensely faster in the most recent version (almost instant), so I'm reluctant to downgrade just to be able to visualise bridges again. I've also noticed that MapSource plots overlays as *underlays*, whereas the GPS properly plots them as overlays. So my one-way arrows appear *underneath* the road in MapSource, but on top of the road in the GPS. Very annoying! -- Charlie
On 20.01.2010 16:54, charlie@cferrero.net wrote:
Quoting Felix Hartmann<extremecarver@googlemail.com>:
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead.
Different versions of MapSource also behave differently. Since upgrading to the latest version, I cannot get it to plot bridge/tunnel casings at all, but it worked fine on the older version.
Then don't use crap ids in the range 0x2b-0x3f. Use extened ones instead.
Unfortunately there seems to be no way to download old versions of MapSource from the Garmin website. In any case, the plotting speed is immensely faster in the most recent version (almost instant), so I'm reluctant to downgrade just to be able to visualise bridges again.
I've also noticed that MapSource plots overlays as *underlays*, whereas the GPS properly plots them as overlays. So my one-way arrows appear *underneath* the road in MapSource, but on top of the road in the GPS. Very annoying!
That has allways been the case. Mapsource draws maps from bottom to top (because of this lines can disappear behind polygons), GPS first draws polygons top to bottom (respecting Draw order of course), then lines top to bottom, then POI top to bottom. It is annoying, but I don't think it will ever be changed. For me old Mapsource versions are much much faster (except if you stuff up your map with too many objects). New versions do cache an image, and once cached it is instantaneous. Before it's cached, it's much much slower. Also newer mapsource displays projection fixed to the equator, which sucks the more north/south you get. Older Mapsource versions are available from gawisp.com (perry archive).
On 20/01/2010 16:02, Felix Hartmann wrote:
On 20.01.2010 16:54, charlie@cferrero.net wrote:
Quoting Felix Hartmann<extremecarver@googlemail.com>:
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead.
Different versions of MapSource also behave differently. Since upgrading to the latest version, I cannot get it to plot bridge/tunnel casings at all, but it worked fine on the older version.
Then don't use crap ids in the range 0x2b-0x3f. Use extened ones instead.
I don't! I use 0x11, 0x12, 0x13 and 0x17. These don't appear in MapSource (6.15.6) but they appeared fine in the earlier version I had installed (which, however, had horifically slow drawing speed). I might try using extended types and see if that makes any difference and/or switching to 6.13.7 as you've recommended elsewhere.
On 20.01.2010 20:50, Charlie Ferrero wrote:
On 20/01/2010 16:02, Felix Hartmann wrote:
On 20.01.2010 16:54, charlie@cferrero.net wrote:
Quoting Felix Hartmann<extremecarver@googlemail.com>:
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead.
Different versions of MapSource also behave differently. Since upgrading to the latest version, I cannot get it to plot bridge/tunnel casings at all, but it worked fine on the older version.
Then don't use crap ids in the range 0x2b-0x3f. Use extened ones instead.
I don't! I use 0x11, 0x12, 0x13 and 0x17. These don't appear in MapSource (6.15.6) but they appeared fine in the earlier version I had installed (which, however, had horifically slow drawing speed). I might try using extended types and see if that makes any difference and/or switching to 6.13.7 as you've recommended elsewhere.
0x17 does not display either. 0x11-0x13 do display for me in any crapsource version.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann escribió:
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead. Great! At last I can have bridges on my maps. I've used 0x10600-2 and they show both on 6.13.7 and 6.15.6, but they are much better rendered on 6.13.7. On 6.15.6 they appear too thin and a bit difficult to see.
On 21.01.2010 11:00, Carlos Dávila wrote:
Felix Hartmann escribió:
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead.
Great! At last I can have bridges on my maps. I've used 0x10600-2 and they show both on 6.13.7 and 6.15.6, but they are much better rendered on 6.13.7. On 6.15.6 they appear too thin and a bit difficult to see.
Ups, don't use 6.15.6, but update to 6.15.7. 6.15.6 is complete junk when it comes to layout.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann escribió:
On 21.01.2010 11:00, Carlos Dávila wrote:
Felix Hartmann escribió:
You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead.
Great! At last I can have bridges on my maps. I've used 0x10600-2 and they show both on 6.13.7 and 6.15.6, but they are much better rendered on 6.13.7. On 6.15.6 they appear too thin and a bit difficult to see.
Ups, don't use 6.15.6, but update to 6.15.7. 6.15.6 is complete junk when it comes to layout. Updated. Thanks, you are always sharing good information.
On 20.01.2010 16:37, Carlos Dávila wrote:
Have you any clue how to get my bridges drawn in MapSource? What am I doing wrong?
Are the "mapname" numbers of the overlay imgs bigger than the ones of the lower layers? Mapsource seems to not care about the draw priority. It draws in the order of the mapnames instead.
Ralf Kleineisel escribió:
On 20.01.2010 16:37, Carlos Dávila wrote:
Have you any clue how to get my bridges drawn in MapSource? What am I doing wrong?
Are the "mapname" numbers of the overlay imgs bigger than the ones of the lower layers? Mapsource seems to not care about the draw priority. It draws in the order of the mapnames instead. I'm working with just one layer. I solved the issue changing bridges type in style to 0x10600. Regards, Carlos
participants (6)
-
Carlos Dávila -
Charlie Ferrero -
charlie＠cferrero.net
-
Felix Hartmann -
Ralf Kleineisel -
Torsten Leistikow