[Feature]: Decide on v4 stereotypes for LocationReferencing

[iancornwell1]

Feature description

The v4 modelling methodology offers new stereotypes, for entities and for codelists. While we are revising the LocationReferencing namespace for v4, we need to decide whether the stereotypes of any elements need changed. Maybe the answer is none, but we should consider and record our decision here.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[LBlaive]

Interesting question. Honestly speaking, after reading the new part 1 (as proposed as prEN 16157-1) I cannot conclude in which case to use the "D2Entity" stereotype or the "D2Class" stereotype. If I wanted to make a parallel with ISO 19103:2015 and EN ISO 19109:2015, I would associate "D2Entity" with the "FeatureType" stereotype and "D2Class" with "DataType". The distinction as stated in these standards is:

• "DataType" is used for any classifier when "lacking identity". They are often used to typify attributes (which implies they be complex) (if we look at CEN/TS 17268:2018 "TN-ITS" the "Condition" and "Validity" classes are stereotyped as "DataType".
• "FeatureType" is used for "abstraction of real-world phenomena", which means a possibility to define an identity.

With this in mind I would say the "PredefinedLocationReference", "PredefinedLocation", "PredefinedItinerary" and ""PredefinedLocationGroup" could become "D2Entity" and even "D2EntityVersionedIndentifiable". The other classes remaining stereotyped as "D2Class".

But probably my interpretation is incorrect.

About "CodeList", I can think of "Lane", "Carriageway", "InfrastructureDescriptor", "NamedAreaType", "SubdivisionType".

An open question may be about some TPEGLoc lists if there were a desire to keep concistency with the evolution of these specifications.