friendly-public-transport-format
friendly-public-transport-format copied to clipboard
Country information in models
Hi, Have you thought about adding country info to specification?
What do you mean by that? Can you elaborate?
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?
In https://github.com/public-transport/transport-apis/pull/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?
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 https://github.com/osmlab/name-suggestion-index/issues/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
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 intransport-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.
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 intransport-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.
Let's follow schema.org/PostalAddress
then, shall we?