giscience / openelevationservice Goto Github PK

Hi!

We are testing the service and found that with encoded polylines with many points (more than 300) the API returns http 400. It does work with simpler encoded polylines.

Is there a known limit in the number of points for the /elevation/line endopoint?

Thanks!

Sampling along lines in fixed intervals and/or per raster cell:
http://blog.mathieu-leplatre.info/drape-lines-on-a-dem-with-postgis.html

currently it is implied that the elevation unit is meters above sea level.
This should be stated somewhere, so people using other elevation units aren't confused.

First reported here:
https://ask.openrouteservice.org/t/elevation-api-not-returning-same-number-of-points-as-sent-to-it/343/5?u=nils

After some digging, it seems I rounded incoming coordinates wrongly (Python3 actually changed the rounding logic compared to Python2).

Hi,

There is an error

jQuery.getJSON('https://api.openrouteservice.org/elevation/line?api_key=my-api-key&geometry=[[13.349762,38.11295],[12.638397,37.645772]]', function (data) {
console.log(data);
}

Chrome developer result:

{code: 405, message: "HTTP Method not allowed"}

Thanks.

Hi,

I was gonna try to deploy this locally to test out, but it appears that the link for the FTP credential sign up (https://harvestchoice.wufoo.com/forms/download-cgiarcsi-srtm/) in the README is broken. Is there another way to get access to the FTP to run the importdata command? Thanks for the help in advance!

API should also accept 'Content-Type': 'application/json;charset=utf-8' as request Header.
This kind of requests currently fails with:

{
"code": 4001,
"message": "HeaderError: Content-Type header is not application/json"
}

Recent updates to the package introduced improvements to encodedpolyline format by adding support for increased precision. While implementing the new encodedpolyline6 format the originally accepted encodedpolyline parameter value was renamed to encodedpolyline5.

This approach, however, breaks backwards compatibility. Apart from it there is also no particular reason to use a different name for the format which follows Google's encoded polyline standard. Please consider renaming encodedpolyline5 to just encodedpolyline.

Cheers,
Andrzej

I've tried building the Docker image, which failed with the following message. This happens during the step where the Python requirements are installed.

configure: error: in `/tmp/pip-build-mmeastyv/gevent/deps/libev':
configure: error: no acceptable C compiler found in $PATH

Attached you can find the full log output from the beginning of the step.
I guess this is because the newer Ubuntu Docker images are smaller than before. I'm sure they dropped everything from the image that is not needed.

I'm currently trying to fix this issue and prepare a pull request afterwards.

docker_build.log

Hi,

I get the following error after: sudo docker-compose up -d

#0 32.10     copying src/greenlet/platform/switch_x86_unix.h -> build/lib.linux-x86_64-3.6/greenlet/platform
#0 32.10     running build_ext
#0 32.10     building 'greenlet._greenlet' extension
#0 32.10     creating build/temp.linux-x86_64-3.6
#0 32.10     creating build/temp.linux-x86_64-3.6/src
#0 32.10     creating build/temp.linux-x86_64-3.6/src/greenlet
#0 32.10     x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/oes_venv/include -I/usr/include/python3.6m -c src/greenlet/greenlet.cpp -o build/temp.linux-x86_64-3.6/src/greenlet/greenlet.o
#0 32.10     unable to execute 'x86_64-linux-gnu-gcc': No such file or directory
#0 32.10     error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
#0 32.10     
#0 32.10     ----------------------------------------
#0 32.21 Command "/oes_venv/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-9yrh8slh/greenlet/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-xmv34gcf-record/install-record.txt --single-version-externally-managed --compile --install-headers /oes_venv/include/site/python3.6/greenlet" failed with error code 1 in /tmp/pip-build-9yrh8slh/greenlet/
------
failed to solve: executor failed running [/bin/sh -c /oes_venv/bin/pip3 install -r /deploy/app/requirements.txt]: exit code: 1
(base) beatgurtner@bg openelevationservice % 

I did not change the content of the *.yml file:

---
attribution: "service by https://openrouteservice.org | data by http://srtm.csi.cgiar.org"
coord_precision: 1e-6
maximum_nodes: 2000
srtm_parameters:
  user: 
  password: 
provider_parameters:
  table_name: oes_cgiar
  db_name: 
  user_name:
  password:
  host: localhost
  port: 5432

Should I change something?

Any idea why I'm getting this error above?

Im using MacOS 13.1 with conda.io, Python 3.11.0 and installed Docker v4.16.2.

Currently the response header contains just Content-Type: application/json and does not specify any encoding unlike the rest of ORS endpoints. This leads to warnings in certain applications as it is not clear which charset to use for parsing the response, see e.g. GIScience/openrouteservice-r#54.

Please consider appending charset=utf-8 to Content-Type.

Just FYI, there has been a similar issue with openpoiservice a while ago, now fixed.

Ref forum.