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 .
This may work. Have your data in a fie with
.xyz extension and then do (need GMT.jl)
G = grdconvert("/path/to/yourfile.xyz");
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
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
It did precompile, right? GMT.jl is working (well installed)
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
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 libpng220.127.116.11.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.
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
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)
you should see (or not, it it errors) the equivalent of
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)
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
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.
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
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.
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
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?