NavSea 交付版 Layer 命名评估表

目的

这份表专门回答一个问题：

当前交付版 pbf 中实际使用的 layer 名，是否表达清晰？

评估口径：

当前交付 layer
- 指当前交付版 pbf / style 实际在消费的 layer 名
建议标准名
- 指后续去掉对日文技术依赖时，建议暴露给交付体系的标准 layer 名
中文语义
- 便于人工确认命名是否准确
是否足够清晰
- 站在“交付给下游或团队协作”角度评估
是否建议重命名
- 指是否建议最终交付版不再直接暴露当前 layer 名

总结判断

当前交付版 layer 名整体上 不够清晰，原因主要有三类：

仍保留大量日文 layer 名
仍保留 P/L/p 与 ククリ 这种旧体系术语
仍保留 L739、P754ククリ 这类编码型 layer 名

从表达清晰度看，可以分成两组：

已经比较清晰，只是还没真正切换到交付层：
- anchorage_area
- navigation_marks
- depth_contour
- place_label_sea
- land_area
仍然不够清晰，建议继续细化：
- depth_zone_739
- depth_zone_741
- clip_outline_754
- baseline_area
- facility_boundary_area

正式评估表

当前交付 layer	建议标准名	中文语义	是否足够清晰	是否建议重命名
`P基本線`	`baseline_area`	基本线相关面/容器层	否	是
`P投錨注意障害物`	`anchor_caution_hazard_area`	抛锚注意障害物面	否	是
`P航行危険障害物`	`navigation_hazard_area`	航行危险障害物面	否	是
`P漁具定置箇所`	`fixed_fishing_gear_area`	定置渔具区域	否	是
`P錨泊地等`	`anchorage_area`	锚地/锚泊地区域	否	是
`P施設・境界線等`	`facility_boundary_area`	设施/边界相关区域	否	是
`P潜堤`	`submerged_reef_area`	潜堤/潜礁区域	否	是
`P橋りょう等構造物`	`bridge_structure`	桥梁等结构物面	否	是
`P陸上構造物陸`	`onshore_structure_area`	陆上结构物面	否	是
`P陸域`	`land_area`	陆地区域	否	是
`P穴`	`hole_area`	穴/凹地面	否	是
`L海底地形`	`bathymetry_line`	海底地形支撑线	否	是
`L等深線`	`depth_contour`	等深线	否	是
`L概略等深線`	`depth_contour_overview`	概略等深线	否	是
`L海底線`	`seabed_line`	海底线	否	是
`L基本線`	`baseline_line`	基本线线层	否	是
`L陸上構造物陸`	`onshore_structure_line`	陆上结构物线层	否	是
`L739`	`depth_zone_739`	深度分带编码层 739	否	是
`L741`	`depth_zone_741`	深度分带编码层 741	否	是
`L高さ制限`	`clearance_limit_line`	高度/净空限制线	否	是
`P基本線ククリ`	`baseline_outline`	基本线边界	否	是
`P危険界ククリ`	`hazard_boundary_outline`	危险界边界	否	是
`P航行危険障害物ククリ`	`navigation_hazard_outline`	航行危险障害物边界	否	是
`P投錨注意障害物ククリ`	`anchor_caution_hazard_outline`	抛锚注意障害物边界	否	是
`P錨泊地等ククリ`	`anchorage_outline`	锚地边界	否	是
`P施設・境界線等ククリ`	`facility_boundary_outline`	设施/边界边线	否	是
`P754ククリ`	`clip_outline_754`	编码型边界层 754	否	是
`p航行危険障害物`	`navigation_hazard_point`	航行危险障害物点	否	是
`p錨泊地等`	`anchorage_point`	锚地符号点	否	是
`p投錨注意障害物`	`anchor_caution_hazard_point`	抛锚注意障害物点	否	是
`p航路標識群`	`navigation_marks`	航标/灯标/浮标点	否	是
`p施設・境界線等`	`facility_boundary_point`	设施/边界符号点	否	是
`p陸上構造物`	`onshore_structure_point`	陆上结构物点	否	是
`p底質`	`seabed_text_point`	底质标注点	否	是
`p高さ制限`	`clearance_limit_point`	高度限制点标注	否	是
`p地名`	`place_label_sea`	海上地名标注	否	是
`p地名陸`	`place_label_land`	陆上地名标注	否	是

重点建议

1. 可以直接进入最终交付标准层名的对象

这些建议标准名已经比较清楚，可以直接作为最终交付版 layer 名候选：

anchorage_area
anchorage_outline
anchorage_point
navigation_marks
navigation_hazard_point
navigation_hazard_outline
depth_contour
depth_contour_overview
place_label_sea
place_label_land
land_area
bridge_structure
onshore_structure_area
onshore_structure_line
onshore_structure_point
clearance_limit_line
clearance_limit_point

2. 还不够理想，需要二次命名设计的对象

这些虽然已经有了英文标准名，但表达仍然偏“技术命名”或“容器命名”，建议二次优化：

baseline_area
- 问题：像容器层，不像业务对象
facility_boundary_area
- 问题：语义过宽，设施和边界混在一起
bathymetry_line
- 问题：更像支撑线，不够区分其具体作用
seabed_text_point
- 问题：表达的是文字载体，不是业务对象
submerged_reef_area
- 问题：要确认是否会和鱼礁/暗礁语义混淆

3. 明显不适合作为最终交付层名的对象

这些标准名本质上仍然只是“稳定占位名”，不适合长期直接暴露给下游：

depth_zone_739
depth_zone_741
clip_outline_754

它们的问题是：

仍然带旧编码
只能表达“来源编号”，不能表达“业务含义”

建议最终方向：

先查清这些编码型层到底承载什么对象语义
再改成真正的业务名

建议的推进顺序

如果下一步要真正去掉交付版对日文 layer 名的依赖，建议按这个顺序做：

先把“已经足够清晰”的标准名直接切到交付版
对 baseline_*、facility_boundary_*、bathymetry_* 这类做二次命名收敛
最后处理 depth_zone_*、clip_outline_* 这类编码型层

当前结论

当前交付版 layer 名：

对历史系统兼容是有效的
对团队理解和长期交付不够清晰

当前已经存在的标准层名体系：

足以作为去日文化的第一版基础
但还需要再做一轮“语义清晰化”

6.4 KiB Raw Permalink Blame History