[
https://issues.apache.org/jira/browse/CALCITE-4294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599725#comment-17599725
]
Julian Hyde commented on CALCITE-4294:
--------------------------------------
Regarding commit and jira case granularity.
You should try to "right-size" commits. If a group of functions are related,
and the resulting code changes are not-too-large and not-too-small, it makes
sense to put them in the same commit. Also, each commit ends up as a line in
the release notes, so the commit message will be the main way that users find
out what's in the project.
But we also encourage people to create "forward-looking" jira cases, to talk
about largish features they'd like to accomplish, and let others join the
discussion, share in the work. Those cases might turn out to be too large to
accomplish in one commit. In which case, each time you have a self-contained
set of work to commit, log a jira case describing that work, and reference the
larger "umbrella" or "epic" case.
Obviously, each commit must be self-contained, in that it contains tests and
documentation as well as the code.
When you've logged a case or cases about vector tiles, I'll comment more there.
I am interested in strategies that implement spatial queries using clever
materialized views in vanilla databases (i.e. organized using sorting and
hashing but not spatial data structures like r-trees) and in CALCITE-2610 I
found that rectangular grids were useful. A next step would be to use bitmap
operations on raster tiles.
> Use JTS rather than ESRI as the underlying library for geospatial (ST_)
> functions
> ---------------------------------------------------------------------------------
>
> Key: CALCITE-4294
> URL: https://issues.apache.org/jira/browse/CALCITE-4294
> Project: Calcite
> Issue Type: Bug
> Components: spatial
> Reporter: Julian Hyde
> Assignee: Bertil Chapuis
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.32.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The geospatial functions are currently implemented using the ESRI library. We
> should consider using JTS instead. AT the time we started work on geospatial
> the JTS did not have a suitable license, but this is no longer the case. I
> gather that JTS is a superior library.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
