是否需要拓展本主题的介绍？ 可以穿插一些用例和示例，例如，…
在此，我们将分享一些与技术和数据相关的常见挑战和成功因素。 我们为希望最大化其价值和影响力的组织和决策者提供了一套可操作的建议。 这并非一份详尽的清单，但它可以帮助您参与对话，识别风险并应用良好实践来减轻这些风险。
| SDI 元素 | 挑战 | 成功因素 | 建议 |
|---|---|---|---|
| 精选内容 | 当 SDI 提供每个人未经整理、海量共享的内容时，终端用户可能会迷失在数据的海洋中。 | 最终用户可以在您的目录中轻松找到并复用他们需要的内容：文档、数据层、地图、应用程序、工具等。 | 坚持以用户为中心的设计，始终将您的目标和终端用户群体放在首位。
|
| 信心和可靠性 | 当链接失效时（例如 Web 服务 URL 和项目 ID 发生变化，导致下游地图和应用程序中断），终端用户会迅速对共享内容失去信心。 | 用户复用共享的权威数据。 他们对数据图层和 Web 服务的可靠性和持久性充满信任和信心。 | 注重可靠性。 传达内容管理和数据生命周期计划。
|
| 协调数据模型 | 反映概念模型全部复杂性的数据方案可能会导致数据难以在标准 GIS 软件和应用程序中使用和消耗。[^1] 不适合在应用程序中使用的数据会威胁到 SDI 的唯一用途。 | 统一的数据模型应针对特定目的、应用场景和目标受众，具备实用性和可操作性。 | 确保核心数据资产的通用数据模式能够满足从地方到国家的不同需求，并能与其他领域的数据进行有效集成。
|
| 从地方机构聚合数据 | 地方层面复杂的数据转换要求若过于繁琐，将对成功实施构成风险。 | 数据管理模式应易于理解，并能为本地数据提供方提供可持续的操作方案。[^2]{::nomarkdown} | 考虑当地合作伙伴长期维持 SDI 的负担。<ul><li>在合作伙伴和协调机构之间合理分配数据转换和统一处理的任务。</li><li>适当评估整个数据管理周期和资源的成本。</li><li>在合作伙伴的投入成本与参与所带来的实际收益和激励之间寻求平衡。</li></ul>{:/} |
| Web 数据服务和下载格式 | 强制规定自定义编码格式可能会阻碍数据的使用，并随着技术发展，妨碍新数据标准和互操作性标准的敏捷采纳。 缺乏 API 接口会限制开发者社区的使用。 | SDI 应满足用户期望，使其能够随时随地通过动态数据图层、Web 服务和可下载数据来访问和使用数据及各项功能。 开发人员能够利用 API 和 SDK 中的数据管理、分析和可视化功能，为特定需求构建定制化的应用。 | 采纳“无障碍访问”的分发策略。
|
| 元数据 | 自定义元数据规范可能会增加实施成本和培训需求，并因准入门槛较高而实际降低互操作性。 我们观察到一些为 SDI 创建的自定义元数据规范，但缺乏实施所需的专业知识。 | 用户友好的“数据集概要”和紧密集成的元数据能够提供良好的人机交互体验，并为计算机可读的、基于标准的元数据提供数据基础。[^3] | 要求数据提供合作伙伴确保提供最低限度的强制性元数据。 优先采纳 ISO 标准作为元数据策略的基础；仅在绝对必要时才进行规范的扩展和/或自定义。 在通过自定义规范进行扩展之前，务必审慎评估每个元数据元素所能满足的实际需求。 将元数据与数据本身一同管理。 |
| 开放数据和 FAIR 数据原则 | 难以与其他系统进行联邦的数据目录会阻碍开放数据倡议和 FAIR 原则的实施。 | SDI 应确保开放数据能够被所有用户重复使用，并遵循 FAIR 原则（即可查找性、可访问性、互操作性、可重用性）。 | 积极拥抱开放理念。 利用 DCAT 标准将 SDI 地理空间数据和服务联邦到开放数据目录。 通过优先采用标准来保持数据目录的互操作性。 直接采用广泛使用的 DCAT 标准，仅在必要时进行规范的扩展和/或自定义。 |
| 交付新功能 | 组织若花费数年时间投入到昂贵且复杂的开发工程中，最终往往会得到难以使用或与当前需求脱节的解决方案。 | SDI 应持续改进地图、应用程序、服务和信息产品，以便它们能够提供附加价值并满足不断变化的需求。 | 采纳以业务为先导的方法，并与利益相关者紧密合作，通过短平快的迭代周期和规律性的节奏，共同定义、优先排序和测试新功能。[^4] |
| 数据量和速度的增加 | 随着传感器、人工智能和物联网 (IoT) 的普及，数据量和传输速度正以前所未有的速度增长。 | 重复性的人工任务耗时少、耗力小、所需专注度低，能够显著提高整体生产力并降低潜在风险。 随着此类任务数量的增加，其积极影响也将成倍放大。 | 对于人为错误可能影响结果可靠性和一致性的任务，以及冗长流程可以在更短时间内完成的环节，应实施自动化。[^5] 设置定时任务，使其在无人为干预的情况下自动运行。 |
| 标准和互操作性 | 对数据内容、元数据、服务和编码标准进行不必要的自定义规范和扩展往往会导致额外的成本和工作量。 当自定义规范难以理解和使用时，人们（即使是 SDI 专家）也常常难以整合来自不同提供商的数据。 实际上，自定义规范会因其较高的准入门槛而增加实施成本和培训需求，并显著降低互操作性。 标准的扩展并非在所有软件平台上都得到通用支持。 | SDI 应优先考虑首先以标准化的方式明确社区内现有标准元素的预期用途，或者通过不增加新元素，而是细化和标准化现有标准元素内的可选值域来实现。 | 采纳“标准优先”的原则，利用即用型开放标准和行业标准来满足业务需求，避免使用自定义规范。 仅在确有必要时才进行扩展和自定义。 |
| 可伸缩性和性能 | 应用程序和服务若性能不佳或无法应对突发的需求增长，可能会对 SDI 的有效性产生负面影响。 | SDI 应满足为不同层级的政府核心 GIS 用户、广泛的内部业务用户（非传统 GIS 用户）以及公用事业、高校和公众等外部用户提供服务的独特需求。 | 采用基于云计算和混合（本地部署与云端结合）的架构已被证明是 SDI 的成功方法。 基于 Web 的地理空间基础设施能够提供经济高效的可用性、性能和可伸缩性。 对于由服务提供商管理的服务，请遵循“构建 ArcGIS 平台”中的最佳实践。 |
| 信任 | 缺乏透明度、开放性，数据不准确或已过期，以及安全隐患都会削弱用户对 SDI 的信任。 | 最终用户会信任并重复使用您共享的内容，并成为忠实的客户。 | 秉持“默认开放，仅在必要时关闭”（出于隐私或安全考虑）的原则。 构建安全可靠的平台。 针对常见的核心数据实施数据质量和时效性控制措施。 |
| 可访问性、响应式设计和搜索引擎优化 (SEO) | 不符合可访问性准则或在移动设备上响应不佳的应用程序将严重限制其使用范围。 | SDI 提供的地图和应用程序应对所有用户均可访问，具备良好的移动设备响应能力，并能在各种搜索平台上轻松被发现。 | 选择符合可访问性准则且易于创建符合这些准则的地图和应用程序的工具。 选择采用自动化 SEO 技术，从而提高数据和应用程序的可发现性的工具。 |
| 应用程序开发 | 自定义应用程序的开发、维护和培训往往伴随着不必要的成本和精力。 | SDI 应通过技术手段交付满足业务需求的功能。 理想的策略是最大限度地降低成本，并优化开发资源的使用效率。 | 采纳“配置优先”的应用程序实施策略。[^6]采用最简化设计模式，降低为用户部署和维护可访问且响应迅速的应用程序所需的成本和精力。 仅在必要时进行扩展和自定义。 |
持续了解不断发展的 SDI 实践中所面临的挑战、成功因素和相关建议。
[^1]：Esri，2024 年。 采纳权威数据提供商的最佳实践故事指南
[^1]：INSPIRE Action 2017.2 替代编码。 背景与上下文访问于 2020 年 8 月
[^2]：Esri。 2024 年。 不断发展的 SDI - 基础数据：数据管理模式
[^3]：UN GGIM IGIF 数据 – 附录…
[^4]：Esri。 2020 年。 构建 ArcGIS 平台：最佳实践 访问于 2020 年 8 月 17 日
[^5]：Esri。 2020 年。 构建 ArcGIS 平台：最佳实践 访问于 2020 年 8 月 17 日
[^6]：Esri。 2020 年。 构建 ArcGIS 平台：最佳实践 访问于 2020 年 8 月 17 日