多层副本的组织和整理？ [关闭]

回到大学时，我遇到了一个“组织和整理”问题–我没有组织，将图层放在不同的文件夹中而没有不同的名称，因此每一层都有多个副本。

自从我开始工作以来，我已经有了很大的进步–我保留了带有特殊子文件夹的特殊文件夹。我根据系统命名层，这使我更加整洁，但是由于我仍然需要管理层的多个副本（由于Autocad和ArcGIS在处理非拉丁语言时有所不同，因此我必须保留一个副本根据每个程序进行调整），我想听听您的经验，也许还可以向您学习一些技巧：

您如何组织图层？如何命名？按名称，日期，内容，客户？
您如何组织或处理多份副本（更严重的是：如何一次更新多份副本）？

注意：我是从分析师/ DBA POV而不是来自一个Web开发人员/ Web管理员的POV（我在谈论的是为自己组织层，也许还要组织两个GIS工作者，而不是更多）。

一个好问题。实际上，这不是一个问题，而是一个追求。一个问题导致一个或一组狭窄的答案，一旦解决，就结束了。追求是一个持续不断的事情，一个冒险可能永远不会有定局，那就是您在这里所拥有的。屈服于一个事实，即无论您遵循什么约定，它都不会完全或无法正常工作。就是说，您可以使用一些约定使路径更平滑，更容易行进。在这方面，凯文（Kevin）的回答以及后续评论是一个很好的起点。

#1 楼

这是一个严重的问题。我们尝试了各种系统，这些系统在一段时间内都在不同程度上起作用，最终变得毫无用处，随着越来越多的边缘情况出现而逐渐瓦解。就是说，我们使用的每个系统总比没有好，这证明了任何系统总比没有好。

以下是我们当前实践的简要概述：

将除栅格外的所有内容放入文件地理数据库中，越少越好。除非要素类以某种方式关联（例如，水>河流，水>湖泊，水>湿地等），否则不要在要素数据集下嵌套要素类。这导致在fgdb顶部有一个很大的长列表，但这是可以接受的。

为所有要素类创建图层文件并进行组织，取而代之的是，这提供了很大的自由，可以根据需要使用不受支持的字符等*来命名，并且可以根据情况的变化进行移动和重命名。它还允许重复而没有冗余，例如，一组按名义规模分组的图层（50k，250k ...），另一层按区域分组（AK，YT ...），第三层按主题分组（驯鹿，土地使用，运输） ...），第四个由客户端执行，而数据存储本身保持不变。

对于重复项，请使用快捷方式而不是图层文件本身，否则更改时会更新的内容太多。配置ArcCatalog以显示快捷方式：*工具>选项>文件类型：.lnk（局限性：预览和元数据不起作用，您无法在ArcCatalog中遵循其源代码的快捷方式。可以使用符号链接代替快捷方式来纠正此问题，请参阅Link Shell Extension）

*（提示：将“ Layers”文件夹添加为“开始”菜单工具栏，使它们始终在您的指尖。）

Z:\Layers\
          Base\
          Thematic\
          Reference\
          All Dressed Base (250k).lyr
          Administration Boundaries (1000k).lyr
          ...
Z:\Raster\
          Landsat\
          Orthos\
Z:\Data\
        Foo_50k.gdb
        Foo_250k.gdb
        NoScale.gdb

本质上更具动态性和可变性的地图组成和输出（打印文件，pdf，导出等）在其他地方以不同的方式存储和组织。这对我们来说更难了。当前，我们使用专用驱动器，该驱动器具有根据Job＃命名的文件夹（再次执行此操作，我改用date，即“ 2010-10-26”），以及用于项目特定数据和结果/可协商对象的子文件夹。电子表格索引列出了所有作业编号（文件夹名称），其对应的地图标题和客户。例如：

W:\Foo_0123\
            Foobarmap_001.mxd
            Docs\
                 ReadMe.doc
            Data\
                 buffers_2000m.shp
                 gps_tracks.csv
            Output\
                   Foobarmap_001.pdf
            Deliverables

保持索引最新是一个摩擦点，人们不喜欢这样做，避免使用它并且与命名不符等。（使用数据库而不是电子表格会有所帮助）。使用数字文件夹名称约定也使没有索引的项目X的映射非常困难，索引是另一个显着的摩擦源。理想情况下，索引将是可点击的html页面，该页面是从db应用程序自动生成的。

关键原则：

将缓慢变化且经常重复使用的东西与动态变量分开，并区别对待
请勿不必要地复制，请尽可能使用图层文件和快捷方式/链接。
请勿过于频繁地更改系统，请尝试尝试。

我非常欢迎示例就像我说过的，我们不满足于现有的结构。 :)

昨天，我因某人发布了太大或太长的内容而轻描淡写地谴责了他，在这里，我去做同样的事情，只是没有照片。您如何看待，是呈现一个有凝聚力的整体，还是将事物分解成模块，而每个模块都可以根据自己的优点进行投票/否决，但可能会破坏或隐藏它们与其他模块的集成，这是更好的选择吗？在meta上谈论它：长而内聚或短而模块化

–马特·威尔基
2010-10-27 19:02

哇。多么完整的归档系统（我已经读过四遍了，还不确定我是否了解全部）。作为AutoCAD和ArcGIS的绑定用户，对于我来说，有两点值得关注：1.如何将DWG的存储空间放入该系统？ 2. GeoDatabase是保持组织良好的好方法。我唯一的问题是AutoCAD地图看不到GDB，而只能看到shapefile。但是，谢谢，我将从您全面的系统中获取提示...

– jonatr
2010-10-28 20:55

请记住，该系统在15年左右的时间里逐渐发展成为这样的系统，并且是针对我们的工作方式量身定制的。但是应该有一些可移植的元素。至于与CAD的互操作性，请坚持ESRI的要求，以兑现其向文件地理数据库发布开放API的承诺。

–马特·威尔基
10-10-30在7:03

与要素数据集相同。除ArcCatalog中的功能外，这是一种无用的功能。他们应该将常用层和空间参考层进行分组，但是程序员从不会看到要素数据集，除非它妨碍了在工作空间中的各层之间循环。使用不同的投影时，单独的数据库似乎比要素数据集更好。

–蒂姆·洛克（Tim Rourke）
2010年11月2日，14：20

@Tim我相信要素数据集是ArcInfo覆盖范围的概念后裔，也就是说，它们将成为将描述共同“事物”的不同几何类型分组到一个篮子中的一种手段。因此，您可以将例如水道（线），水体（多边形）和水中岩石（点）结合在一起。我不知道为什么不直接将它们呈现给程序员。

–马特·威尔基
2010年11月2日，15：47

#2 楼

如果其他人将访问您系统中的数据，则不能使组织架构仅对自己有意义。您必须牢记他们对系统的使用。如果您不考虑这些问题，则会花大量时间回答诸如“土地利用数据在哪里”和“为什么无法在此处找到[插入数据集]？”之类的问题。

在维护这样一个系统多年后，我发现人们首先找到按源组织的数据就找不到了，例如c:\CensusBureau\Roads和c:\ESRI\Countries。相反，我建议先按主题列出数据，如果您有多个来源（例如， c:\Roads\CensusBureau和c:\Roads\LocalGovt。

同样，我不会将栅格和矢量分离到不同的目录中。但是，如果您有很多栅格数据无法容纳在一个驱动器上，则可能有必要将它们拆分到不同的物理或逻辑驱动器上。

我建议使用以下目录结构。 Theme \ SourceYear，其中Theme是主题层，Source是数据源的缩写名称，Year是数据在地面上表示的年份。在这种情况下，来自人口普查局的TIGER Roads将位于\Roads\Census00和\Roads\Census10（或将“ Census”替换为“ TIGER”）。

请注意，ArcGIS中的某些扩展名不适用于文件名称超过13个字符。我不记得是哪个扩展名，我只记得这是一个问题。

谢谢Kevin，文件名约定如何？我正在考虑类似

编程黑洞网

多层副本的组织和整理？ [关闭]

评论

#1 楼

评论

#2 楼

评论

#3 楼