`location` object

[kiliankoe]

The journey definition speaks of location objects. I'm guessing these reference locations that are neither stops/stations/etc. and are currently still left out of the spec?

[juliuste]

You're right! We really need some way to specify the notion of a location, e.g. in order to enable people to build address-to-address-routing using FPTF. We just discussed this and propose a new location type, which would allow routing between locations/stations/stops and also replace the current, optional address and coordinates keys in station and stop. We came up with something like this, we had a slight disagreement about the best solution for saving coordinates though:

{
    type: 'location',
    address: 'Platz der Republik 1, 11011 Berlin', // optional
    name: 'Reichstagsgebäude' // optional,

    // first proposal for coordinates
    coordinates: { // optional, maybe 'coordinate' (see issue #15)
        longitude: 13.4 // required
        latitude: 52.5 // required
        altitude: 1300 // optional
    },

    // second proposal for coordinates (inline)
    longitude: 13.4, // optional
    latitude: 52.5 // optional
    altitude: 1300 // optional
}

While the second proposal for coordinates reduces the depth of the data, the first variant embraces that both coordinate dimensions condition each other: There must always be a latitude if there is a longitude, and vice versa.

I propose a small github poll on this issue, vote 🎉 for the first proposal (separate coordinates object) and ❤️ for the second variant (inline latitude, longitude).

edit by @derhuerst: add altitude.

[juliuste]

(If you have any objections, feel free to share them, don't be cowed by the poll)

[kiliankoe]

GitHub's mobile site still doesn't do emoji reactions :/

I much prefer the first variant to store the coordinate data in a separate object to stay in line with coordinate handling elsewhere in the spec.

[derhuerst]

Everywhere else, we would use location objects instead of coordinates.

[juliuste]

I much prefer the first variant to store the coordinate data in a separate object to stay in line with coordinate handling elsewhere in the spec.

Please note though that we also propose to replace the current coordinates and address attributes with the new location objects.

edit: Didn‘t see @derhuerst already answered this, I‘m keeping this reply anyways.

[kiliankoe]

Oh, must've read over that part^^

In that case I think I might actually prefer variant 2, although having the optionality of one field being determined by the other is kinda weird (probably just programmatically, not really regarding the data itself), but that's just a minor detail. And it would "solve" #15 by just ignoring it altogether 🙈😄

[derhuerst]

So? What do we do now that we have a tie?

[juliuste]

Ok, to make some progress here, I'd be willing to withdraw my vote. So we inline the locations, which conveniently also closes #15, as @kiliankoe already pointed out.