Good day guys,
basic request: https://graphhopper.com/api/1/route?key=<>&point=-38.19293%2C145.30335&point=-38.15039%2C145.36817&locale=en&optimize=false&instructions=true&vehicle=foot&points_encoded=true&details=street_name&block_area=-38.42995%2C145.36435%2C100&ch.disable=true
Problem because of “crazy” “block_area” in the sea.
How this happen? User just added (most probably by accident) no-go area in app.
Solution? Because user and also app, has no idea about data coverage, should be these points just silently ignored?
This is a good question. If you add a block_area and your intent is to block something and there was nothing found then IMO this should return a bad request (?)
I’ll simplify it from user point of view: imagine user set this because he wanted (not as mistake when using app). He wants to be sure, that app won’t compute route over defined area, but instead receive error that server does not have routing data in defined area. Does it make sense?
From technical point of view: user set no-go area and server return error. What should app do? Inform user that in defined area are not routing data and defined area is useless so it should be removed? I think this only complicates usability, because user should not care about this “technical problem”.
Or am I missing something that should explain to me, that this error is needed? Do you have any other customers that use this functionality? If so, how they handle this error?
Why do you think the flow is complicated? If the user adds this block_area and we return an error that basically says “this won’t make sense here”, you’ll inform or not inform the user and remove the added block area. I think it is important to offer this information as it might be confusing that the block area does not work.
Hello. What you wrote it makes sense, anyway it just complicate life when used in app we create. User get feedback after he start compute of route, not in the moment, he insert this block-area definition in the map. Also in this case, user added this area most probably by accident.
So result is: he write on our support site, because he has no idea what error we display (exact text from your server because app is not prepared on this) means and he also do not know what are “no-go points”, because he probably added this definition into map by accident. So instead of just ignoring this definition by your server, he have to deal with it.
Ok then. I’ll have to remove this invalid no-go points automatically on background and send compute request once more. Thanks for discussion.
Ok then. I’ll have to remove this invalid no-go points automatically on background and send compute request once more. Thanks for discussion.
I’m open for suggestions on how to improve this handling, but hiding this from the API user is not a good option as it removes the possibility to inform the user.
Good evening Peter,
just for your information, we may close this issue.
I’m open for suggestions on how to improve this handling, but hiding this from the API user is not a good option as it removes the possibility to inform the user.
What I wanted to tell since begin is how I see it: we do not need to inform the user. I’m sure that user really does not care if a no-go area is in some “invalid location”.
I made in app system that, based on the response from routing engine, the problematic no-go area will be automatically disabled and the request will be sent once more. So “solved”. Thanks
