Lately, I’ve been trying to select data points falling into specific shape (.shp) files. I’m not getting any data points returned that fall inside the shape file. Is this a valid gmt command?
The tm.bin file has relative time in col 0, longitude in col 7 and latitude in col 6. I’ll attach these two files, maybe someone can test. I’ll check back, later, as I’m about to head overseas. jwr_bin_shape.zip (245.4 KB)
I understand that the -F file is supposed to be in ASCII, but I had hoped that gmtselect -F would do the hidden GDAL conversion of a shape file, as needed. This shape file has separate sub-shapes on either side of the 180° line. No sub-shape crosses the line, but runs along it. But maybe that is the deal-breaker, in this case.
I’m finding that dumping the shape file to an ASCII file, via gmtconvert, then feeding that into -F still seems to have troubles, with the dump multiple “holes” and perimeters.
When I manually extract the specific perimeter needed, from the ASCII file, save it as a new data set, and use that as my -F file, gmtselect gives expected results, even with a section of the boundary on the 180° line.
Is it that gmtselect can’t be fed a shape file in -F? Or is it that this shape file has sub shapes on either side of the 180° line? Thanks for taking time to investigate this with me!
I don’t know the implementation of GMT, but I assume that if it specifies an ASCII text file that it means a file in the GMT multiple-point text format. I would not expect it to do a magical conversion of a shapefile with GDAL. A shapefile is not a single file but a set of at least three files, I think, so only the “.shp” file is not sufficient information for GDAL or any other program to convert it to another format. I am not an expert on shapefiles, but the usual set includes “.shp”, “.shx”, “.dbf”, and “.prj”.
I don’t know why the GMT text polygons you got from the “gmtconvert” command did not work.
I think GMT should be able to do the conversion under the hood, with a call to ogr2ogr.
You could convert yourself and see if the file looks as expected?
$ ogr2ogr <outfile> <infile>
Have you considered doing this in e.g. qgis? Might be easier, and quicker. This assumes that this isn’t part of an automated script or anything like that.
You can do many things with the data (in addition to converting from shp to gmt) with the ogr2ogr command, including spatial queries.
John only shared the *.shp file. As Eric points out, more files are needed, e.g. via ogr2ogr messages
Unable to open t.shx or t.SHX
“Shapefiles is a fantastic product” says the man time-shifted from early 1990. It is so much better to have an unknown number of co-files written in a DBASEIII mix binary format that to, say, have a netCDF-based single file. Ah, but you zip them up so you have that extra process to deal with. Silly, I say. But what do I know. Not much.
Many of the software packages we use in industry (even the ones with a 2020 or younger release) still have shapefiles as the only (!) export/exchange option for geospatial vector data that works directly with GIS.
But, hey, you can set up a whole team to build an AI-powered solution to reconstruct those cryptic truncated 12-character column names and the other information you lost in the format translation and label that as “data mining”. There’s clearly no reason to use modern, open and standardised formats.
Barely. The data storage section of the article is more than enough to disagree.
Anyhow, you might have your own reasons to like it. I just avoid it when I can because other formats seem, at least to me, more suited and more convenient. That being said, I have the luxury to do so… OP doesn’t right now
