Now that we have so many nice vector point icons, what do you all think about making a circle the default point icon rather than an X?
Michael
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote on 04/30/2007 06:07 PM:
Now that we have so many nice vector point icons, what do you all
think about making a circle the default point icon rather than an X?
I dislike the current X but it precisely indicates the position which is not
the case with a circle. Mhhh...
Markus
------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------
On Apr 30, 2007, at 12:14 PM, Markus Neteler wrote:
Michael Barton wrote on 04/30/2007 06:07 PM:
Now that we have so many nice vector point icons, what do you all
think about making a circle the default point icon rather than an X?I dislike the current X but it precisely indicates the position which is not
the case with a circle. Mhhh...
you could do a circle with x in it but I agree with Markus.
I usually change the point icon for images used in presentations,
but when I first look at the data, x is quite convenient (I usually
reduce the size) especially if you have very dense points or
points in clusters (e.g. in the new data set even such standard
point data as geodetic points is quite dense along roads and
when first looking at the data, x defines the locations very well).
Helena
Markus
------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
Michael Barton wrote:
what do you all think about making a circle the default point icon
rather than an X?
"o" is bad for centroids as a circle over a series small island makes
all of them look round. (circle is bigger than island)
"x" marks the spot.
we could make the "x" smaller (say size=3), but that's not a good size
for other icons.
for points I usually run my d.stations script as a shortcut to typing a
long d.vect line. (wiki addons)
In addition I have a "d.mark x y" script to put a marker on the xmon at
a given x,y, which is pretty handy, much easier than v.in.ascii+d.vect.
(just added to addons)
examples:
d.mark 65,30
d.mark -m 595968,4918693
I repeat my plea to separate the GUI vector plotting controls into tabs,
4 different tools (pt, line, area, mixed vectors/advanced [current]), or
however. maybe have an "advanced" sub menu for all 3 primary feature
types.
To a new user the vector controls in GIS.m look like a 747 cockpit,
they are overwhelmed with obscure features they'll never use.
If you had three+ GUI vector control panels, points could default to
tiny circles and centroids could default to x's *independently*.
Hamish
On 4/30/07 11:45 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
what do you all think about making a circle the default point icon
rather than an X?"o" is bad for centroids as a circle over a series small island makes
all of them look round. (circle is bigger than island)"x" marks the spot.
we could make the "x" smaller (say size=3), but that's not a good size
for other icons.for points I usually run my d.stations script as a shortcut to typing a
long d.vect line. (wiki addons)In addition I have a "d.mark x y" script to put a marker on the xmon at
a given x,y, which is pretty handy, much easier than v.in.ascii+d.vect.
(just added to addons)
examples:
d.mark 65,30
d.mark -m 595968,4918693
This sounds real handy. Is it on the WIKI? Maybe we should add it to the
main GRASS distribution. It is an easy update to make it respond to a mouse
click in the GUI
I repeat my plea to separate the GUI vector plotting controls into tabs,
4 different tools (pt, line, area, mixed vectors/advanced [current]), or
however. maybe have an "advanced" sub menu for all 3 primary feature
types.
This is the way it is working in wxPython currently.
To a new user the vector controls in GIS.m look like a 747 cockpit,
they are overwhelmed with obscure features they'll never use.
I agree. Maybe if I have some time as the semester winds down I can look
into a notebook for TclTk too.
Michael
If you had three+ GUI vector control panels, points could default to
tiny circles and centroids could default to x's *independently*.Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
> In addition I have a "d.mark x y" script to put a marker on the xmon
> at a given x,y, which is pretty handy, much easier than
> v.in.ascii+d.vect.
> (just added to addons)
> examples:
> d.mark 65,30
> d.mark -m 595968,4918693
>This sounds real handy. Is it on the WIKI? Maybe we should add it to
the main GRASS distribution.
It's on the wiki addons page. It's just a shortcut & doesn't add
anything new so I never considered adding it to the main GRASS CVS.
shrug.
It is an easy update to make it respond to a mouse click in the GUI
it takes at=x,y (% of display frame) as an argument, so yes. If you want
something like this, probably just rewrite the same method in Python
with a system call to d.graph, rather than bother with calling it as a
shell script.
see also "d.where -f" (but that's current frame, not display window)
Hamish
On Thu, May 03, 2007 at 12:25:56AM +1200, Hamish wrote:
Michael Barton wrote:
> > In addition I have a "d.mark x y" script to put a marker on the xmon
> > at a given x,y, which is pretty handy, much easier than
> > v.in.ascii+d.vect.
> > (just added to addons)
> > examples:
> > d.mark 65,30
> > d.mark -m 595968,4918693
> >
>
> This sounds real handy. Is it on the WIKI? Maybe we should add it to
> the main GRASS distribution.It's on the wiki addons page. It's just a shortcut & doesn't add
anything new so I never considered adding it to the main GRASS CVS.
shrug.
I think that such a functionality is regularly needed. Maybe,
it could go into d.labels as being close with 'labels' then
optional and additional reading from stdin? On the other hand,
we don't have too many d.* modules yet.
Markus
Markus Neteler wrote:
On Thu, May 03, 2007 at 12:25:56AM +1200, Hamish wrote:
> Michael Barton wrote:
> > > In addition I have a "d.mark x y" script to put a marker on the
> > > xmon at a given x,y, which is pretty handy, much easier than
> > > v.in.ascii+d.vect.
> > > (just added to addons)
> > > examples:
> > > d.mark 65,30
> > > d.mark -m 595968,4918693
> > >
> >
> > This sounds real handy. Is it on the WIKI? Maybe we should add it
> > to the main GRASS distribution.
>
> It's on the wiki addons page. It's just a shortcut & doesn't add
> anything new so I never considered adding it to the main GRASS CVS.
> shrug.I think that such a functionality is regularly needed. Maybe,
it could go into d.labels as being close with 'labels' then
optional and additional reading from stdin? On the other hand,
we don't have too many d.* modules yet.
It already is "in" d.graph. See the example in the d.graph help page.
The guts of the script is just the 1-liner of that example- d.mark just
rearranges the options to make it a bit simpler+faster to type.
Adding it to d.labels would be an unneeded complication IMO.
I agree that the label system is a bit complicated to use, much like
ps.map is a bit complicated to use. But it works in a predictable and
repeatable way (WYSIWYWant), and it is possible to have the GUI
frontend(s) hide that complication from the user in simple tools. For
command line stuff there is little wrapper scripts like d.mark,
d.stations, and d.varea. I think they differ from other wrapper scripts
like v.centroids, v.dissolve, and r.out.xyz in that it isn't obvious
that for those last 3 that the needed functionality is burried in
v.category, v.extract, and r.stats, whereas for the former you can guess
that d.vect and d.graph should be able to do it, it's just pain to do as
there are so many options to sort past.
2c only,
Hamish