Barriers on Highways

I plotted a few of the Police/Army check points we see here on the main Highways in Thailand, and this seems to drastically affect the routing, both in Garmin and on the OSM directions drop down.
I’m assuming that using barrier=* is the culprit, as checking the routing starting either side of the barrier will have dramatic results, sending you on a massive detour if before the barrier.
I used the tag barrier=concrete_block here and it effectively shut the road. See for yourself at
unless of course its working correctly now that I have just removed the barrier !
Im not sure about lift_gate … I’ll check that shortly.
In the short term, I will remove all barriers I have plotted, but does anyone know exactly how the routers deal with barriers, and if the problem lies on mkgmap, maybe time to get the problem addressed.
If blocks stop traffic, but gate just delays it, or has no effect, can this info be added to the Wiki

According to the Barriers page on the Wiki, most barriers have access=no implied, so the routers would appear to be working properly here. You could solve the problem by adding access=yes to the nodes, but in this case, I don’t think barrier=block is the proper tag to use. (If a node on the road carried the tag, I’d imagine a row of blocks sealing off the entire road.)

I’m not sure which kind of checkpoint you have in mind. But if it employs a boom barrier, you should definitely tag it as barrier=lift_gate rather than barrier=block. Also add access=yes to be sure. If it’s a police checkpoint where barriers are placed to narrow the road, traffic_calming=choker might be appropriate (if the structure’s permanent). There doesn’t appear to be an accepted dedicated tag for security checkpoints.

The barrier tag is very likely the reason your routing isn’t working as you expect. I agree with Paul_012’s assessment and have begun using traffic_calming=choker for those all too common places along Thailand’s highways where you must slow down and go through a police controlled section. There is no commonly accepted way to tag such places that I’ve been able to find.

One could make allowances for certain types of barriers in the compilation of Garmin maps with mkgmap but the best solution is to tag them as traffic_calming, which would be correct and would solve the problem with access at the same time.

Perhaps too we could work with the tagging group to create a set of police check point tags. Taginfo shows a bunch of variants on this theme but, as with so many other tags, it’s a bit of a mess currently.

Thanks for the input guys. If you are sure adding access=yes, will work, then I will do that and test it.
Agreed a traffic_calming tag is more apt in some situations, but for example, there is a lift_gate at both ends of the Nam Nao National park, on Hwy 12. Its a lift gate, there is no better description, and its closed normally. I think currently the routers wont take you down it.
Anyone know how long it takes the new tags to be used by the OSM routing engines? I know its not immediate.

Hi Russ,

Using the barrier tag doesn’t sound right for me. Usually the impact they have is in my experience a slow down of traffic.

So the traffic_calming tag sounds better. Osmand has reduced the frequency of data updates. So it might take some time to get rid of bad tagging.

I am not too certain amount whether to tag such checkpoints at all.
Some might be quite permanent in front of a police box. Others might, be more flexible.
For me there is not much benefits on having them mapped. But understand this is highly dependent on personal interest.

Once our bus was stopped five times on a trip back from Sangkhlaburi. But they had been only interested in seeing ID cards of those looking Burmese. Think I had added some of the check points. Thinking again about it I would vote to remove them.


if it helps, I use military=checkpoint in the south