v.to.db: new variables to add

[mlennert]

[Going on with my series of notes on what would be great to have in GRASS:]

The eigenvalues of the covariance matrix of the coordinates of the vertices of a polygon represent the major and minor (+ medium in 3D) axes of an ellipse (ellipsoid in 3D) that approximates the polygon. These values can be used to approximate different variables in shape analysis (length, direction, asymmetry, etc). It would be great if v.to.db could calculate these values.

[mlennert]

I'm renaming this to make this into a more general collection of ideas for variables to add to v.to.db. Feel free to add other ideas.

• eigenvalues of covariance matrix of coordinates
• bounding box coordinates

[martinl]

Milestone renamed

[hellik]

Replying to mlennert:

I'm renaming this to make this into a more general collection of ideas for variables to add to v.to.db. Feel free to add other ideas.

• eigenvalues of covariance matrix of coordinates
• bounding box coordinates

taken ​https://lists.osgeo.org/pipermail/grass-dev/2017-January/084047.html

is there an easy way to load [...] top, bottom, left, right
coordinates of every geometry (polygon, line) to the vector attribute table?

• bounding box coordinates

this would be a really nice addition to v.to.db

[hellik]

Replying to hellik:

Replying to mlennert:

I'm renaming this to make this into a more general collection of ideas for variables to add to v.to.db. Feel free to add other ideas.

• eigenvalues of covariance matrix of coordinates
• bounding box coordinates

taken ​https://lists.osgeo.org/pipermail/grass-dev/2017-January/084047.html

is there an easy way to load [...] top, bottom, left, right
coordinates of every geometry (polygon, line) to the vector attribute table?

• bounding box coordinates

this would be a really nice addition to v.to.db

referecing to the source: ​Vect_get_area_box

[mlennert]

I've just attached a patch that implements a bounding box measure in v.to.db.

However, at this stage, it doesn't, yet, take into account the case when there is more than one polygon with the same category.

[mlennert]

Replying to mlennert:

I've just attached a patch that implements a bounding box measure in v.to.db.

However, at this stage, it doesn't, yet, take into account the case when there is more than one polygon with the same category.

It also does not take into account 3D vectors. At this stage bounding box is only defined 2D, but it wouldn't be too difficult to include 3D.

But then again this is the case for the other measures as well (area, but no volume, for example).

[mlennert]

first version of patch to implement bounding box

[mlennert]

Replying to mlennert:

I've just attached a patch that implements a bounding box measure in v.to.db.

However, at this stage, it doesn't, yet, take into account the case when there is more than one polygon with the same category.

I just uploaded a modified version of the patch to take this into account (although I think a warning would be appropriate for the case of multiple features with the same cat and '-p' flag set, but that is a different issue).

Please test. If it works for you then I can commit it to trunk for wider testing.

[mlennert]

I finally decided to just go ahead and commit to facilitate testing (r70451). In the case of multiple features by category the module now calculates the total bounding box for all features with same category.

[hellik]

Replying to mlennert:

I finally decided to just go ahead and commit to facilitate testing (r70451).

thanks for the implementation:

tested with

System Info                                                                     
GRASS version: 7.3.svn                                                          
GRASS SVN revision: r70453                                                      
Build date: 2017-01-30                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.1.2                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.14.1                                                                  
Python: 2.7.5                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-8-6.2.9200 (OSGeo4W)  

g.copy vector=lakes@PERMANENT,mylakes                                           
Copy vector <lakes@PERMANENT> to current mapset as <mylakes>

v.to.db map=mylakes@user1 option=bbox columns=t,b,r,l                           
Reading areas...
Updating database...
15279 categories read from vector map (layer 1)
15279 records selected from table (layer 1)
15279 categories read from vector map exist in selection from table
15279 records updated/inserted (layer 1)

v.db.select map=mylakes@user1                                                   
cat|AREA|PERIMETER|FULL_HYDRO|FULL_HYDR2|FTYPE|FCODE|NAME|t|b|r|l
1|280261.46103|2853.9372|2|55626|LAKE/POND|39000||258302.909848466|258130.034036035|636012.26029972|635790.715367031
2|6754.6563|404.28643|3|55650|DAM/WEIR|34300||258248.323799814|258193.490779749|636431.09504699|636410.782219965
3|19512.86146|708.44683|4|55652|LAKE/POND|39000||258245.544932657|258192.348996665|636490.942646686|636425.805537212
4|1132.10986|151.16533|5|53514|LAKE/POND|39000||258212.396727567|258203.793649957|637196.254140018|637177.667259335
5|2849.43244|249.99941|6|53510|DAM/WEIR|34300||258210.786516747|258193.870561307|637209.225457828|637177.667259335
6|5908.42064|413.13377|7|55640|DAM/WEIR|34300||258181.2788371|258130.602489171|636960.29029048|636934.092252985
7|18807.73989|567.89134|8|55644|LAKE/POND|39000||258181.2788371|258125.193192754|636995.050850902|636941.778105157
8|5310.04399|334.89296|9|55660|LAKE/POND|39000||258172.628397222|258130.594259555|635797.542291085|635770.696062993

seems to work; nice addition to v.to.db.

In the case of multiple features by category the module now calculates the total bounding >box for all features with same category.

it's the best way to handle this.

[hellik]

Replying to mlennert:

I finally decided to just go ahead and commit to facilitate testing (r70451). In the case of multiple features by category the module now calculates the total bounding box for all features with same category.

now tested with a wgs84 ll testcase:

v.db.select map=testcalculate@hkmyr columns=l,lg,r,rg,t,tg,b,bg                 
l|lg|r|rg|t|tg|b|bg
9.0801356183|9.08013561826955|10.6452349706|10.6452349706296|47.6779179411|47.6779179411464|46.4101061965|46.4101061964608
11.0347074901|11.0347074900713|12.7965928607|12.7965928607123|47.8068606443|47.8068606443141|46.1987432153|46.198743215305
9.0475885875|9.04758858753172|10.3944050709|10.3944050709074|46.4383355922|46.4383355921998|45.9348643802|45.9348643802451

l,r,t,b calculated by qgis lg,rg,tg,bg calculated by the new v.to.db functionality

looks good also in ll locations.

[hellik]

Replying to mlennert:

I finally decided to just go ahead and commit to facilitate testing (r70451). In the case of multiple features by category the module now calculates the total bounding box for all features with same category.

candidate for a 7.2.x-backport?

[mlennert]

Replying to hellik:

Replying to mlennert:

I finally decided to just go ahead and commit to facilitate testing (r70451). In the case of multiple features by category the module now calculates the total bounding box for all features with same category.

candidate for a 7.2.x-backport?

It's new functionality, not a bug fix. I'm a strong defender of the policy that minor point releases are bug fix only.

I'd rather see 7.4 come out in a not too far future...

[neteler]

Replying to mlennert:

I'd rather see 7.4 come out in a not too far future...

​https://trac.osgeo.org/grass/milestone/7.4.0 --> No date set (yet)

[martinl]

Time to close this issue?

[neteler]

Ticket retargeted after milestone closed