GRASS GIS 8 Programmer's Manual
8.2.2dev(2023)-3d2c704037
|
by GRASS Development Team (https://grass.osgeo.org)
Only boundaries are used to construct areas. Boundaries know the areas to their left and right.
A category, as the name implies, is used to assign a feature to a certain category. A category is thus not a unique id, even though it can be used as such. Unique feature id's are created automatically be the vector lib and can change when the vector is modified (features added, deleted, topology rebuilt).
If you want to be sure that feature number x is always the same, it is safer to set categories such that they can be used as feature ids.
A category always belongs to a given layer. Check if there is one and only one category for the desired layer. If there is no category value set, skip this feature. If there are more categories set for the desired layer, the procedure depends on the purpose of the module. For example, v.extract
would extract a feature if any of the categories set for the given layer is in the list of categories to be selected.
Both cases are generally valid in GRASS. Do not print a warning, maybe a verbose message. It is the responsibility of a module to make a reasonable plan how to handle these cases.
Vect_read_line() reads a feature from the coor file or from external datasources which can be for native GRASS vectors of type GV_POINT, GV_LINE, GV_BOUNDARY, GV_CENTROID or GV_FACE. In the code of the vector library and modules, the word 'line' often refers to a feature in general, not only to features of type GV_LINE.
GRASS supports M:N mapping of categories. Several features can share the same category, and one feature can have several categories. Further more, one feature can have several categories in the same layer. See manual of v.buffer
for an example.
The return value of Vect_read_line() is the feature type, which must be positive, otherwise the read request was illegal. Vect_read_line() fills the Points and Cats structures with coordinates and categories.
Because Vect_read_line() does that, i.e. it can read points, lines, boundaries, centroids, faces. The coordinates of these primitive features are stored in one file, and this file does not have separate sections for points, lines, boundaries, centroids, faces. The equivalent of Vect_get_point() etc is done on module level by checking the return type of Vect_read_line(). Further on, sometimes it is desired to work with more than one type at the same time. That's the reason for
No. An area is constructed from boundaries and centroids.
Input, output, type. Sometimes layer and category lists.
The above plus where for SQL where option.
If the user requires it, you have to take it into account if you read features from a map or data from attribute table. More generally, whenever you work with categories.
It depends. If the feature should only be processed if it belongs to a certain category, yes.
If the columns exist. But sometimes column can be an expression of columns, e.g. col_a/col_b. Otherwise nothing unusual.
What should I check before I can write to attribute table? If the specified table doesn't exists, should I create one? If the module does not create a new vector, and a table exists, check if the column exists and is of the correct type, if not, create the column. If the module does create a new vector, a new table must also be created.
--overwrite
was specified, right? The behaviour for db operations is not cleary defined in GRASS. Quite a lot works without --overwrite
. Try v.db.update
or v.to.db
.
Not really. There is G_legal_filename(), Vect_legal_filename() and Vect_check_input_output_name(). Module-specific options must be checked by the module.
As a rule of thumb, whenever you use some Vect_new_*
() function, there should also be a corresponding Vect_destroy_*
() function. These deallocating functions need only be used if the Vect_new_*
() functions are called in a loop. A one-time call does not matter, memory is freed by the system when the module exits.
A cat_list is used to store a list of cats, e.g. from a cats option. The ilist struct is a list of integers.
Use Vect_read_next_line() function.
Overlapping boundaries are not topologically correct either. Either break boundaries, or (internal use only) do not build areas, or use lines if lines can hold all the info you need.
In general, overlapping areas must be broken up into non-overlapping components. Some of the new areas will have several categories, one for each original area. For internal use, lines may be ok. Use lines instead of boundaries if you don't want to break into non-overlapping components.
It depends what your module is supposed to do. See v.in.ogr
, v.in.region
or v.to.rast
for examples where the current region is considered.
This question is unclear. What would be the alternative? The method to attach centroids to areas is well tested and has been working reliably for many years.
v.to.rast
and r.to.vect
modules? No. Considering the large code base of these two modules, this would require new libraries which in turn would depend on both the vector and the raster libraries.