Routers prefer to route to calculated centre of administrative area rather than place nodes?

Help and support Tagging help & support
, ,
1

Malaysia has 2 well-known tourist highland destinations: Genting Highlands (which is a town and tagged with place=town) and Cameron Highlands (which is a district and tagged with boundary=administrative + admin_level=6). (There was a previously existing place=town node for Cameron Highlands which I deleted since it is not a town but a district).

When we Malaysians say, “I’m going to Cameron Highlands”, we actually mean we’re going to Tanah Rata (the administrative town of Cameron Highlands). When we arrive in Tanah Rata, we don’t normally say, “I’m now in Tanah Rata”, but instead we say, “I’m now in Cameron Highlands”.

We commonly mistake Cameron Highlands as the town, and wrongly assume Tanah Rata as the alternative, less-well-known name for “Cameron Highlands town” where in actual reality, there is no such thing as the “town of Cameron Highlands”.

The problem that I have is with routing services search results. When I key in “Genting Highlands” into the routing service search box, the router will map the route to Genting Highlands since it is tagged with place=town. But when I key in “Cameron Highlands” into the OSM routing service search box:

  • GraphHopper says, “Couldn’t find a route between those two places.”
  • OSRM directs the driver to the calculated centre of the district (which is dense Malaysian jungle) instead of to Tanah Rata.
  • Valhalla does the same as OSRM above.

I attempted to fix this by including a place=district node for Cameron Highlands and included this as a label for the administrative district boundary relation and put this node at Tanah Rata but all 3 routing services above ignored the place=district node.

It didn’t help that I added the tag alt_name=Cameron Highlands to the Tanah Rata town node. The 3 routing services failed to direct the driver to Tanah Rata.

I mentioned above that I deleted the previously existing node tagged with place=town for Cameron Highlands, but because most Malaysians will enter “Cameron Highlands” into the routing service search box instead of “Tanah Rata”, I’m tempted to restore back this erroneous node so that the routing system will work again.

What other available options do I have where I preserve the accuracy of my tags, and entering Cameron Highlands into the routing search box will direct the driver to Tanah Rata?

2

This should help. Keep in mind that the routers don’t update their database immediately. Try again tomorrow.

2 Likes
3

Thank you for your suggestion Michael. It has been more than 24 hours now since adding alt_name=Cameron Highlands to the Tanah Rata town node. GraphHopper, OSRM and Valhalla still failed to direct the driver to Tanah Rata when “Cameron Highlands” is entered into the search box.

I did a little experiment just now. I temporarily renamed relation:10744325 to “Cameron (route test)”. Now when I enter Cameron Highlands into the search box, all 3 routers correctly route to node:7236772808 (place=district + name=Cameron Highlands).

I went one little step further with my experiment and temporarily renamed the place=district node above to “Cameron (test)”. Now when I enter Cameron Highlands into the search box, all 3 routers correctly route to node:254074510 (place=town + name=Tanah Rata + alt_name=Cameron Highlands).

(I have now restored the original names now that my experiment is complete.)

It appears that the problem lies with routing algorithm. There are 3 elements tagged with “Cameron Highlands”:

  1. Boundary Relation with name=Cameron Highlands
  2. place=district node with name=Cameron Highlands
  3. place=town node with alt_name=Cameron Highlands

When entering “Cameron Highlands” into the router’s search box, the routing algorithm chooses the destination element in the order of priority as listed above.

It appears that in this case, routers prefer to route to a calculated center of an administrative area rather than a place node.

4

Routers route to whatever point the search engine gives them. So your actual problem is with the search engine computing the wrong center to the administrative boundary. The current tagging with the label member should do the trick. And it seems to work for me now, probably because your “experiments” have refreshed the search indexes.

If it still doesn’t work for you, please provide the exact steps to reproduce the problem.

3 Likes
5

It works now. Thank you.