search

gmantele / vollt

Java libraries implementing the IVOA protocol: ADQL, UWS and TAP
http://cdsportal.u-strasbg.fr/taptuto/
29 stars 28 forks source link

TAP upload and geography columns #110

Closed vforchi closed 5 years ago

vforchi commented 5 years ago

Hi,

I am trying to enable the upload feature on our TAP server. The backend is SQLServer, where we use geography columns to map adql:region.

I was able to enable the basic upload, but when I tried to upload regions I ran into a problem: the column in the uploaded table is of type varchar, but it should be geography.

As far as I can see the type comes from stil, in tap.data.VOTableIterator.StreamVOTableSink#getAuxDatumValue, and stil considers only the datatype.

This is a serious limitation: if we cannot upload regions the performance of any cross matching would be extremely poor: can you suggest a solution?

Cheers, Vincenzo

gmantele commented 5 years ago

Hi Vincenzo.

Did you set the xtype to "adql:REGION" (or REGION) on the FIELD containing the region?

The datatype of the field must still be VARCHAR, and only the xtype will flag this column as a region. For the moment, regions must be written in STC-s

Cheers, Grégory

Le 8 avril 2019 10:00:31 GMT+02:00, "Vincenzo Forchì" notifications@github.com a écrit :

Hi,

I am trying to enable the upload feature on our TAP server. The backend is SQLServer, where we use geography columns to map adql:region.

I was able to enable the basic upload, but when I tried to upload regions I ran into a problem: the column in the uploaded table is of type varchar, but it should be geography.

As far as I can see the type comes from stil, in tap.data.VOTableIterator.StreamVOTableSink#getAuxDatumValue, and stil considers only the datatype.

This is a serious limitation: if we cannot upload regions the performance of any cross matching would be extremely poor: can you suggest a solution?

Cheers, Vincenzo

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/gmantele/taplib/issues/110

vforchi commented 5 years ago

Did you set the xtype to "adql:REGION" (or REGION) on the FIELD containing the region?

Yes, the table was the output of an ObsTAP query.

Does this mean it is not possible to upload native geometry types into the DB?

gmantele commented 5 years ago

Does this mean it is not possible to upload native geometry types into the DB?

It should be. In my case, it is working well with a Postgres database. It is probably related to the way the geometrical data are identified by the translator.

Is there anything related to geometries in the function convertTypeToDB(DBType) in your implementation of ADQLTranslator?

This function is in charge of declaring the database datatype of the uploaded tables' columns. What I can currently see in the SQLServerTranslator is that it returns varchar for any REGION and POINT.

However, if this function does the job correctly, the problem may come from the identification of the geometries (e.g. DBType.REGION). But, let's see first for the 1st point.

vforchi commented 5 years ago

It was convertTypeToDB(DBType), now I get different errors. Thanks for the tip.