Standard Maintenance

As the LADM standard is now being used (and read by further eyes) it is inevitable that further issue will arrive. These include:

• detecting and correcting simple text errors: 1. on page 1 it states the standard provides ‘… model with four packages’, while on the same page it is also states ‘LADM consists of three packages and one subpackage’, which is correct, 2. In figure 7 on page 13 in the constraint of VersionedObject startLifespanVersion is not correct, this should be beginLifespanVersion, 3. on page 37, in figure 12 the class LA_Point has attribute 'pointType : LA_PointType = control', but there is no reason to specify 'control'.
• The level of conformance for LA_AdministrativeSource (2 per description in page 43) is different from the level of conformance for the same class in the table (1 per the table at page 41). Most likely level 1 for LA_AdmistrativeSource is correct (different from LA_SpatialSource at levcel 2).
• The value type for attribute extPhysicalUtilityNetwork in Class LA_LegalSpaceUtilityNetwork ( ExtPhysicalUtilityNetwork ) in Figure 11. is different from the value type for that same attribute in the description all on page 29 (oid as data type). Most likely extPhysicalUtilityNetwork is correct (similar to situation in LA_LegalSpaceBuildingUnit).
• Figure 9: multiplicity between LA_Party and LAGrouParty : a party can be member of zero or more [0..*] group parties – the related multiplicity in the figure should be [0..*] and not [0..1].
• Correcting omissions (multiplicity in Table 3 with associations: row 1 Party GroupParty , not correct).
• On page 32 it states 'The attributes of LA_Point are: ⎯ estimatedAccuracy'..., but on page 37 LA_Point does not have an attribute estimatedAccuracy (note that on page In the Japan country profile there is indeed an attribute estimatedAccuracy for LA_Point). This needs to be corrected.
• Formalization of code list values: specify registries, procedures for updating the registries with new/ changed/ deleted code list values (possibly with structure: hierarchy; e.g. apply SKOS), national and international aspects (translation and various languages), versioned code list values (possibility to change over time; e.g. refined definition), etc.
• Adding an RRR relationship to relate various rights when needed; e.g. Link a long lease to an ownership right or 2. link the two shares in ownership right of a man and wife.
• Adding further legal refinement and extension of the standard (e.g. extension model conform the proposal of Paasch, 2012). For the first edition of the LADM standard, it was considered to be ‘a bridge too far’ to standardize the legal definitions of the various types of RRRs (and only example RRR types are given in an informative annex F). For second version of standard this might be refined and moved to normative part of standard (together with legal definitions for the various types of RRRs), perhaps using semantic technologies.
• Consider including valuation/taxation (now external classes) in the model. An option could be to include this as informative annex (similar to LPIS or INSPIRE CP annexes). Now mentioned in informative annex K (External classes: ExtValuation and ExtTaxation ).
• Investigate more explicit support, specific for Marine Cadastre, most likely to be developed together with IHO and the development of their standard S121 – Maritime Limits and Boundaries.
• Page 37/49/97: on page 37 the geometry type of LA_BoundaryFace is GM_MultiSurface (correct). However, the first line on page 49 states the this is a GM_Surface, which is inconsistent (not correct). Note that this is an error in the normative part of the standard (Annex B). In the informative Annex E on page 87, the example spatial profile '3D topology' again uses a GM_Surface in 3D_BoundaryFace (and not a GM_MultiSurface). In theory it could be correct here as in the inheritance a more specialized subtype could be used. But is is more likely that this is a small mistake (and it should also have been a GM_MultiSurface).
• Page 22: The text explaining the LA_RRR attribute timeSpec states 'Operational use of a right in time sharing;' and the NOTE below is only mentioning recurring patterns for timeSpec. This is too limited in two ways: 1. it is not only relevant for right but for all RRRs, and 2. more obvious timeSpec should also be mentioned (single time interval with limited duration; as was also shown in Annex C, the instance level diagram for a long lease of 25 years in case C1 or 30 years in case C33).
• Page 29, In LA_SpatialUnit the area/surface is allowed to be multi-part (not preferred), but the attribute referencePoint can at most hold 1 location (GM _Point [0..1]). Is this correct? Or shoyld each area (volume) have a reference point (e.g. for showing label)?
• More explicit relationships with BIM (IFC), GeoBIM , CityGML , IndoorGML , InfraGML , LandXML , etc. for the external classes in LADM (such as ExtPhysicalBuildingUnit and ExtPhysicalUtilityNetwork ), but might also be relevant in the context of the Spatial Unit Package (esp. the Surveying and Representation Subpackage).
• Page 37 is constraint in LA_BoundaryFaceString correct ({(count (geometry) + count (locationByText)) > 0 or count (point) >1} )? For example, should sum of counts not be exactly equal to 1 (so there is either a text or a geometry description, but not both). Current standard could indeed be correct and that it is indeed possible to have at the same time a text and a geometry (GM_MultiCurve) representation in a LA_BoundaryFaceString. And in addition you could also have references to an ordered set of LA_Points (or just have references to points and no text or geometry inside LA_BoundaryFaceString). So, LADM gives a lot of freedom here, it may be possible in a country profile to limit the freedom and have less options.
• Page 48 on line 5 of text when GM_MultiCurve is mentioned, the term 'linestring' is added between brackets. This is gives wrong impression of intention as linestring may imply only straight line segments, which is not the case, and also the fact that multiple curves are allowed values is not reflected. So, better omit this 'explanation' of GM_MultiCurve or make it more correct.
• Page 85, informative annex E, the 2D Polygon profile: as a GM_MultiCurve is used (and not a GM_MultiSurface or GM_Polygon), there should also be some constraints that the curves form closed rings (at least one outer ring and optionally also inner rings) and that the curves are also not intersecting. Actually this is a bit overloaded use of the basic LADM model for various types of spatial representations. The GM_MultiCurve is 'misused' in this case for a GM_MultiSurface. In principle not a big issue, but in the spatial profile this should be corrected by adding constraints. Note that the same would be true for a 3D polyhedral (solid) based spatial profile (not included in Annex): one would expect the use of a GM_MultiSolid as geometry in the 3D LA_BoundaryFace, but this will also not be the case here (but the GM_MultiSurface with constraints that surfaces form properly at least one outer shell and possible more outer/inner shells).
• In the UML model, many classes have an identifier attribute (Xid of type oiD). In the EA UML model, this is not explicitly marked as identifier, it is only in text/explanation mentioned. For model transformations, it is important to know which attribute(s) from the id. Best placed would be oid in Versioned Object.
• Instance level diagrams of STDM contain BAUnit, this is not possible and must be removed.
• LA_SpatialUnit (alias LA_Parcel) have 2 subclasses LA_LegalSpaceBuildingUnit and LA_LegalSpaceUtilityNetwork. Maybe a 3rd subclass LA_Parcel.
• (LADM2018, Zagreb) ISO 19152:2012 establishes that a right or responsibility is directly associated with exactly one (1) party and exactly one (1) basic administrative unit (BAUnit). However, in the face of restrictions, these will be associated with zero or one (0..1) party, and exactly one BAUnit. In this regard we consider that the treatment of the restrictions should be the same as that of the responsibilities, considering that if the rule establishes that LA_PartyType can be a BAUnit, in the case of an existing restriction the association should also be exactly one (1) party and exactly one (1) basic administrative unit. However, in practical life it is found that a BAUnit does not always have an associated responsibility or a restriction, therefore the responsibilities as well as the restrictions should be associated with zero or one (0..1) party and exactly one BAUnit.