Open main menu

Property talk:P2044


elevation above sea level
height of the item (geographical object) as measured relative to sea level
Descriptionaltura del elemento en relación al nivel del mar (es) – (Please translate this into English.)
Representsheight above mean sea level (Q6452016)
Data typeQuantity
Template parameter"elevation_m" and "elevation_ft" in en:template:infobox settlement
Domaingeographic location (Q2221906) (place) (note: this should be moved to the property statements)
Allowed valuesheight in meters or feet (note: this should be moved to the property statements)
Allowed unitsmetre (Q11573), kilometre (Q828224) and foot (Q3710)
ExampleMaïdo (Q3303392) → 2,205 metre
Badwater Basin (Q799720) → -279 foot
Bern Airport (Q619845) → 510 metre
Sourceexternal reference, Wikipedia list article (either infobox or source) (note: this information should be moved to a property statement; use property source website for the property (P1896))
Tracking: sameno label (Q32085169)
Tracking: differencesno label (Q21158631)
Tracking: usageCategory:Pages using Wikidata property P2044 (Q20989797)
Tracking: local yes, WD noCategory:Elevation above sea level not in Wikidata, but available on Wikipedia (Q21158632)
See alsoheight (P2048), vertical depth (P4511), highest point (P610)
Proposal discussionProposal discussion
Current uses1,673,763
  Units: “metre (Q11573), kilometre (Q828224), foot (Q3710): value unit must be one of listed. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2044#Units, SPARQL (new)
  Qualifiers “determination method (P459), applies to part (P518), point in time (P585), valid in place (P3005), sourcing circumstances (P1480), relative to (P2210), minimum value (P2313), maximum value (P2312): this property should be used only with the listed qualifiers. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2044#Allowed qualifiers, SPARQL, SPARQL (new)
  Range from “-160000” to “100000”: values should be in the range from “-160000” to “100000”. (Help)
Exceptions are possible as rare values may exist. Known exceptions: International Space Station (Q25271)
List of this constraint violations: Database reports/Constraint violations/P2044#Range, SPARQL (new)
  Conflicts with “instance of (P31): aircraft family (Q15056993): this property must not be used with the listed properties and values. (Help)
List of this constraint violations: Database reports/Constraint violations/P2044#Conflicts with P31, hourly updated report, SPARQL, SPARQL (new)
  Check minimal value for elevation in country
Items with incorrect elevation value ; todo: only on item who having a single country (Help)
Violations query: SELECT DISTINCT ?obj ?pel ?el ?altMin { ?obj p:P2044/psv:P2044 ?pel. ?pel wikibase:quantityAmount ?el. ?pel wikibase:quantityUnit wd:Q11573. ?obj wdt:P17 ?pays. ?pays wdt:P1589 ?objMin . ?objMin wdt:P2044 ?altMin . BIND(10 AS ?tolerance). FILTER(( (?altMin - ?tolerance) <= ?el ) = false). MINUS { ?obj wdt:P31 wd:Q674775. } } ORDER BY ?obj
List of this constraint violations: Database reports/Complex constraint violations/P2044#Check minimal value for elevation in country

determination method (P459) valuesEdit

This is a list of values used with the qualifier determination method (P459)

This list is periodically updated by a bot. Manual changes to the list will be removed on the next update!

WDQS | PetScan | YASGUI | TABernacle | Find images Recent changes
# qid label count instance of subclass of
1 Q1398875 Normalhöhennull 696 stream gauge
sea level
zero-level elevation
2 Q268449 Normalnull 354 stream gauge
sea level
zero-level elevation
3 Q23202 Metres above the Adriatic 168 stream gauge
zero-level elevation
4 Q694278 Metres above the Sea 112 stream gauge
zero-level elevation
5 Q27700527 NGF - IGN69 24 geodetic reference system
6 Q10566338 Hong Kong Principal Datum 18
7 Q3393392 highest point 7 maximum
8 Q816425 surveying 5 activity technique
academic discipline
9 Q10585806 minimum 2 minimum element
10 Q7053896 North American Vertical Datum of 1988 2
11 Q6452016 height above mean sea level 2 altitude
12 Q39825 census 2 recurring event information source
population estimation
recurrent event edition
data set
13 Q4271952 Amsterdam Ordnance Datum 2 sea level
stream gauge
zero-level elevation
14 Q5727902 circa 2 term
15 Q37221 diameter 1 line segment
16 Q202785 average 1 measured value
central tendency
17 Q791801 estimation process 1 engineering process finding
18 Q12013 Google Maps 1 website
digital map
web application
19 Q483130 geographic information system 1 application
information system
20 Q6130762 Sociedad Asturiana de Estudios Económicos e Industriales 1
21 Q12453 measurement 1 estimation process
22 Q10578722 maximum 1 maximal element
23 Q2924304 multibeam echosounder 1 sonar
24 Q31087168 European Vertical Reference System 1 height reference system
25 Q28652667 Geodätischen Grundnetzpunkt 1

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Determination of levelEdit

Statements using that properties have to mention the reference point. I propose to use determination method (P459) as qualifier in order to provide that information. A constraint about the use of the qualifier is added but the list of values for that constraint should be provided.

I propose to use the reference points of the different countries (at least in Europe) as value for the qualifiers. Snipre (talk) 09:00, 10 September 2015 (UTC)

You already added it as a constraint, but failed to provide a single sample or valid statement .. not really optimal as approach. --- Jura 09:05, 10 September 2015 (UTC)
@Jura1: Please read until the end my comment: I did a proposition for qualifier value. And if I didn't fill the template it is just because I preferred to have some debate about what kind of value can be used because if the property for the qualifier is really well suited for the current case, the type of the value is more difficult to define. Next time try to be a little more helping by doing some proposition a little more constructive. Snipre (talk) 17:43, 10 September 2015 (UTC)
I think this should be changed back from “elevation above sea level” to more general “height”, with a qualifier to specify what the height is relative to (there’s no single “sea level”, dewiki lists 28 different standards). I proposed a new property for this qualifier, but I guess determination method (P459) could be used too. —Galaktos (talk) 10:33, 10 September 2015 (UTC)
Just wondering, how many dewiki elevations are not measured by the national standard (points on borders excluded)? --- Jura 10:55, 10 September 2015 (UTC)
I’m not an expert, but from reading dewiki it seems that Germany switched from Normalnull (Q268449) to Normalhöhennull (Q1398875) (which is apparently “the basis of” United European Levelling Net (Q15852105) in Germany) in 1992 (after the reunification; Eastern Germany apparently used something called SNN56/Höhennull, which doesn’t even have its own Wikidata item).
Most newly published maps are based on NHN, but apparently that conversion isn’t finished yet.
Anyways, it seems heights in dewiki templates usually include the reference height as HÖHE-BEZUG parameter (see full list of supported references on de:Vorlage:Höhe#Parameter, „2. Parameter“). —Galaktos (talk) 11:23, 10 September 2015 (UTC)
So try to be more constructive: Do we want to specify the origin by using as value for the qualifier
  • the place defined as the reference point (Marseille for France, Ajaccio for Corse, Ostende for Belgium, Chiyoda for Japan,...)
  • the national norm/reference used to describe the way to define the level (LN02 for Switzerland and Liechtenstein, Naparima 1955 for Trinidad and Tobago,...)
or something different ? Snipre (talk) 17:43, 10 September 2015 (UTC)
Whatever the source says, right? I suspect this will usually be a national norm/reference (if the source is some official publication), but generally it’s not Wikidata’s task to reinterpret a height given relative to some norm as relative to some reference point, or vice versa. Wikidata just states what’s in the reference. —Galaktos (talk) 22:19, 10 September 2015 (UTC)
The source is always important but the question is to know if we want to increase the data available in Wikidata in order to perform comparison for example. The source will provide that kind of information but when someone wants to do the comparison, he woudln't have the time to read all references to extract that information. The idea of this qualifier is to standardize the way this information is stored in Wikidata. Snipre (talk) 19:39, 13 September 2015 (UTC)
Well, again, I don’t think it’s Wikidata’s goal to standardize the content of the information stored – it only makes it accessible in a common format. For the same reason, we support non-Gregorian calendars, and allow non-SI units for quantities, even though we could convert these too.
There’s also the question of what level to convert to? How do you choose the “standard” sea level when there are lots of different standards (map for Europe), most of which probably don’t even cover the entire globe?
For simple uses, like “what’s the highest mountain in Chile?”, I don’t think a conversion is necessary – it’s fine if the reference level is just ignored, since the difference between object heights is probably much larger than the difference between the reference heights. But for those uses that do care about the exact value, we need to have the correct, unadulterated value. —Galaktos (talk) 11:11, 14 September 2015 (UTC)
I think we have a problem of understanding: the idea is not to do any conversion, the idea is to give an additional information about the reference used in the definition of the elevation in order to inform the reader that one meter above the sea in Spain isn't the same value in France. The difference is often small but can reach more than one meter depending the countries. If I compare the Mont-Blanc in France with the Mount Vesuvius in Italy, I can't use raw data, but I theoretically have to correct the values because the references are not the same. By indicating with a qualifier the reference for each elevation, we can call the attention of the data user to the reference difference. This is not a critical point but this is a typical information which adds value in a database because you can perform some correction automatically like the one we are doing by indicating the calendar with the date.
If we want to do that kind of addition we have to provide some "standard" in order to help people to structure similar data. If someone provides as qualifier of the Mont-Blanc elevation the reference point = 7th arrondissement of Marseille (Q259408) (place where the Marseille marigraph is located) and another one add Marseille marigraph (Q3296411) for the Mont Ventoux, it is impossible for the system to deduce that both elevations have the same reference. So the standardization here is just to indicate what kind of data (location, item representing the measure instrument, the legal text defining the instrument as reference for a country,...) the contributor has to provide. Nothing more, nothing less. Snipre (talk) 13:53, 14 September 2015 (UTC)
Oh, I see the misunderstanding now. Thank you. However, I think I don’t understand the situation in other countries yet.
In Germany, the reference is Normalhöhennull (Q1398875), which is an imagined, quasi-geoid reference surface. All heights above NHN are vertical distances to that virtual plane. It has a reference point in Q1533101 (a church somewhere in northeastern Germany), but heights aren’t relative to that reference point; they’re relative to the plane described by NHN. In Germany, it seems clear to me that the item for the qualifier would be Normalhöhennull (Q1398875), not one of its reference points. And I would have assumed that other countries have a similar reference plane that should be used.
I don’t know if it works the same way in France, though. There seems to be some EU thing, United European Levelling Net (Q15852105), but both items you mentioned seem to be something different, and less suitable for being the qualifier item. (I thought “Marseille marigraph” sounded promising until I looked up what a “marigraph” is :) ) So I’m not sure now how we should proceed… —Galaktos (talk) 14:16, 14 September 2015 (UTC)


Bonjour, comment peut-on faire pour gérer l'altitude maximum et minimum pour les communes, nouvelles propriétés, lower and upperbound ou qualificateurs (lesquels) ... ? Merci à vous.----Pinof (talk) 21:25, 13 September 2015 (UTC)

@Pinof: C'est un problème récurrent: plusieurs propriétés spécialisées ou une propriété avec des qualificatifs ? Il n'y a pas de réponse définitive sur la question. Le plus simple est de proposer les 2 propriétés altitude max et altitude min et de voir ensuite ce que la communauté décide. Les propositions doivent faites en utilisant le modèle Property documentation (voir template:Property documentation) et sur la page suivante Wikidata:Property_proposal/Place#General. Snipre (talk) 09:50, 14 September 2015 (UTC)

Altitude of a city?Edit

A bot has started to import the elevation of cities from the infoboxes in the English WP (see e.g. [[1]]). However, a city may cover several km² and include hills and valleys, so instead of a rather arbitrary mean value (is it a mean value over the whole area, the value at the "city center") we'd either need a new datatype "number range", or two new properties "maximum elevation" and "minimum elevation", or would need some good example how to encode this information with qualifiers. Ahoerstemeier (talk) 21:07, 27 September 2015 (UTC)

I don’t think we need a new data type for this, since the current “Quantity” type already stores a mean value, lower limit, and upper limit (though lower and upper limit are presented in the UI as a single “±X” deviation – I’m not sure if it’s currently possible to store a datum where the value isn’t in the middle of lower and upper limit). —Galaktos (talk) 21:50, 27 September 2015 (UTC)
The “±X” is for precision of the number, which is not the range of the value. Jeblad (talk) 13:23, 7 November 2017 (UTC)

P518 (applies to part)Edit

I have used as value for this property for rivers the items Q1233637 (river mouth) and Q7376362 (river source). --Molarus 05:08, 6 January 2017 (UTC)

Flight Height?Edit

Is this property intended to be used as the flight height of an airplane? As such, it is used by e.g. Q15901049, Q15623287 and Q890198. Steak (talk) 14:58, 16 April 2017 (UTC)

I just found Property:P2254, so using P2044 for airplanes is wrong. Steak (talk) 10:44, 21 April 2017 (UTC)

Truncated valuesEdit

I'm seeing 57 instances of elevation above sea level (P2044) set to -32768 metres. As that is the largest negative signed 16-bit integer, I'm guessing that whatever automated system is adding these truncated values is using just 16 bits for its integers. Could somebody have a word with User:Mr.Ibrahembot and anybody else who is screwing up these entries before we get any more garbage added, please? Also the reference added in each case says nothing that I can see about elevation above sea level, so I can see no means to supply a corrected value. Ping User:Mr. Ibrahem in case the bot notification doesn't get through.

If I'm wrong and this property is somehow constrained in its most negative value by design, then perhaps that is the issue that needs to be addressed. Either way, it makes the data with this property unreliable for use elsewhere, especially with a false sourcing claim. --RexxS (talk) 20:07, 28 October 2018 (UTC)

The bot User:Mr.Ibrahembot, doesn't work with these property any more. --Mr. Ibrahem (talk) 09:26, 30 October 2018 (UTC)
Return to "P2044" page.