acrmap使用常识

右击Layers  出现Reference Scale 它的作用是和symbol 一起才会发生作用的。

set Reference scale 表示 以当前的比例尺作为参照，symbol 大小为1，如果地图放大了 ，那么symbol 大小也相应的放大，地图缩小了 ，symbo 大小l也相应的缩小。

clear Reference scale  取消这种设定，那么地图放大缩小了 symbol 的大小 一直都不变。

zoom to Reference scale  回到symbol为1的对应的比例尺

注 symbol 为1 不是代表symbol 大小为1 而是 以 symbol 的大小 看成1 ，其它symbol大小和原来的symbol 作比较。

Join and relate

Join 目的 是把另一个表的字段 放到目标中，相当于这个表多了几列 ，查询的时候 多出的列在一行显示。

relate

表示当查询到这个对象时 相关联的对象也查到了

如图 看到Mono 对象 对应的StateBnD 对象作为下一级出现了。这么看来 Relate 更加强大 ，当我们点击StateBND时 就能看到这个对象的空间位置了。

建议如果是空间对象使用relate 如果仅仅是不包含空间的信息的属性表 ，那么用join。

 

使用relate 那是因为 2个图层有公共字段 ，如果没有公共字段 没办发 还得使用 空间join

 

这样属性表字段不关联 但是空间位置关联 也可以了，可以把多个图层和表联系起来 设置label 或者symbol 或者做一些图表等分析显示了。

附上一段英文 。更加细节的东西 请看下文

About joining data

This dialog allows data from a layer or table (join table) to be appended to the selected table or layer (target table).

The combo box at the top of the dialog allows you to define the join based either on attributes, a predefined geodatabase relationship class or by location (also referred to as a spatial join). You will only see join by relationship class listed if you are joining geodatabase data for which a relationship class has already been defined in the geodatabase.

You can join data from different data sources. For example, you can join a dBASE table to a coverage or a table from an OLEDB connection to a shapefile.

Joining can also be performed using the following geoprocessing tools in ArcToolbox instead of using this dialog: 

   Analysis Tools > Overlay > Spatial Join tool

   Data Management Tools > Joins > Add Join tool

   Data Management Tools > Joins > Remove Join tool

Use these geoprocessing tools when working with particularly large datasets to get the best performance. You can also include these tools in geoprocessing models and scripts when you want to automate repetitive or complex steps involving joins. As these tools perform the actual behind-the-scenes join processing slightly differently than this dialog, we also recommend using them if you encounter any unexpected issues with the join functionality in this dialog.

Attribute joins and relationship class joins

When you perform an attribute join or a relationship class join, the data is dynamically joined together. This means that nothing is written to disk and edits on the underlying join tables appear in the appended columns.

When you start an edit session, columns from the target table can be edited, but you can't directly edit the data in the appended columns. If you add a field, it is added to the target table or layer and has no effect on the join tables. Appended columns can be referenced when calculating values in the columns of the target table, however.

Several tables or layers can be joined to a single table or layer and relationship class joins can be mixed with attribute joins. When a join table is removed, all data from tables that were joined after it are also removed, but data from previously joined tables remain. Symbology or labeling that is based on an appended column is returned to a default state when the join is removed.

Performance tips

Data from appended fields can be used to symbolize and label features, perform queries and many other operations. Accessing the joined data will be slower than accessing data from the target table because of the additional work needed to maintain the join. The following tips can be used when working with joined data to improve performance:

-  Create attribute indexes on the join fields. In most cases, attribute indexes on join fields will improve overall performance.

-  The "Keep only matching records" is normally faster for operations that require accessing the data in the joined columns (i.e., symbolizing, labeling) when you are working with an ArcSDE geodatabase. The default "Keep All Records" option always performs processing on the client. Performance is normally good for operations that don't require accessing joined data (i.e., drawing with default symbolization). An operation may become much slower if accessing joined data is needed.

-  Cross database joins, where the target table and the join table are from different data sources, may have poorer performance. This is especially the case where the join table is from an ArcSDE server, personal geodatabase or an OLEDB connection. Performance is much better when the join table is from a file based data source (i.e., file geodatabases, shapefiles, dBASE files, Coverages) and the target table has an ObjectID column (most data sources).

-  Joining multiple tables or layers to a single layer can be costly in terms of performance. If all of the data is from the same ArcSDE server and you chose "Keep only matching records" when joining, performance should not be greatly effected.

-  As noted earlier, to get the maximum performance when doing joins, we recommend using the join geoprocessing tools in ArcToolbox instead of using this dialog.

Using joins, relates and relationship classes together

If your data is involved in both joins and relates, the order in which the joins and relates are created is significant. If your layer or table has a relate, it is removed once data is joined to it. If you perform a relate on a joined layer or table, the relate is removed when the join is removed. As a general rule of thumb, it is best to create your joins and then add your relates.

In a situation where you need to join tableA and relate tableB to layerC, two of the three possible ways of doing this will work. The following describes each case:

-  Join tableA to layerC, then relate tableB to layerC - This scenario will work. You will end up with a joined layer that has a relate to tableB.

-  relate layerC to tableB, then join tableA to layerC - This scenario will also work. Since a relate is bi-directional, both tables involved will be able to use it regardless of which table owns the relate. In this case tableB owns the relate so when tableA is joined to layerC the relate is not removed.

-  relate tableB to layerC, then join tableA to layerC - This scenario will not work. This is different from the previous scenario in that layerC owns the relate. Therefore, when tableA is joined to layerC, the relate is removed.

Relates owned by the join table are not effected by the join. These relates can't be accessed by the target table or layer, however.

Relationship classes are never removed as a result of a join or unjon operation. They can be used regardless of whether the data has been involved in joins or relates.

Join by location (spatial join)

Join by location or spatial join uses spatial associations between the layers involved to append fields from one layer to another. Spatial joins are different from attribute and relationship class joins in that they are not dynamic and require the results to be saved to a new output layer.

One of three types of associations can be used to perform a spatial join. These associations are described as follows:

Match each feature to the closest feature or features - In this association, you can either append the attributes of the nearest feature or append an aggregate (i.e. min, max etc.) of the numeric attributes of the closest features.

Match each feature to the feature that it is part of - In this case, the attributes of the feature for which the current feature makes up a portion are appended.

Match each feature to the feature or features that it intersects - Like with the closest feature(s) association above, you can either append the attributes of a single intersecting feature or an aggregate of the numeric attributes of the intersecting features.

For each point, polygon and line combination, only the most commonly used of these associations are available in the join dialog. With VBA, however, it is possible to perform a join based on any association and with any combination of point, line or polygon feature layers.

For the best results, it is recommended that both layers have the same coordinate system. If the layers have different coordinate systems, the following rules apply:

-  The spatial join will be calculated in the target layer's (the select layer in the table of contents) coordinate system.

-  If the type of join performed involves adding a field to show the distance between joined features, the distance will be in a unit of measure associated with the target layer's coordinate system.

-  If one of the layers has an unknown coordinate system and the other a defined coordinate system, an error message will appear. If both layers have an unknown coordinate system, the join will proceed and the resulting layer will have an unknown coordinate system.

-  The coordinate system used to display data in ArcMap has no effect on how the data is joined. ArcMap allows data to be stored in one coordinate system and displayed in another. The analysis is always performed using the stored coordinate system.

For more information on transferring one layer's coordinate system into that of another layer, review the topics on coordinate systems in the on-line help.

Note: Use the Spatial Join geoprocessing tool in ArcToolbox (Analysis Tools > Overlay > Spatial Join tool) instead of this dialog if you are performing spatial join with large or complex datasets. The Spatial Join tool will in these cases give you dramatically better performance and reliability, and you can use the geoprocessing framework to easily automate repetitive or frequently performed joins with the tool as part of a model or script, or simply by entering the parameters for the tool in the geoprocessing command line. For example, you may wish to perform several similar spatial joins to compare the results.

 

About relating data

This dialog allows an association to be created between the selected layer or table and another layer or table.

A Relate is similar to a simple relationship class except it can involve data from different workspaces (i.e. a dBASE table can be related to a coverage) and is stored in a layer file or ArcMap document. If you already have a relationship class set up for your data, you can use it as you would a relate in ArcMap.

Relates can be used in the table window and the identify tool to find data that is related to the selected record or records. The following describes how relates behave when used in ArcMap:

-  Relates are bi-directional, therefore both tables involved will be able to use the relate regardless of which table owns the relate. For example, if a relate is created on layerA for tableB, the relate will be listed under layerA, but tableB will be able to use it to access records in layerA.

-  When a selection is made on a table or layer, it is not automatically applied to the related tables as it is with links in ArcView 3.x. You can use the related tables command from the table window's options menu to apply a selection to a related table or layer.

-  When using the related tables command described above, the related table or layer is added to the Table Of Contents under the active data frame if necessary and it's table window is opened.

-  If two layers in a map point to the same underlying feature class or shapefile, both are affected by and can use a relate that one of them owns. Since relates can be stored in a specific layer file, one layer can't delete a relate owned by another layer even when both layers refer to the same data.

-  A Relate owned by a table that is used to define a route or XY event source layer is not carried over to the event source layer. You must re-create the relate for the event source layer.

-  If you relate to a table that does not have an ObjectID column (i.e., Delimited text files or OLEDB tables), you will not be able to apply selections using the relate. The related tables command from the table window's options menu will list the relate, but it will be dimmed out. The identify tool, however, can still be used to find related records.

Using joins, relates and relationship classes together

If your data is involved in both joins and relates, the order in which the joins and relates are created is significant. If your layer or table has a relate, it is removed once data is joined to it. If you perform a relate on a joined layer or table, the relate is removed when the join is removed. As a general rule of thumb, it is best to create your joins and then add your relates.

In a situation where you need to join tableA and relate tableB to layerC, two of the three possible ways of doing this will work. The following describes each case:

-  Join tableA to layerC, then relate tableB to layerC - This scenario will work. You will end up with a joined layer that has a relate to tableB.

-  Relate layerC to tableB, then join tableA to layerC - This scenario will also work. In this case tableB owns the relate so when tableA is joined to layerC the relate is not removed.

-  Relate tableB to layerC, then join tableA to layerC - This scenario will not work. This is different from the previous scenario in that layerC owns the relate. Therefore, when tableA is joined to layerC, the relate is removed.

Relates owned by join tables are not effected by the join. These relates can't be accessed by the target table or layer, however.

Relationship classes are never removed as a result of a join or union operation. They can be used regardless of whether the data has been involved in joins or relates.