Hi Lorenz,
Thanks for the info. I'll look into adding options to disable these
dynamic conversions between units and geometries, as they can create
such large errors over large distances, so that users can choose to
switch them on.
Thanks,
Greg
On 24/02/2022 07:30, Lorenz Buehmann wrote:
Hi
Hi Greg,
thanks for providing such an informative answer.
On 23.02.22 17:59, Greg wrote:
Hi Lorenz,
Regarding your final point on the use of Euclidean distance for the
geof:distance, this is derived from Requirement A.3.14 on page 38 of the
GeoSPARQL standard (quoted below). The definition of
Hi Lorenz,
Regarding your final point on the use of Euclidean distance for the
geof:distance, this is derived from Requirement A.3.14 on page 38 of the
GeoSPARQL standard (quoted below). The definition of the distance and
other query functions follows that of the Simple Features standard (ISO
Thanks both for your very helpful input - I'm still a GeoSPARQL novice
and trying to learn stuff and first of all just use the Jena
implementation as efficient as possible.
On 21.02.22 15:22, Andy Seaborne wrote:
On 21/02/2022 09:07, Lorenz Buehmann wrote:
Any experience or comments so
On 21/02/2022 09:07, Lorenz Buehmann wrote:
Any experience or comments so far?
Using SubsystemLifecycle, could make the conversions by
GeoSPARQLOperations.convertGeoPredicates
extensible.
Andy
But having coordinate location (P625), located on astronomical body
(P376) as
I have a vague memory of running into this issue in the past, Lorenz. The
wikidata RDF serialization does not conform strictly to the OGC GeoSPARQL
data model nor do the geospatial access methods of the blazegraph extension
attempt to exhibit any of the standards compliant features. That's
Hi,
we can use this as an complementary thread for the ongoing "loading
Wikidata" threads, this time with focus on the geospatial part.
Joachim already did the same for the text index and it works as
expected, though still loading time could be improved.
For the geospatial index things
