Ticket #71 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

When projecting on a geometry literal and have it also as an argument to a spatial function, its label is constructed in the client side leading to confusion as to which of the two WKT datatypes should be used

Reported by: charnik Owned by: charnik
Priority: minor Milestone: Strabon v3.3
Component: endpoint Version: 3.2.10
Keywords: select clause, geometry literal, datatype, mismatch Cc:

Description (last modified by charnik) (diff)

When the SELECT clause projects a geometry literal that also appears as an argument to a spatial function (e.g., buffer, srid, etc.), its label is not retrieved from the label_values/long_label_values table, but instead it is constructed on the client side based on its binary value that has been retrieved from the geo_values table. The consequence of this is that in the client side we cannot determine its datatype, so it might had been stored as geo:wktLiteral and get it now as strdf:WKT.

An example query is the following:

prefix strdf: <http://strdf.di.uoa.gr/ontology#>
SELECT ?o (strdf:srid(?o) as ?srid)
WHERE {

<http://ex.org/geosparql_4326> ?p ?o

}

This should be run on a database with the following triple:

<http://ex.org/geosparql_4326> <http://strdf.di.uoa.gr/ontology#hasGeometry> "<http://www.opengis.net/def/crs/EPSG/0/4326> POINT(37.983917 23.729359899999963)"<http://www.opengis.net/ont/geosparql#wktLiteral> .

Instead of getting a geo:wktLiteral for ?o, we get a strdf:WKT.

Change History

comment:1 Changed 3 years ago by charnik

  • Owner changed from pyravlos-team to charnik
  • Status changed from new to assigned
  • Description modified (diff)

comment:2 follow-up: ↓ 3 Changed 3 years ago by charnik

The problem is that the SQL query corresponding to the above SPARQL query does not communicate the label to the client. This is good and bad. It is good, because of the communication cost between the client and the database (think of having very long geometries and many results). It is bad though, because we do not return what the user has stored. We have the following options:

  • Return also the label. This will result in another two left joins with label_values and long_label_values. Heavy communication costs with the client.
  • Construct the label at the client side, but return the datatype! This will result in one more join with the datatype_values table. Still the communication cost won't be that much.

comment:3 in reply to: ↑ 2 Changed 3 years ago by charnik

  • Status changed from assigned to closed
  • Resolution set to fixed

Replying to charnik:

The problem is that the SQL query corresponding to the above SPARQL query does not communicate the label to the client. This is good and bad. It is good, because of the communication cost between the client and the database (think of having very long geometries and many results). It is bad though, because we do not return what the user has stored. We have the following options:

  • Return also the label. This will result in another two left joins with label_values and long_label_values. Heavy communication costs with the client.
  • Construct the label at the client side, but return the datatype! This will result in one more join with the datatype_values table. Still the communication cost won't be that much.

Bug fixed in changeset 1384:63037c4974c5, following the second approach above.

Note: See TracTickets for help on using tickets.