quantitykind:Altitude vs Latitude, Longitude; related quantitykinds #379
Comments
|
@VladimirAlexiev, many good points, as usual.
|
|
Altitude, latitude, longitude are not specializations of length, they are specializations of position. There is a datum (offset) and direction involved, whereas length is an absolute quantity. Geometry is complicated. There are detailed standards available from OGC and ISO. For coordinate systems which are required for elevation/latitude/longitude/easting/northing etc - see ISO 19111:2018 (the link is to OGC version which is not paywalled). |
|
@dr-shorthair I was just about to write that if we introduce
But this wouldn't express the origin:
Converting between CRS'es is a complicated matter and I don't think QUDT wants to replicate all the CRS info and conversion algorithms collected by OGC.
But there's no quantitykind @nicholascar what do you think? |
|
I don’t thing QUDT should move into the spatial space, other than listing spastic UoMs. I’ve urged OGC to look to signing up to the QUDT consortium to assist in maintaining QUDT and to influence its governance, but the expected way forward here is for QUDT to stick to metrology and for OGC to use QuDT for all units etc. Perhaps, in the fullness of time, QUDT might become an OGC standard... It would not be the first time an externally-developed thing became a standard (think KML, GeoJSON, etc). |
|
@VladimirAlexiev yes, altitude/elevation/depth/latitude/longitude/easting/northing might be conceptualized as quantity-kinds, but we do need to be careful about confusing quantities and coordinates. I feel that QUDT should probably focus on scalar quantities, and leave coordinates to the more specialized communities that use those routinely. In the case of altitude/elevation/depth/latitude/longitude/easting/northing there is a respectable and rigorous organization that is doing this - OGC. |
|
@dr-shorthair @nicholascar So your opinion is to kill About OGC adoption: GS1 are hesitant to adopt QUDT because it's not vetted by a Standards-Developing Organization (SDO). At least they'll conform their developing list of 71 MeasurementTypes to QUDT's quantityKinds (see gs1/EPCIS#248), but I think will copy them to a I tried to convince them that the best way to ensure QUDT stability and evolution is to contribute to it, not just copy from it. I tried to convince them to step in to fill the former role of NASA, but ... |
|
Yes - I think it would be best if QUDT removed |
|
I agree with Simon |
|
Very interesting discussion, and thanks to @nicholascar and @VladimirAlexiev for advocating for more direct involvement by OGC and GS1 to help QUDT remain a viable and sustainable infrastructure upon which others can build. We do in fact have infrastructure costs to keep QUDT going, which currently come out of our personal pockets, and none of us are paid to work on QUDT, so support by helping with contributions, or with cold hard cash makes a big difference! To the subject at hand, if we remove quantitykind:Altitude, then by the same logic would we not also remove quantitykind:Temperature? It exhibits the same behavior - units are scales with a datum (Celsius,...) just like units of Altitude. Just looking for consistency here. |
|
DEG_C has a quantitykind Temperature but not a ThermodynamicTemperature. It also has a quantitykind CelsiusTemperature, but it's the only one that is, and I would have expected MilliDEG_C to have one. |
|
So altitude is not a quantity kind? It is a specialization of height which is a specialization of distance which is a specialization of length which is a quantity kind. I have often wondered why there is no width, breadth, or height (oops, both width and breadth exist) quantity kinds in QUDT. I didn’t chime in on the early discussion about latitude and longitude but I am keen to hear the reasoning for altitude. By the way, we collect quantity kinds from various sources and some of them have questionable value. Altitude doesn’t appear to be questionable.
I have always thought of altitude as radial distance from some place on the ‘ground’ to some place above the ground. As a pilot I refer to altitude as AGL (above ground level) or MSL (above sea level), but have never heard of it used in the context of a position. You could say that, at an altitude, you would have a position, but they aren’t the same.
I do see latitude and longitude as angular coordinate components of position, but they are only a position when both are provided. Otherwise they are angles.
Jack
…Sent from my iPad
On Apr 17, 2021, at 8:47 PM, Joel Bender ***@***.***> wrote:
DEG_C is a Temperature but not a ThermodynamicTemperature.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
The decision to include or remove a domain from QUDT is surely only related to scientific considerations. Surely the absence or presence of other, related, actors in the Semantic Web are important too, since multiple organizations have their parts to play in this networked information. So here, the fact that the OGC (and even the ISO TC211) exist and are involved with Semantic Web things has bearing on QUDT's decisions around quantitykind:Altitude. Surely if Altitude and other spatial things are "adequately handled" from a Semantic Web viewpoint, then QUDT shouldn't move into that space. If not, then it should. Same for temperature: is there a standards or other organization with a good Semantic Web handling of temperature such that QUDT need not implement things? My best guess is that QUDT should work with temperature and probably is already the Semantic Web's go-to place for temperature quantity kinds, units etc. but that QUDT should not work to replicate Semantic Web spatiality, given the OGC and other's long-time work in the field. As Simon's noted above, perhaps QUDT can stick to scalar values? Current work with GeoSPARQL 1.1 is introducing a |
|
I am in favor of standards organizations taking up the gauntlet of trying to standardize a quantity, unit, and dimension semantic pattern and to standardize vocabularies to that pattern. I am not in favor of carving it up into pieces and laying some kind of claim to those pieces. QUDT is intended to support the existing systems of units and quantity kinds and to provide conversion between them. QUDT has also pledged to provide cross references to other vocabularies. QUDT has been liberal in allowing people (subject matter experts in their fields) to submit units and quantity kinds for inclusion into the vocabularies. Finally, QUDT has also allowed for QuantityKind classes to be customized, and that opens the door to all kinds of use. If anything, QUDT is about broadening coverage and being more inclusive.
So if altitude is a commonly used quantity kind, it is measurable, and it has a dimension vector, I see no issue with it.
QUDT represents many data types and that is why we have a datatype schema. You are suggesting that there not be a common representation pattern and associated vocabularies but I would disagree. That some organization chose to carve out a piece of a whole doesn’t make it right. We should integrate the various models and vocabularies and not tear them apart. That sounds like politics and not like science.
…Sent from my iPad
On Apr 17, 2021, at 10:26 PM, Nicholas Car ***@***.***> wrote:
To the subject at hand, if we remove quantitykind:Altitude, then by the same logic would we not also remove quantitykind:Temperature
The decision to include or remove a domain from QUDT is surely only related to scientific considerations. Surely the absence or presence of other, related, actors in the Semantic Web are important too, since multiple organizations have their parts to play in this networked information.
So here, the fact that the OGC (and even the ISO TC211) exist and are involved with Semantic Web things has bearing on QUDT's decisions around quantitykind:Altitude. Surely if Altitude and other spatial things are "adequately handled" from a Semantic Web viewpoint, then QUDT shouldn't move into that space. If not, then it should. Same for temperature: is there a standards or other organization with a good Semantic Web handling of temperature such that QUDT need not implement things?
My best guess is that QUDT should work with temperature and probably is already the Semantic Web's go-to place for temperature quantity kinds, units etc. but that QUDT should not work to replicate Semantic Web spatiality, given the OGC and other's long-time work in the field. As Simon's noted above, perhaps QUDT can stick to scalar values?
Current work with GeoSPARQL 1.1 is introducing a SpatialMeasure class and right this week I'm working on examples of QUT scalar measurements using SpatialMeasure alongside GeoSPARQL Geometry examples which, hopefully, both QUDT and OGC people can comment on. GeoSPARQL 1.1 will be out for full public review shortly, so please do weigh in officially on that draft.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@jhodgesatmb Which 'altitude' do you mean? |
No - Altitude or elevation is not a specialization of length. It is a measure of offset in a specified direction from a specified reference level, which in turn varies according to lateral position. |
|
what are the units of altitude? I have only ever heard of it in ft, m, mi,
km, ...
…On Sun, Apr 18, 2021 at 1:42 AM Simon Cox ***@***.***> wrote:
[Altitude] is a specialization of height which is a specialization of
distance which is a specialization of length which is a quantity kind.
No - Altitude or elevation is not a specialization of length. It is a
measure of offset in a specified direction from a specified reference
level, which in turn varies according to lateral position.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#379 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATQRWOVYWNZ6GC4LGPVLU3TJKLQJANCNFSM425HV4TA>
.
--
Jack
|
|
I can see that length (size) and distance are different, so altitude is a
distance. My mistake. Distance and length do have the same dimensionality.
If I do a simple lookup in the dictionary or wikipedia (not authoritative
sources but good enough for the point) I find several definitions, most
notably differences between its use in aviation, atmospheric studies, and
geometry. Given that QUDT originated with NASA I suspect Altitude is used
in the aviation context. The question is twofold: (1) whether altitude is a
quantity kind (and not whether it is ambiguous across domains), and (2)
whether altitude should be represented in QUDT vocabularies. I see altitude
as a quantity kind so to me it should be in the QUDT vocabulary of quantity
kinds.
*Wikipedia* (a longish description but the first few paragraphs under
aviation are):
In aviation, the term altitude can have several meanings, and is always
qualified by explicitly adding a modifier (e.g. "true altitude"), or
implicitly through the context of the communication. Parties exchanging
altitude information must be clear which definition is being used.[2]
<https://en.wikipedia.org/wiki/Altitude#cite_note-AFM_51-40-2>
Aviation altitude is measured using either mean sea level
<https://en.wikipedia.org/wiki/Mean_sea_level> (MSL) or local ground level
(above ground level, or AGL) as the reference datum.
Pressure altitude <https://en.wikipedia.org/wiki/Pressure_altitude> divided
by 100 feet (30 m) is the flight level
<https://en.wikipedia.org/wiki/Flight_level>, and is used above the transition
altitude <https://en.wikipedia.org/wiki/Transition_altitude> (18,000 feet
(5,500 m) in the US, but may be as low as 3,000 feet (910 m) in other
jurisdictions); so when the altimeter reads 18,000 ft on the standard
pressure setting the aircraft is said to be at "Flight level 180". When
flying at a flight level, the altimeter is always set to standard pressure
(29.92 inHg <https://en.wikipedia.org/wiki/Inches_of_mercury> or 1013.25 hPa
<https://en.wikipedia.org/wiki/Pascal_(unit)>).
*Merriam-Webster*:
1a: the vertical elevation of an object above a surface (such as sea level
or land) of a planet or natural satellite
b: the angular elevation of a celestial object above the horizon
c(1): a perpendicular
<https://www.merriam-webster.com/dictionary/perpendicular#h1> line segment
from a vertex (see VERTEX sense 2a
<https://www.merriam-webster.com/dictionary/vertex>) of a geometric figure
(such as a triangle or a pyramid) to the opposite side or the opposite side
extended or from a side or face to a parallel side or face or the side or
face extended
(2): the length of an altitude
2a: vertical distance or extent
b: position at a heightThe plane lost altitude.
c: an elevated region : EMINENCE
<https://www.merriam-webster.com/dictionary/eminence> —usually used in
plural
3: a high level (as of quality or feeling)the altitudes of his anger
…On Sun, Apr 18, 2021 at 7:21 AM Jack Hodges ***@***.***> wrote:
what are the units of altitude? I have only ever heard of it in ft, m, mi,
km, ...
On Sun, Apr 18, 2021 at 1:42 AM Simon Cox ***@***.***>
wrote:
> [Altitude] is a specialization of height which is a specialization of
> distance which is a specialization of length which is a quantity kind.
>
> No - Altitude or elevation is not a specialization of length. It is a
> measure of offset in a specified direction from a specified reference
> level, which in turn varies according to lateral position.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#379 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AATQRWOVYWNZ6GC4LGPVLU3TJKLQJANCNFSM425HV4TA>
> .
>
--
Jack
--
Jack
|
|
Altitude is quantified with respect to a datum. Likewise depth below sea level. Perhaps these can be handled in a similar way to how coordinate systems are specified. In the NASA work QUDT defined 23 coordinate systems. They should be somewhere in the REPO. I remember not being done on coordinate systems because they lacked support for transformations.
Ralph Hodgson
… On Apr 18, 2021, at 4:42 AM, Simon Cox ***@***.***> wrote:
[Altitude] is a specialization of height which is a specialization of distance which is a specialization of length which is a quantity kind.
No - Altitude or elevation is not a specialization of length. It is a measure of offset in a specified direction from a specified reference level, which in turn varies according to lateral position.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
In support of @jhodgesatmb's point about QUDT's goal of being inclusive, I'd suggest we keep Altitude in the vocabulary, with reference(s) to the OGC entities that correspond. Consistent with how we provide cross-references to other standards, we could invent a new property, something like qudt:ogcMatch (analogous to qudt:dbpediaMatch), or just use rdfs:seeAlso. |
|
@jhodgesatmb You can think of altitude as a distance rather than a length, but distance is always measured from a location. For elevation or altitude this is in a specified direction from a reference level. The direction is vertical, i.e. parallel to the gravity vector, and measured positive upwards. The reference level or datum is usually a spheroid, defined by spherical harmonics (to order 300+), which is at different heights relative to the centre of the earth at different locations, to approximate 'the geoid', which is the surface corresponding to local sea-level. But the main point here is that altitude or elevation is strictly not a quantity, it is a coordinate. It only feels like a simple quantity if you make assumptions about the reference level - probably 'mean sea level', and the direction - up (compare to 'down', which gives you depth rather than elevation/altitude). For many purposes that is 'good enough' but I don't think 'good enough' is the goal of QUDT. As I mentioned, the reference dataset for geodesy records more than 200 vertical reference systems in use around the world. It is unhelpful to pretend it is simpler than that, particularly as there are recognised authorities for geodesy. (I don't accept the proposition that Wikipedia or the Merriam-Webster dictionary are a superior authority for geodetic concepts.) |
|
And yes @steveraysteveray Celsius and Fahrenheit scales do not measure quantities, they measure position on a temperature scale. As @JoelBender points out, |
|
|
@dr-shorthair @nicholascar could you please weigh in on gs1/EPCIS#266 ? |
Definitely not, since they are location dependent. |
There is
quantitykind:Altitude, a specialization ofquantitykind:Lengthquantitykind:Altitude qudt:hasDimensionVector <http://qudt.org/vocab/dimensionvector/A0E0L1I0M0H0T0D0> ; skos:broader quantitykind:Length ;But there aren't
Latitude, Longitudeas specializations ofAngleI find this inconsistent. Please decide whether to create
Latitude, Longitudeor to dropAltitude.Also, there aren't
Speed of ascent, Speed of descentas specializations ofSpeed.But I feel less strongly about this, because there'd be no end (we can then have "acceleration of descent", etc etc).
--
Are there any principles when to create quantitykind "specializations"?
I was surprised to find that the dimension vectors of some quantity kinds and their specializations are different, eg:
A0E0L-3I0M1H0T0D0(same as quantitykind:Density) but hasapplicableUnit unit:UNITLESS? I think that's wrong?A0E0L-3I0M1H0T0D0but there's no relation between them? Isn't one of them superfluous?In general, I think the following quantity kinds need to be examined:
The text was updated successfully, but these errors were encountered: