Specifying nearneighbor -S, unit not understood?

[anbj]

Using nearbeighbor, -S must have a unit. Meter, -Se is default unless stated otherwise.

• In the case below I run the command with -S200 and -S200e. These command should be logically identical, right? The result is not. Specifying -S200e gives an empty grid, while -S200 gives a good grid (which is -S200e under the hood?).

Good:

$ gmt nearneighbor -: -R21897.5/727779.29/7193152.54/8271669.38 $(find . -path "*utm31*" -type f -name "*.asc" | head -n 1) -Gdelete.nc -I100 -S200 -V
nearneighbor [INFORMATION]: Cartesian input grid
nearneighbor [WARNING]: (x_max-x_min) must equal (NX + eps) * x_inc), where NX is an integer and |eps| <= 0.0001.
nearneighbor [WARNING]: (y_max-y_min) must equal (NY + eps) * y_inc), where NY is an integer and |eps| <= 0.0001.
nearneighbor (gmtapi_init_grdheader): Please select compatible -R and -I values
nearneighbor [INFORMATION]: Cartesian input grid
nearneighbor [INFORMATION]: Grid dimensions are n_columns = 7060, n_rows = 10786
nearneighbor [INFORMATION]: Number of sectors = 4, minimum number of filled sectors = 4
nearneighbor [INFORMATION]: Processing input table data
nearneighbor [INFORMATION]: Reading Data Table from file ./nh/utm31/29.asc
nearneighbor [INFORMATION]: Processed record      65520
nearneighbor [INFORMATION]: Gridded row      10786
nearneighbor [INFORMATION]: Writing grid to file delete.nc
nearneighbor [INFORMATION]: 26095 nodes were assigned an average value
nearneighbor [INFORMATION]: 1785 nodes failed sector criteria and 76121280 nodes had no neighbor points (all set to NaN)

Bad:

$ gmt nearneighbor -: -R21897.5/727779.29/7193152.54/8271669.38 $(find . -path "*utm31*" -type f -name "*.asc" | head -n 1) -Gdelete.nc -I100 -S200e -V
nearneighbor [INFORMATION]: Your distance unit (e) implies geographic data; -fg has been set.
nearneighbor [WARNING]: (x_max-x_min) must equal (NX + eps) * x_inc), where NX is an integer and |eps| <= 0.0001.
nearneighbor [WARNING]: (y_max-y_min) must equal (NY + eps) * y_inc), where NY is an integer and |eps| <= 0.0001.
nearneighbor (gmtapi_init_grdheader): Please select compatible -R and -I values
nearneighbor [INFORMATION]: Grid dimensions are n_columns = 7060, n_rows = 10786
nearneighbor [INFORMATION]: Number of sectors = 4, minimum number of filled sectors = 4
nearneighbor [INFORMATION]: Processing input table data
nearneighbor [INFORMATION]: Reading Data Table from file ./nh/utm31/29.asc
nearneighbor [INFORMATION]: Processed record          0
nearneighbor [INFORMATION]: Gridded row      10786
nearneighbor [INFORMATION]: Writing grid to file delete.nc
nearneighbor [INFORMATION]: No valid values in grid [delete.nc]               <-- no valid values
nearneighbor [INFORMATION]: 0 nodes were assigned an average value
nearneighbor [INFORMATION]: 0 nodes failed sector criteria and 76149160 nodes had no neighbor points (all set to NaN)

[Esteban82]

nearneighbor [INFORMATION]: Your distance unit (e) implies geographic data; -fg has been set.

Well, I think explains the different behavior.

[anbj]

Ok, but shouldn't this be set with both -S200e and -S200?

[Esteban82]

The first one is for geographic input data (long and lat). The second for Cartesian (X and Y).

[anbj]

Alright. Thanks Esteban.

[anbj]

Maybe the -S docs should say -Ssearch_radius[unit] to indicate that the unit is optional (relevant if your input is geographic coordinates).

I get confused since it looks like the unit is mandatory. Since my input data is in meters, I use the unit e. But since its already projected, this is wrong.

[PaulWessel]

@joaquim, thoughts?

…

On 6 February 2024 at 23:35:41, anbj ***@***.***) wrote: Maybe the -S docs should say *-Ssearch_radius[unit]* to indicate that the *unit* is optional (relevant if you’re input is geographic coordinates). — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/GenericMappingTools/gmt/issues/8350*issuecomment-1930885052__;Iw!!PvDODwlR4mBZyAb0!VjhAft7Itgfcrz5OqU80cg68sDtF2m4jJqQVUiuL_OcF1m9L2JsIW2btU_ZfaYB2CH-a1rc_1UNUWYpDrVc_NAYsaQ$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AGJ7IXYG5JGY4VPVBTAAQNLYSKV33AVCNFSM6AAAAABC3YWQJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQHA4DKMBVGI__;!!PvDODwlR4mBZyAb0!VjhAft7Itgfcrz5OqU80cg68sDtF2m4jJqQVUiuL_OcF1m9L2JsIW2btU_ZfaYB2CH-a1rc_1UNUWYpDrVcUjxSvtw$> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[joa-quim]

The issue here is that saying -Se is the default is false. That message comes from a generic text that is imported into all modules that use units. The default -S for nearneighbor is the data units, and probably converted to meters when it knows input is geogs but likely not if it doesn't know that. So, yes, a confusing situation.

[anbj]

So, yes, a confusing situation.

Appreciate you saying that.

[anbj]

• So for nearneighbor's -S, maybe we could:

  • Change -Ssearch_radius to -Ssearch_radius[unit]. Since the unit is not mandatory, after all. Might even be an error to use a unit, if the data is (already) projected.
  • Change "Append the distance unit (see [Units])." --> "Append the distance unit if input is geographical (see [Units]).", or something like that.

  Both of these to help the user understand that if the data is already projected, no unit is to be appended.

• It puzzles me that the generic Unit text says meter is [Default unless stated otherwise]. As @joa-quim stated above (and I experienced), -S200 is not at all the same as -S200e. Maybe this is special for nearneighbor.

I can do the changes if you agree.

[anbj]

#8374 deals with the docs. I’m not able to make any changes for the cli, since this involves messing with the souce code.

[joa-quim]

I've committed the C changes directly to master.

[anbj]

Thanks!