external 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))
Check minimal value for elevation in country Items with incorrect elevation value ; todo: only on item who having a single country (Help) Violations query:SELECTDISTINCT?obj?pel?el?altMin{?objp:P2044/psv:P2044?pel.?pelwikibase:quantityAmount?el.?pelwikibase:quantityUnitwd:Q11573.?objwdt:P17?pays.?payswdt:P1589?objMin.?objMinwdt:P2044?altMin.BIND(10AS?tolerance).FILTER(((?altMin-?tolerance)<=?el)=false).MINUS{?objwdt:P31wd:Q674775.}}ORDER BY?obj List of this constraint violations: Database reports/Complex constraint violations/P2044#Check minimal value for elevation in country
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.
You already added it as a constraint, but failed to provide a single sample or valid statement .. not really optimal as approach. --- Jura09:05, 10 September 2015 (UTC)[reply]
@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)[reply]
Just wondering, how many dewiki elevations are not measured by the national standard (points on borders excluded)? --- Jura10:55, 10 September 2015 (UTC)[reply]
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.
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,...)
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 Neue St.-Alexander-Kirche (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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
I'm curious why apply a value of 200 kilometres generates a range constraint violation. The constraint is -160000 to 100000, and the accepted units include kilometers, so this seems...broken? My use cases are like Tsyklon-2 (Q367286), where the target orbit needs to be indicated, and there is no better property than this one since we don't have one for average orbital altitude. — Huntster (t@c)04:21, 17 October 2023 (UTC)[reply]