Getting Error: Gateway Timeout (HTTP 504) in RStudio

[cacomixtla]

Is there an existing issue for this?

• I have searched the existing issues

Where did you encounter this issue?

live API

Request URL

https://openrouteservice.org/dev/#/api-docs/v2/isochrones

POST Request Body

library(openrouteservice)
library(mapview)
library(tidyverse)
library(osmdata)
library(sf)
library(paletteer)
library(ggfx)

ors_api_key("5b3ce3597851110001cf62488c30fb776efd4dbb9d3a08e42f286d7d")
coordinates <- data.frame(lon = c(-0.171201), lat = c(51.464290))

cj_iso <- ors_isochrones(locations = coordinates, profile = "foot-walking", range = 6000, interval = 600, output = "sf")

Response

Error: Gateway Timeout (HTTP 504).

Current behavior

I'm using RStudio and the ORS's API for mapping isochrones between a UK station and walking time. It seems alright until I try to give the isochrones a range and an interval, in this case 6000 and 600 in that order.

cj_iso <- ors_isochrones(locations = coordinates, profile = "foot-walking", range = 6000, interval = 600, output = "sf")

It takes several minutes and the result is this message from the terminal:

Error: Gateway Timeout (HTTP 504).

So I don't know what else to do.

It's important to say that I contacted support and changing the interval to 600 worked out just fine, but I really needed to try 600.

Expected behavior

The expected is running the code just as it is, with visually the double of isochrones in map.

Openrouteservice Version

6.6.1

Build date

No response

Graph date

No response

Forum Topic Link

No response

[EricSamson-Tract]

Just wanted to tack on and say that I am also experiencing the same problem for requesting isochrones from python.

[aoles]

I can confirm that, apparently, there is a performance issue for intervals smaller than 1000. This is quite evident from the following example, where the query with an interval of 500 takes almost 50x longer than one with and interval of 1000. Please note that this phenomenon is not R-specific, but rather a problem with the backend.

library(openrouteservice)

coordinates <- data.frame(lon = c(-0.171201), lat = c(51.464290))
profile <- "foot-walking"
range <- 3000
intervals <- c(3000, 1500, 1000, 500, 300)

query_times <- sapply(intervals, function(interval) {
  res <- ors_isochrones(locations = coordinates, profile = profile, range = range, interval = interval)
  attr(res, "query_time")
})

query_times
#> [1]  0.607648  0.475013  0.396023 19.449573 27.922645
plot(intervals, query_times)

^{Created on 2023-10-20 with reprex v2.0.2}

[aoles]

Some additional benchmarks comparing the performance of isochrone queries across algorithms and ORS versions.

• black is ORS v6.8.3
• red is ORS v8 RC
• blue is ORS v8 RC fastisochrones
  

The plot has been generated with the following script.

library(openrouteservice)

coordinates <- list(c(8.676312, 49.371756))
profile <- "foot-walking"
range <- 3000
intervals <- c(3000, 1500, 1000, 500, 300)
rep <- 7

query_times <- function(ors_url = NULL) {
  options(openrouteservice.url = ors_url)
  sapply(intervals, function(interval) {
    cl = as.call(c(ors_isochrones, list(locations = coordinates, profile = profile, range = range, interval = interval)))
    query_times = as.vector(replicate(rep, attr(eval(cl), "query_time")))
    median(query_times)
  })
}

query_times_v7 <- query_times()
query_times_v7_fast <- query_times("http://localhost:8082/ors")
query_times_v6 <- query_times("http://localhost:8083/ors")

yran <- range(c(query_times_v6, query_times_v7, query_times_v7_fast))

plot(intervals, query_times_v7, col = "red", ylim = yran, ylab = "Query times [s]")
points(intervals, query_times_v7_fast, col = "blue")
points(intervals, query_times_v6)

[aoles]

Dear @cacomixtla,

thanks a lot for reporting the issue and for your patience.

The timeout error message you observe is caused by some performance issues of the isochrones service. Basically, the query timeouts before the service is able to compute the result.

The ORS team will look into addressing this deficiency. In the meantime, you can circumvent the issue by querying for single ranges corresponding to the desired intervals and combining them into a single isochrone geometry like in the example below.

Hope this helps. Cheers!
Andrzej

library(openrouteservice)
library(mapview)

coordinates <- data.frame(lon = c(-0.171201), lat = c(51.464290))
profile <- "foot-walking"
range <- 6000
interval <- 600
ranges <- seq(from = interval, to = range, by = interval)

res <- lapply(ranges, function(range) ors_isochrones(locations = coordinates, profile = profile, range = range, output = "sf"))
isochrone <- do.call(rbind, res)
isochrone$center <- NULL # otherwise mapview complains  ¯\_(ツ)_/¯

mapview(isochrone, alpha.regions = 0.2, homebutton = FALSE, legend = FALSE)

^{Created on 2023-10-23 with reprex v2.0.2}

[cacomixtla]

Sure, thank you a lot 😊 El lun., 23 de octubre de 2023 4:53 p. m., Andrzej K. Oleś < ***@***.***> escribió:

…

Dear @cacomixtla <https://github.com/cacomixtla>, thanks a lot for reporting the issue and for your patience. The timeout error message you observe is caused by some performance issues of the isochrones service. Basically, the query timeouts before the service is able to compute the result. The ORS team will look into addressing this deficiency. In the meantime, you can circumvent the issue by querying for single ranges corresponding to the desired intervals and combining them into a single isochrone geometry like in the example below. Hope this helps. Cheers! Andrzej library(openrouteservice) library(mapview) coordinates <- data.frame(lon = c(-0.171201), lat = c(51.464290))profile <- "foot-walking"range <- 6000interval <- 600ranges <- seq(from = interval, to = range, by = interval) res <- lapply(ranges, function(range) ors_isochrones(locations = coordinates, profile = profile, range = range, output = "sf"))isochrone <- do.call(rbind, res)isochrone$center <- NULL # otherwise mapview complains ¯\_(ツ)_/¯ mapview(isochrone, alpha.regions = 0.2, homebutton = FALSE, legend = FALSE) <https://camo.githubusercontent.com/6cb96ee377713d6ff7d349a835973ad7ac4f1649b4a76a2b17c74d0c887a93ef/68747470733a2f2f692e696d6775722e636f6d2f745249526e6c422e706e67> Created on 2023-10-23 with reprex v2.0.2 <https://reprex.tidyverse.org> — Reply to this email directly, view it on GitHub <#1573 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BABV6KRSB3IIWCZXZKUMM7LYA3RNHAVCNFSM6AAAAAA6FZ4HUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGA4DCMBYGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aoles]

Thanks @cacomixtla for your patience!

As it turns out, some of the performance issues have been already addressed in #1508. This fix is now included in 7.1.1 release which will be rolled out to ORS public API soon. Maybe @rabidllama could provide you with some more details on the timeline.

Apart from that, we are investigating possible further improvements to isochrone query times in #1607, so stay tuned!

Cheers!