想做这个东西的初衷
游历毛线半个多月，在鞘翅飞行了150万米，探明了过半的v4地图之后，有了一个感想：大家在毛线的许多创造物都承载着大量的劳动和思考，但由于各种因素所限，能够让新玩家和在较远处活跃的玩家去发现、欣赏、理解这些创造物的机会却寥寥
无论是浏览普通的地图，还是在游戏中亲自探访，所能得知的往往只是聚落和建筑的位置、范围，大致形态；而对于聚落的规划；建筑的名称、设计思路；建筑与聚落所依附的天然地理概念，乃至于以上这些背后可能会有的背景、设定、历史沿革等等，参观者能得到的理解都非常有限
如果有一种地图系统，能够以多样的方式承载丰富的地理信息，提供易用的展示和查询方式，并且以详尽的引导配合有意愿的玩家上传、填写与归类地理信息，也许能让许多本不为人所知的创造以更加完整的形态展现在更多人面前，同时也能激励乐于分享的玩家们更好地创作吧
这会是一个什么东西？
基于以上的初衷，能够设想的是一种“基于多人协作的地理信息系统”，由玩家各自贡献自己所熟悉的区域以及相关的地理信息，系统会半自动地引导玩家完成信息的归类、相关属性的填写等等，然后以合适的可视化方式展示出来，最终形成一个类似于“世界地图”与“地点维基”的结合
标记
使用逻辑是，玩家上传本地的小地图缓存（VoxelMap）作为网页大地图的一部分。之后可以在页面上进行各种标记，形式可以多种多样，比如点状，线条，圆形、多边形区域，精确的格子等等，也可以基于地表方块类别、生态群系等等辅助标记
概念
有了标记之后，玩家可以声明这些标记的类型，或者说把“概念”关联到这些标记上面，类似“人造物”，“山脉”，“装饰性建筑”，“聚落”，“自然地形”，“公用设施” 这样的词条
这些概念并非互相独立，而是可以定义互相之间的联系，以此来达到整理和引导填写的效果。比如：如果已经存在概念 [人造物，天然物，建筑，雕塑]，并且定义了这样的关系 [“人造物和天然物互斥”，“建筑是人造物”，“雕塑是建筑”]，那么如果用户希望定义新的概念 [别墅]，则可以首先定义“别墅是建筑”，而之后系统会自动计算生成其它的关系“别墅是人造物”，“别墅不是天然物” 等等。这个过程是自动展现在玩家面前的，可以让玩家的信息录入过程更加顺畅自然
属性
之所以要定义概念，是为了以此为依据推断出相应标记可能需要的属性和取值。比如具有“人造物” 概念的标记会自动得到 “设计者”，“建造者”，“建造时间” 的潜在属性，并且引导玩家做进一步的填写与完善；具有 “聚落” 的标记会建议填写 “组织者”，“成员”，具有 “公用设施” 的标记则也有了 “维护者”，“使用权限” 等等
有的概念可能会有以其它地理信息为取值的属性，比如 “建筑群” 可以有 “成员建筑”，其取值是一系列的 “建筑物”，而 “聚落” 的 “区域” 取值则可能是一系列的 “建筑群” 诸如此类。这将给信息的表达与展示能力带来更高的自由度
地图本体
作为所有这些信息的载体和背景，在地图方面，可以支持 VoxelMap 的缓存文件读取，（有可能的话还想尝试支持更多小地图mod），浏览器内的缓存解码，同时提供多种渲染方式，比如mc原版地图的方式，类似VoxelMap的方式，基于材质的可精细放大的方式等等。对于地图上的信息，比如可见方块，高度，生态群系等，也可以有各自的可视化方法
远期的目标包括，诸如修改历史，多人协同编辑，账户相关功能如收藏夹、地理标记权限，等信息管理方面的；多世界，时间轴历史地图，类3d效果的高度光照，读取并展示3d投影文件的信息，等信息展示方面的；诸多可能性可以自由想象
可能遇到的问题
访问门槛：地图的信息量在后期可能变得比较巨大，需要考虑与服务端沟通的传输速率问题，客户端的加载性能问题。初步考虑只传输玩家关注区域的小部分内容，优化内存占用并且利用本地缓存等（目前完整加载每个256x256的区域背景需要1MB左右客户端内存）
录入门槛：需要尽可能简化信息录入的过程，用自动化屏蔽繁琐的细节，比如根据上传需求计算 VoxelMap 的缓存文件夹路径，在录入信息时把最可能的操作以醒目的方式推荐、展示出来。同时需要保证录入完成后信息展示的美观程度与可定制程度，以此鼓励创作者主动参与
开发路线图
已完成：
- 7月21日 - 7月24日：完成了 VoxelMap的缓存读取，客户端渲染成类mc地图，缩放与拖动，显示坐标与可见方块、生态群系
- 7月25日 - 7月27日：考虑以 DSL 的形式描述概念之间的关联，完成了 meta-chevrotain 作为辅助工具
- 7月28日 - 7月31日：初步完成了 correlation 作为概念关联的描述工具
- 8月1日 - 8月10日：初步完成了标签绘制的部分，造了一些关于图形、网格、过渡动画的轮子（浪费了时间
- 8月11日 - 8月15日：学了一点 rust，并把地图数据处理与渲染的部分迁移到了 webassembly，获得了大于五倍的性能提升
- 8月15日：公开了项目repo
- 8月16日-8月20日：忙于一些其他事情
待完成：
八月初：继续地图开发，确定页面结构与交互的逻辑 八月中旬：优化各部分的协同，发布静态地图作为初期预览版本8月22日前：继续完成创建标记的流程，包括先前开发的概念描述语言的完善与引入8月31日前：完成标记信息的展示，包括地图浮层与子页面；完成上传流程，发布无后台预览版本准备造一个不大不小的轮子（再次推翻时间线
……大约九月下旬：上线服务端，开放公测
......- 9月9日留，出于多种原因，本项目将暂时搁置1至2个月的时间
- 最近注意到了 knowledge graph 领域相关的内容，了解了rdf，owl等语义互联网技术栈后，感觉非常符合我的设想，于是推翻了之前写的 correlation 小工具。由于学习新技术需要时间，并且目前几乎没有看到理想的 "web-based, ontology-assisted" 的信息录入与管理解决方案，大概不得不继续造一些轮子了，所需时间难以预估
- 另外还有一个想造的轮子是，由于所设想的信息录入流程的复杂程度，希望把各种录入步骤与场景做成多窗口、多任务形态，来提升用户体验，不过搜寻得到的诸如 winbox.js，golden-layout 的解决方案，其功能与灵活性都无法满足需求。所以希望造一个高度定制化的，综合用户设备、应用场景等条件来计算窗口位置的数学库。这大概也需要几周的时间。
- 最后是因为开学和秋招的原因，各种事情都多起来了，能自由挥霍的时间越来越少 ...
- 虽然无法维持这个项目的优先级并按照初期计划上线，不过在未来一段时间内我依然会以满足这个项目的需求为方向来进行个人开发。希望最后能够得到接近甚至超越最初设想的成品。这个项目的上线时间暂定为今年12月
后面的话
非常抱歉写着写着发现风格快跑偏到课题报告了（
这里要感谢毛线能给启发我全力地投入到一件事中去，如果没有 DWCarrot 的离线渲染工具 （他的这个帖子帮了我不少忙），和论坛里历史上各种 挂掉的 地图 还有 地图 以及 地图，以上等等的先驱者，我不太可能有动力去以毛线服务器为基础仔细思考并付诸实施这个我七年mc游戏经历里一直想要实现的想法
还有一个小请求，想知道各位对于以上描述的这样一个地图项目，意向如何呢，请完成这个投票吧