Opened 7 years ago

Last modified 7 months ago

#1942 new enhancement

v.label.sa not working with areas

Reported by: richardc Owned by: grass-dev@…
Priority: normal Milestone:
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 (14)

comment:1 Changed 7 years ago by hamish

Cc: wolf added
Keywords: v.label.sa added
Milestone: 6.4.36.4.4

comment:2 in reply to:  1 Changed 7 years ago by mlennert

Replying to hamish:

milestone changed from 6.4.3 to 6.4.4

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

comment:3 Changed 7 years ago by hamish

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

comment:4 Changed 7 years ago by wolf

Owner: changed from grass-dev@… to wolf
Status: newassigned
Type: defectenhancement

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 Changed 7 years ago by wolf

Owner: changed from wolf to grass-dev@…
Status: assignednew

comment:6 Changed 7 years ago by hamish

Cc: grass-dev@… added; wolf removed

comment:7 Changed 7 years ago by hamish

Cc: wolf added

comment:8 in reply to:  4 ; Changed 7 years ago by mlennert

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 in reply to:  8 Changed 7 years ago by wolf

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 Changed 6 years ago by neteler

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 Changed 4 years ago by neteler

Milestone: 6.4.46.4.6

comment:12 Changed 3 years ago by neteler

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 Changed 3 years ago by neteler

Component: VectorAddons

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:14 Changed 7 months ago by martinl

Milestone: 6.4.6

Remove Milestone from Addons bugreports.

Note: See TracTickets for help on using tickets.