Property talk:P197

Documentation

adjacent station
the stations next to this station, sharing the same line(s)

Description

the stations next to this station, sharing the same line(s), as qualified by connecting line (P81).

Data type

Item

Domain

entry point (Q228332) or proposed railway station (Q28109487)

Allowed values

railway station (Q55488) (note: this should be moved to the property statements)

Usage notes

Use qualifier "towards" (P5051) instead of "direction" (P560) to indicate the final station in that direction (P5051 does not replace P560 when used to indicate cardinal direction)

Example

Heidelberg Central Station (Q467998) → Heidelberg-Kirchheim/Rohrbach station (Q15785174)
Bond Street tube station (Q892189) → Green Park tube station (Q1366462)
JR East Ueno Station (Q124340272) → JR East Tokyo Station (Q124211552)
Berlin-Friedrichstraße railway station (Q702402) → Berlin Hauptbahnhof (Q1097)

Robot and gadget jobs

DeltaBot does the following jobs:

Change the qualifier P560 to P5051

Tracking: same

no label (Q42533391)

Tracking: usage

Category:Pages using Wikidata property P197 (Q113579703)

Qualifier "connecting line" (P197)[edit]

As mentioned in the discussion there, connecting line (P81) should be used as a qualifier. Multiple connecting lines between two stations are possible. --JonnyJD (talk) 14:44, 29 October 2013 (UTC)[reply]

Why should it be instance of railway station?[edit]

I don't see why the concept of adjacent stations only works with railway. Yes, the amount of stations that can be adjacent is limited to the stations connected with railway tracks. However, the more important and/or general distinction is if there is a train/line going that way, isn't it? That would work the same for many busses, to some degree with boats and planes (in these cases a line mostly connects only 2 stations). I'd rather use station (Q719456) --JonnyJD (talk) 00:38, 31 October 2013 (UTC)[reply]

consistency check gadget[edit]

I added this property to my User:JonnyJD/consistency_check.js. This checks for symmetry and if country, instance, coordinates and administrative unit are present. It is not checked if instance of is a subtype of train station, but most of the time the problem is not having any P31 set anyways. --JonnyJD (talk) 23:47, 17 November 2013 (UTC)[reply]

Precise meaning of this property[edit]

Hi,

I was adding symetric P197 values when Nenntmichruhigip reverted me on Mannheim Central Station (Q706994) saying « those would be "next stop of a long distance train" not "neighbour station on same track") » (Special:Diff/470076590). As I'm not sure if the property is more the first or the second (or something/anything else, the current description is quite wide). I see a lot of both (and as I was just replicating, if A P197 B is wrong then B P197 A is also wrong and should be corrected).

@B.Zsolt, Multichill, Liuxinyu970226, Kemenymate, Mahir256, The mitooo:

Cdlt, VIGNERON (talk) 14:39, 24 March 2017 (UTC)[reply]

For information, here is some stations more than 100 km appart (271 results right now, some are geolocation errors).

SELECT DISTINCT ?stationA ?stationALabel ?stationB ?stationBLabel ?coordA ?coordB ?dist
WHERE
{
	?stationA wdt:P197 ?stationB .
	?stationA wdt:P625 ?coordA .
	?stationB wdt:P625 ?coordB .
	BIND( geof:distance( ?coordA , ?coordB) as ?dist ).
	FILTER ( ?dist > 100 )
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
} order by desc(?dist)

Try it!

@VIGNERON: Pinging someone doesn’t work by adding the user link afterwards, and Template:ping on this wiki only supports six users (on other wikis even just five). So I’ll reping those who propably haven’t been notified now: @Mahir256, Gareth, Odder, Lakokat, Dannebrog Spy:@Cuenqui, Monkeyboy1993: --Nenntmichruhigip (talk) 23:20, 13 August 2017 (UTC)[reply]

From looking at the example of Berlin Ostbahnhof (Q683239) adjacent station (P197) Berlin Hauptbahnhof (Q1097) given on the property page it seems you are right, because there (Berlin Stadtbahn (Q694223), VzG 6109) are at least Berlin Alexanderplatz station (Q698497) and Berlin-Friedrichstraße railway station (Q702402) inbetween, but long distance trains don’t stop there. But

the german translation says „on a railway track“ as opposed to „of a railway line“ (which is what I based my revert upon),
the P1646 (P1646) connecting line (P81) wouldn’t make sense with lines, and
this would result in weird lists of statements, considering that
- some trains of a line might skip a station the line would normally stop at,
- several lines use the same track but stop at different stations, and
- all of this can easily change (especially for lines not having clock-face schedule) on timetable changes.

Anyway: I agree that it should be decided what this is supposed to mean and there needs to be a cleanup in both cases. --Nenntmichruhigip (talk) 15:39, 24 March 2017 (UTC)[reply]

@VIGNERON: The usage right now for the Netherlands and other areas I worked on is the next station on the physical line, not the next station where a train stops. Multichill (talk) 22:59, 24 March 2017 (UTC)[reply]

Il est préférable, de prendre la gare voisine au sens physique du terme (les voisines sur les lignes d'infrastructure), et non mentionner la desserte (lignes commerciales), cette dernière pouvant être variable.

En effet, utiliser la desserte alourdit considérablement les tâches de mises à jour, et, par logique, adjacent station est la voisine physique (de plus, on est pas sur une fiche horaires). --NB80 (talk) 23:11, 24 March 2017 (UTC)[reply]

Following NB80 message, a discussion started on w:fr:Discussion Projet:Chemin de fer where Akiry, Quoique, Geralix agree too to limit this property to the physical neighbour. Is there any opposition? I'll begin to remove the claims for commercial neighbour and see if someone disagree. Cdlt, VIGNERON (talk) 10:08, 26 March 2017 (UTC)[reply]

@VIGNERON, Akiry, Quoique, Geralix: pour info : Topic:Tv7ch86ij0y9vk35. --NB80 (talk) 02:48, 29 July 2017 (UTC)[reply]

@NB80:

English:

thank for the info. While some of Pasleim bot actions where wrong, the intend is good (as I did and said on the first message of this discussion, it's just replication by symmetry, so the robot probably should keep going). Otherwise, is there a logical way to detect all stations with adjacent station (P197) that are not physically adjacent? (in addition to stations more than 100 km appart)

Français :

merci de l'info. Cependant, si certaines actions du robot de Pasleim sont erronées, l'intention globale est bonne (comme je le faisais et disais lors du premier message de cette discussion, c'est juste de la réplication par symétrie, du coup le robot devrait probablement continuer son travail). Sinon, y a-t-il une façon logique de détecter toutes les stations avec adjacent station (P197) qui ne sont pas physiquement adjacente ? (en plus des gares à plus de 100 km de distance)

Cdlt, VIGNERON (talk) 08:41, 29 July 2017 (UTC)[reply]

Lien utile (les discussions étant dispersées...) : User talk:NB80#Gare probablement pas voisine en France. --NB80 (talk) 12:27, 29 July 2017 (UTC)[reply]

Just a stupid idea: Maybe someone could make something to display the next couple of stations of a station in a schematic-map-like graphic? (I’ll be offline the next days, so don’t be angry if I don’t respond) --Nenntmichruhigip (talk) 15:50, 19 August 2017 (UTC)[reply]

@Nenntmichruhigip: this is doable (with a SPARQL quary for instance), what do you like exactly? Cdlt VIGNERON (talk) 10:03, 25 December 2017 (UTC)[reply]

I was thinking of a w:en:planar graph (or actually non-planar in some cases) with the stations as vertices and the lines showing their connection as given by this property, with the vertices beeing draggable to manually arrange them similiar to their geographic positions. Obviously for the whole world that would become unmanagable, so abort after a certain distance (nesting limit) from the starting station. For example, for a simple halt (only one railway line) and nesting limit 1, this would result in three vertices and two lines.

If a reverse property is missing, that could be shown i.e. by a dotted line; but even ignoring reverse properties, such a graphic would propably be useful to spot missing stations or completely missing (or wrong) connections. Ideally that graph could be exported to some GIS format to overlay it over a map, and start time (P580)/end time (P582) would be indicated somehow, but I guess I’m day-dreaming a bit there :-) --Nenntmichruhigip (talk) 18:29, 29 December 2017 (UTC)[reply]

When I was completing the P197 statements for all Swiss train stations, I used wikidata-graph-builder. Example with distance 10 links from Olten. Later I also created a map of the Swiss train network on mapbox.com. If there is some demand I can also create it for other countries (or the whole earth). --Pasleim (talk) 18:50, 29 December 2017 (UTC)[reply]

Thank you @Pasleim:, I use too a lot wikidata-graph-builder ; it's quite simple and efficient. Wikidata Query Service - WDQS - can do it too (it's a bit slower : same example with Olten, maybe WDQS can be more precise and it can export in Json which can maybe convert in GeoJson or TopoJson? not sure but I can look into if if you want). Cdlt, VIGNERON (talk) 19:45, 29 December 2017 (UTC)[reply]

Thanks to both of you! Both have their own (dis)advantages (WGB having the lables obstructing the lines and other lables behind them, and seeing items which only point to but aren’t pointed to from the selected stations (quite… interesting with long-distance train statements from other regions); WDQS beeing sometimes even more ignorant to attempts of aligning the items) and have been helpful in finding where more items can be added :-) I’ve asked on Wikidata:Request a query#Map and Graph at the same time about options to get a mixture of WDQS’ Graph and Map views. --Nenntmichruhigip (talk) 20:59, 4 January 2018 (UTC)[reply]

It looks like @NB80: you have problem regarding stations that provide one-way service (e.g. Qinglongqiao railway station (Q5963337), and I've heard a NYC subway example and a Seoul Metro example years ago? I'm sorry that I no longer have memories of em) which is very rarely happened, so my suggestion fall under this problem is to create a Wikibase reason for deprecated rank (Q27949697) item, proposed name no train can operate follow this direction of stations, then in such A station→B station and not B station→A station cases, normally mark P197 for A→B, mark P197 for B→A as system-provided Deprecated rank and attach reason for deprecated rank (P2241)"that deprecate reason item". --Liuxinyu970226 (talk) 12:56, 22 December 2017 (UTC)[reply]

Exactly, the problem is that Qinglongqiao railway station (Q5963337) is physically connected in both way, only the service is one-way. Using qualifiers and ranks is one way to solve it. Maybe using a new and different property would be a better and more clear solution. This new possible property could be useful for long distance train like the one connecting Paris and London without stop (like indicated on Gare de Paris-Nord (Q745942) and Ashford International railway station (Q800406) right now). For information, for the moment, there is only a small number of items where P197 is used for service instead of geographic proximity (around 300 on 36 000 uses) but in the future that could change. Cdlt, VIGNERON (talk) 10:03, 25 December 2017 (UTC)[reply]

Symmetric constraint[edit]

Hi all,

English:

probably after the recent problem of duplication of some bad values raised by NB80, Pasleim removed the symmetric constraint of this property (Special:Diff/529149628). I think it's a mistake: the information about adjacent station is symmetric. At least, I see no case where a station A is adjacent to a station B but where this station B is not adjacent to the station A (or I'm a wrong?). Any remark or objection to putting this constraint back?

Français :

sans doute suite au récent problème de duplication de quelques valeurs fausses soulevé par NB80, Pasleim vient de retirer la contrainte de symétrie de cette propriété (Special:Diff/529149628). Je pense que c'est une erreur: l'information sur les gares voisines est symétrique. En tout cas, je ne vois pas de cas où une gare A est voisine d'une gare B mais où cette station n'est pas voisine de la gare A (me trompé-je ?). Des remarques ou des objections sur le fait de remettre cette contrainte ?

Cdlt, VIGNERON (talk) 22:24, 30 July 2017 (UTC)[reply]

Support The NB80's problem can be resolved by just marking that claim as "deprecated class". --Liuxinyu970226 (talk) 02:48, 30 November 2017 (UTC)[reply]

Avant de voter, puis-je avoir la certitude que seules les gares voisines physiques seront prises en compte ? Car la desserte est on ne peut plus variable au fil du temps, et si se baser là-dessus n'est pas corrigé, on ne pourra en revenir qu'au problème initial (et heureusement que ce n'est pas Wikidata qui remplit le contenu des articles de gares sur Wikipédia, notamment la section "Situation ferroviaire"). --NB80 (talk) 22:05, 22 December 2017 (UTC)[reply]

@NB80: (sorry for my bad knowledge of French) Je me demande où est l'exemple où une station à la station B ne peut pas simplement dériver à la station B à la station A. --Liuxinyu970226 (talk) 13:34, 23 December 2017 (UTC)[reply]

Pour moi, il est hors de question que l'on fasse repasser un bot tant que la logique physique (et non commerciale) ne sera pas appliquée dans les éléments Wikidata. Car cette histoire de symétrie me fait penser que le problème initial n'est toujours pas pris en compte (!) ; où est le bon sens dans ce cas ? Le bon sens étant donc de vérifier au lieu de faire passer un bot. --NB80 (talk) 14:43, 23 December 2017 (UTC)[reply]

@VIGNERON: I'm afraid only you can tell us what the actual problem this user pointed (at least why this user pointed something that "non-commercial"?). --Liuxinyu970226 (talk) 06:56, 25 December 2017 (UTC)[reply]

@Liuxinyu970226: the problem pointed by NB80 is exactly the one from the section above (but with the word « commercial » instead of « next stop of a long distance train » but the logic is hte same). I think the two problems are relatively independant but in the end I don't rally care ; meanwhile, NB80 seems to think that the problem of the definition should be dealt with first. Cdlt, VIGNERON (talk) 09:45, 25 December 2017 (UTC)[reply]

@VIGNERON, NB80: Anyway, if the problem is regarding that bot, how about reproviding this constraint without autofixing by that bot, instead just take a list, see this example of type of electrification (P930), those are constraints that kept for years. --Liuxinyu970226 (talk) 12:55, 31 December 2017 (UTC)[reply]

Le problème n'a pas été corrigé. Un bot est revenu à la charge, en se basant sur les nombreuses variantes commerciales de dessertes, au lieu des voisines physiques. J'ai annulé pour deux gares (Q801473 et Q757180) ; dois-je le faire arrêter ?

Il serait souhaitable qu'un bot fasse le travail inverse, à savoir vérifier et corriger selon les voisines physiques ! --NB80 (talk) 22:43, 24 June 2018 (UTC)[reply]

NB80 oui, le problème reviendra encore et encore tant que la situation n'aura pas été clairement posée, expliquée et comprise.

Ici le problème n'est pas les robots et les robots n'ajoutent pas les dessertes commerciales. Les robots ne font qu'une tâche extrêmement simple et correcte : rendre cohérente les informations ajoutées par des êtres humains (et du coup, par effet secondaire, les robots ajoutent des gares qui sont des dessertes quand un humain a ajouté une desserte mais le robot ne sait pas si qui est physique ou non, il n'a aucun moyen de le savoir). Il n'y a *aucune* raison d'interdire aux robots de rendre les données plus cohérentes. Ici, ce sont les humains qui font des erreurs. Il faut donc absolument que des humains corrigent ces erreurs (les robots en sont de toute façon incapables) pour éviter qu'elles ne se répande. NB80 c'est toi le spécialiste, si tu pouvais corriger ces erreurs ce serait vraiment utile. Par exemple, en commençant par Strasbourg-Ville station (Q801473) que tu n'a corrigé qu'à moitié, du coup ta correction est une erreur logique qui rend les données incohérentes... quelqu'un - robot ou humain - sera forcément tenté de corrigé ta correction ; tant que les données ne seront pas vraiment corrigées, le cercle vicieux ne sera pas rompu. Cdlt, VIGNERON (talk) 09:17, 25 June 2018 (UTC)[reply]

J'ai autre chose à faire qu'à corriger des milliers d'éléments Wikidata (et ce wiki est une usine à gaz…) ! C'est le rôle d'un robot que de corriger des milliers de pages ; j'ai déjà àmha suffisamment de travail à faire sur Wikipédia.

Pour le seul élément sur la gare Strasbourg-Ville, en quoi le travail a t-il été à moitié fait ? Je l'ai simplement rendu cohérent avec cette description correcte sur Wikipédia en français.

Heureusement que ce n'est pas Wikidata qui remplit les articles : ce serait le début de la fin pour l'encyclopédie. CQFD.

--NB80 (talk) 16:09, 25 June 2018 (UTC)[reply]

NB80 sauf erreur cette discussion ne concerne plus la propriété en soi, peut-on continuer cette discussion sur ta page de discussion ? VIGNERON (talk) 18:08, 25 June 2018 (UTC)[reply]

Si cela aboutit à la correction souhaitée, oui, sinon, je n'ai rien à ajouter. --NB80 (talk) 18:12, 25 June 2018 (UTC)[reply]

usage on abandoned stations[edit]

The undo action by @Multichill: give us a problem: do we really need this property on abandoned stations? --Liuxinyu970226 (talk) 04:43, 12 February 2018 (UTC)[reply]

Notified participants of WikiProject Railways --Liuxinyu970226 (talk) 04:49, 12 February 2018 (UTC)[reply]

Yes, even abandoned stations had their adjacent stations, so we can record them. We just need to use qualifiers properly to not confuse users.--Jklamo (talk) 09:28, 12 February 2018 (UTC)[reply]

Please keep abandoned stations but add end time (P582) qualifier. I'm not only interested in the current existing rail network but especially also how the network looked in the past. --Pasleim (talk) 13:42, 12 February 2018 (UTC)[reply]

That's exactly what I said :-) Multichill (talk) 18:06, 12 February 2018 (UTC)[reply]

Ok with @Pasleim: position. Is it possible to distinguish disused / converted / destroyed stations ? --A1AA1A (talk) 12:15, 14 February 2018 (UTC)[reply]

You can use end cause (P1534) as an additional qualifier with some appropriate value, e.g. destruction (Q17781833) --Pasleim (talk) 12:28, 14 February 2018 (UTC)[reply]

@Pasleim: Not always OK for me, at least because lack of useful resources about abandon date (but is lacking resources meaning that station is "still open"?) --Liuxinyu970226 (talk) 14:12, 14 February 2018 (UTC)[reply]

Come on Liuxinyu970226 don't use deprecated for information that is correct, see Help:Ranking#Deprecated_rank. Use end time. Multichill (talk) 14:25, 14 February 2018 (UTC)[reply]

@Multichill: Thx but isn't that saying "or that represent outdated knowledge"? How are P197 value not outdated even in abandon cases? --Liuxinyu970226 (talk) 14:29, 14 February 2018 (UTC)[reply]

@Liuxinyu970226:, no old informations are not outdated. An outdated knowledge is something like « The Earth is flat » or « This guy is the son Zeus », not just old but also erroneous. « Ramesses is pharaoh of Egypt between 1279–1213 BCE » is old but not outdated (as it's factual, it has always been and will always be true). Cdlt, VIGNERON (talk) 10:01, 16 February 2018 (UTC)[reply]

@VIGNERON: But then how do you think some enwiki CRH stations articles which are really not true? e.g. Q7504453 (explained in talk page of that). --Liuxinyu970226 (talk) 10:05, 16 February 2018 (UTC)[reply]

@Liuxinyu970226: this is a very specific and different case. Q7504453 is not true or not true, it's "not even wrong" (not even wrong (Q1225402)) and should just be deleted (I've asked for deletion of the enwiki article - I'll ask for deletion here too if the article is deleted - and in the meantime I've removed unreferenced statements). Cdlt, VIGNERON (talk) 10:22, 16 February 2018 (UTC)[reply]

Anyway, the reason why I usually use deprecated value rank is about {{Wikidata list}}, lists using this template generally list items if they have P31 values in either Preferred or Normal, but won't list if they're Deprecated, so without altering that to deprecated, there's no other ways to remove from such lists in case those really should be removed. --Liuxinyu970226 (talk) 09:40, 16 February 2018 (UTC)[reply]

{{Wikidata list}} use SPARQL queries, it's very easy to removed all stations with a end time (P582) in qualifier, ranks are not needed for that. Cdlt, VIGNERON (talk) 10:01, 16 February 2018 (UTC)[reply]

contra User:VIGNERON, if using this with end time (P582) to record a station that was formerly adjacent to a present one, please do make sure that the statement(s) for the current adjacent station(s) do have preferred rank. SPARQL path queries can't check qualifiers. Jheald (talk) 14:24, 26 February 2018 (UTC)[reply]

@Jheald:, yes of course using preferred rank if possible is a must-do. But I have 2,5 remarks : 1. we should use preferred on the current value, not deprecated on the old value (this it not what deprecated is meant to do) 1bis. what about stations with no current value, should we then put a 'no value' with preferred rank? 2. formally ranks are not needed, you can remove old stations without using the rank. At least it's easily doable in SPARQL :

SELECT DISTINCT ?station ?stationLabel ?nextStation ?nextStationLabel WHERE {
  ?station wdt:P31 wd:Q55488 ; wdt:P197 ?nextStation .
  MINUS { ?station p:P31 [ ps:P31 wd:Q55488 ; pq:P582 ?endDate ] . }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
limit 5

Try it!

Cdlt VIGNERON (talk) 14:52, 26 February 2018 (UTC)[reply]

@VIGNERON: That's not a path query, though, is it? A path query would be something like:

SELECT ?depth WHERE {
  VALUES ?to {wd:Q49870}
  SERVICE gas:service {
       gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" .
       gas:program gas:linkType wdt:P197 .
       gas:program gas:in wd:Q1948428 .
       gas:program gas:out ?station .
       gas:program gas:out1 ?depth .
       gas:program gas:maxIterations 20 .
   }
   FILTER (?station = ?to)

}

Try it!

(Can you get from Heino railway station (Q1948428) to Duivendrecht railway station (Q49870) in 20 stops?) Jheald (talk) 15:28, 26 February 2018 (UTC)[reply]

@Jheald: oh, I don't know this syntax (I didn't understood what you meant by "path query") but wouldn't something like this query work:

SELECT ?depth WHERE {
  VALUES ?to {wd:Q49870}
  SERVICE gas:service {
       gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" .
       gas:program gas:linkType wdt:P197 .
       gas:program gas:in wd:Q1948428 .
       gas:program gas:out ?station .
       MINUS { ?station p:P31 [ ps:P31 wd:Q55488 ; pq:P582 ?endDate ] . }
       gas:program gas:out1 ?depth .
       gas:program gas:maxIterations 20 .
   }
   FILTER (?station = ?to)
}

Try it!

Anyway, back to the original question : "deprecated rank shouldn't be use" and to go further, you're right : "preferred rank is the solution" and "old information must be indicated in Wikidata" (it necessary to do query like "in 1998, could you get from Heino railway station (Q1948428) to Duivendrecht railway station (Q49870) in 20 stops" ; I don't know "path query" but I'm certain this can't work if the data are not indicated). Cdlt, VIGNERON (talk) 15:53, 26 February 2018 (UTC)[reply]

@VIGNERON: More generally, a path query is a query using predicates like P197* or P197+ to find items linked via a chain of a particular predicate. But in this case the P197* set got too big, and the query didn't converge, which is why I used the Blazegraph GAS service instead.

Unfortunately neither syntax can be limited by qualifier. You can exclude stations that have now been closed at the end; and you can exclude links that have been closed by denying them preferred rank. But, seemingly, you cannot limit the results to paths that were accessible 20 years ago; nor (perhaps even more unfortunately) to qualify eg just to connections using a particular line or sub-network. (On the latter, see this recent discussion on the query request page).

I suppose these limitations are quite likely to restrict the amount people want to use adjacent station (P197) for path queries. But 'preferred rank' may help those queries where it could be used. Jheald (talk) 16:07, 26 February 2018 (UTC)[reply]

@Jheald: oh I see, gas:out is only for the final result (thanks for the links, I'll look into it). So indeed, it seems we need to use ranks every time. Cdlt, VIGNERON (talk) 16:15, 26 February 2018 (UTC)[reply]

Constraint "Located in administrative territorial entity"[edit]

Why does this property require the statement it is used on to also have located in the administrative territorial entity (P131)? As far as the property is concerned it doesn't require its location to be known.--Wanderer28 (talk) 02:59, 13 March 2018 (UTC)[reply]

@Wanderer28: Topic:Ufogh1bbovmkfkzi you may be interested in it. --Liuxinyu970226 (talk) 09:58, 23 August 2018 (UTC)[reply]

Constraint "follows"[edit]

"adjacent station" does not allow "follows" as a qualifier. In fact it is plausible if (as I have done to the whole of the Seibu network) also qualified by "start time": this information can be used ultimately to chart not only current adjacent stations, but also previous adjacent stations. In most cases, this can happen if the station was opened at an earlier date than the adjacent station, with its adjacent station also opened at an earlier date. --Wanderer28 (talk) 09:02, 17 March 2018 (UTC)[reply]

Distance between stations[edit]

For Khlong Yang railway halt (Q13015623), I tried to import the distance between the adjoining station from the infobox in Thai wikipedia. However, length (P2043) isn't listed as an allowed qualifier. Would it be worth to add it? Or is there another way to encode the mileage on a railway line? Ahoerstemeier (talk) 14:32, 23 April 2018 (UTC)[reply]

@Ahoerstemeier: I've added this qualifier (as well as follows (P155) and followed by (P156)). I was bold and estimate that it wasn't allowed just because nobody thought about adding these qualifiers (which are already used is similar cases like Q59510#P197) ; if someone think I was wrong, feel free revert me and please tell me why. Cdlt, VIGNERON (talk) 15:01, 23 April 2018 (UTC)[reply]

Multiple qualifiers for the same station[edit]

Am I doing this right? Tuen Mun station (Q2106644) now has three different statements (with different qualifiers and the statement which is currently true preferred) to show that the next station on the line is Siu Hong station (Q996814). (I've been making QuickStatements batches to add this property to 28 stations, and it has taken a very long time because QuickStatements merges all statements with the same property and value.) Jc86035 (talk) 15:25, 15 July 2018 (UTC)[reply]

Usage on non-passenger stations[edit]

@Liuxinyu970226: Is it appropriate to use this property for non-passenger stations (see Airport Island Angle Station (Q28418727))? I'm not sure; it could be valid but the statement should probably indicate this, and I don't know if this was originally in the scope of the property. Jc86035 (talk) 18:13, 27 December 2018 (UTC)[reply]

How to handle adjacent stations that only send trains to a given station but don't receive trains from it?[edit]

Take The Forest tram stop (Q21061482) (the line diagram on Wikipedia is helpful to understand this) – it has three adjacent stations:

The next station you hit when traveling south [i.e. towards (P5051) Toton Lane tram stop (Q24230260) or Clifton South tram stop (Q24237784)] is High School tram stop (Q19462304)
The next station you hit when traveling north [i.e. towards (P5051) Hucknall station (Q2393008) or Phoenix Park tram stop (Q7186947)] is Noel Street tram stop (Q24884890). So far so good.
The previous station when coming from the north is Hyson Green Market tram stop (Q24993380). Trains coming from this stop are southbound only, so they don't go "towards" Hucknall or Phoenix Park; they go towards Toton Lane or Clifton South. But if you're starting at The Forest, your next stop in that direction is High School, not Hyson Green Market. So how should this be indicated? Previously, syntax clarification (P2916) was pressed into service to explain the northbound/southbound distinction, but that's clearly not what that property is meant for.

Swpb (talk) 21:48, 5 March 2019 (UTC)[reply]

@Swpb: There is now a discussion at the WikiProject Railways talk page about this topic. Jc86035 (talk) 17:13, 11 March 2019 (UTC)[reply]

Property talk:P197

Contents

Documentation

Qualifier "connecting line" (P197)[edit]

Why should it be instance of railway station?[edit]

consistency check gadget[edit]

Precise meaning of this property[edit]

Symmetric constraint[edit]

usage on abandoned stations[edit]

Constraint "Located in administrative territorial entity"[edit]

Constraint "follows"[edit]

Distance between stations[edit]

Multiple qualifiers for the same station[edit]

Usage on non-passenger stations[edit]

How to handle adjacent stations that only send trains to a given station but don't receive trains from it?[edit]

Navigation menu

Property talk:P197

Documentation

Qualifier "connecting line" (P197)[edit]

Why should it be instance of railway station?[edit]

consistency check gadget[edit]

Precise meaning of this property[edit]

Symmetric constraint[edit]

usage on abandoned stations[edit]

Constraint "Located in administrative territorial entity"[edit]

Constraint "follows"[edit]

Distance between stations[edit]

Multiple qualifiers for the same station[edit]

Usage on non-passenger stations[edit]

How to handle adjacent stations that only send trains to a given station but don't receive trains from it?[edit]

Navigation menu

Search