Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

isochrome no longer working #61

Closed
elkerns opened this issue Jun 12, 2020 · 2 comments
Closed

isochrome no longer working #61

elkerns opened this issue Jun 12, 2020 · 2 comments

Comments

@elkerns
Copy link

elkerns commented Jun 12, 2020

I get the following error no matter what options I use including the exact example code.
"The OSRM server returned an error:
Error: lexical error: invalid char in json text.
<!DOCTYPE HTML PUBLIC "-//IETF/
(right here) ------^"
@ngfrey
Copy link

ngfrey commented Jun 13, 2020

I'm doing a little digging into this as well. Please note: I'm only considering driving examples right now. Also please note: I could be completely wrong about everything. (It's happened before)

As far as I can tell, the problems seem to be two, potentially three fold.

First problem:, Getting greedy. It seems that we can get an error back from the server that says "Request-URI Too Long. The requested URL's length exceeds the capacity limit for this server." This response is HTML, not JSON. The code res <- jsonlite::fromJSON(resRaw) on line ~57 in the osrmTable function doesn't work and we see the simpleError message you have posted in the comment above.

Second problem: Whenever the OSRM server isn't able to find a given destination in the sgrid object that is created by the rgrid function that lives inside the osrmIsochrone function, we get back an error, which is actually HTML, not JSON. Again, we see the whole lexical awesomness error mentioned earlier, but the fundamental reason for this error is vastly different. The concerning part about this is, if you spent the time to figure out which exact destination coordinate is breaking OSRM, and then changed it to be an origin coordinate, the whole thing would work (provided we are not asking for too many points). What does this tell us? Somewhere on the OSRM server, there is different logic running on origin vs destination parsing. Does knowing this really help us? Maybe sorta...but not really. Moving on...

A few ideas on potential solutions
Firstly, if the URIs are just too long, this is an easy fix. You'll notice in the osrmIsochrone function the f500, r500 and st (start index) and en (end index) all use a hard-coded value of 300. Lower this number to say, 200, AND/OR give it a default, but also parameterize it. This solution may be quick, easy, and wrong. But I kept digging further...

If there is different logic running on the origin vs. destination parsing, what might OSRM be doing? Honestly, outside of a hunch, I have no idea, but when reading the documentation I stumbled upon the OSRM's Nearest Service API Endpoint. A potential solution to may be to use the nearest service from OSRM and apply that to every point generated by the sgrid call. Of course, the points from the sgrid object should be transformed via sf::st_transform(sgrid, crs=4326) prior to being used to build out API calls to the nearest service, but if you take the response from the OSRM service and use those values as destinations instead of whatever was calculated by rgrid....it is hard to imagine the OSRM service would fail to process that URL. The caveat this method may solve the problem, but it may end up greatly increasing the number of API calls made to the OSRM server. This means you'll get throttled by OSRM.

If someone else has some ideas, please share. As I said at the start, and as my 3rd ex-wife always reminds me, I could be completely wrong about everything.

@rCarto
Copy link
Member

rCarto commented Jun 14, 2020

Thanks @ngfrey for the investigation.
See #60 for a quick and dirty fix (uri too long, I changed the hard coded value to a lower value).
Note that this only happens with the demo server, I think the problem does not come from OSRM but rather from the demo server config.

@rCarto rCarto closed this as completed in f4c8552 Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rCarto @ngfrey @elkerns