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.

Vince
  • 20,017
  • 15
  • 45
  • 64
SimpleProgrammer
  • 232
  • 1
  • 10

1 Answers1

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

abenrob
  • 175
  • 1
  • 8
  • though GeoJSON is not EPSG:4326 – nmtoken Nov 09 '19 at 08:06
  • per geojson spec, the coordinate reference system for GeoJSON is WGS84. WGS84 IS EPSG:4326. – abenrob Nov 10 '19 at 09: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 09: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 09:27
  • https://gis.stackexchange.com/a/3342/13970 – abenrob Nov 10 '19 at 15:42
  • GeoJSON is not a perfect standard, and the long/lat vs lat/long issue/discussion is far from clear or resolved (https://macwright.org/lonlat/). FWIW, many geospatial development tools (postgis in this case) interpret GeoJSON's crs as EPSG:4326, thus the quasi-standard. Not really worth continuing the thread. – abenrob Nov 10 '19 at 15:49
  • There's nothing wrong with the GeoJSON format, it's a simple JSON format for showing WGS 84 datum coordinates in long/lat. It's just the projection is not EPSG:4326. – nmtoken Nov 10 '19 at 15:53
  • Yes several tools have coordinate axis wrong for EPSG:4326. The definitive reference is the EPSG Geodetic Parameter Registry. Note that World Geodetic System 1984 datum is not EPSG:4326 it's EPSG::6326, and the WGS 84 ellipsoid is EPSG:7030 – nmtoken Nov 10 '19 at 16:00
  • Let us continue this discussion in chat. – abenrob Nov 10 '19 at 17:03