# Xyz2grd no longer attaching longitude and latitude **URL:** \ **Category:** Q&A\ **Created:** [October 17, 2022, 8:16pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359 "2022-10-17T20:16:26Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![hila](https://avatars.discourse-cdn.com/v4/letter/h/c6cbf5/32.png) [@hila](https://forum.generic-mapping-tools.org/u/hila)\ **Post date:** [October 17, 2022, 8:16pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359/1 "2022-10-17T20:16:26Z")
Hi all, I am using xyz2grd to grid text files of remote sensing data, where the first two columns are longitude and latitude, and following columns contain different variables. I’m using code that has previously worked just fine, but suddenly the latitude and longitude info is being lost and I can’t plot it as a netcdf4 anymore. There are ‘x’ and ‘y’ fields in the variable attributes (where there used to be ‘lon’ and ‘lat’) and as a result the images now plot in netCDF viewing programs upside down. Comparing “old” and “new” files the new ones no longer say they follow the COARDS convention. The GMT version is `6.3.0`. I’m using Ubuntu `22.04` Example code: `input=A202106616162500.L2_SWIR_v3` `gmt xyz2grd ${input}.asc -i,0,1,4 -G${input}.grd -I300e -R/-68.8/-63.1/43.1/46.2 -V` So far I have reinstalled GMT but am thinking maybe the issue stems from dependencies (e.g. versions of HDF5 or Netcdf) or my GMT setup. Figured I would post here as I’m not making headway. The input file (as a .txt) is attached as well as some .pngs of the Metadata. Thanks, -Andrea [A2021066162500.L2\_SWIR\_v3.txt](https://forum.generic-mapping-tools.org/uploads/short-url/pj9pDlV1XLOGUR5Srx5ihsXldCZ.txt) (5.3 KB) ![Global_Attributes](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/1/1173f58786ce2d056e6aa5ac80d7db5785dc0d99.png) ![Variable_Attributes](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/2/213c578e7caff4c2880943b84a9c598ccbb390fa.png) ---
**Author:** ![Joaquim](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/joaquim/32/16_2.png) [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)\ **Post date:** [October 17, 2022, 9:58pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359/2 "2022-10-17T21:58:27Z")
> [@hila](#): > > -i,0,1,4 This should be `-i0,1,4` but that’s not the soucre of the problem. The source is, the code is the same but the data is not. You have `-I300e`, that is an increment of 300 meters but your data points seem to have a separation of ~1 km. And note `xyz2grd` is **NOT** a _gridder_. It does not _grid text files_. What it does is to reformat it and assumes data is already gridded, which I don’t know if it’s really the case. ---
**Author:** ![hila](https://avatars.discourse-cdn.com/v4/letter/h/c6cbf5/32.png) [@hila](https://forum.generic-mapping-tools.org/u/hila)\ **Post date:** [October 20, 2022, 4:27pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359/3 "2022-10-20T16:27:26Z")
Hey Joaquim, Thanks for your response. I’ll update `-i0,1,4`. I had grabbed a random file small enough to share here but removed NA pixels - turns out the remaining pixels were separated at ~ 1km like you mention. Part of another image with better coverage is attached. [A2021280172500.L2\_SWIR\_v3.txt](https://forum.generic-mapping-tools.org/uploads/short-url/bqQZe9BN990q8j7DIkVJvHXTDqF.txt) (420 KB) A bit of background getting to your second point - these are satellite images processed at approximately 250 m per pixel resolution, which I have been removing NA data and writing out to text file then applying xyz2grd to assign them to a 300m grid. Some have very little data or have gaps between pixels with available data (at swath edge, like in the one I originally shared). > And note `xyz2grd` is **NOT** a _gridder_ . It does not _grid text files_ . What it does is to reformat it and assumes data is already gridded, which I don’t know if it’s really the case. Sorry I am a bit confused by this statement. Do you mean that xyz2grd is not appropriate for, for example, point data collected with a GPS (e.g. not regular)? Or do you mean that text files created from gridded data, like in my case, aren’t appropriate for “re-gridding” to 300 m? Thanks ---
**Author:** ![Joaquim](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/joaquim/32/16_2.png) [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)\ **Post date:** [October 20, 2022, 4:49pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359/4 "2022-10-20T16:49:37Z")
> [@hila](#): > > Sorry I am a bit confused by this statement. Do you mean that xyz2grd is not appropriate for, for example, point data collected with a GPS (e.g. not regular)? Yes, that’s precisely the point. `xyz2grd` is **NOT** appropriate for that. See the introduction of its man page > **xyz2grd** reads one or more _x, y, z_ or _z_ tables and creates a binary grid file. **xyz2grd** will report if some of the nodes are not filled in with data. Such unconstrained nodes are set to a value specified by the user [Default is NaN]. Nodes with more than one value will be set to the mean value. As an option (using [**-Z**](https://docs.generic-mapping-tools.org/dev/xyz2grd.html#z)), a 1-column _z_ table may be read assuming all nodes are present (_z_ tables can be organized in a number of formats, see [**-Z**](https://docs.generic-mapping-tools.org/dev/xyz2grd.html#z) below.) **Note** : **xyz2grd** does not grid the data, it simply reformats existing data to a grid structure. For gridding, see [surface](https://docs.generic-mapping-tools.org/dev/surface.html), [greenspline](https://docs.generic-mapping-tools.org/dev/greenspline.html), [nearneighbor](https://docs.generic-mapping-tools.org/dev/nearneighbor.html), or [triangulate](https://docs.generic-mapping-tools.org/dev/triangulate.html). What you want in your case is probably `nearneighbor` On a more different (but much more _friendly_) option, see [Aqua SST · RemoteS.jl](https://www.generic-mapping-tools.org/RemoteS.jl/dev/gallery/Aqua_sst/remotes_L2_SST/) ---
**Author:** ![hila](https://avatars.discourse-cdn.com/v4/letter/h/c6cbf5/32.png) [@hila](https://forum.generic-mapping-tools.org/u/hila)\ **Post date:** [October 20, 2022, 5:04pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359/5 "2022-10-20T17:04:20Z")
Thanks for confirming. There is something going wrong with this function for me still, as the issue persists when using other old code and old data that I successfully gridded. The geolocation is getting lost, though the latitude and longitude are still there as attributes. Current: ![image](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/b/b15b0cd8dc4ee5db250d1fce34b1c691da21b44d.png) Previous: ![image](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/2X/1/1c10ddf51aafe84ba7335c8122f4bba6bf42f166.png) ---
**Author:** ![Joaquim](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/joaquim/32/16_2.png) [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)\ **Post date:** [October 20, 2022, 5:11pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359/6 "2022-10-20T17:11:36Z")
Don’t remember what GMT5 did but you must use **-fg** to tell that data is in geographical coords. ---
**Author:** ![hila](https://avatars.discourse-cdn.com/v4/letter/h/c6cbf5/32.png) [@hila](https://forum.generic-mapping-tools.org/u/hila)\ **Post date:** [October 20, 2022, 5:55pm UTC](https://forum.generic-mapping-tools.org/t/xyz2grd-no-longer-attaching-longitude-and-latitude/3359/7 "2022-10-20T17:55:51Z")
Thank you! At least now I know how to make this work with geographic data again! I did not find this in the changelog so didn’t realize the difference with `-fg` between versions 5 and 6.