x/y inverted in /locations result set

[marcelstoer]

x/y are supposed to represent lat/long. This works fine for the URL parameters. However, in the result set x represents long and vice versa.

Example: http://transport.opendata.ch/v1/locations?x=47.1795&y=8.00459

{"stations":[{"id":"8502006","name":"Wauwil","score":null,"coordinate":{"type":"WGS84","x":8.019016,"y":47.183848},"distance":1192.7},{"id":"8582442","name":"Wauwil, Zentrum","score":null,"coordinate":{"type":"WGS84","x":8.019483,"y":47.184837},"distance":1272.4},....

Just noticed that it's actually coming back that way from Hafas. This is the request submitted: http://fahrplan.sbb.ch/bin/query.exe/dny?performLocating=2&tpl=stop2json&look_maxno=10&look_stopclass=1023&look_maxdist=5000&look_y=47043989&look_x=8465647 Here's what's coming back:

{ prods:"1023",
stops:
[
{
x : "8466696",
y : "47044003",
extId:"8505074",
puic:"95",
name : "Rigi Kaltbad-First",
prodclass : "32",
urlname : "Rigi%20Kaltbad-First"
}
,

I guess in order to fix this in a future-proof way (that is until Hafas fixes this) you'd have to check whether y > x then invert and skip otherwise.

[HthSolid]

was just about to post the same :-)

[marcelstoer]

Something like this added to Entity/Coordinate.php:42 would fix it:

        $externalX = self::intToFloat($json->x);
        $externalY = self::intToFloat($json->y);
        if ($externalY > $externalX) { // HAFAS bug, returns inverted lat/long
          $coordinate->x = $externalY;
          $coordinate->y = $externalX;
        } else {
          $coordinate->x = $externalX;
          $coordinate->y = $externalY;
        }

[marcelstoer]

What's the meaning of 'Fixed' here? It may be fixed in source code but as long as the fixed version isn't deployed at transport.opendata.ch it ain't really "fixed" for the general public.

http://transport.opendata.ch/v1/locations?query=neuchatel still exhibits the old buggy x/y values. How would I find out what version/revision is actually deployed?

[fabian]

I usually deploy the changes right after the commit - the server is currently at commit 2040e6e5f62e34f3c89e160875c41043c42a6c28. I've to look into why they are still returned wrong - search with the coordinates returns the right ones at least… http://transport.opendata.ch/v1/locations?x=47.1795&y=8.00459

[fabian]

I think I finally found the fix for this now. Hope it doesn't brake too many existing applications.