Hi all.
I have a map of cities. I want to draw labels using city names, but,
some generalization is needed. In other words, some labels overlap
with other labels.
I installed grass63 to use v.generalize, but I see that I can not use
that tool with maps of points. Please, I need some suggestions.
Thanks
José María
On Thu, Oct 16, 2008 at 11:40 PM, José María Michia
<jose.maria.michia@gmail.com> wrote:
Hi all.
I have a map of cities. I want to draw labels using city names, but,
some generalization is needed. In other words, some labels overlap
with other labels.
You need v.label.sa:
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.label.sa
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.label.sa/description.html
For whatever reason it is not enabled in GRASS 6.4.svn !?
In future, I hope that someone integrates the new:
PAL - cartographic label placement library
http://geosysin.iict.ch/trac/wiki/Index4extJPAL
which has been recently integrated into gvSIG. The developers are
interested to get it integrated into GRASS, too.
Markus
On Friday 17 October 2008, Markus Neteler wrote:
On Thu, Oct 16, 2008 at 11:40 PM, José María Michia
<jose.maria.michia@gmail.com> wrote:
> Hi all.
>
> I have a map of cities. I want to draw labels using city names, but,
> some generalization is needed. In other words, some labels overlap
> with other labels.You need v.label.sa:
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.l
abel.sa
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.l
abel.sa/description.htmlFor whatever reason it is not enabled in GRASS 6.4.svn !?
Any ideas on why? Wasn't this a Google SOC project that was completed?
Cheers,
Dylan
In future, I hope that someone integrates the new:
PAL - cartographic label placement library
http://geosysin.iict.ch/trac/wiki/Index4extJPALwhich has been recently integrated into gvSIG. The developers are
interested to get it integrated into GRASS, too.Markus
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
On Fri, 17 Oct 2008, Dylan Beaudette wrote:
On Friday 17 October 2008, Markus Neteler wrote:
You need v.label.sa:
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.l
abel.sa
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.l
abel.sa/description.htmlFor whatever reason it is not enabled in GRASS 6.4.svn !?
Any ideas on why?
I seem to vaguely remember that the plan was to replace v.label by v.label.sa, but Hamish wanted to add some functionality to v.label.sa that was missing before replacing it totally. So I guess the idea was not to let it become known by the v.label.sa name if it was imminently going to be renamed to v.label. Apologies to those concerned (Wolf and Hamish) if I have mis-remembered.
Wasn't this a Google SOC project that was completed?
No - it was written by Wolf.
In future, I hope that someone integrates the new:
PAL - cartographic label placement library
http://geosysin.iict.ch/trac/wiki/Index4extJPALwhich has been recently integrated into gvSIG. The developers are
interested to get it integrated into GRASS, too.
Looks very nice, although v.label.sa sounded pretty advanced too from Wolf's descriptions to the list. Do you know what advantages PAL has? At least the C++ is a disadvantage I suppose. Have the PAL developers tested v.label.sa?
Paul
On 17.10.2008 19:14, Paul Kelly wrote:
On Fri, 17 Oct 2008, Dylan Beaudette wrote:
abel.sa/description.html
For whatever reason it is not enabled in GRASS 6.4.svn !?
Any ideas on why?
I seem to vaguely remember that the plan was to replace v.label by
v.label.sa, but Hamish wanted to add some functionality to v.label.sa
that was missing before replacing it totally. So I guess the idea was
not to let it become known by the v.label.sa name if it was imminently
going to be renamed to v.label. Apologies to those concerned (Wolf and
Hamish) if I have mis-remembered.
I'm still waiting for Hamish to check a patch for d.labels to allows
precision placement that v.label.sa. So far he has been to busy to check
it. *shrug* Also v.label.sa still needs area label placement support,
but that might have to wait for spring, when I start working on my
Bachelor. Also Hamish wanted to integrate v.label.sa to v.label, but
IMHO they are maybe too much different in philosophy to merge...
Wasn't this a Google SOC project that was completed?
No - it was written by Wolf.
Correct. And I hope to uses it as my bachelor (adding the area positioning).
In future, I hope that someone integrates the new:
PAL - cartographic label placement library
http://geosysin.iict.ch/trac/wiki/Index4extJPALwhich has been recently integrated into gvSIG. The developers are
interested to get it integrated into GRASS, too.Looks very nice, although v.label.sa sounded pretty advanced too from
Wolf's descriptions to the list. Do you know what advantages PAL has? At
least the C++ is a disadvantage I suppose. Have the PAL developers
tested v.label.sa?
Hmm interesting. I would be interested in doing that, if that is what we
want. I'll study the paper and will comment later on the differences.
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
2008/10/17 Markus Neteler <neteler@osgeo.org>:
On Thu, Oct 16, 2008 at 11:40 PM, José María Michia
<jose.maria.michia@gmail.com> wrote:Hi all.
I have a map of cities. I want to draw labels using city names, but,
some generalization is needed. In other words, some labels overlap
with other labels.You need v.label.sa:
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.label.sa
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/vector/v.label.sa/description.html
I installed "GRASS6.4.svn" and I tried "v.label.sa". I see that this
tool mantain the number of labels, and re-arrange labels locations for
better results. But my map has many elements. It is necessary to
suppress some labels, or some points.
For example, I have seen that the program MapServer performs this task
very well.
Anyway, I'm very happy using GRASS! So, thanks all. Specially, to developers.
José María Michia
For whatever reason it is not enabled in GRASS 6.4.svn !?
In future, I hope that someone integrates the new:
PAL - cartographic label placement library
http://geosysin.iict.ch/trac/wiki/Index4extJPALwhich has been recently integrated into gvSIG. The developers are
interested to get it integrated into GRASS, too.Markus
On 18.10.2008 02:30, José María Michia wrote:
But my map has many elements. It is necessary to
suppress some labels, or some points.
Yes, v.label.sa doesn't suppress any labels. That is also the main
difference between PAL and v.label.sa. v.label.sa assumes that you want
to display all labels. I have plans of adding a few other features to it.
Another main difference between PAL and the v.label.sa algorithm is the
way to find an optimum solution. v.label.sa uses Simulated Annealing,
which is based on randomness. PAL on the other hand uses chained
transformations which to my understanding means that you take a label
and if it is overlapping, you move it to another candidate place. If it
overlaps with exactly one other label then you move that label and the
chain goes on until you move a label to overlap with multiple labels in
which case you choose not to display that label, and stop the recursion.
The best visited configuration is selected as the new. I still have to
read the papers they refer to, but it seems like a nice approach. A bit
different from the SA one.
I feel that allowing a user to select which labels to show is more
powerful than having an algorithm drop labels off.
1) Allow a where argument which allows you to select features to label
2) Allow multiple maps
3) Add support for labeling of areas. (currently labels areas as point
labels around centroid)
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
2008/10/18 Wolf Bergenheim <wolf+grass@bergenheim.net>:
On 18.10.2008 02:30, José María Michia wrote:
But my map has many elements. It is necessary to
suppress some labels, or some points.Yes, v.label.sa doesn't suppress any labels. That is also the main
difference between PAL and v.label.sa. v.label.sa assumes that you want
to display all labels. I have plans of adding a few other features to it.Another main difference between PAL and the v.label.sa algorithm is the
way to find an optimum solution. v.label.sa uses Simulated Annealing,
which is based on randomness. PAL on the other hand uses chained
transformations which to my understanding means that you take a label
and if it is overlapping, you move it to another candidate place. If it
overlaps with exactly one other label then you move that label and the
chain goes on until you move a label to overlap with multiple labels in
which case you choose not to display that label, and stop the recursion.
The best visited configuration is selected as the new. I still have to
read the papers they refer to, but it seems like a nice approach. A bit
different from the SA one.I feel that allowing a user to select which labels to show is more
powerful than having an algorithm drop labels off.1) Allow a where argument which allows you to select features to label
2) Allow multiple maps
3) Add support for labeling of areas. (currently labels areas as point
labels around centroid)--Wolf
If possible, I think it would be useful feature the following:
- Where two labels overlap, comparing an attribute to decide which one stays
For example: on a map of cities you can use the number of inhabitants.
If the city "A" has more inhabitants than the city "B", maintaining
the label of the city "A".
José María
--
<:3 )---- Wolf Bergenheim ----( 8:>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
On 18.10.2008 17:25, José María Michia wrote:
If possible, I think it would be useful feature the following:
- Where two labels overlap, comparing an attribute to decide which one stays
For example: on a map of cities you can use the number of inhabitants.
If the city "A" has more inhabitants than the city "B", maintaining
the label of the city "A".
Hmm well that might work. Have a numeric weight column to decide after
the final arrangement which one stays... hmm. Yes I think that would
work. So for all overlaps, then I'd just fetch the column values and
keep the one with the max value.
Can you think of any other needed comparison methods?
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
If messages are allowed to collide, how about looking at it length to determine they top->bottom ordering? Like - if "foo" and "barbarbar" are colliding, then display "foo" on top of "barbarbar".
As I have not tested new labeling module, it's just a plain idea.
Maris.
2008/10/19, Wolf Bergenheim <wolf+grass@bergenheim.net>:
Hmm well that might work. Have a numeric weight column to decide after
the final arrangement which one stays... hmm. Yes I think that would
work. So for all overlaps, then I'd just fetch the column values and
keep the one with the max value.Can you think of any other needed comparison methods?
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
On 19.10.2008 14:05, Maris Nartiss wrote:
If messages are allowed to collide, how about looking at it length to
determine they top->bottom ordering? Like - if "foo" and "barbarbar"
are colliding, then display "foo" on top of "barbarbar".
Hmm... Well that would be more complicated... I think d.labels diplays
the labels in the order they are in the label file (Hamish probably
knows), so I'd have to change the order they are in the file or else
maybe d.labels could do that?
I'm now working on José María's wish for v.label.sa to hide colliding
labels based on some weight db column.
--Wolf
As I have not tested new labeling module, it's just a plain idea.
Maris.
2008/10/19, Wolf Bergenheim <wolf+grass@bergenheim.net>:
Hmm well that might work. Have a numeric weight column to decide
after the final arrangement which one stays... hmm. Yes I think
that would work. So for all overlaps, then I'd just fetch the
column values and keep the one with the max value.Can you think of any other needed comparison methods?
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
_______________________________________________ grass-user mailing
list grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
<:3 )---- Wolf Bergenheim ----( 8:>
On Fri, Oct 17, 2008 at 10:19 PM, Wolf Bergenheim
<wolf+grass@bergenheim.net> wrote:
...
I'm still waiting for Hamish to check a patch for d.labels to allows
precision placement that v.label.sa. So far he has been to busy to check
it. *shrug*
Wolf, could you dig out the relevant link(s) or ticket?
Maybe we can accelerate things but I don't remember details.
Markus
José María,
If possible, I think it would be useful feature the following:
- Where two labels overlap, comparing an attribute to decide which one stays
For example: on a map of cities you can use the number of inhabitants.
If the city "A" has more inhabitants than the city "B", maintaining
the label of the city "A".
I have just now committed a change in v.label.sa that will do exactly
this. See the new overlap parameter. I would appreciate it if you could
test it, and give some feedback on how it is working for you.
Thank you,
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
On 19.10.2008 21:49, Markus Neteler wrote:
On Fri, Oct 17, 2008 at 10:19 PM, Wolf Bergenheim
<wolf+grass@bergenheim.net> wrote:
...I'm still waiting for Hamish to check a patch for d.labels to allows
precision placement that v.label.sa. So far he has been to busy to check
it. *shrug*Wolf, could you dig out the relevant link(s) or ticket?
Maybe we can accelerate things but I don't remember details.
I was too lazy to go digging through mail archives so I filed a ticket
instead (I never filed one for this issue, so I hope it's ok). The
ticket is number 340
http://trac.osgeo.org/grass/ticket/340
I also uploaded fresh patches (against the current develbranch_6).
Thanks for taking a look 
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
2008/10/19 Wolf Bergenheim <wolf+grass@bergenheim.net>:
José María,
If possible, I think it would be useful feature the following:
- Where two labels overlap, comparing an attribute to decide which one stays
For example: on a map of cities you can use the number of inhabitants.
If the city "A" has more inhabitants than the city "B", maintaining
the label of the city "A".I have just now committed a change in v.label.sa that will do exactly
this. See the new overlap parameter. I would appreciate it if you could
test it, and give some feedback on how it is working for you.Thank you,
--Wolf
Yes, I am doing the tests right now.
It's very good for me to working with you in some way. So, thank you.
José María
--
<:3 )---- Wolf Bergenheim ----( 8:>
2008/10/19 Wolf Bergenheim <wolf+grass@bergenheim.net>:
José María,
If possible, I think it would be useful feature the following:
- Where two labels overlap, comparing an attribute to decide which one stays
For example: on a map of cities you can use the number of inhabitants.
If the city "A" has more inhabitants than the city "B", maintaining
the label of the city "A".I have just now committed a change in v.label.sa that will do exactly
this. See the new overlap parameter. I would appreciate it if you could
test it, and give some feedback on how it is working for you.
After some drawbacks to update "GRASS," I have achieved some results.
- The command d.labels does not show anything. It seems to run
normally, without error, but the active monitor does not show
anything.
- Working with the GIS Manager ", the labels are displayed well.
However, after exporting the "Display Map" to "raster" labels
disappear from the image (JPG, PPM, and others).
- I got maps with labels using "ps.map". See files attached.
labels_sa_new.pdf : show labels obtained with the command:
$ v.label.sa map=ciudades_region labels=ciudades_v_label_sa_new
column=LOCALIDAD font=arial overlap=inhab
labels.pdf : show labels obtained with the command:
$ v.label map=ciudades_region labels=ciudades_v.label column=LOCALIDAD
font=arial
The files in "$MAPSET/paint/labels" have the same number of tags. No
label is removed by "v.label.sa."
Please tell me what else I can do, or what other information I can provide it.
Thank you
José María
Thank you,
--Wolf--
<:3 )---- Wolf Bergenheim ----( 8:>
labels.pdf (12.9 KB)
labels_sa_new.pdf (12.5 KB)
On 20.10.2008 20:31, José María Michia wrote:
After some drawbacks to update "GRASS," I have achieved some results.
- The command d.labels does not show anything. It seems to run
normally, without error, but the active monitor does not show
anything.- Working with the GIS Manager ", the labels are displayed well.
However, after exporting the "Display Map" to "raster" labels
disappear from the image (JPG, PPM, and others).- I got maps with labels using "ps.map". See files attached.
labels_sa_new.pdf : show labels obtained with the command:
$ v.label.sa map=ciudades_region labels=ciudades_v_label_sa_new
column=LOCALIDAD font=arial overlap=inhab
Hmm that is really strange...
Could you send me that city map (off list), so that I can test a bit. I
did try it and it worked for me. Also caopy.paste all commands you used
to generate the maps.
Thanks for testing,
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>