0

After the Route 360 QGIS plugin stopped working, I developed my own script to handle CSV to GeoJSON travel time polygons.

Up until recently, I had been using this page I created to turn CSV files into travel time polygons outputted as a GeoJSON file. This would just use PHP to make a cURL request and give the response to the user. Right now it's in a debugging mode to output as much info as possible.

I have been in discussion with the developers and they can't seem to get to the bottom of the issue.

Does anyone know of any resources for getting travel time polygons for Targomo (formerly Route 360) outputted as a GeoJSON file instead of just being displayed in the browser? All of the examples on the Targomo website are to output to the Web browser instead of a file.

Improve this question
1

There are geojson-specific resources on this page here: https://targomo.com/developers/resources/concepts/gis/

With cURL, I often use in conjunction with "jq" to parse the return prior to piping to file:

curl --compressed -H 'Content-Type: application/json' --data "{'sources':[{'lat':52.52,'lng':13.405,'id':'54321','tm':{'walk':{}}}],'polygon':{'serializer':'geojson','srid':'4326','values':[1200,600]}}" 'https://service.targomo.com/westcentraleurope/v1/polygon_post?key=API_KEY' | jq .data > polygons.geojson

Improve this answer
9
  • though GeoJSON is not EPSG:4326
    – nmtoken
    Nov 9 '19 at 8:06
  • per geojson spec, the coordinate reference system for GeoJSON is WGS84. WGS84 IS EPSG:4326.
    – abenrob
    Nov 10 '19 at 9:09
  • The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. This is equivalent to the coordinate reference system identified by the Open Geospatial Consortium (OGC) URN urn:ogc:def:crs:OGC::CRS84. But EPSG::4326 is lat/long. So they are not the same.
    – nmtoken
    Nov 10 '19 at 9:16
  • 1
    Considering that the GeoJSON spec was released some time after the definition of EPSG:4326, it's odd wouldn't you think that it gave the CRS a different authority and code? rather the different code shows us that GeoJSON is not EPSG:4326. OGC came up with CRS:84 because it too made a hash up of axes order in the WMS 1.1.1 specification by incorrectly asserting that EPSG:4326 was lon lat. The WMS 1.3.0 specification uses EPSG:4326 correctly (lat/lon) but all WMS 1.3.0 service software must offer support for CRS:84 to allow service providers to offer clients WGS 84 long/lat .
    – nmtoken
    Nov 10 '19 at 9:27
  • gis.stackexchange.com/a/3342/13970
    – abenrob
    Nov 10 '19 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.