public-transport/friendly-public-transport-format

Country information in models

DmitriyBobrovskiy opened this issue · 7 comments

DmitriyBobrovskiy commented

Hi,
Have you thought about adding country info to specification?

derhuerst commented

What do you mean by that? Can you elaborate?

DmitriyBobrovskiy commented

Sure, I mean if I provide API for travelling between different countries it can be useful to know in what country some station/stop/location is.
For example ecolines provide country code in ISO-3166

{
    "description": "Bus Station (Dworzec PKS) on 1 Sucha str.",
    "id": 598,
    "keywords": "Wroclaw Wroclaw Wroclaw Вроцлав",
    "location": {
        "latitude": "51.096756",
        "longitude": "17.035747"
    },
    "state": "PL",
    "title": "Wroclaw"
}

And that would be good to have optional property in location for instance to store country code.

Does that answer your question?

derhuerst commented

In public-transport/transport-apis#1, we had a similar discussion: How do we define a mechanism to encode a geographical/political relationship that works across the globe? We agreed that using ISO-3166 is the best system we're currently aware of.

Regarding your proposal (adding a field named state): Shall we name it something more general, because a state is usually a specific type/level of geographic/political entities? E.g. region, like we do it in transport-apis.

What do you think @juliuste, @matkoniecz & @kiliankoe?

matkoniecz commented

https://github.com/osmlab/name-suggestion-index may be useful here

They record where given brand is active - most of that is country level but sometimes special weirdness needs to be handled.

See say https://github.com/osmlab/name-suggestion-index/blob/37b1ecead8a22d9833fd48eea9977d5207a69716/data/brands/amenity/fast_food.json#L512 that (a) excludes au in entirety and handles

Burger King has the right to use this name throughout USA, with the exception of a 20-mile radius surrounding a restaurant, also called Burger King, in Mattoon.

See osmlab/name-suggestion-index#4817

In general that project has this part of setting in quite active use, so this solution is relatively battle tested (it was redesigned at least once)

See https://github.com/osmlab/name-suggestion-index/wiki/Contributing#locationset-required for documentation

DmitriyBobrovskiy commented

Regarding your proposal (adding a field named state): Shall we name it something more general, because a state is usually a specific type/level of geographic/political entities? E.g. region, like we do it in transport-apis.

But usually trips happen from one political entity to another one, isn't it?
Region in my opinion is quite ambiguous, because for instance Africa is a region, but not a country.

vkrause commented

In public-transport/transport-apis#1, we had a similar discussion: How do we define a mechanism to encode a geographical/political relationship that works across the globe? We agreed that using ISO-3166 is the best system we're currently aware of.

Regarding your proposal (adding a field named state): Shall we name it something more general, because a state is usually a specific type/level of geographic/political entities? E.g. region, like we do it in transport-apis.

transport-apis mixes countries (ISO 3166-1) and country subdivisions (ISO 3166-2) in its region field, which is a bit unusual. It might make more sense to follow common naming conventions for address fields here, such as schema.org/PostalAddress or vCard. Those use country (for ISO 3166-1) and region (for ISO 3166-2). That would also allow to consistently extend this by more address fields should that become necessary.

  • 👍2
derhuerst commented

Let's follow schema.org/PostalAddress then, shall we?

  • 👍1