Skip to content

Proposal for more consistency for scaling vectors and shrinking attributes #6190

@PaulWessel

Description

@PaulWessel

Description of the desired feature

We still seem to have some inconsistencies when it comes to vector scaling (converting user vector magnitude to plot length) and attribute shrinking (reduce head size and stem pen width when vectors are smaller than a limit)

Scaling issues:

  • Cartesian vectors plotted by plot are expected with direction and length (in plot units, say cm) in columns 3 and 4. However, if you prefer to give components dx, dy instead then these are scaled by +zscale and combined with hypot. So while I can then give dx and dy in some random user unit (say mm/yr) and use scale to convert that to reasonable component lengths in inches, I cannot give the polar form in anything but final plot units. This is inconsistent (same is true in plot3). In contrast, for grdvector the vectors are of course expected to be in user units in both polar and component forms, and they are scaled via the information in -S to get them into plot lengths. This makes sense, and the same is true in velo.
  • Geovectors are special great-circle vectors whose lengths are given in map distances (e.g., km or spherical degrees). In plot and plot3 the input is expected to be azimuth and length (in any map distance unit). The +z modifier does not apply to geovectors. In grdvector, one can create geovectors from user data by selecting a suitable scale in -S. This converts user unit magnitudes to map distances, then plots the geovector. This cannot be done in plot or plot3, but in velo, so a bit inconsistent.

Shrinking issues:

  • Cartesian vectors can shrink if their lengths are below a threshold. That threshold is currently in plot units (e.g., 0.5i, 1c, 24p) and if the plot length is shorter we compute a shrink scale as s = length/limit, but also prevent s from being smaller than a user-selectable threshold [0.25]. If my input data are in mm/yr then I am out of luck to specify a limit in mm/yr and I would have to work out via the plot scale what such a limit would be in cm or points.
  • In contrast, geovectors have their attributes shrunk in a similar way but the length here is the geographic map length (e.g., in km). Since the plot length of these vectors vary with projection and view point it makes no sense to use a plot-length limit, hence the limit is in map lengths. Yet, if my data in grdvector are in mm/yr and I wanted a shrink limit in those units I am out of luck again.

Proposals:

  1. Offer a way, like +zscale, to accept polar form direction, length input, with length in data units to be scaled to plot units. A possible modifier is +vscale for "scale vector data length to plot length". Append a unit from c|i|p to indicate the unit of the product.
  2. Allow the shrinking limit to be given in data units or plot units. Follow the lead of plot -Sb and use unit u to indicate data units (since no unit would mean cm and hence a plot unit for Cartesian vectors and km as map unit for geovectors).
  3. Allow +z in plot and plot3 to accept components for a geovector and have them scaled to map distances. Properly compute what azimuth and length this corresponds to and plot the geovector accordingly. Should be possible to plot a vector given by components in, say, km along the parallel and meridian.
  4. Disable (or give error) +z in grdvector since here we control polar vs component via -A.
  5. If geovectors are plotted in grdvector, allow shrink limit to be given either in map length (current choice) or data length (new). Here we have a problem in that unit u means "survey foot" and another letter is needed. Perhaps l for length?
  6. Ensure that any use of vector modifiers that cannot apply in a particular module result in errors.
  7. Accept a default scale of 1 if +z has no argument (currently this would give junk).

Let me know if I am missing anything and if you are OK with this proposal, @GenericMappingTools/gmt-team.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions