In my meager understanding of Gosmore, it comes down to this: The rules for routing are defined in the elemstyles.xml where a rule is defined for highway=tertiary and one for surface=unpaved among other things. The highway rule has a <routing> tag which tells Gosmore at what speed you can travel, but the surface tag doesn't.
Now one could add a <routing> tag to to the surface rule, but then two rules apply to the same road. Unfortunately on the top of the elemstyles.xml I read: 'BEWARE: If a key/value pair matches more than one rule, the "rule that wins" is unpredicted!'. To solve this the stuff in libgosm.cpp that reads the elemstyles.xml should probably be adapted to either: a) read until the first rule that has a <routing> tag and define the surface rules earlier in the elemstyles.xml b) change the code reading the elemstyles.xml to handle complex rules Elemstyles.xml: http://svn.openstreetmap.org/applications/rendering/gosmore/elemstyles.xml libgosm.cpp: http://svn.openstreetmap.org/applications/rendering/gosmore/libgosm.cpp The code that reads the elemstyles.xml starts at line 1124. John Smith wrote: > How should a road be marked to get gosmore to not route along an unsealed > tertiary route and instead prefer a primary route that isn't much further? > > > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
