Wikidata:Property proposal/same transportation stop on the other side of the road
same transportation stop on the other side of the road
editOriginally proposed at Wikidata:Property proposal/Place
Description | pair transportation stop (eg. bus stop) for this item. May be located on the other side of the road or around a bend |
---|---|
Represents | public transport stop (Q548662) |
Data type | Item |
Domain | public transport stop (Q548662) (eg. bus stop (Q953806)) |
Example 1 | Roddom no. 3 (Q75271893) → Roddom no. 3 (Q90985343) |
Example 2 | Meschersky prospekt (Q90990057) → Meschersky prospekt (Q74170211) |
Example 3 | Davydkovskaya ulitsa (Q90994636) → Davydkovskaya ulitsa (Q75262979) + Davydkovskaya ulitsa (Q75264230) |
Planned use | public transport stop (Q548662) (eg. bus stop (Q953806)) |
Expected completeness | eventually complete (Q21873974) |
See also |
Motivation
editFollowing the example of OpenStreetMap, I suggest having separate elements for bus/trolleybus stops on each side of the road. For example, I attached two of their entities of bus stops to our two (1247147305 → Roddom no. 3 (Q75271893) + 2339398944 → Roddom no. 3 (Q90985343)).
On the example of Moscow, I can say that sometimes a stop on the opposite side of the street can be renamed, leaving the second old name[1], respectively, we should be able to separately keep a history of the names of each stop. Also on the different sides of the road different routes may stop. Pair bus stops may have different equipment (pavilion, access to wi-fi), different operating mode (request or regular stop), different dates of establishment (if first of them did not have pair for a some time).
We also need to have separate coordinate location (P625) for each stop, especially since they can move independently on each side.
So, it should be symmetric property (Q18647518) for grouping pairs of public transport stop (Q548662) (something like this).
As for triple example (Davydkovskaya ulitsa (Q90994636) + Davydkovskaya ulitsa (Q75262979) + Davydkovskaya ulitsa (Q75264230)), this bus stops are located on intersection (Q285783)[2] and have the same name so I think should be grouped too. Сидик из ПТУ (talk) 12:08, 18 April 2020 (UTC)
Discussion
edit- Weak oppose It seems to me like for a given station like "Davydkovskaya ulitsa" you have two bus stops for trains going in both directions. There are also stations that will have more then two bus stops. It seems to me like a better model would be to have on item for "Davydkovskaya ulitsa" that then has two bus stops that are "part of" the main item. ChristianKl ❪✉❫ 16:08, 21 April 2020 (UTC)
- "Davydkovskaya ulitsa" means Davydkovskaya Street (Q4153718) in Russian. There are not any bus station (Q494829) here and I don't see any usage for station item because any of this three bus stops[3][4][5] can be independently renamed. The parent element in this case will be excessive bureaucratic fiction, it essentially does not exist in real life, all the properties must still be maintained in the child elements. Otherwise, I would simply combine these pairs and triples into single elements again, but above I write why this is not an optimal option. However, I don’t think that bus station (Q494829) need child items for each their bus stop (Q953806) as items are not needed for each platform (Q64896574) of railway station (Q55488) or each door of terminal (Q67183571). Сидик из ПТУ (talk) 10:42, 22 April 2020 (UTC)
- @Сидик из ПТУ: We need a model that doesn't just work for the Russian stations but that generalizes. ChristianKl ❪✉❫ 22:50, 19 May 2020 (UTC)
- For example, here is a similar situation in Denmark[6][7], Australia[8][9], Chile[10][11]. Сидик из ПТУ (talk) 06:52, 21 May 2020 (UTC)
- @Сидик из ПТУ: that example currently contains no information about what name is used in the countries for the stations (e.g. on the train schedule). ChristianKl ❪✉❫ 15:03, 16 July 2020 (UTC)
- @ChristianKl: do you really think that these pairs of stops need a third element to describe a certain bus station? What data will need to be included so that it is not just a duplication of information from the first two items? And if not the names, then the list of bus routes for such pairs certainly does not have to coincide. For example, if we describe a circle route (Q145179) then the bus will make stops only on one side of the street, so it is advisable to indicate a stop on a specific side of the street in the route chain. OK, let's look to names of Chilean bus stops I found. [12] is a PI985-Camino A Lonquén / Esq. Los Yacimientos although [13] is a PG1432-Camino A Lonquén / Esq. Camino Privado. It turns out that they even have different IDs: PI985 and PG1432. Сидик из ПТУ (talk) 09:36, 19 July 2020 (UTC)
- I do not intend to use the property for rail or subway at all. Only for road transport but maybe for trams and boats. Сидик из ПТУ (talk) 10:38, 19 July 2020 (UTC)
- @Сидик из ПТУ: that example currently contains no information about what name is used in the countries for the stations (e.g. on the train schedule). ChristianKl ❪✉❫ 15:03, 16 July 2020 (UTC)
- For example, here is a similar situation in Denmark[6][7], Australia[8][9], Chile[10][11]. Сидик из ПТУ (talk) 06:52, 21 May 2020 (UTC)
- @Сидик из ПТУ: We need a model that doesn't just work for the Russian stations but that generalizes. ChristianKl ❪✉❫ 22:50, 19 May 2020 (UTC)
- "Davydkovskaya ulitsa" means Davydkovskaya Street (Q4153718) in Russian. There are not any bus station (Q494829) here and I don't see any usage for station item because any of this three bus stops[3][4][5] can be independently renamed. The parent element in this case will be excessive bureaucratic fiction, it essentially does not exist in real life, all the properties must still be maintained in the child elements. Otherwise, I would simply combine these pairs and triples into single elements again, but above I write why this is not an optimal option. However, I don’t think that bus station (Q494829) need child items for each their bus stop (Q953806) as items are not needed for each platform (Q64896574) of railway station (Q55488) or each door of terminal (Q67183571). Сидик из ПТУ (talk) 10:42, 22 April 2020 (UTC)
- Support Nepalicoi (talk) 18:40, 19 May 2020 (UTC)
Notified participants of WikiProject Railways --- Jura 14:59, 15 July 2020 (UTC)
- Oppose I think, Wikidata should't be as detailed as OpenStreetMap (Q936). Public transport tagging in OSM is very complicated. I like the beauty and simplicity of OSM and how Wikidata and OSM match: OSM shows the details and exact positions, Wikidata is perfect for the big picture (of a bus stop, e.g.). --Geogast (talk) 18:51, 15 July 2020 (UTC)
- Weak oppose per Geogast. Too detailed. Multichill (talk) 10:20, 18 July 2020 (UTC)
- It would be too detailed (and redundant) for a couple of bus stops to create another element of which they would be a part (bus station consisting of two road signs), as suggested above by ChristianKl. It would also be an overkill to create an element for each shelter at the bus station. You are now voting against cross links between items of bus stops. But how then to navigate between their items? Сидик из ПТУ (talk) 09:13, 19 July 2020 (UTC)
@SemModAP, IrvingBirger, WiseWoman, Dansen89, Nepalicoi: Сидик из ПТУ (talk) 09:55, 19 July 2020 (UTC) @Theklan, Chabe01, Stolbovsky, Xivk: Сидик из ПТУ (talk) 10:15, 19 July 2020 (UTC)
- As a last resort, we can use the interchange station (P833) for the stated purpose but I'm not sure for multi-lane highways. Сидик из ПТУ (talk) 10:19, 19 July 2020 (UTC)
- Oppose This property is far too vaguely defined. It could be useful to represent this type of relationship in Wikidata, but it would have to use more specific criteria for the relationship to make its usage clearer (e.g. share at least one route, share a name, not the same direction) and it may well be better to represent this using parent/child items, as is currently done for some interchange stations, instead of using a many-to-many property. Jc86035 (talk) 00:56, 7 August 2020 (UTC)
- Oppose Per the above. Don't ping me NMaia (talk) 01:39, 11 November 2020 (UTC)
- Not done@Сидик из ПТУ, Jc86035, Geogast, Jura1, Nepalicoi: due to wide opposition. ChristianKl ❪✉❫ 16:15, 8 December 2020 (UTC)