[mkgmap-dev] Wrong rendering Layer=1

Sun Feb 25 19:31:10 GMT 2018

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.
So I assume , it is hardcoded.

      Thomas 

--------------------------------------------------
Von: "Gerd Petermann" <gpetermann_muenchen at hotmail.com>
Datum: Sonntag, 25. Februar 2018 19:03
An: "Thomas Morgenstern" <webmaster at img2ms.de>; "Development list for mkgmap" <mkgmap-dev at lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1

> Hi Thomas,
> 
> what I wanted to suggest is to use --preserve-element-order and change the order of the two ways in the osm file.
> Without --preserve-element-order the order is not predictable, but might be the same as with
> the option.
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern <webmaster at img2ms.de>
> Gesendet: Sonntag, 25. Februar 2018 19:48:50
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
> 
> Hi Gerd, i have tested now --preserve-element-order . You are right. This
> does not help. The result is similar to without --preserve-element-order.
> thomas
> 
> --------------------------------------------------
> Von: "Gerd Petermann" <gpetermann_muenchen at hotmail.com>
> Datum: Sonntag, 25. Februar 2018 18:17
> An: "Thomas Morgenstern" <webmaster at img2ms.de>; "Development list for
> mkgmap" <mkgmap-dev at lists.mkgmap.org.uk>
> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
> 
>> Hi Thomas,
>>
>> my understanding is that this was already tried in the past, without
>> success.
>> You can test it with a test osm file containing only two ways. When you
>> use
>> --preserve-element-order mkgmap should write them in the order of
>> the OSM file. It is better to use a small file for those tests so that all
>> data
>> fits into one sub division.
>>
>> It might well be possible that Garmin software has a hard coded draw order
>> for
>> specific line types. As Arndt already mentioned this is the case for
>> 0x01..0x03.
>>
>> Gerd
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
>> Thomas Morgenstern <webmaster at img2ms.de>
>> Gesendet: Sonntag, 25. Februar 2018 18:10:24
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
>>
>> Some time ago we have introduced the teature 'order-by-decreasing-area'.
>> Maybee a similar arangement  helps. Order all  lines ,(related to streets)
>> in range of layer . Highest layer at last ?
>> thomas
>>
>> --------------------------------------------------
>> Von: "Gerd Petermann" <gpetermann_muenchen at hotmail.com>
>> Datum: Sonntag, 25. Februar 2018 16:50
>> An: "Thomas Morgenstern" <webmaster at img2ms.de>; "Development list for
>> mkgmap" <mkgmap-dev at lists.mkgmap.org.uk>
>> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
>>
>>> Hi Arndt,
>>>
>>> many OSM applications evaluate tags like bridge and layer.
>>> The default style doesn't even evaluate bridge or layer, since we don't
>>> know a way to tell Garmin software a draw order
>>> of lines. This is just a special problem with the (old) Garmin img
>>> format.
>>> Maybe there is a way to change the draw order, if you have an idea,
>>> please
>>> let us know.
>>>
>>> Gerd
>>>
>>> ________________________________________
>>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
>>> Thomas Morgenstern <webmaster at img2ms.de>
>>> Gesendet: Sonntag, 25. Februar 2018 17:25:08
>>> An: Development list for mkgmap
>>> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
>>>
>>> I am wondering, why we write tag=bridge and tag layer=anywhat, when
>>> mkgamp
>>> does ignore bridge=yes and layer=1. All the work, to tset this tag is
>>> seenless.?
>>> thomas
>>>
>>> Von: Arndt Röhrig<mailto:arndt at speichenkarte.de>
>>> Datum: Sonntag, 25. Februar 2018 14:52
>>> An: Development list for mkgmap<mailto:mkgmap-dev at lists.mkgmap.org.uk>
>>> Betreff: Re: [mkgmap-dev] Wrong rendering Layer=1
>>>
>>>
>>> Hi,
>>>
>>> imho there is no draw prio possible with lines. Solid has no effect. Only
>>> typ 0x01, 0x02, 0x03 and perhaps 0x04 will be draw always over the other
>>> lines. I used it for one-way-arrows.
>>>
>>> Arndt
>>>
>>> "osm at pinns<mailto:osm at pinns>" <osm at pinns.co.uk<mailto:osm at pinns.co.uk>>
>>> hat am 25. Februar 2018 um 15:21 geschrieben:
>>>
>>>
>>> Hi
>>>
>>> Layering of lines does not seem to be supported by Garmin - I have seen
>>> many Topos where bridges are completely ignored.
>>>
>>> Using a TYP file you can often force lines to have a draworder by making
>>> them solid - solid has often a higher draworder than lines with bitmaps.
>>>
>>> I'm not sure whether placing a line  at  the end of a 'lines' block in
>>> the
>>> RGN would ensure it will be parsed last.
>>>
>>> Nick
>>>
>>> On 25/02/2018 13:15, Thomas Morgenstern wrote:
>>>
>>>
>>> Hi , maybee I found a bug in rendering layer's. I have prepared a small
>>> SanIsidro.osm.pbf  and the resulting gmap with FID 982, created with
>>> mkgmap-r4127, Download :
>>> http:\\img2ms.de/Downloads\WrongLayerSanIsidro.rar .
>>> The error is, that the highway ID=217.806.076 is rendered over the bridge
>>> ID=65.208.316. Bridge has tag bridge=yes and originaly layer=1. I tried
>>> layer=2, but it makes  no different, it should bee rendered  over the
>>> highway,  This wrong rendering happens in may cases related to TF-1 in
>>> tenerife.
>>> [cid:793096B291174F75AFA2407BB062C915 at dell]
>>>
>>> any idees to resolve this in stylefile ?
>>> thomas
>>>
>>>
>>> ________________________________
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>>
>>>
>>> ________________________________
>>>
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>
>>
>>
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20180225/213ef514/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7AA.jpg
Type: image/jpeg
Size: 13254 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20180225/213ef514/attachment-0001.jpg>