Let GMT_Put_Vector accept GMT_DATETIME as type

[PaulWessel]

See this issue for context. This PR allows for calling GMT_Put_Vector with type = GMT_DATETIME and the array as an array of strings (char **) and we convert ISO time-stamps to internal doubles for internal column representation.
I did not add the same for GMT_Get_Vector. Some issues arose:

1. Because input vector is not numerical, GMT needs to allocate an array to hold the internal representation. This array was allocated by GMT, not the external user. Hence, when GMT quits there will currently be a memory leak. Probably not the end of the world.
2. Ideally, we should flag that this array is internally allocated, but the GMT_VECTOR structure only as a scalar alloc_mode variable that applies to all columns. This was short-sighted. However, that variable is in the hidden section and not accessible to users, so we can change.
3. For GMT_Get_Vector, the question is do we need that capability? Is it not easier to convert the double array with internal time to some string-representation in python via library function on your end? If not, then GMT would have to allocate a string array and pass it out, having no mechanism to free it.

I suggest you first try this branch to see if you can get those values in there and test this first. Meanwhile, I will go back to master and let the alloc_mode be an array with one entry per column, just like we have for data type. Then we can free those columns that were internally allocated and ignore the others. OK?

[seisman]

A working script works with the master branch but crashes using this branch. The error message is:

Error returned from GMT API: GMT_NOT_A_SESSION (29)

[PaulWessel]

Sorry about that, try now.

[PaulWessel]

Merged the master in so now no more memory leak for your case.

[joa-quim]

In Julia

julia> D = text_record(["2008-01-01T00:00  5.0"; "2008-01-01T00:01 6.0"]);

julia> plot(D, region="2008-01-01T00:00/2008-01-01T00:01/5/6", f="T", Vd=1)
        psxy  -R2008-01-01T00:00/2008-01-01T00:01/5/6 -JX12c/8c -Baf -BWSen -fT -P -K > C:\TMP\GMTjl_tmp.ps
[Session GMT (0)]: Error returned from GMT API: GMT_READ_ONCE (77)
[Session GMT (0)]: Error returned from GMT API: GMT_READ_ONCE (77)
[Session GMT (0)]: Error returned from GMT API: GMT_READ_ONCE (77)

D is a dataset with text only.

[seisman]

GMT command line also supports input data like 123:27:15.120W, but it seems no way to pass these geographic coordinate strings to GMT API, too.

[PaulWessel]

As you (may) know, GMT has several methods for reading its input. Command line is focused on files, but other modes are reading datasets from input matrices, sets of vectors, another dataset, etc. I seems you may be asking about a general method that expects an array of text records. You would then open a VirtualFile with a new modifier, e.g..,

GMT_Open_VirtualFile (API, GMT_IS_DATASET|GMT_VIA_STRINGS, GMT_IS_PLP, GMT_IN, T, input);

and then pass input as the virtual file to the module. Is that what is needed?

As for the original question about Put_Vector I think having the ability to pass datetime strings is reasonable since that is a common time representation, but to extend this to give text representations for longitude etc seems too much. Yet I am not using the API as you are so you tell me if the VirtualFile solution above would solve what you are trying to do. If we had to solve this via GMT_Put_Vector then I can imagine inventing a GMT_GEO_STRING type that is passed just like the GMT_DATETIME is now passed and we could do the conversion the same way.

[seisman]

I seems you may be asking about a general method that expects an array of text records. You would then open a VirtualFile with a new modifier, e.g..,

GMT_Open_VirtualFile (API, GMT_IS_DATASET|GMT_VIA_STRINGS, GMT_IS_PLP, GMT_IN, T, input);

and then pass input as the virtual file to the module.

It seems a good solution for complicated input types.

[seisman]

This PR now works well for PyGMT.

@joa-quim's test is using another API function?

[PaulWessel]

Yes, I think he wants to feed an array of strings (i.e., a virtual text file) into GMT, but that is not implemented (yet). We will let @joa have the last word on that tomorrow, but unless he is useing GMT_Put_Vector I think this one will then be closed and merged.

[joa]

I assume this was ment for @joa-quim ,)

[PaulWessel]

Yes, @joa-quim sorry.

[joa-quim]

Yes, I think he wants to feed an array of strings (i.e., a virtual text file) into GMT

Yes, what I want is to pass a dataset with text and that being recognized.

[PaulWessel]

Perhaps those who are most motivated to see this done should take the lead? I truly have my hands full these days. Because our modules either read via GMT_Read_Data or via GMT_Get_Record there needs to be two slightly different implementations added. Our gmt_ascii_input does all the work of parsing except that it reads the next record from a file pointer, whereas you will want to give it that record from a text array.. We probably need to rearrange gmt_ascii_input so that we dont duplicate all that code just to access an array.
I can tell you there is quite a bit work to get this implemented so I am ruling it out for 6.1.

[seisman]

I think it's a very low priority for PyGMT. It's OK for me to merge it as it is.

[PaulWessel]

Yes, it would not go into this branch anyway. @joa OK for you to make a clear feature request for this.