ISO-TC211 / StandardsTracker

This GitHub repository lets you - our users - log and track issues that you find with our standards and other document. Tag the issue with the standard or standards effected; we will assign it to the relevant group(s) within TC 211.
11 stars 0 forks source link

Basic types and definitions for reference for 19103 and or 19107 #418

Open wilkesg opened 2 years ago

wilkesg commented 2 years ago

The core 19123-1 coverages team had a meeting 25 Aug 2021 to discuss some content we think should be included in working group 1 agenda and the 19103 project, or future 19107 work. For the current draft DIS of coverages we identified the need for a stable definition for reference for:

• Direct position -Need for a basic type for reference • RSID -The references we have for it in UML is included in spares? Not part of main text definition.

During the call, the consensus for the team members was for some other need for some ‘basic types’ independent of the coverages work.

• Complex numbers, integers, number fractions, there are likely others, but this is what I jotted down during our call.

PeterParslow commented 2 years ago

I'm not sure what you mean by "included in spares"? Is this actually part of the question about the relationship between "things defined in the model" (UML, proposed ISO 19103 type dictionary) and "things defined in the terminology"? I think that question needs resolving by wider discussion that the ISO 19103 project - or any other project. @jetgeo : is it something that HMMG and/or the Resource group more widely would like to take on?

Direct position seems at home in ISO 19107 where it's defined at the moment (and was in Edition 1). What would be the case for separating it from the rest of Coordinate Geometry?

If by RSID you mean the RSID ("reference system identity") union class in ISO 19107 Coordinate Geometry, then again that seems a reasonable home for it.

Integer is a type already defined in ISO 19103 (Primitive types). Decimal is there too, but not a generic type for fractions. And not Complex numbers either. I guess those are candidates for inclusion in the new register of "common types".

heidivanparys commented 2 years ago

Integer is a type already defined in ISO 19103 (Primitive types). Decimal is there too, but not a generic type for fractions. And not Complex numbers either. I guess those are candidates for inclusion in the new register of "common types".

Yes, I agree. FYI: the need for fractions has been raised in the systematic review as well (DK-013 in ISO/TC 211 N 5609).

For the current draft DIS of coverages we identified the need for a stable definition for reference for:

• Direct position

(cc @ReesePlews) ISO 19136-1:2020, 3.1.20 can be used a reference for the concept, see Geolexica, Online Browsing Platform and Edition 2020-06-02 Multi-Lingual Glossary of Terms (MLGT):

control body decision event:

Supersession of ISO 19107:2003 and publication of ISO 19136-1:2020

register manager notes:

Authoritative reference changed from ISO 19107:2003 to ISO 19136-1:2020(E), 3.1.20. Lineage source added as ISO 19107:2003

Update: When reading the mail again, I am unsure whether a UML class (HMMG) or a definition (TMG) is needed for reference?

PeterParslow commented 2 years ago

@ReesePlews : surely it makes more sense to keep the definitive home of DirectPosition in ISO 19107, even though ISO 19136-1 then uses it? ISO 19107 defines the data type, ISO 19136-1 defines an XML encoding of it. I don't think that being published more recently automatically makes something more authoritative - so I disagree with whichever control body Heidi is quoting here.

I think the bigger question remains the balance of "authority" for types vs textual (terminology) definitions. But in this example, both standards have text that describes the class. The question is why does ISO 19136-1 have have a 'clause 3' entry for Direct Position? Of course, behind that is 'why did OGC define the term, rather than just import the class?'

@wilkesg : can you clarify whether WG6 / ISO 19123 is looking for a class or a terminology definition?

PeterParslow commented 2 years ago

See https://github.com/ISO-TC211/StandardsTracker/issues/400 regarding Direct Position

wilkesg commented 2 years ago

@PeterParslow , we are looking for both. Our Editor requires a class that should be able to carry general multi-dimensional points

2015Yuqi commented 2 years ago

Thanks for Doug OBrien's nice summary, :-)

In Working Group 7 we also have the need for several of these basic types. In particular, there is the need for Direct Position, and for Fraction. Direct Position is used everywhere since it is the basic geometric point location. It used to be defined in 19107. The new 19107 still includes the model for it but the definition is gone. It needs to be restored in 19103. Fraction exists in both the 19152 series and the 19144 series, although in the 19152 series it is a nominator and denominator description (that allows irrational numbers), and in the 19144 series it is a decimal fraction. Also the 19144 series includes several restrictions, for example, positive fractions. Simply 19103 should provide ALL the basic number types.

PeterParslow commented 2 years ago

Thanks for the input, @2015Yuqi . That's exactly my question about the balance of usefulness & priority between a Clause 4 terminology definition of a term & a class definition.

I don't think the solution is for ISO 19103 to have terminology definitions. It is tasked with create a 'class dictionary' initially populated with the classes currently defined in ISO 19103 plus (perhaps) some of the homeless ones. Direct Position isn't one of those - as a class, its home is rightly in ISO 19107 and I think we're all happily reusing the class from there.

@ReesePlews . @jetgeo : it seems that both WG6 & WG7 value having "Clause 4 like" term definitions as well as classes. I think this makes it more important that we answer the question of the priority/precedence (in the sense of 'which is more authoritative' between terms, concepts, and classes. Is this also a further case for a TC211 concept register, to which both terminology (with its multi-lingual support) & classes relate?

PeterParslow commented 2 years ago

@wilkesg : I don't think there is, or has ever been, a limit on the number of dimensions that a DirectPosition is defined in, that depends on the CRS used, for which ISO 19107 references ISO 19111. ISO 19107:2019 explicitly adds "which may be compound" (including as an ordered sequence of RS identifiers); the first edition left that implicit (i.e. in ISO 19111).

In my understanding, ISO 19111 limits it to 1, 2, or 3 dimensions plus time (Introduction: "Geographic information is inherently four-dimensional and includes time").

Software implementations of course do often limit the number of dimensions.

wilkesg commented 2 years ago

@PeterParslow Thank you for the information on the non limitation of dimension. Will share it with the Project Team.

wilkesg commented 2 years ago

@PeterParslow Comments back from the team on the above: -6.2.9 there is a DirectPosition definition. It is not in the terms section. -req 6 requires coordinates to be numbers - does not work with time. See also: 6.2.9.4 Attribute coordinate The attribute "coordinate" is a sequence of Real numbers that hold the coordinates values for this position in the specified reference systems The requirement is to handle more than real, like string. It was also noted that the fig 6 and HM might show some differences worthy of a check.

PeterParslow commented 2 years ago

"-req 6 requires coordinates to be numbers - does not work with time."

I suspect John's response, as the editor of ISO 19107 (especially this revision) would be that conceptual measures along a time axis can be represented as real numbers. The time axes definition would specify the units: there are certainly time reference systems that count in seconds from an origin (datum), whilst others are more usually expressed in years/days or years/months/days with hours/minutes/seconds.

That's effectively the same that happens when one chooses to represent a latitude or longitude with decimal degrees or degrees / minutes / seconds - I don't think that means the conceptual definition of coordinates (& therefore DirectPosition) is wrong on this count.

The implementation level requirement will often be to handle the time dimension as a coded string (e.g. ISO 8601).