<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML ChildAreas="4" xmlns:canvas><HEAD>
<META content="text/html; charset=unicode" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.23588"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="false"
name="Compose message area">
<DIV
style="PADDING-BOTTOM: 2px; PADDING-LEFT: 7px; WIDTH: 100%; PADDING-RIGHT: 5px; PADDING-TOP: 2px">
<DIV>Yes I have understand your suggestion. And created a small SanIsidro.osm.
Inside are only 2 ways, tagged as bridge=yes and layer=1. This 2 ways are placed
at the end of osm.file. Then created a map with option --preserve-element-order
. But it looks wrong. I maked 2. test : have changed the 0x1 and 0xc.
Result is : 0x1 is drawn over 0xc.</DIV>
<DIV>So I assume , it is hardcoded.</DIV>
<DIV> </DIV></DIV><SPAN contentEditable=false><SPAN style="DISPLAY: block"
layoutEmptyTextWellFont="Tahoma" xmlns:canvas="canvas-namespace-id"><SPAN
style="DISPLAY: block; MARGIN-BOTTOM: 15px; HEIGHT: 19px; OVERFLOW: visible"></SPAN><SPAN
style="DISPLAY: inline-block; MARGIN-BOTTOM: 25px; HEIGHT: 241px; VERTICAL-ALIGN: top; OVERFLOW: visible; MARGIN-RIGHT: 25px">
<TABLE style="HEIGHT: 241px">
<TBODY>
<TR>
<TD>
<DIV style="WIDTH: 215px; HEIGHT: 215px; OVERFLOW: hidden"><IMG
style="MARGIN-TOP: 21px; DISPLAY: inline-block; MARGIN-LEFT: 0px" border=0
src="cid:D774A55636BF4B80AC8D30E95AF492A5@dell" width=215
height=172></DIV></TD></TR>
<TR>
<TD>
<DIV
style="TEXT-ALIGN: center; WIDTH: 215px; FONT-FAMILY: verdana; FONT-SIZE: 10pt"><FONT
face=Arial>Thomas</FONT></DIV></TD></TR></TBODY></TABLE></SPAN></SPAN></SPAN>
<DIV
style="PADDING-BOTTOM: 2px; PADDING-LEFT: 7px; WIDTH: 100%; PADDING-RIGHT: 5px; HEIGHT: 50px; PADDING-TOP: 2px">
<DIV><BR><BR>--------------------------------------------------<BR>Von: "Gerd
Petermann" <gpetermann_muenchen@hotmail.com><BR>Datum: Sonntag, 25.
Februar 2018 19:03<BR>An: "Thomas Morgenstern" <webmaster@img2ms.de>;
"Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk><BR>Betreff:
Re: [mkgmap-dev] Wrong rendering Layer=1<BR><BR>> Hi Thomas,<BR>> <BR>>
what I wanted to suggest is to use --preserve-element-order and change the order
of the two ways in the osm file.<BR>> Without --preserve-element-order the
order is not predictable, but might be the same as with<BR>> the
option.<BR>> <BR>> Gerd<BR>> <BR>>
________________________________________<BR>> Von: mkgmap-dev
<mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern
<webmaster@img2ms.de><BR>> Gesendet: Sonntag, 25. Februar 2018
19:48:50<BR>> An: Development list for mkgmap<BR>> Betreff: Re:
[mkgmap-dev] Wrong rendering Layer=1<BR>> <BR>> Hi Gerd, i have tested now
--preserve-element-order . You are right. This<BR>> does not help. The result
is similar to without --preserve-element-order.<BR>> thomas<BR>> <BR>>
--------------------------------------------------<BR>> Von: "Gerd Petermann"
<gpetermann_muenchen@hotmail.com><BR>> Datum: Sonntag, 25. Februar 2018
18:17<BR>> An: "Thomas Morgenstern" <webmaster@img2ms.de>; "Development
list for<BR>> mkgmap" <mkgmap-dev@lists.mkgmap.org.uk><BR>> Betreff:
Re: [mkgmap-dev] Wrong rendering Layer=1<BR>> <BR>>> Hi
Thomas,<BR>>><BR>>> my understanding is that this was already tried
in the past, without<BR>>> success.<BR>>> You can test it with a
test osm file containing only two ways. When you<BR>>> use<BR>>>
--preserve-element-order mkgmap should write them in the order of<BR>>>
the OSM file. It is better to use a small file for those tests so that
all<BR>>> data<BR>>> fits into one sub
division.<BR>>><BR>>> It might well be possible that Garmin software
has a hard coded draw order<BR>>> for<BR>>> specific line types. As
Arndt already mentioned this is the case for<BR>>>
0x01..0x03.<BR>>><BR>>> Gerd<BR>>><BR>>>
________________________________________<BR>>> Von: mkgmap-dev
<mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von<BR>>> Thomas
Morgenstern <webmaster@img2ms.de><BR>>> Gesendet: Sonntag, 25.
Februar 2018 18:10:24<BR>>> An: Development list for mkgmap<BR>>>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1<BR>>><BR>>> Some
time ago we have introduced the teature 'order-by-decreasing-area'.<BR>>>
Maybee a similar arangement helps. Order all lines ,(related to
streets)<BR>>> in range of layer . Highest layer at last ?<BR>>>
thomas<BR>>><BR>>>
--------------------------------------------------<BR>>> Von: "Gerd
Petermann" <gpetermann_muenchen@hotmail.com><BR>>> Datum: Sonntag,
25. Februar 2018 16:50<BR>>> An: "Thomas Morgenstern"
<webmaster@img2ms.de>; "Development list for<BR>>> mkgmap"
<mkgmap-dev@lists.mkgmap.org.uk><BR>>> Betreff: Re: [mkgmap-dev]
Wrong rendering Layer=1<BR>>><BR>>>> Hi
Arndt,<BR>>>><BR>>>> many OSM applications evaluate tags like
bridge and layer.<BR>>>> The default style doesn't even evaluate bridge
or layer, since we don't<BR>>>> know a way to tell Garmin software a
draw order<BR>>>> of lines. This is just a special problem with the
(old) Garmin img<BR>>>> format.<BR>>>> Maybe there is a way to
change the draw order, if you have an idea,<BR>>>>
please<BR>>>> let us know.<BR>>>><BR>>>>
Gerd<BR>>>><BR>>>>
________________________________________<BR>>>> Von: mkgmap-dev
<mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von<BR>>>>
Thomas Morgenstern <webmaster@img2ms.de><BR>>>> Gesendet:
Sonntag, 25. Februar 2018 17:25:08<BR>>>> An: Development list for
mkgmap<BR>>>> Betreff: Re: [mkgmap-dev] Wrong rendering
Layer=1<BR>>>><BR>>>> I am wondering, why we write tag=bridge
and tag layer=anywhat, when<BR>>>> mkgamp<BR>>>> does ignore
bridge=yes and layer=1. All the work, to tset this tag is<BR>>>>
seenless.?<BR>>>> thomas<BR>>>><BR>>>> Von: Arndt
Röhrig<mailto:arndt@speichenkarte.de><BR>>>> Datum: Sonntag, 25.
Februar 2018 14:52<BR>>>> An: Development list for
mkgmap<mailto:mkgmap-dev@lists.mkgmap.org.uk><BR>>>> Betreff: Re:
[mkgmap-dev] Wrong rendering
Layer=1<BR>>>><BR>>>><BR>>>>
Hi,<BR>>>><BR>>>> imho there is no draw prio possible with
lines. Solid has no effect. Only<BR>>>> typ 0x01, 0x02, 0x03 and
perhaps 0x04 will be draw always over the other<BR>>>> lines. I used it
for one-way-arrows.<BR>>>><BR>>>>
Arndt<BR>>>><BR>>>> "osm@pinns<mailto:osm@pinns>"
<osm@pinns.co.uk<mailto:osm@pinns.co.uk>><BR>>>> hat am 25.
Februar 2018 um 15:21
geschrieben:<BR>>>><BR>>>><BR>>>>
Hi<BR>>>><BR>>>> Layering of lines does not seem to be
supported by Garmin - I have seen<BR>>>> many Topos where bridges are
completely ignored.<BR>>>><BR>>>> Using a TYP file you can
often force lines to have a draworder by making<BR>>>> them solid -
solid has often a higher draworder than lines with
bitmaps.<BR>>>><BR>>>> I'm not sure whether placing a
line at the end of a 'lines' block in<BR>>>>
the<BR>>>> RGN would ensure it will be parsed
last.<BR>>>><BR>>>> Nick<BR>>>><BR>>>> On
25/02/2018 13:15, Thomas Morgenstern
wrote:<BR>>>><BR>>>><BR>>>> Hi , maybee I found a bug
in rendering layer's. I have prepared a small<BR>>>>
SanIsidro.osm.pbf and the resulting gmap with FID 982, created
with<BR>>>> mkgmap-r4127, Download :<BR>>>>
http:\\img2ms.de/Downloads\WrongLayerSanIsidro.rar .<BR>>>> The error
is, that the highway ID=217.806.076 is rendered over the bridge<BR>>>>
ID=65.208.316. Bridge has tag bridge=yes and originaly layer=1. I
tried<BR>>>> layer=2, but it makes no different, it should bee
rendered over the<BR>>>> highway, This wrong rendering
happens in may cases related to TF-1 in<BR>>>>
tenerife.<BR>>>>
[cid:793096B291174F75AFA2407BB062C915@dell]<BR>>>><BR>>>> any
idees to resolve this in stylefile ?<BR>>>>
thomas<BR>>>><BR>>>><BR>>>>
________________________________<BR>>>>
_______________________________________________<BR>>>> mkgmap-dev
mailing list<BR>>>>
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><BR>>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>>><BR>>>><BR>>>><BR>>>>
_______________________________________________<BR>>>> mkgmap-dev
mailing list<BR>>>>
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><BR>>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>>><BR>>>><BR>>>><BR>>>>
_______________________________________________<BR>>>> mkgmap-dev
mailing list<BR>>>> mkgmap-dev@lists.mkgmap.org.uk<BR>>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>>><BR>>>><BR>>>><BR>>>>
________________________________<BR>>>><BR>>>>
_______________________________________________<BR>>>> mkgmap-dev
mailing list<BR>>>> mkgmap-dev@lists.mkgmap.org.uk<BR>>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>>><BR>>><BR>>><BR>>><BR>>>>
_______________________________________________<BR>>>> mkgmap-dev
mailing list<BR>>>> mkgmap-dev@lists.mkgmap.org.uk<BR>>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>><BR>>>
_______________________________________________<BR>>> mkgmap-dev mailing
list<BR>>> mkgmap-dev@lists.mkgmap.org.uk<BR>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>>
_______________________________________________<BR>>> mkgmap-dev mailing
list<BR>>> mkgmap-dev@lists.mkgmap.org.uk<BR>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>><BR>>
_______________________________________________<BR>> mkgmap-dev mailing
list<BR>> mkgmap-dev@lists.mkgmap.org.uk<BR>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<BR>>
_______________________________________________<BR>> mkgmap-dev mailing
list<BR>> mkgmap-dev@lists.mkgmap.org.uk</DIV></DIV></BODY></HTML>