Opened 12 years ago
Last modified 5 years ago
#1942 new enhancement
v.label.sa not working with areas
Reported by: | richardc | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.8.3 |
Component: | Addons | Version: | 6.4.3 RCs |
Keywords: | v.label.sa | Cc: | wolf, grass-dev@… |
CPU: | x86-32 | Platform: | Linux |
Description
Ref: http://osgeo-org.1560.x6.nabble.com/v-label-sa-not-working-with-areas-td5048543.html
RichardC wrote:
v.label.sa does not work with areas. On running the following I get an empty labels file.
v.label.sa --verbose map=hydrobasins_africa@hydrolayers type=area column=MAJ_NAME labels=africa_basins_sa font=Trebuchet_MS size=0.5 color=red
However, it works with lines - I can output a labels file if the layer comprises line features.
_ I just tested with census_wake2000 from the NC demo dataset and can confirm the issue.
The problem seems to be with the type 'area' which is not recognised somewhere along the process. Adding the option 'centroid' to the 'type' parameter and using that option makes it create the expected labels.
I'm not sure which would be the better solution:
- Leave the options as is and change the code so that 'area' is remapped
to 'centroid'
- Change the options from area to centroid.
Moritz
Change History (15)
follow-up: 2 comment:1 by , 12 years ago
Cc: | added |
---|---|
Keywords: | v.label.sa added |
Milestone: | 6.4.3 → 6.4.4 |
comment:2 by , 12 years ago
comment:3 by , 12 years ago
the milestone is just an indicator, not policy. it only really needs to be correct when the ticket is closed, since then it gets auto-added to the "changes since last version" trac-wiki page. FWIW my logic was that at this point we should be focusing our energy on the last few major bugs for 6.4.3, the minor stuff can happen later. If someone provides a fix before then, no problem. As for backporting to relbr64, as long as there's time to test it properly. Any commit to that branch in the last moments before release is going to be risky..
shrug, it'll be fixed when it's fixed, Hamish
follow-up: 8 comment:4 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Type: | defect → enhancement |
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!
--Wolf
comment:5 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:6 by , 12 years ago
Cc: | added; removed |
---|
comment:7 by , 12 years ago
Cc: | added |
---|
follow-up: 9 comment:8 by , 12 years ago
Replying to 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
comment:9 by , 12 years ago
Thanks for the analysis. :)
This sounds like a good, quick, interim solution, I'll have a look at it. And Indeed later I'd like to extend this to deal with areas in a more intelligent way.
comment:10 by , 12 years ago
BTW, I tried to compile v.label.sa in GRASS 7 but it fails due
labels.c:86:5: warning: implicit declaration of function ‘find_font_from_freetypecap’ ... labels.c:98:5: warning: implicit declaration of function ‘free_fontcap’
due to this changeset: r34923
comment:11 by , 9 years ago
Milestone: | 6.4.4 → 6.4.6 |
---|
comment:12 by , 8 years ago
Since v.label.sa does not compile. I suggest to move it from core to Addons.
If there aren't any objections, I'll do that for relbranch72 and trunk.
comment:13 by , 8 years ago
Component: | Vector → Addons |
---|
For the record:
moved from trunk (r68783) and relbranch72 (r68784) to Addons: https://svn.osgeo.org/grass/grass-addons/grass7/vector/v.label.sa/
The code is broken since r34923.
comment:15 by , 5 years ago
Milestone: | → 7.8.3 |
---|
Replying to hamish:
In my eyes this is a bug. Shouldn't we try to get the fix into 6.4.3 ?
Doesn't seem too invasive to me.
Moritz