[GRASS5] v.to.sites question

GRASS GIS GRASS GIS developer
1

Hi,

today I tried to generate a sites file from a vector map
(containing a circle). However, the result was not what
I expect from the man page:

  "If -a flag is selected,
   v.to.sites extracts all vertices from a vector file, if not selected,
   it extracts site (point) features only, ignoring lines and areas. If
   -i flag is selected then, for each line, if the distance between any
   two vertices on this line is greater that dmax, additional points are
   added to keep the distance withing dmax range."

I thought that lots of sites are generated along the vector lines (that's
what I need). Am I wrong in my assumption? Is it a bug or a feature...?

Best regards

Markus

2

On Mon 19. November 2001 16:53, Markus Neteler wrote:

Hi,

today I tried to generate a sites file from a vector map
(containing a circle). However, the result was not what
I expect from the man page:

  "If -a flag is selected,
   v.to.sites extracts all vertices from a vector file, if not selected,
   it extracts site (point) features only, ignoring lines and areas. If
   -i flag is selected then, for each line, if the distance between any
   two vertices on this line is greater that dmax, additional points are
   added to keep the distance withing dmax range."

I thought that lots of sites are generated along the vector lines (that's
what I need). Am I wrong in my assumption? Is it a bug or a feature...?

It seems to work with labeled lines.

Radim

Best regards

Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

Markus Neteler wrote:

Hi,

today I tried to generate a sites file from a vector map
(containing a circle). However, the result was not what
I expect from the man page:

  "If -a flag is selected,
   v.to.sites extracts all vertices from a vector file, if not selected,
   it extracts site (point) features only, ignoring lines and areas. If
   -i flag is selected then, for each line, if the distance between any
   two vertices on this line is greater that dmax, additional points are
   added to keep the distance withing dmax range."

I thought that lots of sites are generated along the vector lines (that's
what I need). Am I wrong in my assumption? Is it a bug or a feature...?

Markus, check your parameters, if you selected -i a spline function is
used to generate additional points along your line, I haven't used it for a
while,
but it used to work (often I forgot to change dmax and it was generating
lots of points along contours causing problems with segmentation in
s.surf.rst for reasons
which are beyond this answer to explain, so now I make sure that my dmax is
really
large so that v.to.sites does not add any addtional sites to my data). Also
make sure that
you use -c if necessary. So unless somebody has changed it, it should work
and I suggest that you check your parameters and your data (make sure that
dmax is smaller
than the distances between your data points if you want additional data)

Helena

Best regards

Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

4

On Mon, Nov 19, 2001 at 05:19:57PM +0100, Radim Blazek wrote:

On Mon 19. November 2001 16:53, Markus Neteler wrote:
> Hi,
>
> today I tried to generate a sites file from a vector map
> (containing a circle). However, the result was not what
> I expect from the man page:
>
> "If -a flag is selected,
> v.to.sites extracts all vertices from a vector file, if not selected,
> it extracts site (point) features only, ignoring lines and areas. If
> -i flag is selected then, for each line, if the distance between any
> two vertices on this line is greater that dmax, additional points are
> added to keep the distance withing dmax range."
>
>
> I thought that lots of sites are generated along the vector lines (that's
> what I need). Am I wrong in my assumption? Is it a bug or a feature...?

It seems to work with labeled lines.

well: so I have added dig_cats support to v.bubble (was not
implemented there). Additionally I have fixed it for v.circle,
the numbers for dig_att were wrong and the file not closed.
Additionally I have applied a fix from Bob Covill to avoid
crashes on Solaris (v.bubble).

Both should be fine now.

Now back to try v.to.sites...

Markus

5

On Mon, Nov 19, 2001 at 11:30:12AM -0500, Helena Mitasova wrote:

Markus Neteler wrote:

> Hi,
>
> today I tried to generate a sites file from a vector map
> (containing a circle). However, the result was not what
> I expect from the man page:
>
> "If -a flag is selected,
> v.to.sites extracts all vertices from a vector file, if not selected,
> it extracts site (point) features only, ignoring lines and areas. If
> -i flag is selected then, for each line, if the distance between any
> two vertices on this line is greater that dmax, additional points are
> added to keep the distance withing dmax range."
>
> I thought that lots of sites are generated along the vector lines (that's
> what I need). Am I wrong in my assumption? Is it a bug or a feature...?

Markus, check your parameters, if you selected -i a spline function is
used to generate additional points along your line, I haven't used it for a
while,
but it used to work (often I forgot to change dmax and it was generating
lots of points along contours causing problems with segmentation in
s.surf.rst for reasons
which are beyond this answer to explain, so now I make sure that my dmax is
really
large so that v.to.sites does not add any addtional sites to my data). Also
make sure that
you use -c if necessary. So unless somebody has changed it, it should work
and I suggest that you check your parameters and your data (make sure that
dmax is smaller
than the distances between your data points if you want additional data)

Thanks for the hints, but I am not successfull...

GRASS:~ > v.to.sites -ai in=bug out=ring dmax=0.1

   v.to.sites:
Number of nodes = 1
GRASS:~ > v.to.sites -aic in=bug out=ring dmax=0.1

   v.to.sites:
Number of nodes = 1

Too many bugs around!

Ciao

Markus

6

I would like to suggest to include the release of GRASS5 as an item for the
upcomming meeting in Trento.
I mean not just discuss it but rather doing it. It may be easier just to go
through the
list of remaining bugs together and decide on the spot whether they are
release critical and, if they are not
(which I hope is the case) release GRASS5 so that GRASS5.1 can be started.
It will fit with Bernhards presentation.

It appeared that we were pretty close to the release but now it seems to be
going away again.

I hope that I am not too much of a pain with with this,

regards,

Helena

7

On Mon, Nov 19, 2001 at 12:42:37PM -0500, Helena Mitasova wrote:

I would like to suggest to include the release of GRASS5 as an item for the
upcomming meeting in Trento.
I mean not just discuss it but rather doing it. It may be easier just to go
through the
list of remaining bugs together and decide on the spot whether they are
release critical and, if they are not
(which I hope is the case) release GRASS5 so that GRASS5.1 can be started.
It will fit with Bernhards presentation.

Helena,

why not... I also thought about a release (would be a nice item and
reason to enjoy the evening).

It appeared that we were pretty close to the release but now it seems to be
going away again.

The only problem is that a few basic thinks still don't work.
As requested I have tagged the critical bugs to "70" priority.
Feel free to downgrade them.

I hope that I am not too much of a pain with with this,

regards,

Helena

I would be glad to have it published. However, I cannot provide more
time to fix the problems than what I currently do...

Suggestion: There are a few days left, perhaps we catch all critical
bugs until then? :slight_smile:

Happy hacking,

Markus

8

Markus Neteler wrote:

On Mon, Nov 19, 2001 at 12:42:37PM -0500, Helena Mitasova wrote:
> I would like to suggest to include the release of GRASS5 as an item for the
> upcomming meeting in Trento.
> I mean not just discuss it but rather doing it. It may be easier just to go
> through the
> list of remaining bugs together and decide on the spot whether they are
> release critical and, if they are not
> (which I hope is the case) release GRASS5 so that GRASS5.1 can be started.
> It will fit with Bernhards presentation.

Helena,

why not... I also thought about a release (would be a nice item and
reason to enjoy the evening).

> It appeared that we were pretty close to the release but now it seems to be
> going away again.

The only problem is that a few basic thinks still don't work.
As requested I have tagged the critical bugs to "70" priority.
Feel free to downgrade them.

Markus some of your 70 priority bugs were identified as users error or wishes -
so maybe whoever looked at the bug and changes it to wish can also change
the priority (i haven't yet figured out how to do it, but I must admit that I
did not try too hard,
do I need to login?)
In fact the big group of bugs that came recently and that you put at 70 were
really more inconvenieces, inconsistencies and wishes rather than bugs.
Even replacing d.legend by d.leg.thin should not be critical, although I am the
one
crying the loudest to get the legends working better (3 things are needed: add
show=val,cats to d.leg.thin,
make it possible to place and size the legend with a mouse for discrete
categories,
and have an option to define the values to be used in the legend to support
non-linear
maps) - but you can still do a lot of work with GRASS without these
capabilities.

What seems to be serious is 825 r.poly - Glynn suggest : Andrea would you have
time to look at it?
819 requires just adding a warning to i.rectify if system ifs full - can
somebody do that? Otherwise
this could be downgraded to 30 (should the system let the user know that the
system is full?)
818 import of arcinfo files seems to be serious and complex so some decision
needs to be
taken as whether it could be solved or whether we just admit the the manual that
not all
cases of e00 can be imported.

So it indeed looks like more work needs to be done, although I am concerned that
given the size
of GRASS, as soon as the release is done, we would get tons of additional bugs
and wishes.
Maybe we should say for the release that vast majority of modules is bugfree and
reliable, however
there are few that need some fixing for special cases of data and/or are not
fully consistent with
the rest of the modules and we welcome the contribution of additional users and
developers
in identifying and fixing those bugs, to make GRASS truly robust and reliable.
(wow, that is
a long sentence).

So I don't really know, as one can always dowload some pre* version and not
really care
whether it is called stable, final release or not.

Helena

> I hope that I am not too much of a pain with with this,
>
> regards,
>
> Helena

I would be glad to have it published. However, I cannot provide more
time to fix the problems than what I currently do...

Suggestion: There are a few days left, perhaps we catch all critical
bugs until then? :slight_smile:

Happy hacking,

Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

9

On Tue, Nov 20, 2001 at 11:59:49AM -0500, Helena Mitasova wrote:

Markus Neteler wrote:
> On Mon, Nov 19, 2001 at 12:42:37PM -0500, Helena Mitasova wrote:
> > It may be easier just to go through the
> > list of remaining bugs together and decide on the spot whether they are
> > release critical and,

We should not do a release in a hurry.
In general it is a good idea to rank the bugs and find a strategy
for a release.

> > It appeared that we were pretty close to the release but now
> > it seems to be going away again.

I agree with Helena that it looks like we are more
far away from a release then we were before.

Generally our strategy of branching did not work out as I expected it.
We will of course have to maintain the GRASS 5.0.x line for a while
and the plan of the branches was to let us stabilise for a release.

> The only problem is that a few basic thinks still don't work.
> As requested I have tagged the critical bugs to "70" priority.
> Feel free to downgrade them.

Markus some of your 70 priority bugs were identified as users
error or wishes - so maybe whoever looked at the bug and changes
it to wish can also change the priority (i haven't yet figured out
how to do it, but I must admit that I did not try too hard, do I
need to login?)

Yes, you have to log in to be able to manipulate bugs.
If you are logged it, it is easy:
  Display the the bug. (e.g. click on the number)
  Select the text "Current priority"
  Change value.

Note that we have added https access to the bugtracker.
If possible use this if you log in as transmission of your password
will be more secure.

  https://intevation.de/rt/webrt?q_queue=grass&logout=guest

In fact the big group of bugs that came recently and that you put
at 70 were really more inconvenieces, inconsistencies and wishes
rather than bugs. Even replacing d.legend by d.leg.thin should
not be critical, although I am the one crying the loudest to get
the legends working better (3 things are needed: add
show=val,cats to d.leg.thin,
make it possible to place and size the legend with a mouse for
discrete categories, and have an option to define the values to be
used in the legend to support non-linear
maps) - but you can still do a lot of work with GRASS without these
capabilities.

I have lowered some wishs to below 25, because they are not release critical.

What seems to be serious is 825 r.poly
- Glynn suggest : Andrea would you have time to look at it?

Priority up to 75.

819 requires just adding a warning to i.rectify if system ifs full
- can somebody do that? Otherwise this could be downgraded to 30
(should the system let the user know that the system is full?)

New Priority: 50 as it is not release critical.

818 import of arcinfo files seems to be serious and complex so
some decision needs to be taken as whether it could be solved or
whether we just admit the the manual that not all cases of e00 can
be imported.

So it indeed looks like more work needs to be done, although I am
concerned that given the size of GRASS, as soon as the release is
done, we would get tons of additional bugs and wishes.

Maybe we should say for the release that vast majority of modules
is bugfree and reliable, however there are few that need some
fixing for special cases of data and/or are not fully consistent
with the rest of the modules and we welcome the contribution of
additional users and developers in identifying and fixing those
bugs, to make GRASS truly robust and reliable. (wow, that is a
long sentence).

We can add a KNOWN_BUGS section.
Grass does not need to be completely bug free when we release it.

So I don't really know, as one can always dowload some pre*
version and not really care whether it is called stable, final
release or not.

> > I hope that I am not too much of a pain with with this,

Keep the comments comming it is need to motivate the developers
and to get a feeling for what is important.

> I would be glad to have it published. However, I cannot provide more
> time to fix the problems than what I currently do...

You are already doing a lot and many many thanks for this work!

> Suggestion: There are a few days left, perhaps we catch all critical
> bugs until then? :slight_smile:

Not until we get a lot of developers up to help!
A lot of these bugs seems to be very easy to squash,
so I can only encourage all developers to look at the bugs
and see if they have a couple of minutes to fix for progress the
fixing of the bug.

Thanks,
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)