gmt spatial -Sb stray lines / cartesian only? / gap bridging / buffer scaling

[KristofKoch]

Description of the problem

See this forum post for context.

• When calculating a buffer polygon around a line with gmt spatial -Sb occasional stray lines appear. See upper left and lower right.
• Buffer in N-S direction is larger than in E-W direction. Visible in all three examples. Maybe only works for cartesian data?
• Bridges gaps instead of following both sides of line. See lower right. Negative space on the inside of upper left rectangle missing
• In the example I tried to get a 10 nautical miles (NM) wide buffer using -Sb10n but this ended far outside of 10 NM. In the example 0.05n is used. Scaling seems to be way off.

Full script that generated the error

#!/usr/bin/env bash

echo "Using GMT version: $(gmt --version)"

cat > testline1.txt << EOF
>
7.8 50.4
7.8 50.6
8.1 50.6
8.1 50.4
7.8 50.4
EOF

cat > testline2.txt << EOF
>
8   50
9.5 50.5
EOF

cat > testline3.txt << EOF
>
9   49.6
9   50
9.8 50
9.8 49.8
9.4 49.8
9.4 49.6
EOF

gmt spatial testline1.txt -Sb0.05n > testline1_buffer.txt
gmt spatial testline2.txt -Sb0.05n > testline2_buffer.txt
gmt spatial testline3.txt -Sb0.05n > testline3_buffer.txt

gmt begin buffer png
  gmt basemap -R007:30/010:00/49:30/50:50 \
    -JL008:34:13.64/50:01:59.90/49:57/50:23/15c -B
    
  gmt plot testline1.txt -W1p,green
  gmt plot testline1_buffer.txt -W1p,red

  gmt plot testline2.txt -W1p,green
  gmt plot testline2_buffer.txt -W1p,red

  gmt plot testline3.txt -W1p,green
  gmt plot testline3_buffer.txt -W1p,red
gmt end show

Actual outcome

See above

Expected outcome

Joaquim did some Mirone Magic which comes close to the expected outcome

System information

• Operating system: 5.9.16-1-MANJARO x86_64 GNU/Linux
• GMT version (gmt --version): 6.2.0_43ff8ef_2021.05.25

[joa-quim]

The stray lines come from the unites in -S. If I do -Sb0.1, there is no trash at the end.

[PaulWessel]

Please prepare a PR that states -Sb requires Cartesian data (hence no units) in the usage as well as the docs.

[KristofKoch]

More of a general question – I could make good use of -Sb working with geographic data. Do you see advantages there as well?

[joa-quim]

The error in using buffers in geogs is that the distance is not really what you asked for but the difference might be acceptable if one know what is going on.

Regarding Mirone, I tried long ago and there were problems with right-clicks callbacks but maybe it has improved meanwhile. I'm talking about using Mirone in Wine (which sounds very appealing).

[PaulWessel]

Best we could do is

#. determine region and do an equal-area projection under the hood
#. Run the code on projected data
#. Unproject on output

then your -Sb units could be honored.

[maxrjones]

@PaulWessel, do you think the path forward here is the docs update or the equal-area projection option for using -Sb with units?

[PaulWessel]

I guess maybe we could try this. Since gmtspatial is using GMT_Read_Data then you can make a wesn[] array from D->min and D->max arrays. Then set up a fake -JQ projection. then loop over all tbls, segments, rows and convert from geo to cart. At the end, do the inverse projection.

gmtselect.c has a similar section where we project all the data. Search for do_project.

[ZMAlt]

After #7623 , I get this.

[joa-quim]

Hmm, then I'm afraid we have to revert previous commit (or find a better fix).

[joa-quim]

FYI, I reverted #7623

[ZMAlt]

I think there are three different issues.

1. weird points which are related to Fix size of buffer sequence #7623
2. incorrect buffer, as follows
3. Geographic and cartesian coordinates, not considered here

May be No.1 and No.2 are related.

As to No.2, I think it is with the GEOSGetExteriorRing_r funciton that gets the outermost ring of the buffer.
https://github.com/GenericMappingTools/gmt/blob/922ac04df194dde8210568ca4add12a22219d312/src/gmtspatial.c#L2486C1-L2499C1

However, I didn't find a function in GEOS to convert POLYGON to Sequence directly.