dibowei2069的专栏

要素操作实体（feature operation entity）：这是在地理信息系统中定义的操作实体，用于执行特定操作，如计算、更新或查询要素属性。形式定义（formal definition）：这是对操作行为和影响的明确描述，通常包含操作的逻辑、规则、输入参数、输出结果等。

rolePlayer: 在特定关联中充当特定角色的要素类型。例如，在“河流-湖泊”关联中，河流可以作为“流入者”（FlowingEntity），湖泊可以作为“接受者”（ReceivingEntity）。: 适用于多个要素类型的全局属性，具有广泛的应用范围。绑定的关联角色实体（bound association role entity）: 一个中介实体，用于在关联角色和要素类型之间建立清晰的绑定关系，同时继承所有绑定实体的属性和关联。

这些要求确保了值列表的规范化和一致性，使得地理信息系统中的要素属性能够准确、清晰地表示和使用预定义的值。：使用列出值实体来指定枚举或受控词汇表。：每个列出值实例必须有一个唯一的标签。：如果有定义属性，则该属性必须命名为“definition”。：如果有附加标识符属性，则该属性必须命名为“code”。

要素属性（feature attribute）：这是用于描述地理要素特性的属性，例如河流的长度、湖泊的面积。全局属性角色（globalProperty role）：适用于多个要素类型的属性，具有广泛的应用范围。值类型（valueType）：属性的值类型，例如字符串、整数、浮点数等。绑定的要素属性实体（bound feature attribute entity）：用于确保要素属性和要素类型之间绑定关系明确的中介实体，它继承了绑定实体的所有属性和关联。

要素属性（feature attributes）：这是用于描述地理要素特性的属性，例如河流的长度、湖泊的面积等。要素操作（feature operations）：这是在地理信息系统中定义的操作，用于影响或获取要素的属性值或行为。例如，更新河流水质的操作就是一个要素操作。关联角色（association roles）：描述要素操作观测到的要素属性值。：描述要素操作由要素属性值触发。：描述要素操作影响到的要素属性值。

我们有一个全局属性“维护状态”（MaintenanceStatus），用于描述地理实体的维护情况。其可能的值域包括“良好”、“需要维修”、“严重损坏”。为了确保数据模型的清晰性、一致性和可维护性，全局属性（globalProperty）在绑定时必须明确其唯一性。它只能绑定到featureType或rolePlayer中的一个，不能同时绑定到两者。这有助于避免属性定义和使用中的混淆，确保地理信息系统的可靠性和可理解性。

要素操作（feature operation）：这是在地理信息系统中定义的操作，用于影响要素的属性值或行为。例如，更新河流水质的操作就是一个要素操作。要素类型（feature type）：这是指具体的地理实体类型，如河流、湖泊、道路等。“featureType”角色：这是用于指定要素操作与要素类型之间关系的角色。

理解ISO 19110中“global-xor-local”要求，关键在于明确全局属性（global property）与局部属性（local property）的互斥关系。

绑定实体（binding entity）：这是在地理信息系统中用于连接属性和要素类型或不同要素类型之间的实体。约束实体（Constraints entity）：这是用于表示和维护绑定实体约束条件的实体。描述属性（description property）：这是约束实体中的一个属性，用于描述约束条件，其值为字符串。constrainedBy角色（constrainedBy role）：这是用于链接绑定实体和约束实体的角色，确保绑定关系满足特定条件。

要素操作实体（feature operation entity）：这是在地理信息系统中定义的操作实体，用于执行特定操作，例如计算、更新或查询要素属性。签名（signature）：这是一个唯一标识操作的方法名称和参数列表的属性。它定义了如何调用操作，包括操作的名称和需要提供的参数。

要素操作（feature operation）：这是在地理信息系统中定义的操作，用于影响要素的属性值或行为。例如，更新河流水质的操作就是一个要素操作。要素类型（feature type）：这是指具体的地理实体类型，如河流、湖泊、道路等。“featureType”角色：这是用于指定要素操作与要素类型之间关系的角色。

在实际的 XML 实例文档中，我们使用具体类来实现抽象类所定义的通用结构和属性。这些具体类提供了完整的实现，符合 ISO 19115-1 和 ISO/TS 19139-1:2019 的标准和要求。因此，在示例中，我们看到的是具体类而不是抽象类。抽象类主要在模式定义和设计阶段发挥作用，而具体类则用于实例化实际的元数据文档。

最小元数据 XML 实例文档应包含 cit 和 mri 命名空间中的元素，根据需要包含 srv 或 gex 命名空间中的元素。通过使用这些命名空间，确保了元数据文档的结构和内容符合 ISO 19115-1 标准的要求。

a)测试目的：验证每个用户定义的元数据包、元数据类和元数据元素都是唯一的，且未在本文件或任何其他文件中定义。b)测试方法：测试每个用户定义的元数据实体和元数据元素，以确保其唯一且未曾使用。c)参考：第 6 章和附录 B 及 ISO 19115-1:2014 第 6 章和附录 B。d)测试类型：基本。a)测试目的：验证用户定义的元数据实体和元数据元素是否按 ISO 19115-1 的规定定义。b)测试方法：测试每个用户定义的元数据实体和元数据元素，以确保已定义所有属性。c)参考。

该 XML 模式扩展并旨在与 ISO/TS 19115-3 中提供的 XML 模式一起使用（本文件还利用了 ISO 19157 的 XML 实现中的命名空间 dqc（

元数据类/元素的描述。这是一个描述符，指示元数据实体或元数据元素是否应始终记录在元数据中或有时记录在元数据中，即包含值。该描述符可以有以下值：M（必需）或 O（可选）。

该包扩展了 ISO 19115-1 中的 MD_Metadata，并提供了使用影像、传感器和其他获取方法获取地理空间数据的具体细节。MI_Instrument：用于获取数据的测量仪器的指定；MI_Sensor：MI_Instrument 的一种特定类型；MI_Operation：数据所贡献的整体数据收集计划的指定；MI_Platform：获取数据的平台；MI_InstrumentEventList：影响 MI_Platform 和 MI_Instrument 的事件的列表；