Presentation and options Dialog box of the application
Syntax

Presentation and options

This application 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.

Options detailed description:

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 application. 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 application.

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 application 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 application 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 application 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.

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

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

LinArc defines six types of tolerances for 6 different cases that can be founded in the structure of a vector file. This section explains how each type of situation corresponds geometric tolerance and how LinArc applies them in the application (only in 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.

Diagrama de toleràcies
Fig 1. The figure shows the original vectors in black and the result of the topological structure in red.
  1. Pseudogeneralization tolerance reduces the number of vertices of the vectors, eliminating alignments.
  2. 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).
  3. Undershoot tolerance connects a vertex that is close to another arc. In the figure the upper vector has been digitalized before the other one.
  4. Node snap tolerance moves the lower node to connect it with the top one, previously generated.
  5. 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

To guarantee an optimal result, it is recommended to follow these suggestions:

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

To eliminate ending nodes it is recommended using:

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

In the simplified syntax, the parameter is equivalent to the amplified following tolerance:

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

If any of these tolerances is 0 (except in precision) the process of this tolerance is being eliminate from the process, making it a quickly execution. It is only recommended when you know that the file or files you are processing don't have a specific king of problem. In precision, 0 is in fact 1e-5. If you indicate Tolerance=0 the result is:

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

If any tolerance is 0 (but precision), its application is not executed and the processing time is lower. This is recommended in the case the original file do not have one of the possible problems. If the precision given is 0, 1e-5 is used as default. In the simplified syntax, tolerance parameter is equivalent to the following expanded tolerances:

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

MPORTANT: Usually, these tolerances are only required in files that have been digitized with other software packages or with MiraMon without adequately using the tools that the application offers to connect graphical objects. When digitizing has been correctly done with MiraMon, a simplified tolerance of 0 value is the adequate option. It normally results in rapid and problem-safe processes:

LinArc 2 VecFile ArcFile 0

List file format (to structure several files simultaneously).