logo separator

[mkgmap-dev] natural=wetland; why is ~ disallowed at top level?

From Marko Mäkelä marko.makela at iki.fi on Mon Jan 18 09:06:10 GMT 2010

Hi Steve,

> > I see.  I guess that only the first matching [] rule will be run
> > and that any {set} or {add} rules will not affect further tests.
> 
> There is a 'continue' keyword that allows further matches to take
> place.

The 'continue' keyword is for the [] action, right?  And the further
matches could be terminated by another [] action that would generate
another map element, right?

> The set and add actions are expected to affect further matches (as in
> people expect it to happen, as it is meant to work as-if the rules
> were applied in order), but as you will realise this is difficult to
> implement as you have to throw away optimisation if you detect that it
> could happen.
> 
> The style branch implements that a bit better.

I did not realise that the style branch has not been merged to trunk yet.
Are you planning to do that soon?  In which way does the implementation in
the style branch differ from trunk?

> > The same would apply to second.isType(OR), I suppose.
> 
> What kind of rule would that work for?

The same type of rules as the first.isType(OR), but with the roles
of first and second swapped.  I am pulling the example from the
source code comment.  This is a bad example, because to my understanding,
it would not be handled by the isType(OR) but the earlier isType(EXISTS):

// (a=b|a=c) & d=f => (a=b&d=f) | (a=c&d=f) => solved

The symmetric case would be

// d=f & (a=b|a=c)

which would now be translated into the same.  (Would it be beneficial to
check for isType(OR) within isType(AND) before the isType(EQUALS) and
isType(EXISTS)?)

> The backslashes should not be there.  Running the following
> works fine with all backslashes removed (in RuleFileReaderTest).

You are right, I get the same size gmapsupp.img after removing the \
before |().

Uh oh, It seems that there must be a bug in the default style then.
The regexps for smoothness and sac_scale are wrong.  But I thought
that I successfully tested the patch (setting mkgmap:unpaved=1)
with a road whose smoothness was tagged bad.

	Marko



More information about the mkgmap-dev mailing list