[PATCH v1] finalizer style file

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH v1] finalizer style file

WanMil
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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

finalizer_style_v1.patch (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH v1] finalizer style file

osm-8
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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH v1] finalizer style file

WanMil
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
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH v1] finalizer style file

Steve Ratcliffe
In reply to this post by 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
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

[PATCH v2] finalizer style file

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
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

finalizer_style_v2.patch (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH v2] finalizer style file

WanMil
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
> [hidden email]
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

finalizer_style_v3.patch (29K) Download Attachment