WIP Try to fix grdgdal access via MEX

[joa-quim]

Something is breaking the MEX interface. Even with the changes in this branch the NN algo works once but next time I try to open a file via GDAL it errors. Apparently via Julia things work fine.

[PaulWessel]

You should not have to do anything special here but call GMT_Read_Data. It will figure out if you are passing it a GMTAPI tag. The object[0] most certainly will cause trouble since you do not know it is 0. It may be 6, or 3, or 44. So don't get into the weeds like that. GMT_Read_Data does its own GMT_Init and Begin and End IO so no need to have those either.

[joa-quim]

If I do the part in the #if 0 it works from Matlab, but only once. That's the shit I don't get.

[PaulWessel]

Your fatal error is object[0]. You are making an assumption that is 100% incorrect.

[joa-quim]

But that it's in this branch. On master I have not the GMT_Init_IO call and the shit is the same.

[PaulWessel]

I will look at the master.

[joa-quim]

The master is like the #if 0 but without the two module_input settings, which in fact makes it not not working at all in Matlab.

[PaulWessel]

You should add a if (GMT_Destroy_Data (API, &D)) {
errormessage;
} at end of gdal_vector since you are copying x,y,z values into GDAl so you have no need for this later.

Can you give me an example/data that I can run and fail with in mex?

[joa-quim]

Funny, I'm not able to reproduce it now. It first happen in Mirone where it will take longer to tray to reproduce, but it happened in command line too. But not now!

[joa-quim]

Shit came back. It's something of this form but this gdalread is a pure MEX in Mirone (the ancestor of the one in GMT``

>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.005 -Nn -S1');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.005 -Nn -S1');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
Error using gdalread
Unable to open c:\v\A2014365131500.L2_LAC_OC.nc.

[PaulWessel]

OK, I need data files to test this.

[joa-quim]

You cannot. You don't have that gdalread

[joa-quim]

But note that it's clearly related to the libarified functions. When I use the GMT nearneighbor the error does not show up.

>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.005 -Nn -S1');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.005 -Nn -S1');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
Error using gdalread
Unable to open c:\v\A2014365131500.L2_LAC_OC.nc.
 
>> clear mex
>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.005 -N1 -S1');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.05 -N1 -S1');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');
>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.05 -N1 -S1');
>> att = gdalread('c:\v\A2014365131500.L2_LAC_OC.nc', '-M', '-C');

[joa-quim]

Can it be in save_grid_with_GMT(). Something that needs to ended/finished/closed/destroyed?

[PaulWessel]

Yes. If that grid is Created with no data, then if you do Grid->data = tmp to write out, you need to set
Grid->data = NULL afterwards.

[joa-quim]

You mean, line 195 should not have an if condition?

[PaulWessel]

Yes, just set it to NULL since it clearly was set to tmp above.

[PaulWessel]

For init_open, would be more readable if the mode argument was GMT_IS_GRID or GMT_IS_DATASET instead of nebulous 0 and 1.

[joa-quim]

Nope, because then

>> g = gmtmex('nearneighbor c:\v\lixo.csv -R0/10/0/10 -I0.005 -Nn -S1');
Error using gmtmex
gmtmex_get_grid: programming error, output matrix G is empty

[PaulWessel]

I am looking at save_grid_with_GMT. There is nPixelSize yet Grid->data is float. Since nPixelSize must be 8 why is it even a variable? And if it is not 8, don't you need to check and convert?

Also, if you are "Writing" to memory here then yes cannot set data = NULL but then you need to allocate memory? Or use GMT_VIA_MATRIX probably. Cannot play too fast and loose with pointers like that otherwise.

[PaulWessel]

Why are you doing a calloc in line 177 instead of a GMT_Create_Data with GMT_DATA_ONLY as arg to add the missing ->data array? You are in GMT, allocating arrays for GMT but not telling GMT about it.

[joa-quim]

Yes, I need to test nPixelSize but it's a variable because user may pass an input argument to gdal that return another data type.

I used a calloc because that was memory passed to GDAL to get back the result. Close to what is done is gdalread.

[PaulWessel]

OK, but tmp cannot be anything but float for GMT, so at least you will need to check if nPixelSize is 8, and if not you need to take some action, like creating a float array and copy over. Second, it looks like GDALRasterIO is putting the values into tmp, like any other function. So I dont understand why that cannot be GMT-allocated memory since there is no realloc etc going on with tmp. That way, tmp is not needed (just allcoate grid and pass Grid->data) and no longer an issue I think.

[joa-quim]

Yes, passing Grid->data should be fine. Tomorrow.

[joa-quim]

Found the issue with the Unable to open .... It was in my gdalread MEX that was not meant to be used in parallel with other MEXs accessing GDAL.

[PaulWessel]

Could you give me more info on when input is grid versus dataset so I can try to fix the KEYS?

[joa-quim]

I think only the gdalgrid takes datasets. All others take grids. You can confirm by seeing which gdal modules it wraps. On my way to Lisbon but by car. Avoid crowds is the present rule.

…

Sent from my iDedo

No dia 13/03/2020, às 18:33, Paul Wessel ***@***.***> escreveu:  Could you give me more info on when input is grid versus dataset so I can try to fix the KEYS? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[joa-quim]

Outdated proposal. Closing.

[joa-quim]

I think this is solved

[PaulWessel]

Yes