Preservation of order not working
Hello! My application makes heavy use of a layering concept that puts items in a particular order so they are drawn on top of each other on the garmin. This is used to draw bridges/tunnels in the proper order and to construct composite elements by overlaying multiple lines or icons in a particular order. Versions of mkgamp up to 590 did maintain the order of elements, in later versions the order was random due to use of a hash map, then maintaining the order was restored - theoretically. I now tried to migrate my application to work with current versions of mkgmap, but the drawing order still does not correspond to the order in the input osm file. In the particular use case I attempt to create markings for hiking trails by drawing a symbol (e.g. yellow cross) on top of a background (white rectangle). I double-checked the OSM input file, all the background nodes are in the file before any of the symbol nodes. In the output, the symbols are drawn correctly on top or hidden behind the white rectangles at random. The effect is the same in MapSource and on the device. The same symbol/background combinations are sometimes drawn properly and sometimes in reverse order. I have attached two images showing the good and broken case on two neighboring nodes. From the tooltips in Mapsource you can see the inverted order of foreground and background in the broken case. I have checked this with mkgmap r858 and r935, both with identical results. The last version this works completely is r590. Ways seem to be ok, at least I could see no problems there during my first tests. Is it possible that the fix only applies to ways but not tod nodes? bye Nop
Hi Nop, Please try attached patch - it should preserve the order of the nodes and ways. Cheers, Mark
Can other people please test this patch and report success/failure or if it make a noticeable difference to processing speed and/or space required. Thanks, Mark
Mark Burton wrote:
Can other people please test this patch and report success/failure or if it make a noticeable difference to processing speed and/or space required.
Thanks,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I can't comment on order but running great_britain.osm against a patched r942 completed without error. Cheers Paul
Hi Paul,
I can't comment on order but running great_britain.osm against a patched r942 completed without error.
Thanks, that's good to know. Sorry about the inter-tile routing problems. How big is the gmapsupp.img you are using? If it's not too large (< 15MB after zipping), please email to me directly. Or, if it is large, can you make a cut down version? Cheers, Mark
Sorry about the inter-tile routing problems.
How big is the gmapsupp.img you are using? If it's not too large (< 15MB after zipping), please email to me directly. Or, if it is large, can you make a cut down version?
No, its to large. It has 57MB at the moment. I'll try to generate a cut down version of the problem.
Mark Burton wrote:
Hi Paul,
I can't comment on order but running great_britain.osm against a patched r942 completed without error.
Thanks, that's good to know.
Sorry about the inter-tile routing problems.
How big is the gmapsupp.img you are using? If it's not too large (< 15MB after zipping), please email to me directly. Or, if it is large, can you make a cut down version?
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
This is a cut down version of the map created in the following way. I split england.osm which produced the attached areas.list. I then ran java -Xmx2048M -jar mkgmap.jar --gmapsupp --route --latin1 60000004.osm 60000005.osm to produce the gmapsupp at http://osm.pointdee.co.uk/files/gmapsupp.img.2 (rename to remove the .2) I've tested this against my 605 and it gives the same results as previously described Paul # List of areas # Generated Fri Feb 27 22:43:03 GMT 2009 # 60000001: 0x233800,0xfffb6800 to 0x252000,0xffff4800 # : 49.526367,-6.459961 to 52.207031,-1.010742 60000002: 0x233800,0xffff4800 to 0x24a000,0x17800 # : 49.526367,-1.010742 to 51.503906,2.065430 60000003: 0x24a000,0xffff4800 to 0x252000,0x17800 # : 51.503906,-1.010742 to 52.207031,2.065430 60000004: 0x252000,0xfffb6800 to 0x27c800,0xfffed000 # : 52.207031,-6.459961 to 55.942383,-1.669922 60000005: 0x252000,0xfffed000 to 0x27c800,0x17800 # : 52.207031,-1.669922 to 55.942383,2.065430
Hi! Mark Burton schrieb:
No, but a different patch is being considered and may be put in soon.
Told you it would be soon.
Ok, when you say soon, you obviously mean it. :-)
Try the nightly build for tonight and use the --preserve-element-order option. Please report back to the list success or failure.
I am happy to report success. With that option, both nodes and ways seem to be drawn in the correct order. BTW: I did not find a snapshot, but was able to build mkgmap locally. Thank you Nop
Hi Nop,
Mark Burton schrieb:
No, but a different patch is being considered and may be put in soon.
Told you it would be soon.
Ok, when you say soon, you obviously mean it. :-)
As I was writing that email, I received the notification that Steve had actually checked in the patch!
I am happy to report success. With that option, both nodes and ways seem to be drawn in the correct order.
Very good.
BTW: I did not find a snapshot, but was able to build mkgmap locally.
It's worth having the ability to build from source because then if you have a request for some new capability, you can receive and test a patch without the experimental code having to go into the trunk. Cheers, Mark
participants (4)
-
Johann Gail -
Mark Burton -
Nop -
Paul