[GRASS-dev] [GRASS GIS] #1942: v.label.sa not working with areas
GRASS GIS
trac at osgeo.org
Tue Apr 23 08:06:33 PDT 2013
#1942: v.label.sa not working with areas
-------------------------+--------------------------------------------------
Reporter: richardc | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 6.4.4
Component: Vector | Version: 6.4.3 RCs
Keywords: v.label.sa | Platform: Linux
Cpu: x86-32 |
-------------------------+--------------------------------------------------
Comment(by mlennert):
Replying to [comment:4 wolf]:
> Oh I'm so happy to someone working on v.label.sa. I didn't really
implement it for areas yet, but now that I see someone is looking for that
feature I'm more than happy to work on it. Assigning this to me. I can't
promise a time, but I'm definitely going to work on this!
As mentioned my comment reproduced in the original report, I don't think
this is much work, as areas can be considered as their centroids and so it
becomes a placement of labels for points. Unless you want to optimise in
terms of size of areas, etc. I would suggest to implement a simple
solution at first in just replacing GV_AREA by GV_CENTROID. You can then
always optimize specifically for areas later.
AFAICT, the problem now is that in labels.c you have
{{{
legal_types = Vect_option_to_types(p->type)
}}}
which results in legal_types = GV_AREA if area is chosen, but further on
{{{
label_sz = Vect_get_num_primitives(&Map, legal_types);
}}}
but Vect_get_num_primitives() does not allow for GV_AREA.
So probably just replacing GV_AREA by GV_CENTROID in legal_types before
calling Vect_get_num_primitives should work (but this is just after a very
superficial look...).
The other, easier, solution is to replace area by centroid in the possible
answers to the type option.
Moritz
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1942#comment:8>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list