The linestring response from the journey endpoint is inverted. The GeoJSON response is incorrectly ordered [Latitude, Longitude] where the standard should be [Longitude, Latitude].
The is correctly used in the line route endpoint where the response is ordered and can be plotted as a line geometry on a compliant map.
It is quite annoying that there’s no universal consistency when it comes to the order of coordinates. It seems like the standard for GeoJSON is indeed [Longitude, Latitude] ( RFC 7946 - The GeoJSON Format (ietf.org)), but I’m guessing the API might not use this order because the majority of map software (e.g. Leaflet, Google Maps API, Google Maps SDKs, Apple MapKit, etc) all use [Latitude, Longitude] ( lon lat lon lat lon - macwright.com), so it’s easier to integrate the API into third party maps.
There isn’t really a consistency on which is “correct”, but I guess since the API uses the GeoJSON format it should conform to its [lon, lat] format. Though changing this now is likely to break a lot of existing software.
However, with the API not being consistent between 2 different endpoints this is a wider issue when using conformant software. As I don’t have control over the map platform, I cant use the API!
Oh I apologise, I thought the problem was that it was in the wrong order, not that it was inconsistent. That does seem very odd…
