| Forum | GitHub | Maps | Blog

Use Block_Area in the Optimization API



we want to add blocked areas to a map (such as building sites or so). And we want, that the Routing API respects the blocked_areas in the returned (optimized) route.

To achive this, we use the block_area property in the route API.

But the parameter seems to be ignored?!

This is our URL:,8.549277&point=49.187137,8.535487&point=49.154412,8.574702&point=49.158956,8.58513&point=49.116592,8.575745&point=49.052883,8.520463&point=49.052883,8.520463&point=49.046426,8.467731&point=49.012472,8.446729&point=49.012472,8.446729&point=49.012472,8.446729&point=49.012472,8.446729&point=49.012472,8.446729&point=49.012472,8.446729&point=49.012472,8.446729&point=49.012472,8.446729&instructions=true&type=json&key=[THE_KEY]&vehicle=small_truck&locale=de&ch=%5Bobject%20Object%5D&block_area=49.107694%2C8.573901%2C30%3B49.173614%2C8.550427%2C30


Would you try to add ch.disable=true?


Sorry, I postet the wrong request.

Here’s the right one and as you can see, the ch.disabled is set to true



This looks like a bug, strange. Will have a look.


Ah, this is a current limitation that we have to fix sooner than later as it is really ugly:

The problem is that the block area must contain at least one junction in order to function properly. You can do this in your case via increasing the radius to 300 for both:



Okay, can you describe the issue a bit more?

The thing is, if we have a larger circle of the restricted area, then there is a chance that we block also areas, which shouldn’t be blocked.

So, if we block a land road without junctions, then this wouldn’t work, but if we block a junction of the land road with another road, then both roads are blocked on this point, right?


then there is a chance that we block also areas, which shouldn’t be blocked.

Yes, sure. Unfortunately in this case you’ll have to move the coordinates of the block area a bit to keep the small radius or wait until this ugliness is fixed.

BTW: It must not be a real “junction”. Also a change in expected speed leading to an internal node is sufficient so it is rather unlikely that there is really no node. (you can see all internal nodes of a path via attaching &debug=true&details=edge_id at GraphHopper Maps)