Polygon with barrier problem
Hi I'm new to the joys of creating my custom styles & renderings. Using -r1505. WinXp I have a landuse=farmyard polygon with, a barrier=wall additional tag. This barrier wasn't an additional way drawn around the perimeter of the polygon, but with the barrier=wall key added as an extra tag. The problem is it only renders the barrier, the polygon being transparent. I have other landuse=farmyard polygons without the barrier tag & they render correctly. Using this command: java -Xmx512M -ea -jar mkgmap.jar --remove-short-arcs --gmapsupp "Contours.img" --transparent --style-file="c:\dwgs\Programs\GPS All\Garmin Profile" --family-id=42 M000002.TYP Barrier_test.osm In my line style: barrier=wall In my polygon style: landuse=farmyard & barrier=wall landuse=farmyard What do I need to do to get it to render? Thanks for your help Cheers Dave F.
Dave F. schrieb am 22.01.2010 19:03:
In my line style: barrier=wall
In my polygon style: landuse=farmyard & barrier=wall landuse=farmyard
What do I need to do to get it to render?
I think, right now it is not possible, to get from one garmin element a polygon as well as a line in the map. A possible solution is to get rid of the wall. You could change your line style to barrier=wall & landuse!=*, so that a wall line will not be generated, if there is also a landuse tag. Or another solution is to place two lap layers above each other. You can generate one map with the landuse polygon, and on top of that (with a higher draw_priority and with the transparent flag) you can put a second map containing the wall line. Gruss Torsten
Dave F. wrote:
Hi
I'm new to the joys of creating my custom styles & renderings. Using -r1505. WinXp
I have a landuse=farmyard polygon with, a barrier=wall additional tag. This barrier wasn't an additional way drawn around the perimeter of the polygon, but with the barrier=wall key added as an extra tag.
The problem is it only renders the barrier, the polygon being transparent.
I have other landuse=farmyard polygons without the barrier tag & they render correctly.
Using this command: java -Xmx512M -ea -jar mkgmap.jar --remove-short-arcs --gmapsupp "Contours.img" --transparent --style-file="c:\dwgs\Programs\GPS All\Garmin Profile" --family-id=42 M000002.TYP Barrier_test.osm
In my line style: barrier=wall
In my polygon style: landuse=farmyard & barrier=wall landuse=farmyard
What do I need to do to get it to render?
Thanks for your help
Cheers Dave F.
Torsten has explained what's going on here. For future reference, mkgmap processes the style files in a strict order, which is: 1. version 2. info 3. options 4. relations 5. points 6. lines 7. polygons 8. overlays Thus your landuse=farmyard & barrier=wall object is being matched by the lines style file at 6 first and then further rule matching is terminated, meaning that whatever applicable rules you have in your polygons file at 7 are never applied. Charlie
On Jan 23, 2010, at 11:59, Charlie Ferrero wrote:
For future reference, mkgmap processes the style files in a strict order, which is: 1. version 2. info 3. options 4. relations 5. points 6. lines 7. polygons 8. overlays
And I assume that the "continue" statement will not allow processing to continue across style files? Cheers.
Clinton Gladstone schrieb am 23.01.2010 12:11:
And I assume that the "continue" statement will not allow processing to continue across style files?
Sadly the continue statement is only working in one style file at the moment. I think later it should be possible to continue also in different style files, but for now we should finish the simple continue-handling first, before we start extending it. Gruss Torsten
Torsten Leistikow wrote:
Clinton Gladstone schrieb am 23.01.2010 12:11:
And I assume that the "continue" statement will not allow processing to continue across style files?
Sadly the continue statement is only working in one style file at the moment.
I think later it should be possible to continue also in different style files, but for now we should finish the simple continue-handling first, before we start extending it.
Gruss Torsten
Thanks for the replies. I guess i can live with it for now. Are there any other situations like this that I should be aware of? I'm aware of one problem of tagging the 'inner' of a multipolygon, are there an others? Could you explain the continue statement please. I couldn't find anything on it in the wiki. Cheers Dave F.
Are there any other situations like this that I should be aware of? I'm aware of one problem of tagging the 'inner' of a multipolygon, are there an others?
What do you mean with "tagging the 'inner' of a multipolygon"? I have reimplemented the whole mulitpoylgon code so I am very interested in problems that still exist. Can you give a relation id which makes problems? WanMil
WanMil wrote:
What do you mean with "tagging the 'inner' of a multipolygon"? I have reimplemented the whole mulitpoylgon code so I am very interested in problems that still exist.
Can you give a relation id which makes problems? I'm using r1505 on an Oregon 300 using the latest firm/software.
http://www.openstreetmap.org/browse/relation/383291 With these tags added to the inner relation the void doesn't fully show on the Garmin. There is a thin slit where it should be a sort of sausage shape. <tag k='name' v='River Avon' /> <tag k='waterway' v='riverbank' /> Because there's that slit it's as if with those tags, the inner polygon has been some width. If I remove them it works. I thought it might be because I also had waterway=river, width=15 but by using an extraction of OSM & deleting those ways manually from the XML data, I verified that wasn't the cause. Cheers Dave F.
WanMil wrote:
What do you mean with "tagging the 'inner' of a multipolygon"? I have reimplemented the whole mulitpoylgon code so I am very interested in problems that still exist.
Can you give a relation id which makes problems? I'm using r1505 on an Oregon 300 using the latest firm/software.
http://www.openstreetmap.org/browse/relation/383291
With these tags added to the inner relation the void doesn't fully show on the Garmin. There is a thin slit where it should be a sort of sausage shape. <tag k='name' v='River Avon' /> <tag k='waterway' v='riverbank' />
Because there's that slit it's as if with those tags, the inner polygon has been some width.
If I remove them it works.
I thought it might be because I also had waterway=river, width=15 but by using an extraction of OSM& deleting those ways manually from the XML data, I verified that wasn't the cause.
Cheers Dave F.
Dave, I compiled a map using default style that covers the relation. There were no problems with the relation (the island shows as big as expected on my Oregon). But http://www.openstreetmap.org/browse/way/37737680 overlaps the river and produces a very wide bridge. This is either a data or a style problem. As far as I could see the multipolyon code works as expected. WanMil
Dave F. schrieb am 24.01.2010 03:47:
Could you explain the continue statement please. I couldn't find anything on it in the wiki.
For each OSM-object mkgmap normally scans through all rules in your style file and searches for the rule with the highest priority, i.e. the first rule, that matches. This rule is executed, i.e. the corresponding garmin item is created, and afterwards the nect OSM-object is processed. If the applied rule contains a continue statement, e.g. highway=primary [0x01 resolution 20 continue], than mkgmap will apply this rule and afterwards continue scanning the style file (right now it does not scan any additional style files) for the next matching rule. If the matching rule has also an actions part, e.g. {set oneway=yes}, than this part is only applied to the garmin element created by this rule and not for the following elements created from the same OSM item If you use instead of "continue" the "continue with_actions" statement, than the action part is applied to the actual item as well as to all follwing items. The best example for the continue statement is a node, which is tagged as restaurant and as hotel at the same time. Without continue statement you can only get one garmin element, either a hotel or a restaurant. With the continue statement you can get both at the same time. Gruss Torsten
Torsten Leistikow wrote:
For each OSM-object mkgmap normally scans through all rules in your style file.... Thanks for all your replies.
As I said, I'm a newbie so i may not understand fully, but wouldn't it be better if, when mkgmap reads the OSM file, it decides when it finds a polygon (first point=last point) then it should look directly in the polygon file? It seems a bit back to front at the moment. Cheers Dave F.
participants (5)
-
Charlie Ferrero -
Clinton Gladstone -
Dave F. -
Torsten Leistikow -
WanMil