I figured out that mkgmap does already support nested relations, but it is not working for me. The attached patch attempts to copy the route name to the members of member relations. This is the relation in question: <relation id='155054' timestamp='2010-01-03T22:13:56Z' uid='93285' user='skela' visible='true' version='3' changeset='3533281'> <member type='relation' ref='375952' role='stop' /> <member type='way' ref='2735495' role='' /> <member type='relation' ref='375951' role='stop' /> The route name is successfully applied to relation 375952 (and its members) and way 2735495, but according to an echo action that I added, not even the outer apply is executed on relation 375951. What am I doing wrong? I could not see any obvious bug in the code. In the future, I think that it might be useful if apply supported the following: * apply role ~ 'regexp' {} notation, e.g., for matching '\(forward_\|backward_\)?stop' * apply node ... for applying only to member nodes * apply way ... for applying only to member ways * apply relation ... for applying only to subrelations * apply cond <conditions> { <actions> } for conditions on the attributes of relation members Best regards, Marko
On Mon, Jan 04, 2010 at 05:09:43PM +0200, Marko Mäkelä wrote:
I figured out that mkgmap does already support nested relations, but it is not working for me. The attached patch attempts to copy the route name to the members of member relations. This is the relation in question:
<relation id='155054' timestamp='2010-01-03T22:13:56Z' uid='93285' user='skela' visible='true' version='3' changeset='3533281'> <member type='relation' ref='375952' role='stop' /> <member type='way' ref='2735495' role='' /> <member type='relation' ref='375951' role='stop' />
The route name is successfully applied to relation 375952 (and its members) and way 2735495, but according to an echo action that I added, not even the outer apply is executed on relation 375951. What am I doing wrong? I could not see any obvious bug in the code.
The bug apparently is in the relation parser, in the way how uk.me.parabola.mkgmap.reader.osm.Relation.addElement() is invoked. In the source file, <relation id='375952'> occurs after the super-relation, while relation 375951 is defined before the super-relation. It seems that there should be a Relation.addRelation(String role, long id) and the subrelation id resolution would be deferred until all relation definitions have been parsed. Currently, the id resolution is attempted too early. It works for node and way members, because they always occur before relations in the input file. It is broken for relation members. Another bug in Relation.addElement() is that it allows members to occur in at most one role. Route relations can legitimately contain members multiple times in different roles. Marko
On Mon, Jan 04, 2010 at 11:26:39PM +0200, Marko Mäkelä wrote:
The bug apparently is in the relation parser, in the way how uk.me.parabola.mkgmap.reader.osm.Relation.addElement() is invoked.
Fixed in src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java revision 1466.
Another bug in Relation.addElement() is that it allows members to occur in at most one role. Route relations can legitimately contain members multiple times in different roles.
This only affects style files containing apply role=blah {} constructs. Only one role of the member element would be recorded. I plan to address that by defining Relation.roles as a poor man's MultiMap, similar to what I did in Osm5XmlHandler.deferredRelationMap. (Only the role information will be lost. All relation members will be recorded in order, because otherwise apply_once would not have been necessary.) Marko
Actually as you're working on it. Is there an easy way to specify priority of apply for several routes? Checking for route=bicycle & network=icn -- ncn -- rcn --lcn Status quo: there is no way I can specify (other than set over add) to put the ref/name of the icn relation onto a street. If no icn then take ncn, no ncn take rcn, no rcn take lcn. There is no way to check if a higher priority relation is using the same way. I know I could write the names like name_ncn, name_rcn ... but my naming line is already so long that I don't want to make it any longer.... Felix P.S My current naming string present over 600 times in my lines file. { name '${ref|highway-symbol:hbox:6:4} ${name} ${route_name} ${extremecarver6}${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:hbox:6:4} ${route_name} ${extremecarver6}${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:hbox:6:4} ${name} ${extremecarver6}${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:hbox:6:4} ${extremecarver6}${mtb:scale}${mtb:scale:uphill}' | '${extremecarver|highway-symbol:hbox:6:4}${mtb:scale}${mtb:scale:uphill} ${name} ${route_name}' | '${extremecarver|highway-symbol:hbox:6:4}${mtb:scale}${mtb:scale:uphill} ${name}' | '${extremecarver|highway-symbol:hbox:6:4}${mtb:scale}${mtb:scale:uphill} ${route_name}' | '${extremecarver|highway-symbol:hbox:6:4}${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:oval:6:4} ${name} ${route_name} M${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:oval:6:4} ${route_name} M${mtb:scale}${mtb:scale:uphill}' | '${name} ${route_name} M${mtb:scale}${mtb:scale:uphill}' | '${route_name} M${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:oval:6:4} ${name} M${mtb:scale}${mtb:scale:uphill}' | '${name} M${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:oval:6:4} M${mtb:scale}${mtb:scale:uphill}' | '${ref|highway-symbol:hbox:6:4} ${name} ${route_name} ${extremecarver6}${mtb:scale}.' | '${ref|highway-symbol:hbox:6:4} ${route_name} ${extremecarver6}${mtb:scale}.' | '${ref|highway-symbol:hbox:6:4} ${name} ${extremecarver6}${mtb:scale}.' | '${ref|highway-symbol:hbox:6:4} ${extremecarver6}${mtb:scale}.' | '${extremecarver|highway-symbol:hbox:6:4}${mtb:scale}. ${name} ${route_name}' | '${extremecarver|highway-symbol:box:6:4}${mtb:scale}. ${name}' | '${extremecarver|highway-symbol:hbox:6:4}${mtb:scale}. ${route_name}' | '${extremecarver|highway-symbol:hbox:6:4}${mtb:scale}. ' | '${ref|highway-symbol:oval:6:4} ${name} ${route_name} M${mtb:scale}.' | '${ref|highway-symbol:oval:6:4} ${route_name} M${mtb:scale}.' | '${name} ${route_name} M${mtb:scale}.' | '${route_name} M${mtb:scale}.' | '${ref|highway-symbol:oval:6:4} ${name} M${mtb:scale}.' | '${name} M${mtb:scale}.' | '${ref|highway-symbol:oval:6:4} M${mtb:scale}.' | '${ref|highway-symbol:hbox:6:4} ${name} ${route_name} ${extremecarver6}.${mtb:scale:uphill}' | '${ref|highway-symbol:hbox:6:4} ${route_name} ${extremecarver6}.${mtb:scale:uphill}' | '${ref|highway-symbol:hbox:6:4} ${name} ${extremecarver6}.${mtb:scale:uphill}' | '${ref|highway-symbol:hbox:6:4} ${extremecarver6}.${mtb:scale:uphill}' | '${extremecarver|highway-symbol:hbox:6:4}.${mtb:scale:uphill} ${name} ${route_name}' | '${extremecarver|highway-symbol:box:6:4}.${mtb:scale:uphill} ${name}' | '${extremecarver|highway-symbol:hbox:6:4}.${mtb:scale:uphill} ${route_name}' | '${extremecarver|highway-symbol:hbox:6:4}.${mtb:scale:uphill} ' | '${ref|highway-symbol:oval:6:4} ${name} ${route_name} M.${mtb:scale:uphill}' | '${ref|highway-symbol:oval:6:4} ${route_name} M.${mtb:scale:uphill}' | '${name} ${route_name} M.${mtb:scale:uphill}' | '${route_name} M.${mtb:scale:uphill}' | '${ref|highway-symbol:oval:6:4} ${name} M.${mtb:scale:uphill}' | '${name} M.${mtb:scale:uphill}' | '${ref|highway-symbol:oval:6:4} M.${mtb:scale:uphill}' | '${ref|highway-symbol:box:6:4} ${name} ${route_name} ${extremecarver6}' | '${ref|highway-symbol:box:6:4} ${route_name} ${extremecarver6}' | '${ref|highway-symbol:box:6:4} ${name} ${extremecarver6}' | '${ref|highway-symbol:box:6:4} ${extremecarver6}' | '${name} ${route_name} ${extremecarver6}' | '${name} ${extremecarver6}' | '${route_name} ${extremecarver6}' | '${extremecarver6}' | '${ref|highway-symbol:oval:6:4} ${name} ${route_name}' | '${ref|highway-symbol:oval:6:4} ${route_name}' | '${name} ${route_name}' | '${route_name}' | '${ref|highway-symbol:oval:6:4} ${name}' | '${name}' | '${ref|highway-symbol:oval:6:4}'; add display_name = '${name} (${ref}) ${route_name}' | '${name} (${ref}) ${extremecarver6}' | '${name} (${ref})' }
Hi Felix,
Actually as you're working on it. Is there an easy way to specify priority of apply for several routes?
I wish there were, because I would like borders to be named in a logical order (biggest entity first if a boundary line belongs to multiple admin_levels). I suppose that there could be some predicate for ordering relations, but I don't know how to realize that, both in the language syntax and in the implementation. Do you have any suggestions?
P.S My current naming string present over 600 times in my lines file.
I think that we should consider having macros, or perhaps conditional actions within actions to shorten the notation. Would they be useful for you? Best regards, Marko
On 05.01.2010 22:41, Marko Mäkelä wrote:
Hi Felix,
Actually as you're working on it. Is there an easy way to specify priority of apply for several routes?
I wish there were, because I would like borders to be named in a logical order (biggest entity first if a boundary line belongs to multiple admin_levels).
I suppose that there could be some predicate for ordering relations, but I don't know how to realize that, both in the language syntax and in the implementation. Do you have any suggestions?
No not really. I think the only way to do it would be to write the information gathered via relations to an intermediary file where one could then using another file to define order, run regexp commands to match rules on the same way against each other and then apply the outcome to the normal data.
P.S My current naming string present over 600 times in my lines file.
I think that we should consider having macros, or perhaps conditional actions within actions to shorten the notation. Would they be useful for you?
Well if you see a way to cut down the length of commands that would be great. Obviously naming of streets is the most complex task.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Felix Hartmann -
Marko Mäkelä