v.net.iso / v.net.alloc: keep original cat values or change output to field in attribute table instead of new map

[effilc36]

Dataset: nc_spm_08

Input:

v.net.iso input=streets_net output=streets_net_iso ccats=1-100000 nlayer=2 \ costs=200,400,600,800 afcolumn=navcost

v.category streets_net_iso option=report (works as expected)

Results:

Adding streets_net_iso to the GIS Manager and classifying by cat=1 produces "database connection not defined" error.

"Show attribute columns" in GIS Manager produces the same results

[mlennert]

Reclassifying this as a wish instead of a bug since this is a feature of the current version of v.net.iso: all line segments are given the category number of the distance class they belong to. Thus they cannot be linked to the table of the original input file, as the segment identifiers have changed and do not correspond to the original attribute table key field anymore.

However, I do agree that it might be desirable to implement (some of) the following:

1) at least create an attribute field containing the min and max distances of the class. Otherwise, you might forget which distances you used to create the map and then the cat values are useless for anything else but ordinal logic.

2) keep the old category values of the input map and create a new column in the table in which you enter the distance class (preferrably in the form "min-max") for each line segment. This way one could connect to the table of the input map if so desired

3) add a flag which would allow to do 2) by updating the table of the input map instead of creating a new map. No need really to use up disk space for a map which only contains distance classes if you can just as easily integrate them into the existing attribute table. Even more relevant now that Markus' work allows to use quite large networks.

Moritz

[mlennert]

Replying to mlennert:

However, I do agree that it might be desirable to implement (some of) the following:

Just brainstorming here: the same can be said for v.net.alloc.

[martinl]

Milestone renamed

[mlennert]

Pinging this after a class where many students thought they did something wrong because the approach using cat values is not very intuitive and is not directly visible.

I still think that giving the option to write the results as new columns in the attribute file of the network would be a nice feature to have.

In addition, for the default of creating a new map with relevant category values, it would be nice (and I imagine not hard to implement) to at least apply a color table to the vector map that renders the results immediately visible.

[mmetz]

Replying to mlennert:

Pinging this after a class where many students thought they did something wrong because the approach using cat values is not very intuitive and is not directly visible.

I still think that giving the option to write the results as new columns in the attribute file of the network would be a nice feature to have.

v.net.iso and v.net.alloc split some of the input lines: if the start node and the end node of a line belong to different classes, that line is split proportional to the cost difference and the two (or more) new lines will belong to different classes.

Therefore it is not possible to simply add a new attribute to input lines.

What could be done is to add a new flag that 1) creates unique categories and adds an attribute table with class id (iso zone) and distance, 2) copies original arc attributes to a separate layer with some lines sharing the original arc category.

[mlennert]

Replying to mmetz:

Replying to mlennert:

Pinging this after a class where many students thought they did something wrong because the approach using cat values is not very intuitive and is not directly visible.

I still think that giving the option to write the results as new columns in the attribute file of the network would be a nice feature to have.

v.net.iso and v.net.alloc split some of the input lines: if the start node and the end node of a line belong to different classes, that line is split proportional to the cost difference and the two (or more) new lines will belong to different classes.

Therefore it is not possible to simply add a new attribute to input lines.

Now that you say it, it's obvious... ;-)

What could be done is to add a new flag that 1) creates unique categories and adds an attribute table with class id (iso zone) and distance, 2) copies original arc attributes to a separate layer with some lines sharing the original arc category.

That sounds like a good idea.

And any objection to applying in any case a default color table ? I know (think) this would be a first, but for these modules one has to already understand GRASS' category vs attributes logic in order to understand the results. Coloring them by default would make the user experience easier, IMHO. Or at least give this option a an additional flag ?

[mmetz]

Replying to mlennert:

Replying to mmetz:

Replying to mlennert:

Pinging this after a class where many students thought they did something wrong because the approach using cat values is not very intuitive and is not directly visible.

I still think that giving the option to write the results as new columns in the attribute file of the network would be a nice feature to have.

v.net.iso and v.net.alloc split some of the input lines: if the start node and the end node of a line belong to different classes, that line is split proportional to the cost difference and the two (or more) new lines will belong to different classes.

Therefore it is not possible to simply add a new attribute to input lines.

Now that you say it, it's obvious... ;-)

What could be done is to add a new flag that 1) creates unique categories and adds an attribute table with class id (iso zone) and distance, 2) copies original arc attributes to a separate layer with some lines sharing the original arc category.

That sounds like a good idea.

Done in r71193 for v.net.iso (new flag -u). The newly created attribute table has the fields cat (category value), ocat (original category value), center (category value of nearest center), isonr (iso band number), isolbl (iso band label). A side effect is that a line is now correctly split if it is assigned to two different centers.

Done in r71194 for v.net.alloc (new flag -u). The newly created attribute table has the fields cat (category value), ocat (original category value), center (category value of nearest center).

And any objection to applying in any case a default color table ? I know (think) this would be a first, but for these modules one has to already understand GRASS' category vs attributes logic in order to understand the results. Coloring them by default would make the user experience easier, IMHO. Or at least give this option a an additional flag ?

[mlennert]

Replying to mmetz:

Done in r71193 for v.net.iso (new flag -u). The newly created attribute table has the fields cat (category value), ocat (original category value), center (category value of nearest center), isonr (iso band number), isolbl (iso band label). A side effect is that a line is now correctly split if it is assigned to two different centers.

Works great, thanks ! And the output is very useful, and probably more intuitive for many.

Done in r71194 for v.net.alloc (new flag -u). The newly created attribute table has the fields cat (category value), ocat (original category value), center (category value of nearest center).

This one segfaults for me when doing the following:

v.net streets_wake points=schools_wake op=connect out=network thresh=99999
v.net.alloc -u network ccats=1-5 out=alloc

valgrind reports the issue to be on line 344 of main.c:

Invalid read of size 4
==3597==    at 0x10B588: main (main.c:344)
==3597==  Address 0x10 is not stack'd, malloc'd or (recently) free'd

[mmetz]

Replying to mlennert:

Replying to mmetz:

Done in r71194 for v.net.alloc (new flag -u). The newly created attribute table has the fields cat (category value), ocat (original category value), center (category value of nearest center).

This one segfaults for me when doing the following:

v.net streets_wake points=schools_wake op=connect out=network thresh=99999
v.net.alloc -u network ccats=1-5 out=alloc

valgrind reports the issue to be on line 344 of main.c:

Invalid read of size 4
==3597==    at 0x10B588: main (main.c:344)
==3597==  Address 0x10 is not stack'd, malloc'd or (recently) free'd

Fixed in r71197.

I want to sync v.net.alloc and v.net.iso some more, these two modules are very similar.

[mmetz]

Replying to mmetz:

I want to sync v.net.alloc and v.net.iso some more, these two modules are very similar.

Done in trunk r71212.

v.net.iso could now with little effort changed to optionally produce the output of v.net.alloc. v.net.alloc could then become a simple wrapper for v.net.iso.

[mlennert]

Replying to mmetz:

Replying to mmetz:

I want to sync v.net.alloc and v.net.iso some more, these two modules are very similar.

Done in trunk r71212.

v.net.iso could now with little effort changed to optionally produce the output of v.net.alloc. v.net.alloc could then become a simple wrapper for v.net.iso.

I just tested and both work fine in the current state.

Is it better to have everything in a module and create wrapper modules, or would it be more interesting to put the common part of the code into a library ?

[mmetz]

Replying to mlennert:

Is it better to have everything in a module and create wrapper modules, or would it be more interesting to put the common part of the code into a library ?

I would prefer to make the costs option of v.net.iso optional and make v.net.alloc a wrapper for v.net.iso.

If other modules need that functionality as well, the code part that assigns centers to nodes could be put into the neta library. The existing functions NetA_distance_[from|to]_points() are similar, but return the paths to nearest centers instead of the nearest centers themselves.

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed