As far as I understand, there is no mechanism for optimal label
placement when labels overlay partially to each other.
I think it is an important feature. Are there any work-arounds within
grass (except of exporting to lets say SVG and play around with a vector
graphics program)? Or any plans to develop such a feature?
Thank you,
Nikos
On 19.06.2008 00:40, Nikos Alexandris wrote:
As far as I understand, there is no mechanism for optimal label
placement when labels overlay partially to each other.
There is an experimental module v.label.sa, available in the svn. It is ready but I'm still waiting on word for patches to ps.map and d.label from Hamish. v.label.sa uses a simulated annealing method of finding an optimal label placement.
It supports point and line features. I'm working on adding support for areas
It is not built by default, but if you want to give it a try I'll gladly help more.
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
On Thu, 2008-06-19 at 01:40 +0300, Wolf Bergenheim wrote:
On 19.06.2008 00:40, Nikos Alexandris wrote:
> As far as I understand, there is no mechanism for optimal label
> placement when labels overlay partially to each other.There is an experimental module v.label.sa, available in the svn. It is
ready but I'm still waiting on word for patches to ps.map and d.label
from Hamish. v.label.sa uses a simulated annealing method of finding an
optimal label placement.
It supports point and line features. I'm working on adding support for areasIt is not built by default, but if you want to give it a try I'll gladly
help more.--Wolf
Thank you Markus and Wolf. I did not think to search in
grass-source/vector directory. It also makes sense now why it's not
compiled by default.
I am fighting to get something on the screen. I have the impression that
it works but I can't find the proper size (in metres)?
Would this be considered as an extra feature? Estimating a default size?
Excuse my ignorance if this is something extremely difficult or
impossible.
Nikos
On 19.06.2008 01:44, Nikos Alexandris wrote:
I am fighting to get something on the screen. I have the impression that
it works but I can't find the proper size (in metres)?Would this be considered as an extra feature? Estimating a default size?
Excuse my ignorance if this is something extremely difficult or
impossible.
It is a legitimate request 
I'll look into getting it to calculate some sane default value. Also note that I've had some problems getting gis.m to display the label files produced by v.label.sa, as they are very precise in both size and placement.
Use the v.distance or the gis.m measurement tool to measure a distance that you find to be approximately the height of letters, and give this distance to v.label.sa
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
Nikos:
I am fighting to get something on the screen. I have the
impression that it works but I can't find the proper size
(in metres)?
I am not sure if v.label.la supports this, but with v.labels you can do fontsize= and then a standard size is used for all, not based on map units.
the idea with map unit sized labels is that street names go away when you zoom out far enough, etc.
beware that the curl words flag sets each letter as its own geocoord label, and so will look funny if you change the zoom from the one it was generated for.
Hamish
On Wed, 2008-06-18 at 20:58 -0700, Hamish wrote:
Nikos:
> I am fighting to get something on the screen. I have the
> impression that it works but I can't find the proper size
> (in metres)?
I am not sure if v.label.la supports this, but with v.labels you can do fontsize= and then a standard size is used for all, not based on map units.
the idea with map unit sized labels is that street names go away when you zoom out far enough, etc.
beware that the curl words flag sets each letter as its own geocoord label, and so will look funny if you change the zoom from the one it was generated for.
Hamish
I can't get a "proper" size for v.label.sa in a wgs84 location. I tried
measuring but... (well, in the beginning I thought I was in a metric
location and was trying numbers around 10000! No wonder that it didn't
work;-)
So it's something like the scale dependent rendering (?)
Anyhow, I think having some auto-estimation of viewable fonts in
v.label.sa would be a starter value from which one can increase/decrease
the font size in order to get the desired font size.
Nikos:
As far as I understand, there is no mechanism for optimal
label placement when labels overlay partially to each other.I think it is an important feature. Are there any work-arounds
within grass [...] ?
possible work around if v.label.sa doesn't solve it for you:
use regular v.label and then shift overlapping labels by hand.
the $MAPSET/paint/labels/$NAME is an easy text file to edit, just adjust xoffset and yoffset + or - some integer for the problematic label.
for d.labels the offset value is in pixels, for ps.map it is in points (1/72").
d.labels + edit/save + d.redraw makes this go quickly.
once we resolve issues it is my goal that v.label.sa becomes a flag of v.label instead of another module. that way the features won't get out of sync as they are now. (e.g. fixed fontsize=)
Sorry for the d.labels/ps.map ref="none" patch delay Wolf.. ASAP
Hamish
On 19.06.2008 13:55, Nikos Alexandris wrote:
I can't get a "proper" size for v.label.sa in a wgs84 location. I tried
measuring but... (well, in the beginning I thought I was in a metric
location and was trying numbers around 10000! No wonder that it didn't
work;-)
heh. Come to think of I haven't tried v.label.sa in lat-long location. I'll look into it. Thanks for the feedback.
So it's something like the scale dependent rendering (?)
Anyhow, I think having some auto-estimation of viewable fonts in
v.label.sa would be a starter value from which one can increase/decrease
the font size in order to get the desired font size.
I will try to come up with something, but the tricky part is that it will require a monitor to be open to get the resolution, so that I can calculate a nice visible size for the font. I'll see what I can do.
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
On 19.06.2008 15:24, Hamish wrote:
once we resolve issues it is my goal that v.label.sa becomes a flag
of v.label instead of another module. that way the features won't get
out of sync as they are now. (e.g. fixed fontsize=)
The problem is that v.label.sa needs to always use map sizes or then convert the shape points into display coordinates, since it needs to calculate things like label overlap with features etc.
For now I haven't wanted to muck around with monitors (they are about to change anyway), which I believe is the only way to calculate a point size into a map units size.
Sorry for the d.labels/ps.map ref="none" patch delay Wolf.. ASAP
No problems I've been busy myself.
--wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
Just reporting...
v.labels.sa works fine on a "metric" projection. Yet, I don't understand
how the "isize=" parameter affects the location of the labels.
Sometimes labels are placed over the "x" points (point "icons" which
represent for example my climatic stations).
Greetings,
Nikos