Wikidata:Property proposal/Transportation
| Property proposal: | Generic | Authority control | Person | Organization |
| Creative work | Place | Sports | Sister projects | |
| Transportation | Natural science | Computing | Lexeme |
See also
[edit]- Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
- Wikidata:Properties for deletion – proposals for the deletion of properties
- Wikidata:External identifiers – statements to add when creating properties for external IDs
- Wikidata:Lexicographical data – information and discussion about lexicographic data on Wikidata
This page is for the proposal of new properties.
Before proposing a property
- Search if the property already exists.
- Search if the property has already been proposed.
- Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
- Select the right datatype for the property.
- Read Wikidata:Creating a property proposal for guidelines you should follow when proposing new property.
- Start writing the documentation based on the preload form below by editing the two templates at the top of the page to add proposal details.
Creating the property
- Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
- Creation can be done 1 week after the creation of the proposal, by a property creator or an administrator.
- See property creation policy.
| On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2025/12. |
Infrastructure
[edit]Aviation
[edit]- see also: WikiProject Aviation
Water transport
[edit]- see also: WikiProject Ships
Railway
[edit]- see also: WikiProject Railways
Doors open on the… / exit train on the…
[edit]| Description | side of the train where the doors open at this station or only side where this vehicle has doors |
|---|---|
| Data type | Item |
| Domain | railway station (Q55488), metro station (Q928830), rolling stock class (Q811704), transport service itinerary (Q1067164) |
| Example 1 | Louvre - Rivoli (Q1461794) → right (Q14565199) |
| Example 2 | Palermo train station (Q5572984) → left (Q13196750) |
| Example 3 | F8E (Q106425229) → right (Q14565199) |
| Example 4 | Wuppertal Schwebebahn (Q256964) → right (Q14565199) |
| Example 5 | Sé (Q3132156) → Spanish solution (Q1342434) |
| Allowed values | left (Q13196750), right (Q14565199), Spanish solution (Q1342434) |
| Expected completeness | always incomplete (Q21873886) |
Motivation
[edit]On many small train and most metro stations, it is unambiguous and clear where the doors of the train open in regular service. For (the very few) stations where doors of a train open on both sides at the same time, use the value Spanish solution (Q1342434).
Some rolling stock class (Q811704) only have doors on one side, e.g. trams.
There are some entire public transport lines or networks where doors only open on one side (e.g. Wuppertal Schwebebahn (Q256964)).
Notified participants of WikiProject Railways
– The preceding unsigned comment was added by Geogast (talk • contribs) at 13:57, January 27, 2025 (UTC).
Discussion
[edit]
Notified participants of WikiProject Railways - pinging does not work when unsigned. --Lewis Hulbert (talk) 10:01, 2 February 2025 (UTC)- Doesn’t Spanish solution (Q1342434) refer to entry on one side, exit in the other, as opposed to simply having a platform on both sides, which also happens? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:46, 3 February 2025 (UTC)
- Indeed, Spanish solution (Q1342434) is a complex situation for this proposal; more complex than simple cases where doors on one side open for exit and entry. A possible solution could be to create 3 new items, sub-types of Spanish solution (Q1342434): "exit left, entry right", "exit right, entry left" and something like: "entry and exit on either side". Geogast 🤲 (talk) 21:19, 3 February 2025 (UTC)
- How do you propose recording the information for an interchange station with platforms on multiple platforms with different rules? I suggest you ping any WD Access projects, as it is likely of greatest benefit to blind travellers. For multi-platform railway stations, operating patterns might mean certain routes are always open left, others right, and some both. How would you record this by route, how would you record "either side". Some stations are always left in one direction, but either in the other, so a direction qualifer might be needed then. Its a worthy idea if done comprehensively. Metros are much easier than railways. Would you anticipate this property being used for trams? Vicarage (talk) 19:21, 3 February 2025 (UTC)
- Many questions… thanks!
- Interchange stations could have statements with qualifiers. Let's take metro station XY, where there are two subway lines that cross each other on different levels. Line A has one island platform; line B has side platforms; both run on the right hand side. That would mean: Station XY: doors open on the left, applies to part (P518) line A; and: doors open on the right, applies to part (P518) line B. I can imagine this do be done in mayor train station, too, as long as the correlation between a line and its platform at this station are unambigous. But, of course, for other mayor stations, where trains usually stop at different platforms, this property might not work.
- As you say, there are stations where e.g. northbound trains open on the left; southbound on the right; I know a station like this. I agree: We could use direction (P560) or towards (P5051) qualifiers to express this case.
- Thanks for the suggestion to ping "WD Access projects"! I could not find anything in that sense. You did not mean WikiProject Open access (Q19794158), right?
- Trams: of course!! Most of the tram stops I know are cases that could easily be described with this proposed property. Geogast 🤲 (talk) 21:35, 3 February 2025 (UTC)
- For Access I meant disability, but they don't like that name now Vicarage (talk) 21:44, 3 February 2025 (UTC)
- I can see the benefits in this if it can be recorded simply and accurately, but I'm not sure that it can. Thinking about London, all of the following exist:
- All trains open the doors on the left (e.g. St. James's Park)
- All trains open the doors on the right (e.g. Royal Oak)
- Trains in one direction open the doors on the left, those in the other on the right (e.g. Chancery Lane)
- Trains in one direction open the doors on the left, those in the other direction on either side (e.g. Leytonstone)
- Doors on either side may be opened (e.g. Edgware Road H&C)
- Doors on both sides are opened, both sides may be used for both boarding and alighting (e.g. Canary Wharf DLR)
- Doors on either or both sides may be opened, both sides may be used for both boarding and alighting (e.g. Morden)
- Doors on both sides are opened westbound (both sides may be used for both boarding and alighting), only those on the left are opened eastbound (Stratford Central line)
- Through trains usually open the doors on the right, terminating trains usually on the left (e.g. Loughton)
- Through trains open the doors on the right, terminating trains may open either (e.g. Aldgate)
- Doors on both sides are opened, in theory those on the right (in the arrival direction) are for alighting, those on the left for boarding but in practice people alight from both sides but almost exclusively board on the left in the arrival direction (Tower Gateway).
- Trains on one branch open the doors on the left, trains on the other on the right (e.g. Camden Town)
- Eastbound trains open the doors on the left, westbound and terminating trains open the doors on the right (e.g. North Greenwich)
This all assumes standard running (e.g. the DLR is fully bidirectionally signalled, and so trains can and do run the opposite way to normal when then the need arises) and there are probably situation that occur elsewhere that are not listed above. e.g. it seems plausible that the side might be dependent on model of train, time of day (perhaps doors open on both sides during the peak but only one side off peak) or other factors. It also needs to make it clear what the direction is relative to for terminating trains, e.g. a train in a bay platform opens the doors on the left from the perspective of alighting passengers but on the right from the perspective of boarding ones. Verifiability is also going to be a potential issue as the information cannot be reliably obtained just by looking at a map. Thryduulf (talk) 05:45, 8 February 2025 (UTC)- In fact there are many cases where reality is too complex for this property. The point is: Should Wikidata abstain from recording data where it is possible to record it – because there are cases where it is too complex!? It is clear that Wikidata will never describe all of reality in all of its aspects. That is why I wrote: "On many small train and most metro stations, it is unambiguous and clear where the doors of the train open in regular service." – I could have added: this property is difficult/impossible to use on very complex stations, like main stations and others. And you gave some good examples where this property is, at least, challenged. But let's feed that kind of information into Wikidata that is possible. I always understood Wikidata that way. Geogast 🤲 (talk) 14:56, 8 February 2025 (UTC)
- I suggest you create new WD items "either side" and "both sides at once" to go with left and right, rather than have more than one value. And mention that this under normal conditions, not during engineering work. You need to state this is from the perspective of the alighting passenger. None of these caveats and the qualifiers to clarify them stop this being a useful property, so I
Support it. You could have qualifiers for which platform is being used, but that just adds complexity, and its all to easy for users to ignore the qualifiers, so as you say for most stations it will be left or right, and "either" for the rest will do. And if you ask on rail forum the denizens will delight in telling you all the answers! Vicarage (talk) 15:22, 8 February 2025 (UTC)
- So, that would be: left, right, either side and both sides at once? Yes. I think thats covers a lot of (of course: not all) cases. Geogast 🤲 (talk) 18:03, 12 February 2025 (UTC)
- A good idea on the paper, but on the practice... Perhaps specifying in the title "the most common side per regular basis" Bouzinac 💬●✒️●💛 17:59, 10 February 2025 (UTC)
- In the motivation, I wrote: "in regular service". It might be a good idea to put that in the description. Geogast 🤲 (talk) 18:02, 12 February 2025 (UTC)
- Should Wikidata abstain from recording data where it is possible to record it – because there are cases where it is too complex!? the answer to this question depends how much value there is in incomplete data, and what proportion of data can be recorded. Where there is a high value to the data where it can be recorded and most cases can be, the answer is that we should record what we can. When there is low value to incomplete data and only a small portion can be recorded, the maintenance and verification costs exceed the benefits. I still think that this proposal falls on the latter end of the scale. Particularly the data source"ask people on forums" is not reliable, it can only capture a small subset of stations (and "doors can open on either side" is very low value information) and only for regular service.
Oppose. Thryduulf (talk) 13:42, 16 February 2025 (UTC)
- I would be with you if were really talking about: "only a small portion can be recorded". But I would say that for 99% of metro station (Q928830) and 90-95% of railway station (Q55488) we have a clear, unambiguous situation in regular service, this is: you can say where doors open; and it is mostly not on either, but just one side. I do not think that we are talking about a small portion here. And for a case where it is a clear situation, it is not "incomplete data" – it is just incomplete if we look at all railway station (Q55488). Then again, why abstain from collecting data at clear cases (99% of metro station (Q928830) and 90-95% of railway station (Q55488))?
- Of course, I am with you at: "data source'ask people on forums' is not reliable". Geogast 🤲 (talk) 12:59, 17 February 2025 (UTC)
- Considering only Docklands Light Railway (Q216360) services, which is a relatively simple system in normal operation, only 73% of stations can be accurately described as one of "left", "right" or "both". For the alphabetically first 100 London Underground stations it's only 63%. These figures rise slightly if you treat each line separately but decrease significantly if you consider all the modes at a station together (e.g. at Bank, DLR trains open their doors on the right, Waterloo & City line trains open either, Northern and Central lines open on the right).
- Reliable sourcing is the bigger problem though: Even as a London-based transport enthusiast who spends a lot of time considering stations, I don't know how to reliably source this information for all-but a very small handful of stations - it simply is not something that is relevant to the vast, vast majority of sources. As an example, I've just tried sourcing the information for Covent Garden tube station (Q38879) - a simple station with one platform in each direction in Central London that is in a tourist hotspot and so should be the easiest to source, yet I've come up with absolutely nothing reliable. I did find [1], which allows sourcing for a single platform at each of Stratford, Arnos Grove and Barking - but the description at Barking is incorrect and out-of-date (platform 2 allows cross-platform interchange with National Rail trains in platform 1 not LU trains in platform 2, but platform 1 is now not used in regular service, I'm unsure if trains still open the doors on both sides) and is misleading about Arnos Grove (generally the doors on the left of terminating trains open for alighting passengers, close when the train is empty, then shortly before departure doors open on the opposite side for boarding passengers). It is also completely silent on what side doors open on other platforms at those stations. Figure 9 on page 17 of the RAIB report into an uncontrolled evacuation at Clapham Common tube station can be used, together with other information in the report, to work out that doors open on the right at that station but it is not stated anywhere explicitly (and it is thus unlikely someone searching for information about the door side opening will find this document). Thryduulf (talk) 14:31, 17 February 2025 (UTC)
- Have either of you reached out to the worldwide transit mapping community, which seems very active, to find out whether such information has been recorded or would be useful? The absence of a dataset actually makes a case for WD to be a nucleus for a project to record it. Given that platform information is available in real-time train systems, it seems an armchair exercise to record it, as indeed it has been by EnWiki for my local station. You do need more supporters to ensure the property is populated in a timely fashion, but I doubt they will be hard to find. Vicarage (talk) 15:16, 17 February 2025 (UTC)
- Platform numbers are easy to reliably source, but that's not the same as which side of the train that platform is - and even if there is a platform adjacent to e.g. the left side of the train that doesn't necessarily mean that the train will open its doors on that side for alighting passengers. Thryduulf (talk) 17:20, 17 February 2025 (UTC)
- I'm sure you will come up with counter examples, but most platforms are considered a single face onto a track. Anyway, its not my problem to counter your endless objections, as I don't plan to push the proposal forward, though I still
Support it. Vicarage (talk) 17:28, 17 February 2025 (UTC)
- What counts as a platform is surprisingly complicated (File:How many platforms.svg, File:How many platform faces do these stations have.svg)) but yes there are many instances of tracks with platforms on both sides. Examples in London include: Loughton tube station (platforms 2 & 3), Uxbridge tube station (2 & 3), Morden tube station (1 & 2, 3 &4); Canary Wharf DLR station (1 & 2, 3 & 4, 5 & 6) and Tower Gateway DLR station (not prominently numbered). Different door opening arrangements exist at all of them (Loughton: doors open on 3 only for alighting, 4 only for boarding, never at the same time; Uxbridge: platform 3 is not used; Morden (platform 1 is not used, doors open on 3 & 4 at the same time; Canary Wharf: doors open on each pair at the same time; Tower Gateway: nominally Spanish solution). I'm saying this only to highlight that simply looking at a plan of the station is not a reliable way to tell which side the doors will open, nor is platform numbering. Thryduulf (talk) 23:52, 17 February 2025 (UTC)
- I'm sure you will come up with counter examples, but most platforms are considered a single face onto a track. Anyway, its not my problem to counter your endless objections, as I don't plan to push the proposal forward, though I still
- Platform numbers are easy to reliably source, but that's not the same as which side of the train that platform is - and even if there is a platform adjacent to e.g. the left side of the train that doesn't necessarily mean that the train will open its doors on that side for alighting passengers. Thryduulf (talk) 17:20, 17 February 2025 (UTC)
- Have either of you reached out to the worldwide transit mapping community, which seems very active, to find out whether such information has been recorded or would be useful? The absence of a dataset actually makes a case for WD to be a nucleus for a project to record it. Given that platform information is available in real-time train systems, it seems an armchair exercise to record it, as indeed it has been by EnWiki for my local station. You do need more supporters to ensure the property is populated in a timely fashion, but I doubt they will be hard to find. Vicarage (talk) 15:16, 17 February 2025 (UTC)
- I suggest you create new WD items "either side" and "both sides at once" to go with left and right, rather than have more than one value. And mention that this under normal conditions, not during engineering work. You need to state this is from the perspective of the alighting passenger. None of these caveats and the qualifiers to clarify them stop this being a useful property, so I
- In fact there are many cases where reality is too complex for this property. The point is: Should Wikidata abstain from recording data where it is possible to record it – because there are cases where it is too complex!? It is clear that Wikidata will never describe all of reality in all of its aspects. That is why I wrote: "On many small train and most metro stations, it is unambiguous and clear where the doors of the train open in regular service." – I could have added: this property is difficult/impossible to use on very complex stations, like main stations and others. And you gave some good examples where this property is, at least, challenged. But let's feed that kind of information into Wikidata that is possible. I always understood Wikidata that way. Geogast 🤲 (talk) 14:56, 8 February 2025 (UTC)
Road transport
[edit]applies if VIN matches regular expression
[edit]| Description | this statement is only true if the Vehicle Identification Number (VIN) of a vehicle matches this regular expression |
|---|---|
| Data type | String |
| Domain | automobile model (Q3231690) |
| Example 1 | Mazda3 (BM) (Q120646876)intended public (P2360)Australia (Q408) |
| Example 2 | Mazda3 (BM) (Q120646876)engine displacement (P8628)2.2 litre |
| Example 3 | Mazda3 (BM) (Q120646876)engine displacement (P8628)2.5 litre |
| Allowed values | Regular expression string usually in PCRE format but can be specified alternatively using regular expression syntax (P4240). |
| Source | Manufacturer manuals and similar publications which detail automobile models by their assigned VINs, or which provide detail on how that manufacturer assigns VINs for different automobile models. |
| Planned use | Add this qualifier to automobile models where the manufacturer has a particular code in a VIN or range of VINs for one or more of: factory where an automobile was manufactured, jurisdiction where an automobile is designed to be used within, inclusion of a particular engine or other major feature in an automobile model, etc. |
| See also | applies if regular expression matches (P8460), vehicle identification number (P6322) |
| Wikidata project | WikiProject Automobile manufacturers (Q60003385) |
Motivation
[edit]Many properties of automobile models are only applicable to a subset of instances of the automobile model, depending on the selected factory configuration at time of manufacture. Due to the high configurability of vehicles on a production line (e.g. same vehicle could be manufactured in different factories, or a vehicle is built to left-hand drive or right-hand drive configuration, or there is a choice of 3 engines, ...) it is impractical to create a new Wikidata item for every type of vehicle configuration possible.
This qualifier would allow a Wikidata item for an automobile model to note that there are 3 factories used to manufacture the automobile model, that there are 6 international markets to which slightly different vehicle models are sold, that there is a choice of 4 engine configuration, etc and to map these properties to the VINs of instances of an automobile model.
Additional information:
- This qualifier can be used multiple times for the same statement. If any of the regular expressions match a VIN, the property is applicable to that instance of an automobile.
- It is left as a matter for the community/property users to decide how strict or loose regular expressions should be. For the example provided for "intended public" of an automobile model, the first 3 characters of the VIN should provide enough of a match without having to match the remainder of the VIN. However, the example ends up matching the rest of the VIN anyway, ensuring that an otherwise invalid VIN is rejected (e.g. if the remainder of the VIN specifies an engine code that doesn't exist in vehicles built for sale in Australia--only for vehicles sold in Japan). It is probably preferable to err on the strict side of specifying regular expressions against the entirety of a VIN.
--Dhx1 (talk) 04:16, 4 July 2025 (UTC)
Discussion
[edit]
Comment I don't edit this area much, so take it with a grain of salt. However, it seems to me this conflates cause and effect a bit, so to say: It's true that some configurations of Mazda3 (BM) (Q120646876) have a 2.2-litre engine and it's true some configurations of Mazda3 (BM) (Q120646876) have a VIN with a particular syntax. But the fact that those two sets are the same does not seem to be properly described by such a qualifier, it seems to me. I'd say an ideal model would be very specific items for the individual configurations which would say unambiguously that the engine is 2.2-litre, and on the same level, what the VIN codes look like. However, I guess this would be very complicated, as there are usually so many individual configurations in various countries, etc. (I wanted to improve data coverage of my own car model but abandoned the idea exactly because it would be so complicated. Also, cf. the various car parameter databases with all those model years, engine options, etc.) So, in the end, this might be a usable "temporary" compromise to at least indicate a useful piece of data on a less-than-ideal data model? Possibly. Even though I would consider changing the conditional "applies if" to something more generic, so that it might be used on the hypothetical ideal data item specific for a single configuration, stating "this model configuration used the following set of VINs". --Mormegil (talk) 17:03, 8 July 2025 (UTC)
Wheeled vehicle
[edit]Intersection
[edit]Spaceflight
[edit]- Please visit Wikidata:WikiProject Space for more information. To notify participants use {{Ping project|Space}}
oxygen endurance
[edit]| Description | The maximum time a submarine, spacecraft or enclosed vehicle can sustain life using its onboard oxygen supply. |
|---|---|
| Data type | Point in time |
| Domain | P |
| Example 1 | USS Nautilus (Q827360)oxygen autonomy90 hours |
| Example 2 | Apollo Lunar Module (Q208382)oxygen autonomy14 days |
| Example 3 | Titan (Q119799500)oxygen autonomy96 hours |
| Allowed units | minute (Q7727) hour (Q25235) day (Q573) |
Motivation
[edit]This property is proposed to provide detailed information on the maximum duration that enclosed vehicles, such as submarines and spacecraft, can operate while relying on their onboard oxygen supply. This data is essential for understanding the operational limits of such vehicles, particularly in life-support critical environments.
Discussion
[edit]
Notified participants of WikiProject Space
Comment Is it oxygen endurance or oxygen autonomy?--Trade (talk) 00:01, 14 March 2025 (UTC)
- Maybe autonomy is better, I am a portuguese speaker. Can you change the name and move the page for the correct one? Kássio Santiago (talk) 14:49, 14 March 2025 (UTC)
- Why oxygen, other building gases building up, like CO2, can be the limiting case. But there is a useful measure of how long any standard crew can survive in a vehicle, and water/food endurance is much less common and poorer defined. I don't think we can device a clean property of other lifespans of vehicles that would also cover this, like 14 days for Moon landers. Vicarage (talk) 17:17, 17 March 2025 (UTC)
Oppose as proposer has not responded. Vicarage (talk) 12:26, 28 September 2025 (UTC)
Support Bit of a misnomer, as no-one breathes pure oxygen, it's usually some mix of gasses, with or without equipment to scrub CO2 buildup. Some of the gasses can cause issues when diving, too much oxygen becomes toxic and too much nitrogen becomes narcotic. What would be a good name, "onboard supply of air analogue/breathable gas-mix" perhaps? And should this include those rods they burn onboard submarines to produce oxygen? I'm guessing those shouldn't be counted. Infrastruktur (talk) 15:12, 2 April 2025 (UTC)
Oppose In the current state where no attempt is made for looking at existing ontology for the concept. I would expect that there's prior art for how to model this concept and currently no prior art is referenced in the discussion. ChristianKl ❪✉❫ 11:54, 28 September 2025 (UTC)
- And what if the previous ontology doesnt exist? Trade (talk) 01:42, 29 September 2025 (UTC)
General
[edit]sign meaning
[edit]| Description | Signification de l'indication ou du panneau pour la circulation (fr) – (Please translate this into English.) |
|---|---|
| Data type | Item |
| Template parameter | fr:Modèle:Infobox Panneau de signalisation ; signification |
| Domain | signal language (Q2285130) |
| Example 1 | Q3362324→level crossing (Q171448) |
| Example 2 | C20a (Q3362348)→pedestrian crossing (Q8010) |
| Example 3 | lighthouse (Q39715)→port (Q44782) |
Motivation
[edit]Defining properties for road signs or over signalization devices author TomT0m / talk page 18:10, 14 June 2025 (UTC)
Discussion
[edit]
Support Similar to identifies (P10476), but it can only be used for nonphysical identifiers. -wd-Ryan (Talk/Edits) 23:17, 15 June 2025 (UTC)
Comment Would represents (P1268) not work for this use case? –IagoQnsi (talk) 00:42, 18 July 2025 (UTC)
- It's originally for an organisation that sends someone to represent itself or delegate its authority, that's quite a stretch of meaning. It's very different from an indication of something. It's not that the word can be the same that the definition fits. We should focus on the "meaning", not the "word" here, this is (the item part of) Wikidata. author TomT0m / talk page 07:12, 18 July 2025 (UTC)
- Hmm, I see. One of the examples on P1268 was misleading (apparently added by me 5 years ago, mea culpa). What about symbolizes (P4878) though? I see it's already even used on restroom pictogram (Q18463298) for this purpose. –IagoQnsi (talk) 23:04, 18 July 2025 (UTC)
- It's originally for an organisation that sends someone to represent itself or delegate its authority, that's quite a stretch of meaning. It's very different from an indication of something. It's not that the word can be the same that the definition fits. We should focus on the "meaning", not the "word" here, this is (the item part of) Wikidata. author TomT0m / talk page 07:12, 18 July 2025 (UTC)
Oppose lighthouse (Q39715) in general don't exist to signal where ports are. They exist to signal that there's land so that ships don't crash into the land.
- My general feeling is that we should have a clear separation between represents (P1268), identifies (P10476) and maybe a new "denotes" property for that relationship. "sign meaning" feels a bit ambigious where it's not exactly clear what a sign is. I would also want a clear property desciption in English. "denotes" feels more compatible with prior art from W3C in semiotics:denotes and ontolex:denotes. ChristianKl ❪✉❫ 12:33, 28 September 2025 (UTC)