Hello Michael,
sorry if I misunderstand your issue, but before patching these two maps
are you sure that each has a set of cat values strictly distinct from
the other? If a vector feature in map A shares the same cat value as
another feature in map B then after patching these features will be
assigned a single record in the attribute table because their cat will
be indentical.
V.
Le samedi 16 mars 2024 à 00:37 +, Michael Barton a écrit :
> I got this to work *finally*. But there are still complications. Here
> is an example work flow:
>
> 1. Create a map of vector features
> 2. Create a basic attribute table (e.g., with v.db.addtable).
> 3. Export that table into a csv file using db.out.ogr
> 4. Add some attribute fields to that csv file
> 5. Try to import that csv file using db.in.ogr
> 6. Error: it won't import the cat field
> 7. Edit the csv file to rename cat to mycat
> 8. Try to import the csv file again using db.in.ogr
> 9. If you have not changed the sort order of the csv file, the new
> cat numbers that db.in.ogr automatically assigns (no option about
> this) will match the original cat numbers.
> 10. If cat does not match mycat, no problem because when you connect
> the attribute table to the vector with v.db.connect, you can specify
> mycat as the key field.
> 11. Try to patch this vector with another vector that has the same
> structure of attribute table. *Fail* Because patching creates new cat
> numbers in some order that is not necessarily related to the old
> linkage. The attribute table of the 2nd map is properly added to the
> first attribute table, but the second map is not linked properly to
> the attribute records.
>
> In my case, patching updated my non-cat keyfield to the max cat value
> of the original table (154) + the max cat value of the patched table
> (155) = 309. Very odd. This did not match any record. Fortunately,
> because I only have only one vector feature in the 2nd patched map, I
> could edit the cat field in the table (because it was not the key
> field) to match the new cat of the 2nd vector feature, and rejoin the
> table to the vector using cat. If I would have had multiple features
> in the 2nd file, it would have been difficult to impossible.
>
> I'm not sure how to fix this. It may need to be a combination of
> allowing various vector modification modules to specify a cat value
> for a feature, assuming no duplication. It may need some change to
> db.in.ogr to allow for importing a field named cat. Maybe more
> changes to patch (and other features that have legacy underlying
> assumptions from the old pre-version6 vector format).
>
> Michael
> _
> C. Michael Barton
> Associate Director, School of Complex Adaptive
> Systems (https://scas.asu.edu)
> Professor, School of Human Evolution & Social
> Change (https://shesc.asu.edu)
> Director, Center for Social Dynamics &
> Complexity (https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
>
> Executive Director, Open
> Modeling Foundation (https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
>
> personal website: http://www.public.asu.edu/~cmbarton
>
>
> > On Mar 15, 2024, at 5:05 PM, Michael Barton
> > wrote:
> >
> > Never mind. I figured it out when I saw the post. Now for the next
> > step.
> >
> > Michael
> > _
> > C. Michael Barton
> > Associate Director, School of Complex Adaptive
> > Systems (https://scas.asu.edu)
> > Professor, School of Human Evolution & Social
> > Change (https://shesc.asu.edu)
> > Director, Center for Social Dynamics &
> > Complexity (https://complexity.asu.edu)
> > Arizona State University
> > Tempe, AZ 85287-2701
> > USA
> >
> > Executive Director, Open
> > Modeling Foundation (https://openmodelingfoundation.github.io)
> > Director, Network for Computational Modeling in Social & Ecological
> > Sciences (https://comses.net)
> >
> > personal website: http://www.public.asu.edu/~cmbarton
> >
> >
> > > On Mar 15, 2024, at 3:29 PM, Michael Barton
> > > wrote:
> > >
> > > Something is just not working here.
> > >
> > > I can't try the new PR until I can get the original cats fixed.
> > > v.category does not seem to be working as expected. I have a map
> > > with a single area. I clipped it out of another map (where it had
> > > cat=18) using v.select. When I check the categories, it looks
> > > like this:
> > >
> > > v.category input=SA5@SAA2024 type=centroid option=report
> > > Layer/table: 1/SA5
> > > type count min max
> > > point 0 0 0
> > > line 0 0 0
> > > boundary 0 0 0
> > > centroid 1 28 28
> > > area 0 0 0
> > > face 0 0 0
> > > kernel 0 0 0
> > > all 1 28
