I'm struggling to render nested networks of international cycling route relations and maybe found an issue with the sort order of relation ID's. My observation is that if the parent relation has a higher ID than the child relation, my mkgmap style won't render the tags of the parent relation on the underlying ways. For example, this cycleway which is part of a (super)relation EV12 (North Sea Cycle route) and a national route LF1. http://www.openstreetmap.org/browse/way/4549529 (cycleway) http://cycling.waymarkedtrails.org/nl/?zoom=17&lat=52.13921&lon=4.33606 part of Noordzeeroute (2761) network = ncn, ref = LF1, route = bicycle, type = route http://www.openstreetmap.org/browse/relation/2761 part of North Sea Cycle Route - part The Netherlands (1977662) network = icn, ref = EV12, route = bicycle, type = superroute http://www.openstreetmap.org/browse/relation/1977662 part of North Sea Cycle Route (1207220) network = icn, ref = EV12, route = bicycle, type = superroute http://www.openstreetmap.org/browse/relation/1207220 My goal is to get ref EV12(North Sea Cycle Route) on this cycleway, but all it gets are the ncn tags LF1 (Noordzeeroute). With a similar route relation in Germany, I don't have problems to render it, for instance this way: http://www.openstreetmap.org/browse/way/23018057 (highway=secondary) http://cycling.waymarkedtrails.org/nl/?zoom=15&lat=52.0506&lon=6.70903 part of D3 D-Netz-Route (Nordrhein-Westfalen) (2003425) network = ncn, ref D3, route = bicycle, type = route http://www.openstreetmap.org/browse/relation/2003425 part of Capitals Route (2003423) network = icn, ref EV2, route = bicycle, type = superroute http://www.openstreetmap.org/browse/relation/2003423 part of D-Netz-Route 3 (901472) network = ncn, ref D3, route = bicycle, type = route With this way, mkgmap renders tags EV12 (Capital route) as expected. With JOSM I found out that the sort order of the relation ID is the problem. If I swapped the contents and tags of relation 2761 and 1977662 (of course I didnt upload it to OSM, just saved the file) it gets rendered. If I make a new relation, it gets a negative ID and there is no problem either, all the relations that I put in this new relation gets the tags from the parent relation. In the German route example, the parent relation has a lower ID than the child, 2003423 vs 2003425. With this the relation styles have no problem to render it. Is there a way to solve this?
It's a question of parsing the data. You (means mkgmap) have to rebuild superroutes, till there are only way-member in it. Eg: parse tile and read all relation (maybe store in RAM) if relation_A contains relations_B, replace all relations_B in this relation_A with the objects the relation_B1...Bn contain. end, if no relation contains any relation. This shouldn't be very complex and not very expensive, because there are typical not so many relation in one tile. mkgmap did this afaik only the way you discoverd (increasing ID). Henning
Another test: I removed the option --preserve-element-order in my mkgmap options and it seems to render the relations fne now... Where is this option good for?
On 07/12/12 14:37, Minko wrote:
Another test: I removed the option --preserve-element-order in my mkgmap options and it seems to render the relations fne now... Where is this option good for?
With the option it processes the elements in the order that they appear in the input file. Without it, they are processed in an arbitrary order. In this case you are lucky as the arbitrary order happens to work for you. With a different tile extract or after a few edits you may be unlucky again. The reason that I think that preserve-element-order should always be on is that it makes the output consistent. ..Steve
Ok, so the problem of rendering those nested relations still exist, can this be solved?
Without it, they are processed in an arbitrary order. In this case you are lucky as the arbitrary order happens to work for you. With a different tile extract or after a few edits you may be unlucky again.
The reason that I think that preserve-element-order should always be on is that it makes the output consistent.
..Steve
It's a question of parsing the data.
You (means mkgmap) have to rebuild superroutes, till there are only way-member in it.
Eg: parse tile and read all relation (maybe store in RAM) if relation_A contains relations_B, replace all relations_B in this relation_A with the objects the relation_B1...Bn contain. end, if no relation contains any relation.
This shouldn't be very complex and not very expensive, because there are typical not so many relation in one tile.
Yes, but mkgmap must make sure that it handles the case when relations are building loops: Examples: rel_a contains rel_b, rel_b contains rel_a or, a bit more complex: rel_a -> rel_b -> rel_c -> rel_d->rel_b some time ago I found a relation (probably a joke) like this: rel_a -> rel_a splitter handles this for the problem relations and it is not very time consuming. Gerd
participants (4)
-
Gerd Petermann -
Henning Scholland -
Minko -
Steve Ratcliffe