multiple garmin elements from one osm element
Moin, finally I got my eclipse environment running and was able to build mkgmap from source. So the next step was my first extension of mkgmap. Until now a single OSM element was converted into a single garmin element, i.e. the first one in the style file with the matching expression. I have extended the style definition by two commands (stop and continue), to allow the generation of multiple elements. A classic conversion rule has a syntax like: amenity=restaurant [0x2a00 resolution 20] With my extension this is equal to amenity=restaurant [0x2a00 resolution 20 stop] and has the meaning: If this rule is used, no further rules will be applied to the element. If this line is changed now to amenity=restaurant [0x2a00 resolution 20 continue] mkgmap will convert a matching OSM element into a garmin Element type 0x2a00, but afterwards it will check, whether another rule is matching for the same osm element. So this will allow, that for the same item additionally a tourism=hotel [0x2b01 resolution 20] rule might be applied. My modification is working on points as well as on lines or polygons, i.e. it will also help with barrier=fence problem. There are two problems with my modification: 1. The POI generation for an area will not work, with multiple conversion rules. 2. I do not know, how to provide a proper patch for my modification, so I just attached the modified java-files (based on mkgmap-r1087). I hope you can incorporate the modification into your mkgmap and give it a try. Without any change to the style, the modification should not change anything. As a try, you could add the continue command to all point rules and all barrier rules. What do you think about it? Gruss Torsten
Is there a big speed difference when using your patches? I currently have quite some difficulties running extensive checks, as I can only create maps via remote desktop. Principally I think many people await this feature. 2009/7/19 Torsten Leistikow <de_muur@gmx.de>
Moin,
finally I got my eclipse environment running and was able to build mkgmap from source. So the next step was my first extension of mkgmap.
Until now a single OSM element was converted into a single garmin element, i.e. the first one in the style file with the matching expression.
I have extended the style definition by two commands (stop and continue), to allow the generation of multiple elements.
A classic conversion rule has a syntax like:
amenity=restaurant [0x2a00 resolution 20]
With my extension this is equal to
amenity=restaurant [0x2a00 resolution 20 stop]
and has the meaning: If this rule is used, no further rules will be applied to the element.
If this line is changed now to
amenity=restaurant [0x2a00 resolution 20 continue]
mkgmap will convert a matching OSM element into a garmin Element type 0x2a00, but afterwards it will check, whether another rule is matching for the same osm element. So this will allow, that for the same item additionally a
tourism=hotel [0x2b01 resolution 20]
rule might be applied.
My modification is working on points as well as on lines or polygons, i.e. it will also help with barrier=fence problem.
There are two problems with my modification:
1. The POI generation for an area will not work, with multiple conversion rules.
2. I do not know, how to provide a proper patch for my modification, so I just attached the modified java-files (based on mkgmap-r1087).
I hope you can incorporate the modification into your mkgmap and give it a try. Without any change to the style, the modification should not change anything. As a try, you could add the continue command to all point rules and all barrier rules.
What do you think about it?
Gruss Torsten
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix Hartmann schrieb:
Is there a big speed difference when using your patches?
I haven't noticed any significant difference, but I haven't done any real comparison measurements. It certainly depends on the number of additionally created elements, but I think it will take some time, until the extended possibilities are really used. Right now I am trying to add a marking to highways with bridge=yes. Another idea would be to add a marking to all highways with a cycleway=track. Gruss Torsten
Torsten Leistikow wrote:
Felix Hartmann schrieb:
Is there a big speed difference when using your patches?
I haven't noticed any significant difference, but I haven't done any real comparison measurements. It certainly depends on the number of additionally created elements, but I think it will take some time, until the extended possibilities are really used. Right now I am trying to add a marking to highways with bridge=yes. Another idea would be to add a marking to all highways with a cycleway=track.
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
If you know my maps ( http://openmtbmap.org ), you would know that I use 3 layers and patched mkgmap via the rules reader file (older messages on this list) for me to reduce it down from 6 to 3 layers. continue/stop is definitely easier than patching the rule reader files for many things to continue, so my only fear is that going for continue/stop makes mkgmap slower. Since my main lines style-file got to around 80.000 lines because of checking several attributes for each possible line, speed of mkgmap reduces somtimes badly (about 500%plus on my older light styles consisting of only around 2.000 lines), even though most lines are only about getting additional attributes into the name. On gps map panning several layers provide speed improvements, therefore I would still continue with multilayer maps, but maybe go down to two layers if speed improves. Could you try with/without your patches on germany.osm.bz2 from geofrabrik to see the speed difference (just record with timer in batch/bash) The main things I'm currently doubling are bridges, tunnels, sac_scale, mtb:scale, mtb:scale:uphill, trackgrade, several route types, cycleways, and some more but via my own patches I already got this down to three layers. other things to double would be rivers.
Felix Hartmann schrieb:
so my only fear is that going for continue/stop makes mkgmap slower.
I did some performance tests today, comparing mkgmap version 1087 with my modified version on the area (46.0;3.0) to (56.0;19.0) cut into 89 tiles. With the default style both the original version and the modified version took approx. 17 minutes. Actually the modified version was a little bit faster, but this can not be caused by the modification the reason must be some background work form the windows system. The resulting Garming image files had (as expected) the same size of 324MB. For the third run I used a modification of the default style, where I added a "continue" to evere conversion rule in the lines, points and polygon files (not very usefull except for some performance estimations). With this style the processing time increased to approx. 20 minutes and the resulting image files have a size of 434MB. If you want to try the modified version, you can download my jar-file at: http://demuur.gmxhome.de/mkgmap_multi.jar Gruss Torsten
okay, that's a pretty modest time increase. On 21/07/2009, Torsten Leistikow <de_muur@gmx.de> wrote:
Felix Hartmann schrieb:
so my only fear is that going for continue/stop makes mkgmap slower.
I did some performance tests today, comparing mkgmap version 1087 with my modified version on the area (46.0;3.0) to (56.0;19.0) cut into 89 tiles.
With the default style both the original version and the modified version took approx. 17 minutes. Actually the modified version was a little bit faster, but this can not be caused by the modification the reason must be some background work form the windows system. The resulting Garming image files had (as expected) the same size of 324MB.
For the third run I used a modification of the default style, where I added a "continue" to evere conversion rule in the lines, points and polygon files (not very usefull except for some performance estimations). With this style the processing time increased to approx. 20 minutes and the resulting image files have a size of 434MB.
If you want to try the modified version, you can download my jar-file at: http://demuur.gmxhome.de/mkgmap_multi.jar
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Torsten Leistikow <de_muur@gmx.de> wrote:
Until now a single OSM element was converted into a single garmin element, i.e. the first one in the style file with the matching expression.
Will this allow for Generation of fake cycleways for one-way streets which are tagged cycleway=opposite_lane? Sven -- "and on the third day he rebooted into Linux-1.3.84" (Linus Torvalds, Easter Kernel Release 1996) /me is giggls@ircnet, http://sven.gegg.us/ on the Web
Hi Torsten, I've created a "proper" patch for your modifications and attached it. Regards Thilo
Torsten Leistikow wrote:
Moin,
finally I got my eclipse environment running and was able to build mkgmap from source. So the next step was my first extension of mkgmap.
Until now a single OSM element was converted into a single garmin element, i.e. the first one in the style file with the matching expression.
I have extended the style definition by two commands (stop and continue), to allow the generation of multiple elements.
A classic conversion rule has a syntax like:
amenity=restaurant [0x2a00 resolution 20]
With my extension this is equal to
amenity=restaurant [0x2a00 resolution 20 stop]
and has the meaning: If this rule is used, no further rules will be applied to the element.
If this line is changed now to
amenity=restaurant [0x2a00 resolution 20 continue]
mkgmap will convert a matching OSM element into a garmin Element type 0x2a00, but afterwards it will check, whether another rule is matching for the same osm element. So this will allow, that for the same item additionally a
tourism=hotel [0x2b01 resolution 20]
rule might be applied.
My modification is working on points as well as on lines or polygons, i.e. it will also help with barrier=fence problem.
There are two problems with my modification:
1. The POI generation for an area will not work, with multiple conversion rules.
2. I do not know, how to provide a proper patch for my modification, so I just attached the modified java-files (based on mkgmap-r1087).
I hope you can incorporate the modification into your mkgmap and give it a try. Without any change to the style, the modification should not change anything. As a try, you could add the continue command to all point rules and all barrier rules.
What do you think about it?
Gruss Torsten
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Could you or someone try to modify this patch so that it compiles against mkgmap 1140.
I tried merging it for more than 1 hour today but did not get any clean compile. There are nearly 10 conflicts against the new extended types code. Both, the extended types and the "continue" behaviour are very important features for me..... I would really miss the above patch if it is not implementable to current svn. thanks very much in advance if someone could try to change it to get it working... I attach the patch as prepared by Thilo again so searching for old e-mails is not needed....
participants (5)
-
Felix Hartmann -
Mark Burton -
Sven Geggus -
Thilo Hannemann -
Torsten Leistikow