[GRASS-user] Not matching categories/line IDs

[Markus Metz]

Apparently the count in v.category option=report is the total number of
categories per type and layer. If you have e.g. two lines with categories

line1: 1
line2: 1,2

there are two lines and three categories. This needs to be explained in the
manual.

Markus M


On Fri, Sep 14, 2018 at 8:53 AM Johannes Radinger <
johannesradinger at gmail.com> wrote:

> Hi Markus,
> Hi all,
>
> I created a zipped version of a test location including one PERMANENT
> mapset that includes the vector map that causes these inconsistencies
> (Ebro_river_vector_poly_clean_tmp). The test location can be downloaded
> from here: https://we.tl/t-eSUZqfP0TQ. I also included the initial vector
> map before running the v.clean tool (Ebro_river_vector_poly_tmp). More
> specifically, I am using following code:
>
> grass.run_command("v.clean",
>         overwrite=True,
>         flags="c",
>         input="Ebro_river_vector_poly_tmp",
>         output="Ebro_river_vector_poly_clean_tmp",
>         tool="break,rmdupl,rmline,rmsa,rmdangle",
>         threshold="0,0,0,0,0.001")
>
> Maybe this helps to find out what happens here.
>
> /Johannes
>
> On Thu, Sep 13, 2018 at 10:26 PM Markus Metz <
> markus.metz.giswork at gmail.com> wrote:
>
>>
>>
>> On Thu, Sep 13, 2018 at 10:50 AM Johannes Radinger <
>> johannesradinger at gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I am a little bit puzzled about the actual number of lines/categories
>> of a specific vector map (river network). As discussed yesterday, the
>> output of v.category with the report option provides a column 'count' which
>> is a feature count. Running v.category option=report on my vector provides
>> me following:
>> >
>> > v.category input=Ebro_river_vector_poly_clean_tmp at Ebro2_alien_spread
>> option=report
>> > Layer/table: 1/Ebro_river_vector_poly_clean_tmp
>> > type       count        min        max
>> > point          0          0          0
>> > line         804          1       1053
>> > ....
>> >
>> > This would indicate that I have 804 line features. However, using the
>> tool v.info on the same vector I get following different result
>> regarding the number of lines:
>> > v.info map=Ebro_river_vector_poly_clean_tmp at Ebro2_alien_spread
>>
>> >
>>  +----------------------------------------------------------------------------+
>> >  | Name:            Ebro_river_vector_poly_clean_tmp
>>        |
>> >  ...
>> >  |   Number of points:       0               Number of centroids:  0
>>        |
>> >  |   Number of lines:        799             Number of boundaries: 0
>>        |
>> > ...
>> >
>> > And even more puzzling, I then added a table to this vector map and the
>> output of v.db.addtable is:
>> > v.db.addtable map=Ebro_river_vector_poly_clean_tmp at Ebro2_alien_spread
>>
>> > Reading features...
>> > Updating database...
>> > 803 categories read from vector map (layer 1)
>> > 803 categories read from vector map don't exist in selection from table
>> > 803 records updated/inserted (layer 1)
>>
>> If there are 804 features, 2 features must have the same category value,
>> resulting in 803 updates to the database
>> >
>> > So, is it 804,799 or 803??
>>
>> The output of v.info and v.category option=report must be identical with
>> regard to the count of features.
>> >
>> > The map I am using is a polyline river network (cat=first) that has
>> gone trough the tool v.clean with the options:
>> break,rmdupl,rmline,rmsa,rmdangle. The number of lines and cats before the
>> cleaning tool is 805 (consistent output among all tools).
>> >
>> > So I am wondering what happens during cleaning and how to get a clean
>> map with a corresponding table that has entries for each cat, and were each
>> cat represents one line feature (i.e. that the number of cats/line features
>> is consistent over the multiple tools).
>> >
>> > Please let me know if I should share the vector map (and how, which
>> format).
>>
>> Ideal would be a stripped down GRASS mapset with only this vector
>> Ebro_river_vector_poly_clean_tmp. Exporting the vector would change the
>> geometry representation and it would no longer be possible to reproduce the
>> problem.
>>
>> Markus M
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180914/57b72f2c/attachment-0001.html>