-
AtriTop: Transfer of attributes between vector entities
AtriTop: Transfer of attributes between vector entities| Presentation and options | Dialog box of the application |
| Syntax |
This application transfers attributes from one graphical layer to another based on a geometrical relation between both of them. Therefore, attributes can be transferred from a point layer to a polygon layer, or vice versa, that is, attributes can be transferred to the points from the polygon they are in.
Another example is the transfer of attributes from an arcs layer to a polygon layer. In this case, the polygons can receive the attributes of the arcs that are completely contained within them or the arcs can receive the attributes of the polygons they are in.
AtriTop allows to perform very sophisticated operations for attribute transfer. Some of them may even never be needed. Some of the examples and considerations made in this help will probably be difficult to understand or unnecessary for your specific application, so the understanding of all of them is not necessary for a correct use of this application. Only users with advanced requirements (for example relabelling of polygons which present multiple records with a point layer which also presents multiple records and the tables of which do not have the same structure) should try to fully understand the working logic of this application.
In the case of transferring attributes from one point file to another, two options are allowed. The first option is that each donor transfers attributes to the closest receptor and the second option is that each receptor receives attributes from the nearest donor. In the last case, it is necessary to assign a numberdonors, that will be the nearest to consider. If the number is 1, the attributes of the nearest donor are directly transferred to the receptor, whereas if the number is greater than 1, it applies a mean (in the case of a numeric field) or a mode (in the rest of field types) of the attributes of donors to consider. In the particular case that one or more donors present multiple record, a main/mode of the attributes for each donor object is previously made which will become a donor object with only one newly record and its mean/mode values from its recalculated record will be those that will enter into the mean/mode calculation with the other nearest donorsto considered. Finally, in this second option it is possible, for now only if the number of donors is 1, to request that all records be transferred through the special parameter /TRANSF_MULTI_REG.
Please note that AtriTop does not perform changes in the geometry or topology of the files, it simply transfers attributes based on the geometrico-topological position of the geographical elements. Therefore, when transferring attributes between polygons and arcs, in either direction, arcs and/or polygon limits have to be previously cut with option 2 of the application LinArc. If we take into consideration the example of arcs and polygons it means that all arcs need to be entirely within the polygon.
When trying to label an arc dataset with its own polygon dataset the application behavior changes and it will create a table relating every arc with its left and right polygon and a dynamic link will be set between the three data tables. Also, when you are trying to label a polygons dataset with its own arc dataset,it will create a table relating every polygon with arcs forming the border as a multiple record. This table also informs about each arc is forming the external boundary, if it has to been turned to build the polygon and the ring index. A minicam link will be set between the three data tables. In these two last cases NomResul1 parameter is the name of this new table, instead of the name of the resulting file. This information is only present in the polygon binary file, but this procedure allows to explicit it in order to allowto do vicinity operations between arcs and polygons.
The transfer of attributes between points and nodes uses a proximity criteria; user can set a maximum planimetric distance that confines the search of attributes into this range. A new field that contains the distance between the donor point and the receptor node will be added. For those points with no nodes nearly enough, the user can request the insertion of a new node on some arc within the maximum distance, following the track of one of the arcs that already exist in the receiving base. The process will try to split the arc through some vertex; otherwise, it will split the arc through the closest place to the donor point. These new nodes will be ignored by the rest of points of the donor file. Into nodes database as well as in report file, new nodes will be indicated by either "V" for vertex-derived nodes or "T" for nodes coming from a segment split.
In the text that follows, by donor file it is meant labelling file, by receptor file it is meant labelled file and by resulting file it is meant the file that results from the process of labelling. The resulting files have the same graphical elements that the receptor file has (graphically identical), however, its alphanumerical database is a mixture of what the donor and the receptor database have contributed.
The user can choose the contents of the resulting database by specifying the NAME of the fields that will form the resulting database and the NAME of the field of the donor and/or receptor database to which they correspond. From now on we will refer to the fields that are linked with this correspondence as linked fields and to the file that describes them as between-fields correspondence file.
This procedure gives maximum flexibility since it does not force the origin and destination fields to have the same name. It also allows the deletion of irrelevant fields and to change the order of the fields between the receptor database and the resulting database. In the case that this file is not specified, the application will generate the resulting database by gathering ALL fields of the receptor database and ALL the 'thematic' fields of the donor database. Field names that are equal in both databases will be considered as linkable. The resulting field width will be equal to the maximum field width of the donor and receptor databases and if one of them is of character type the resulting field will also be of character type. In the case of a link between two numeric fields the number of decimals in the resulting field will be the maximum number of decimals of the donor and receptor databases.
The format of the file that allows to choose the fields is the following:
[BASE_RESULTAT] Camp1=NOM_RES1,NOM_REC1,NOM_DON1 Camp2=NOM_RES2,NOM_REC7,NOM_DON4 Camp3=NOM_RES2,NOM_REC3 Camp4=NOM_RES3,,NOM_DON2
Note: 'Camp' means 'Field'.
The correspondence between the graphical identifier field of the resulting database and that of the receptor database is implicit and must not be stated (it would be a correspondence as Camp0=ID_GRAFIC,ID_GRAFIC).
Only the fields in the main table of the graphical layer can be chosen but the associated files of the fields of the donor and receptor database will be conserved. In case of conflict the donor database will have priority.
Please note that this procedure allows both the inclusion of new labels on an already labelled file and the relabelling of a field from scratch. It needs only to be stated or not stated in the file of correspondences between fields:
If new labels are to be included on field A the syntax is:
[BASE_RESULTAT] Camp1=A,A,AIf field A is to be fully relabelled from scratch the syntax is:
[BASE_RESULTAT] Camp1=A,,Athis will make all attributes A of the receptor database to disappear.
The algorithm followed by the mixture of fields is the following:
In the case that the results have identical records, repeated records are deleted. These repetitions can be the product of repetitions in the original databases or the product of combinations between both databases which result in equal results.
Below some examples which show the working of the algorithm are shown: In all of them it is supposed that there exists a correspondence between the graphical object 1 of the receptor database and the graphical object 2 of the donor database. Only records of these two objects are shown. All fields of the receptor and donor database have been included, except for the graphical identifier of the donor database. All equal field names are linked.
Example 1:
Receptor Donor Result
ID_G A B C D ID_G A B E F ID_G A B C D E F
1 a b c d 2 a2 b2 e f 1 a b c d
1 a b1 c d1 2 a b1 e1 f1 1 a b1 c d1 e1 f1
1 a2 b2 e f
Example 2:
Receptor Donor Result
ID_G A ID_G A B ID_G A B
1 a 2 a b 1 a b
1 a1 2 a b1 1 a b1
1 a1
Example 3:
Receptor Donor Result
ID_G A B ID_G A D ID_G A B D
1 a b1 2 a d 1 a b1 d
1 a b 2 a d1 1 a b d
1 a b1 d1
1 a b d1
Example 4:
Receptor Donor Result
ID_G A B ID_G E F ID_G A B E F
1 a b 2 e f 1 a b e f
1 a1 b1 2 e1 f1 1 a b e1 f1
1 a1 b1 e f
1 a1 b1 e1 f1
Example 5:
Receptor Donor Result
ID_G A B E ID_G E F ID_G A B E F
1 a b 2 e f 1 a b e f
1 a1 b1 e1 2 e1 f1 1 a b e1 f1
1 a1 b1 e2 1 a1 b1 e1 f1
1 a1 b1 e2
 |
| Dialog box of AtriTop. |