Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#3016 closed enhancement (fixed)

Add option to set scalebar length

Reported by: annakrat Owned by: grass-dev@…
Priority: normal Milestone: 7.2.0
Component: Display Version: unspecified
Keywords: d.barscale, gsoc2016, cartography Cc:
CPU: Unspecified Platform: All

Description

Currently the scalebar automatically selects the right size. It would be nice to be able to customize the length. Also adding custom label would be useful, for example for cases when I don't want 'meters' but only 'm'.

Attachments (3)

d.barscale.diff (46.8 KB) - added by lazaa 3 years ago.
Added options length and segment to customate barscale. Added -u flag for display unit symbol/name.
d.barscale.2.diff (47.2 KB) - added by lazaa 3 years ago.
Updated patch with flag -n to display small north-arrow symbol next to barscale.
d.barscale3.diff (15.9 KB) - added by lazaa 3 years ago.
Added option units

Download all attachments as: .zip

Change History (13)

comment:1 Changed 4 years ago by wenzeslaus

Version: unspecified

I think the size should be specified in map units, for example user can say size=250 to get 250m scale bar. This seems like a simple and actually a desired option. What are the units there probably depend on the rest of the implementation or interface of d.barscale. With the current implementation it would be probably meters by default but it should be feet when the -f is used.

Changed 3 years ago by lazaa

Attachment: d.barscale.diff added

Added options length and segment to customate barscale. Added -u flag for display unit symbol/name.

comment:2 in reply to:  1 ; Changed 3 years ago by lazaa

Replying to wenzeslaus:

I think the size should be specified in map units, for example user can say size=250 to get 250m scale bar. This seems like a simple and actually a desired option. What are the units there probably depend on the rest of the implementation or interface of d.barscale. With the current implementation it would be probably meters by default but it should be feet when the -f is used.

I added optionlength, so the size can be specified in map units. By defaults in meters, with -f flag in feet. I'm not sure it's the best solution. If user wants a barscale of size let's say 150 miles he has to convert 150 miles into feet.

Changed 3 years ago by lazaa

Attachment: d.barscale.2.diff added

Updated patch with flag -n to display small north-arrow symbol next to barscale.

comment:3 in reply to:  2 ; Changed 3 years ago by annakrat

Replying to lazaa:

Replying to wenzeslaus:

I think the size should be specified in map units, for example user can say size=250 to get 250m scale bar. This seems like a simple and actually a desired option. What are the units there probably depend on the rest of the implementation or interface of d.barscale. With the current implementation it would be probably meters by default but it should be feet when the -f is used.

I added optionlength, so the size can be specified in map units. By defaults in meters, with -f flag in feet. I'm not sure it's the best solution. If user wants a barscale of size let's say 150 miles he has to convert 150 miles into feet.

I was thinking it would be good to add new option units with options meters, kilometers, feet and miles instead of the flag -f. This flag would have to stay there for compatibility reasons but would be marked obsolete. By default it would use map units, see m.measure for example.

Also having option to set custom label (overriding the unit) would enable working in XY location with mm for example. I think it would bring more flexibility comparing to the -u flag, so users could choose whether they want 'meters' (current default) or 'm' or name of the units in other languages.

comment:4 Changed 3 years ago by mlennert

All of Adam's patches concerning d.barscale give a lot of fails when trying to apply them to trunk. Maybe this is linked to the recent running of the indent script on the version in trunk ?

comment:5 in reply to:  4 Changed 3 years ago by annakrat

Replying to mlennert:

All of Adam's patches concerning d.barscale give a lot of fails when trying to apply them to trunk. Maybe this is linked to the recent running of the indent script on the version in trunk ?

I think so. He used indent script on his working copy, so he has a lot of whitespace changes. So I decided to commit the whitespace changes separately. Adam should upload the new patches just with the real code changes. I am not sure what's the best way to get rid of whitespace changes in a patch for now, probably apply it to older version of the file and create a new diff without whitespace or use meld.

comment:6 in reply to:  3 Changed 3 years ago by lazaa

Replying to annakrat:

Replying to lazaa:

Replying to wenzeslaus:

I think the size should be specified in map units, for example user can say size=250 to get 250m scale bar. This seems like a simple and actually a desired option. What are the units there probably depend on the rest of the implementation or interface of d.barscale. With the current implementation it would be probably meters by default but it should be feet when the -f is used.

I added optionlength, so the size can be specified in map units. By defaults in meters, with -f flag in feet. I'm not sure it's the best solution. If user wants a barscale of size let's say 150 miles he has to convert 150 miles into feet.

I was thinking it would be good to add new option units with options meters, kilometers, feet and miles instead of the flag -f. This flag would have to stay there for compatibility reasons but would be marked obsolete. By default it would use map units, see m.measure for example.

Why the flag -f would have to stay? If I add option units it's not necessary anymore, is it?

Also having option to set custom label (overriding the unit) would enable working in XY location with mm for example. I think it would bring more flexibility comparing to the -u flag, so users could choose whether they want 'meters' (current default) or 'm' or name of the units in other languages.

comment:7 Changed 3 years ago by neteler

Copied here from ML due to trac problems:

On Wed, Jun 1, 2016 at 6:29 PM, Anna Petrášová wrote:

The flag should stay there (and work as before) to keep backwards compatibility until grass 8 is released. If you remove it, some user scripts will break.

Changed 3 years ago by lazaa

Attachment: d.barscale3.diff added

Added option units

comment:8 Changed 3 years ago by annakrat

Committed in r68570 with small modifications.

Known issue is that when using -f, label is ignored.

Testing is very welcome.

comment:9 Changed 3 years ago by annakrat

Resolution: fixed
Status: newclosed

Backported in r69051.

comment:10 Changed 3 years ago by annakrat

Milestone: 7.3.07.2.0
Note: See TracTickets for help on using tickets.