[GRASS-dev] d.vect changes

GRASS GIS GRASS GIS developer
1

Hi,

I've just committed some changes to d.vect in CVS. of note:

bugfix: it wasn't calculating new x,y for symbols if colors were all
none. (potentially nasty, probably invisible so was benign?)

simplification: use D_symbol() to plot symbols. This changes how -c
random and rgb_column work on symbols. Now fill color is constant (ie
whatever fcolor= was set to) and line color changes; previously -c or -a
changed either the line color or fillcolor depending on if the symbol
primitive drawing STRINGs or POLYGONs (that does odd things to symbols
that use both, like pushpin). I don't really see a way around this
without a new flag to specify if the custom color is meant to be the
line color or fill color. Deciding what to do on a per-symbol or per-
primitive basis sucks IMO. I'm open to suggestions (other than putting
the low level symbol rendering code back into d.vect).
I can solve the pushpin problem by forcing its line color to always be
black. But that doesn't solve the "x" vs "o", stroke vs fill, problem.
Lines, areas, and centroids are unaffected.

clone of D_symbol() using primary_color and secondary_color instead of
line_color and fill_color??

speed: It now only plots symbols which are in the graphics frame.
For my tests with the NC sample LIDAR dataset (1.15M points), this,
together with the switch to D_symbol(), sped up zoomed rendering by 54%
(zoomed display region covered 12% of original region area)
The overlapping edges of large offscreen symbols will no longer be drawn
at the edges of the display monitor; the point has to be in the frame.

Hamish

2

Yesterday, Hamish wrote:

I've just committed some changes to d.vect in CVS. of note:

..

simplification: use D_symbol() to plot symbols. This changes how -c
random and rgb_column work on symbols. Now fill color is constant (ie
whatever fcolor= was set to) and line color changes; previously -c or
-a changed either the line color or fillcolor depending on if the
symbol primitive drawing STRINGs or POLYGONs (that does odd things to
symbols that use both, like pushpin).

..

I can solve the pushpin problem by forcing its line color to always be
black.

I've done that now.

But that doesn't solve the "x" vs "o", stroke vs fill, problem.

..

clone of D_symbol() using primary_color and secondary_color instead of
line_color and fill_color??

I've done that now.

D_symbol2():
* The same as D_symbol(), but it uses a primary and secondary color
* instead of line and fill color. The primary color is used to draw
* stroke lines (STRINGs) and as the fill color for polygons. The
* secondary color is used for polygon outlines.
TODO: merge duplicate D_symbol() code into common lib fns in symbol.c

Markus wrote:

d.vect kills x0

..

strace d.vect myroads_net col=red

don't know, can you reproduce it with a spearfish map?
make distclean? :wink:

In the past segfaults had arisen from untested combinations of
color=none and fcolor=none leading to uninit'd variables, but I think
I've caught all those. One thing I haven't tested is using with
rgb_column, but I haven't touched that part of d.vect so I think it'll
still be ok.

mysterious day:

same here, e.g. I never received your email, nor mine above. Only
Glynn's response. But they show up on Gmane. (changing back my new yahoo
->/dev/null spam filter to ->bulkmail)

Hamish

3

On Thu, May 03, 2007 at 03:01:46PM +1200, Hamish wrote:

Markus wrote:
> d.vect kills x0
..
> strace d.vect myroads_net col=red

don't know, can you reproduce it with a spearfish map?
make distclean? :wink:

It happens with Spearfish. Just try my new v.net.path
example in the description.html.

BTW: the v.clean step therein fails - it does NOT properly
connect the lines. Sigh.

Markus

4

Hi Markus,

On Thu, 3 May 2007 07:47:59 +0200
Markus Neteler <neteler@itc.it> wrote:

On Thu, May 03, 2007 at 03:01:46PM +1200, Hamish wrote:
> Markus wrote:
> > d.vect kills x0
> ..
> > strace d.vect myroads_net col=red
>
> don't know, can you reproduce it with a spearfish map?
> make distclean? :wink:

It happens with Spearfish. Just try my new v.net.path
example in the description.html.

BTW: the v.clean step therein fails - it does NOT properly
connect the lines. Sigh.

I don't know your example, but I had similar problems some time ago because I
used a wrong tool order. As far as I remember the one below worked for me
and connected all lines.

v.clean in=xx out=xx tool=snap,break thres=xx

regards,
Otto

Markus

5

On Thu, May 03, 2007 at 07:56:17AM +0200, Otto Dassau wrote:

Hi Markus,

On Thu, 3 May 2007 07:47:59 +0200
Markus Neteler <neteler@itc.it> wrote:

> On Thu, May 03, 2007 at 03:01:46PM +1200, Hamish wrote:
> > Markus wrote:
> > > d.vect kills x0
> > ..
> > > strace d.vect myroads_net col=red
> >
> > don't know, can you reproduce it with a spearfish map?
> > make distclean? :wink:
>
> It happens with Spearfish. Just try my new v.net.path
> example in the description.html.
>
> BTW: the v.clean step therein fails - it does NOT properly
> connect the lines. Sigh.

I don't know your example,

It is in the manual page of v.net.path (CVS).

but I had similar problems some time ago because I
used a wrong tool order. As far as I remember the one below worked for me
and connected all lines.

v.clean in=xx out=xx tool=snap,break thres=xx

Indeed, this helps. To me the order of snap,break isn't much
intuitive but well.

Unfortunately, even though that the map looks ok in v.digit,
v.net.path fails to navigate (but d.path does!):

...
dglShortestPath error: Head Node Not Found
WARNUNG: Point with category [10] is not reachable from point with category
         [9]
WARNUNG: [1] destinations unreachable (including points outof threshold)
...

However, the cats are correct:
d.vect myroads_net disp=shape,cat type=point

Maybe someone could try the example?

thanks
Markus

6

> Markus wrote:
> > d.vect kills x0
> ..
> > strace d.vect myroads_net col=red

HB:

> don't know, can you reproduce it with a spearfish map?
> make distclean? :wink:

MN:

It happens with Spearfish. Just try my new v.net.path
example in the description.html.

all works fine for me, even when fancy:
  d.vect myroads_net icon=basic/triangle fcol=green size=12
  d.vect myroads_net disp=cat type=point lsize=14

BTW: the v.clean step therein fails - it does NOT properly
connect the lines. Sigh.

Is that where this v.net.path error comes from?

Building graph ...
Registering arcs ...
100%
Flattening the graph ...
Graph was built
dglShortestPath error: Head Node Not Found
WARNING: Point with category [10] is not reachable from point with category
         [9]
WARNING: [1] destinations unreachable (including points outof threshold)
Building topology ...
0 primitives registered

* "[1] destinations unreachable" reads weird as "1" is not parenthetical

This is because "connect" lines are missing any cat values. v.clean (and
almost all vector modules) work by cycling through the list of cats. You
have to use v.category to give them a cat before going on. I have forgotten
to do this enough times that now I always remember it.

[...]
v.db.addtable connect ...

# use cat 0 (no data) for both roads as "off-road" ?
v.category in=connect out=connect_cat cat=0 step=0
# not sure if this is needed later?
# v.db.update won't work for a insert? add a -i flag to it? new module?
echo "INSERT INTO connect_cat (cat, label, forward, backward) VALUES (0, 'no data', 50, 50)" | db.execute

v.db.select connect
v.db.select connect_cat

[...]

then I get a nice mypath vector and no error from v.net.path.

I have added some examples based on Spearfish:
v.net.iso/description.html
v.net.path/description.html

They need testing and simplification (v.net.path).
My problem is how to get the nodes (centers) onto the
network lines. Maybe we should implement threshold such
as in d.path? If you look at the v.net.path, you see that
it is rather painful to connect the node to the network.
Or some fancy v.edit trick to digitize the start/end
nodes?

v.net.iso: the v.clean step also removes the point patched into roads_n ?

v.net.path:
"Shortest path from two digitized nodes" example
also try:
  d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
and
  d.path -b myroads_net coor="601653.5,4922869.2","593330.8,4924096.6" \
    afcol=forward hcolor=green

[I do get a segfault from d.path if I spell the af column name wrong.]

Hamish

7

[ v.net.path example ]

On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:
...

This is because "connect" lines are missing any cat values. v.clean (and
almost all vector modules) work by cycling through the list of cats. You
have to use v.category to give them a cat before going on. I have forgotten
to do this enough times that now I always remember it.

If you look at v.db.addtable, you see that it tries to add
categories. But only in the table. Perhaps *there* should be
an addition to first check if categories are present at all,
if not, add them?

See line 192 in v.db.addtable.

This would greatly simplify the example.

Markus

8

On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:

> > Markus wrote:

...

> BTW: the v.clean step therein fails - it does NOT properly
> connect the lines. Sigh.

Is that where this v.net.path error comes from?
WARNING: Point with category [10] is not reachable from point with category
         [9]
WARNING: [1] destinations unreachable (including points outof threshold)
Building topology ...
0 primitives registered

* "[1] destinations unreachable" reads weird as "1" is not parenthetical

fixed in CVS.

This is because "connect" lines are missing any cat values. v.clean (and
almost all vector modules) work by cycling through the list of cats. You
have to use v.category to give them a cat before going on. I have forgotten
to do this enough times that now I always remember it.

Haha!! OK, this wasn't really clear to me. Unfortunately there is
no error message/warning indicating this.
See my other mail concerning v.db.addtable.

[...]
v.db.addtable connect ...

# use cat 0 (no data) for both roads as "off-road" ?
v.category in=connect out=connect_cat cat=0 step=0
# not sure if this is needed later?
# v.db.update won't work for a insert? add a -i flag to it? new module?
echo "INSERT INTO connect_cat (cat, label, forward, backward) VALUES (0, 'no data', 50, 50)" | db.execute

v.db.select connect
v.db.select connect_cat

[...]

then I get a nice mypath vector and no error from v.net.path.

Now me, too! :slight_smile:

I have updated the example in CVS.
Still the chosen path looks a bit weird to me, maybe the speed
limits (mph) are chosen badly.

> I have added some examples based on Spearfish:
> v.net.iso/description.html
> v.net.path/description.html
>
> They need testing and simplification (v.net.path).
> My problem is how to get the nodes (centers) onto the
> network lines. Maybe we should implement threshold such
> as in d.path? If you look at the v.net.path, you see that
> it is rather painful to connect the node to the network.
> Or some fancy v.edit trick to digitize the start/end
> nodes?

v.net.iso: the v.clean step also removes the point patched into roads_n ?

Good question. Maybe Martin has an idea? I guess it survives since
it is a different vector type.

v.net.path:
"Shortest path from two digitized nodes" example
also try:
  d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
and
  d.path -b myroads_net coor="601653.5,4922869.2","593330.8,4924096.6" \

     afcol=forward hcolor=green

How cool, I didn't realize this -b flag so far.
The difference is striking. I am not really sure about the second one.

[I do get a segfault from d.path if I spell the af column name wrong.]

Same thing for v.net.path. Perhaps we need a global sanity check
for column names. Maybe with db_get_column()?

Markus

PS: Amazing, where the v.net.iso suggestion for streams gets us :slight_smile:

9

On Thu, May 03, 2007 at 01:24:33PM +0200, Markus Neteler wrote:

On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:
> > > Markus wrote:

...

> > I have added some examples based on Spearfish:
> > v.net.iso/description.html
>
> v.net.iso: the v.clean step also removes the point patched into roads_n ?

Good question. Maybe Martin has an idea? I guess it survives since
it is a different vector type.

Indeed, it doesn't survive. I have updated the procedure to
create a connecting line, snap and break it and then also
the v.net.iso example works.

Updated in
vector/v.net.iso/description.html

Cheers
Markus

10

Markus Neteler wrote:

> > v.net.iso: the v.clean step also removes the point patched into
> > roads_n ?
>
> Good question. Maybe Martin has an idea? I guess it survives since
> it is a different vector type.

Indeed, it doesn't survive.

v.clean type='s default includes points:
  default: point,line,boundary,centroid,area

so it should get passed through based on that.

perhaps the point is being treated as a node and snapped to the line it
is on? test: does it get "cleaned" if it isn't on/near a line?

it has a category number, right?

Hamish

11

On Thu, May 03, 2007 at 01:24:33PM +0200, Markus Neteler wrote:

On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:

...

> v.net.path:
> "Shortest path from two digitized nodes" example
> also try:
> d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
> and
> d.path -b myroads_net coor="601653.5,4922869.2","593330.8,4924096.6" \
           afcol=forward hcolor=green

How cool, I didn't realize this -b flag so far.
The difference is striking. I am not really sure about the second one.

OK, my mistake - the column should contain *costs*. That might be
the inverse of the speed limit, not the speed limit itself:

e.g.
# define traveling costs as inverse of speed limit:
v.db.update myroads col=forward val=1/50

I have update the example in CVS. Please suggest if you have better
ideas.

Markus

12

> > v.net.path:
> > "Shortest path from two digitized nodes" example
> > also try:
> > d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
> > and
> > d.path -b myroads_net
> > coor="601653.5,4922869.2","593330.8,4924096.6" \
> afcol=forward hcolor=green
>
> How cool, I didn't realize this -b flag so far.

I just added it recently, same time as coor=.
  (coor= so we can use d.path from the GUI)

> The difference is striking. I am not really sure about the second
> one.

OK, my mistake - the column should contain *costs*. That might be
the inverse of the speed limit, not the speed limit itself:
e.g.
# define traveling costs as inverse of speed limit:
v.db.update myroads col=forward val=1/50

ahh. Is "backward" really needed? (is it optional in d.path) I'm not
really sure what that means actually. Does it mean it costs more to
drive the wrong direction on a one way street? Harder to canoe upsteam?

I have update the example in CVS. Please suggest if you have better
ideas.

For completeness: re speed limits- Expect 30mph on residential streets,
55mph on minor highways and up to 75mph on the interstate. This varies
state to state & I'm not sure what the rules are in the Dakotas, but I
expect they let you go pretty damn fast. :slight_smile:

but google knows all:
http://www.iihs.org/laws/state_laws/speed_limit_laws.html

Hamish

13

On Sat, May 05, 2007 at 03:24:40AM +1200, Hamish wrote:

Markus wrote:
> OK, my mistake - the column should contain *costs*. That might be
> the inverse of the speed limit, not the speed limit itself:
> e.g.
> # define traveling costs as inverse of speed limit:
> v.db.update myroads col=forward val=1/50

ahh. Is "backward" really needed? (is it optional in d.path) I'm not
really sure what that means actually. Does it mean it costs more to
drive the wrong direction on a one way street? Harder to canoe upsteam?

It's for the cases that you have a two lane road (see NC dataset).
You can simulate traffic jam: say, morning time one lane, in
the evening the other lane. Or connect to some traffic service
which updates your DB in real time.

> I have update the example in CVS. Please suggest if you have better
> ideas.

For completeness: re speed limits- Expect 30mph on residential streets,
55mph on minor highways and up to 75mph on the interstate. This varies
state to state & I'm not sure what the rules are in the Dakotas, but I
expect they let you go pretty damn fast. :slight_smile:

but google knows all:
http://www.iihs.org/laws/state_laws/speed_limit_laws.html

Cool. So we can improve it again...

Markus