• LinArc: Conversion between VEC files (lines) and ARC/NOD files

This program performs the conversion between VEC files containing lines and Top-MiraMon structured vector files (ARC and NOD). Both file formats are supported by MiraMon. VEC files are a superset of the Idrisi ASCII VEC files.

The first format consists on ASCII files that do not have topological structure (at least, not explicitly) and that are not linked to databases (every graphic object accepts only one attribute). A document file (DVC) must always exist in order to define the type of graphic object contained in the .VEC files as well as other general parameters.

The second format consist of Top-MM structured vector files, that are binary files usually with arc-node topology. They are linked to a relational database (A.REL, A.DBF, N.REL and N.DBF). In version 3.x, a document file (DVA and DVN) must exist, but in the next versions it is integrated in the corresponding REL file.

If we have a family of structured vectors as the one described above, we can convert it to VEC format (lines) with the Option 1 of the LINARC program. This is necessary to modify the graphic file from MiraMon or when we want the file to be in text format.

Up to version 3.x of MiraMon, line digitizing is done on non structured vectors. The topological structure of arcs and nodes posterior to the digitizing process is such a complex process that it results almost impossible to do it by hand. This task can be done by choosing the Option 2 of the LINARC program.

In some cases, a VEC file can contain lines that implicitly define arcs and nodes, for example when it comes from a conversion of a family of arc-node files to a VEC through Option 1 of LINARC. In this case, we can choose, through Option 3, not to perform the computing task to define the topological relationships to generate ARC/NOD files, so the process becomes much faster. This option can only be used when la topological structure is not essential; it sometimes is the case of line layers such as contour lines. When polygons have to be built over this layer, this option it is possible to use this option only when the VEC file has implicit arc-node topology, due to topological relationships are essential to cicle polygons. Network analysis is another case where the topology is essential.

Option 2 supports a polygon VEC file as input file, but Option 3 does not support it. In the former case, polygon boundaries are treated simply as lines.

The program creates the LONG_ARC field in the database, indicating the length of each arc. The values of the LONG_ARC field is calculated based on the coordinates in the (map) projection and, therefore, do not give the length on the Earth but as they appear on the map, calculated as it would normally be by a computer assisted drawing (CAD) program. In projections such as UTM these calculations are accurate enough for most purposes. For example, within a UTM zone the length of each arc on the map may differ from the length on the terrestrial ellipsoid by a factor between 0.9996 and 1.0009811009).

When the cartographic projection is known (see list of known projections), as well as the LONG_ARC field the program also creates the LONG_ARCE field, that indicates the real length of each arc as calculated over the terrestrial ellipsoid using accurate geodesic criteria. These new field is especially relevant for cartographic projections in which the calculations made on the maps give clearly different values from the real values over the Earth's surface (for example, the Mercator projection) or in map projections where the difference may be small but significant errors may be accumulated when dealing with long lines.

According to the map projection used the program makes LONG_ARC or LONG_ARCE visible and hides the other field, depending on which is the most commonly used measure of length in that projection. These display criteria may be changed in the REL file.

Options detailed description:

From Arc to VEC (option 1): Converts an ARC family of topologically structured files to a VEC file, which is an ASCII file containing lines that does not have explicit topological relationships. Attributes in the resulting file can be the graphic identifier, a constant attribute or a field of the ARC database (A.REL and A.DBF). The program supports the existence of more than one database record for each graphic element. In this case it writes as many coincident lines as existing records for this graphic element; every line will have one of the multiple attributes.

De VEC a ARC/NOD (option 2): Takes a file and structures it topologically, creating nodes where arcs intersect and connecting those under the tolerance limit. Later it saves a topological ARC/NOD family. Original file can be a single VEC file, a single ARC file or a set of VEC and ARC files listed in a list file. This last possibility allows overlaying vector layers. Original database fields are combined in the output database A.DBF, becoming a single field if they have the same name (they get a compatible size and type) or different fields if they have different name. Fields of NODE databases are not inherited in the output file. A VEC file is treated as a one-field database of type indicated in the documentation file or with the name that figures in the command line or in the list.

From VEC to ARC/NOD (option 3): Converts from VEC format to an ARC/NOD family. The only change in the geometry of the original file is the following: given two nodes at a distance lower than the tolerance, the program will consider them as the same node; the position of the second coincidental node will be modified to be equal to the first.

Fusion (option 4): It joins pairs of arches with the same thematic attributes which share a node and, at the same time, no other arch coincides with the node. This operation does not carry out any topological structuring (it does not divide arches, carry out connections, etc). It is useful for importing files from other formats which display limitations in the number of vertices by object which forces them to make more than one object per strip of vertices due to the fact that as MiraMon has practically no limitations regarding the number of vertices per arch, it is better from a conceptual perspective to join contiguous arches. Please note that a conventional structuring could generate undesired intersections (e.g. roads on two levels that could intersect on one level).

Minimal local Distances (option 5): Analyses minimal local distances between arcs. It generates a table that can be represented as a frequency histogram of minimal distances; useful to determine snap tolerance thresholds for option 2. It also generates a VEC file of lines that join points of different arcs being at a distance between ThresholdMin and ThresholdMax. This file allows to see all the movements that will be produced on arcs when applying option 2, and thus determine the percentage of automatically correctly solved errors.

In options 2 and 3, the program deletes the coordinates repeated (only one preserved). Furthermore, entities formed by a single vertex are removed.

Type of tolerance and its application in the program LinArc, option 2.

Very important: all these tolerances are usually unnecessary if one scans correctly using MiraMon tools connection. However, when a file has been digitalized without following these basic rules of connection, or it has been generated with another software that not properly connects the elements can be necessary to apply these tolerances.

Precision (Fuzzy tolerance) [Prec]

Minimum distance between vertices. It must be a very small value, almost infinitesimal.

Pseudogeneralization tolerance. [T_Psgen] (fig 1.a)

Tolerance to remove vertices situated upon the same line. (It is a definition local to each arc)

Arcs tolerance. [T_Arc]

Distance than an arc can be moved (Fig 1.b1) or segment can be bended, generating a new vertex (Fig 1.b2) to connect with another (implies a relationship between arc and others).

Undershoot tolerance (fig 1.c) (Arc snap tolerance) [T_Usht]

It is the maximum distance an arc can be extended to connect to others. (It implies a relationship among one arc and the others.)

Node snap tolerance (fig 1.d). [T_Nod]

Minimum distance between nodes. It is the distance from where one node absorbs or is absorbed by its neighbours. (This implies a relationship among one node and the others.)

Dangle tolerance (fig 1.e) [T_Dngl]

Arcs shorter than this tolerance will be removed if they present one or two end nodes. (It is a definition local to each arc.)

Fig 1. The figure shows the original vectors in black and the result of the topological structure in red. Pseudogeneralization tolerance reduces the number of vertices of the vectors, eliminating alignments. Tolerance between arcs tend to connect vectors that are close The vertex of the latests digitalized vector moves so connects to the other (1). The upper segment bends to connect to the close vertex digitized previously (2). Undershoot tolerance connects a vertex that is close to another arc. In the figure the upper vector has been digitalized before the other one. Node snap tolerance moves the lower node to connect it with the top one, previously generated. Dangle tolerance makes disappear the part of the vector that excels from the other vectors where it was going to connect.

Fig 2. When three objects are closer than dangle tolerance, a path is found somewhere between them, but the object was first digitized remains stationary (in the figure above) while the secondly digitalized (on the left) moves to meet the first and the third one moves to connect with other two at the same point.

How can we define all these tolerances?

LINARC 2 OriFile ArcFile T_Arc FieldDescrip FieldName Prec T_Psgen T_Usht T_Nod T_Dngl

1. Prec <= T_Psgen <= T_Usht <= T_Nod <= T_Dngl
2. Prec and T_Psgen infinitessimal (in practice you put 0).

1. Prec=T_Psgen=T_Arc=T_Nod=0
2. T_Esc with moderate value and T_Allg with hight value.

1. T_Arc=T_Nod=T_Esc=T_Allg=tolerància
2. Prec=T_Psgen=1e-5

1. T_Arc=T_Nod=T_Esc=T_Allg=0
2. Prec=T_Psgen=1e-5

1. T_Nod=T_Usht=T_Dngl=Tolerance
2. Prec=T_Psgen=1e-5

LINARC 2 VecFile ArcFile 0

List file format (to structure several files simultaneously).

Simple format

Simple file format

primer.arc
segon.vec
tercer.vec

Advanced format

• 'FileName' is the name of a VEC file (extension is optative) or ARC (extension is compulsory). Must always be present.
• 'FieldName' is the name of the field to be created in the database (A.DBF) where the attributes of the VEC file will be written (compulsory for VEC files).
• 'DescriptorCamp' is the descriptor for the field 'FieldName' mentioned above (compulsory for VEC files).
• 'Frame' indicates whether the file serves as a the extension to which arcs should be cut. When extent equals 1 the cut vectors that fall outside the extension indicated by the file are ignored. In this case, 'NomFitxer' must be a polygon VEC file. By default, this value equals 0.
• 'Include' indicates whether the extension file must be included or not in the resulting file. When this parameter equals 0, the file is used as a cutting boundary but its elements are not included in the resulting file. By default, this value is 1.

In the following example, a list file is given, with a VEC file and an ARC file. The ARC file will be processed before the VEC file.

Advanced file format

[FITXERS]
Llista=2,1,3

[FITXER_1]
NomFitxer=segon.vec
NomCamp=ATRIBUT
DescriptorCamp=Atribut

[FITXER_2]
NomFitxer=primer.arc

[FITXER_3]
NomFitxer=marc.vec
NomCamp=ATRIBUT
DescriptorCamp=Atribut
Marc=1
Incloure=1

[FITXERS]
Llista=1,2,3,4,5,6,7,8,9,10,11,12
Llista2=13,14,15,16,17,18,19,20,21,22,23,24
Llista3=25,26
...

How to know what type of algorithm use in option 2? (optional modifier /ALGORITME=)

Idrisi is a program © of J.Ronald Eastman and Clark University.
MiraMon is a program © of Xavier Pons.