Hi, I had a look how much effort it is to add a finalizer style file that is used each time a rule with an element type definition matches. This might make it more easy to implement "general rules" (like the mkgmap:access tag which seems to be useful for complex styles). The finalize file must contain actions only. Otherwise mkgmap stops with an error message. Attached patch for the mergeroads branch realizes this. Maybe have a look on it and reply if you find it useful or superfluous. The patch also contains an additional style function type() returns node, way or relation depending on the elements type. @Steve: do you think it would be possible to add a finalize section to the bottom of each style file (especially points, lines and polygons)? I have the feeling that this is more understandable and maybe better to have different finalize styles for each element type. WanMil
Hi WanMil, just to make sure, I've got it right. way with: a=b c=d e=f actual in lines: a=b & c=d {set x=y } x=y & e&f [0x01 ...] with finalizer: -in lines: x=y & e=f [0x01 ..] - in finalizer: a=b & c=d & type()=way {set x=y} If this is true, also the hole addr-part could be moved to finalizer. Regarding type I think it should better return line, point, relation and polygon. Henning
Hi Henning,
Hi WanMil, just to make sure, I've got it right.
way with: a=b c=d e=f
actual in lines: a=b & c=d {set x=y } x=y & e&f [0x01 ...]
with finalizer: -in lines: x=y & e=f [0x01 ..]
does not match because the way has no tag x=y.
- in finalizer: a=b & c=d & type()=way {set x=y}
Sets x=y. Setting a tag in finalizer makes sense only for mkgmap:* tags which are evaluated by mkgmap internally.
If this is true, also the hole addr-part could be moved to finalizer.
Yes, that's also a good example how the finalizer can be used. The disadvantag is that you cannot use country specific rules in the lines or points file.
Regarding type I think it should better return line, point, relation and polygon.
I agree, but I'll have to take a look if that's possible. WanMil
Henning
Hi WanMil
I had a look how much effort it is to add a finalizer style file that is used each time a rule with an element type definition matches. This might make it more easy to implement "general rules" (like the mkgmap:access tag which seems to be useful for complex styles). The finalize file must contain actions only. Otherwise mkgmap stops with an error message.
This is interesting, early on I though that access rules would have to be in a separate file and this might be it. It also fits in with something else that I want to do, which is to remove all the other getTag() calls from StyledConverter.
@Steve: do you think it would be possible to add a finalize section to the bottom of each style file (especially points, lines and polygons)? I have the feeling that this is more understandable and maybe better to have different finalize styles for each element type.
Sounds like a good idea, I can't think of a syntax for it I like just yet though. You could also have different files lines_final, points_final etc. ..Steve
The finalizer rules are now defined in each style file. The rules start after the finalize section marker: <finalize> @Steve: Please have a look on the patch. I think it is cleanly integrated in the current implementation without too much hacking ;-) I haven't implemented tests yet so it's not well tested. But my first tests seemed to work well. WanMil
Hi WanMil
I had a look how much effort it is to add a finalizer style file that is used each time a rule with an element type definition matches. This might make it more easy to implement "general rules" (like the mkgmap:access tag which seems to be useful for complex styles). The finalize file must contain actions only. Otherwise mkgmap stops with an error message.
This is interesting, early on I though that access rules would have to be in a separate file and this might be it.
It also fits in with something else that I want to do, which is to remove all the other getTag() calls from StyledConverter.
@Steve: do you think it would be possible to add a finalize section to the bottom of each style file (especially points, lines and polygons)? I have the feeling that this is more understandable and maybe better to have different finalize styles for each element type.
Sounds like a good idea, I can't think of a syntax for it I like just yet though. You could also have different files lines_final, points_final etc.
..Steve
Attached is another patch introducing the new finalize part. Now a test is included and rules with actions that have an element type definition are now also handled by the finalize block. I think it is now ready to commit (for branch and trunk). (I don't yet understand why a scripted style test didn't work....). WanMil
The finalizer rules are now defined in each style file.
The rules start after the finalize section marker: <finalize>
@Steve: Please have a look on the patch. I think it is cleanly integrated in the current implementation without too much hacking ;-) I haven't implemented tests yet so it's not well tested. But my first tests seemed to work well.
WanMil
Hi WanMil
I had a look how much effort it is to add a finalizer style file that is used each time a rule with an element type definition matches. This might make it more easy to implement "general rules" (like the mkgmap:access tag which seems to be useful for complex styles). The finalize file must contain actions only. Otherwise mkgmap stops with an error message.
This is interesting, early on I though that access rules would have to be in a separate file and this might be it.
It also fits in with something else that I want to do, which is to remove all the other getTag() calls from StyledConverter.
@Steve: do you think it would be possible to add a finalize section to the bottom of each style file (especially points, lines and polygons)? I have the feeling that this is more understandable and maybe better to have different finalize styles for each element type.
Sounds like a good idea, I can't think of a syntax for it I like just yet though. You could also have different files lines_final, points_final etc.
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Henning Scholland -
Steve Ratcliffe -
WanMil