Hello Community!
I have data like so
where I would like to visualise a heatmap of the TimeDiff_mean column and the other two columns (representing a reticulation over geographical datapoints).
I have sought for one or another utility function that may help me quickly do this without avail and though all the information is there pretty explicitly my brain is now saturated and my custom attempts have failed me 
.
Thank you!
This may work. Have your data in a fie with .xyz extension and then do (need GMT.jl)
using GMT
G = grdconvert("/path/to/yourfile.xyz");
imshow(G)
OMG! Homebrew installing it nowā¦ This looks very impressive and should prove very helpful for what I am looking to do!
Iāve downloaded GMT and necessary dependencies, added the julia wrapper via
Pkg.add GMT
using GMT
but it canāt find grdconvert. Iāve also tried prefixing GMT.grdconvert Whatās going on?
Iām not in front of a computer right now so canāt confirm if missed porting the grdconvert module. When you did the first
using GMT
It did precompile, right? GMT.jl is working (well installed)
Try this
G = gmt(āgrdconvert yourfile.xyzā)
There other options to do this, but this would be the simplest for your case.
Yes, seemingly it did precompile just fine but it now throws an error when using: during initialization of module Gdal it turns out it could not load ~.julia/conda/3/lib/libgdal.30.dylib The reason: Incompatible library version: libgdal.30.dylib requires version 54.0.0 or later, but libpng16.16.37.0.dylib provides version 16.0.0 So Iāve uped my package environment and reloaded everything anew but no cigar.
Thatās getting complicated. So you installed GMT with brew and next did a ] add GMT (the equivalent with Pkg). In this case the brew installed version should have been detected and no automatic (via conda) installation should occur. But your error message makes think it was ~.julia/conda/3/lib/libgdal.30.dylib or then some previous GDALlib was already there. Try to just unlink the brew GMT installation and try again to see the automatic one set correctly.
Regarding my recipe, it works fine. What happened is the grdconvert module seem to me that had no interest in the wrapper (it converts between grid formats of disk files) but it turns out that itās very handy for this case where a GDAL function will guess the grid parameters when parsing the text file. Iāll add a wrapper to it but meanwhile this worked fine for me.
using GMT
G = GMT.peaks(); # Create one grid
D = grd2xyz(G); # Convert to x,y,z
gmtwrite(D, "lixo.xyz") # Save it as disk file
G2 = gmt("grdconvert lixo.xyz"); # Load it
imshow(G2) # and display
Iāve unlinked, removed GMT from my package environment, linked back, added the GMT.jl back inā¦ same error. Iāve disabled the PyCalls via conda (I believe) I was making and removed it from my environment as well but nothingās changed.
I will say that if I evaluate using GMT a second time it wonāt complain and will instantiate a peaks() grid but when I call grd2xyz() on it, then the same error happens again. Iām out of ideas but for a clean installationā¦
It still seems to me that it is homebrew that has screwed (it does it many times). To check that try this on a shell (no Julia involved)
grdinfo @earth_relief_20m
you should see (or not, it it errors) the equivalent of
grdinfo @earth_relief_20m
c:/j/.gmt/server/earth/earth_relief/earth_relief_20m_p.grd: Title: SRTM15 Earth Relief at 20 arc minutes
c:/j/.gmt/server/earth/earth_relief/earth_relief_20m_p.grd: Command: grdfilter SRTM15_V2.4.nc -Fg37.1 -D1 -I20m -rp -Gearth/earth_relief/earth_relief_20m_p.grd=ns+s0.5+o0 --IO_NC4_DEFLATION_LEVEL=9 --IO_NC4_CHUNK_SIZE=4096 --PROJ_ELLIPSOID=Sphere
...
otherwise what I would try is to follow the leads of
otool -L ~.julia/conda/3/lib/libgdal.30.dylib
and/or those of the output of this shell cmd (if the shell command above didnāt error)
gmt --show-library
A clean installation of gmt via homebrew and from .julia/packages/GMT has got me over that hurdle! I think maybe the problem was that I first added the julia wrapper and then gmt as such?
Anyways, I now get an GMT error number = 79 when calling gmt("grdconvert ~/Desktop/sample.xyz")which I saw from your previous post that it has to do with ghostscript so will unlink and try againā¦
Yeap, that will end up with two GT installations and dependency hells are easy.
What was the full error? That command does not produce any figure so ghostscript errors should not occur. But yes, if you ae using the homebrew install youāll need to install ghostscript as well.
My shell doesnāt know grdinfo.
otool output is @rpath/libgdal.30.dylib (compatibility version 31.0.0, current version 31.2.0)
I did install ghostscript I think I had it installed previously by LaTeX or something, but I did re-run the brew command
Sorry, my Windows habits. It should have been
gmt grdinfo ...
otool -L prints lots of lines and the dependency conflicts use to be shown in one of those lines. As I said, this is debugging info that just tell us where the conflicts are comming from. Not how to solve them.
I get no errors here!
Oki, there were others but the first and closest match was the one I reported
So, hereās where Iām at:
I load in data and packages -all good
Then I use CSV.write to save a sample of my data to with an xyz extension
Then when I call G = gmt("grdconvert ~/Desktop/sample.xyz") I get ERROR 4: "~/Desktop/sample.xyz" not recognized as a supported file format. grdconvert (GMT_grdconvert): Not a supported grid format [~/Desktop/sample.xyz] ERROR: Something went wrong when calling the module. GMT error number = 79
Ok, maybe we can continue this on GMT.jl issue. No need to bother others with this issue.
But the ERROR 4: "~/Desktop/sample.xyz" not recognized as a supported file format. is a GDAL error message and it means it could not deal with your sample.xyz file.
Does my synthetic example above (the one that ended with a figure) work for you?
EDIT: ā¦ or preferably on the GMT forum.
It is beautiful!
Sorry for not responding right away but since this is my first post the website disallowed further comments for 24 hours.
What should I do though? Is the workflow above correct, as far as it goes?