> I sometime wondered if "sis-utility" and "sis-metata" modules should be
merged into "sis-referencing", because I think that the two former are
rarely used alone. Would it help?
I don't know the deep details driving the separation of the two so my
response comes from shallow knowledge. With that, yes it would help reduce
the dependency surface area.
> Then it is a bug. I will investigate. Depending on when you would need
the fix, it could be in a 1.4.1 release or a 1.5 one.
No worries. I have a midterm work around so it won't block the current
effort.
> I will think to a replacement. Would a static method in
`org.apache.sis.setup.Configuration` be okay?
Yes this would be a great alternative.
> This is work in progress and will be available in SIS 1.5. Note that it
requires version 10 or later of EPSG database
No worries, no rush, and not a problem on the upgrade.
> Maybe Derby could be used in short term, and a Lucene-backed authority
factory be a medium term goal?
Definitely. That's the approach I'm taking for the time being. However I've
run into another issue. My test suite consists of six test cases that each
call `CRS.forCode` with different EPSG codes. The test cases are free to
run at max processing speed, and they call forCode twice each test method.
Apparently this is causing some kind of cache pressure?
Caused by: java.lang.RuntimeException: Failed to create CRSHandler for
projection from [EPSG:4326] to [EPSG:3857]
at
io.test.ReprojectionProcessor.lambda$new$0(ReprojectionProcessor.java:87)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
at io.test.ReprojectionProcessor.<init>(ReprojectionProcessor.java:83)
... 40 more
Caused by: org.opengis.referencing.NoSuchAuthorityCodeException: No
‘CoordinateReferenceSystem’ object found for code “3857”. However,
only a subset of the EPSG geodetic dataset has been queried. See
https://sis.apache.org/epsg.html for instruction about how to install
the full EPSG database.
at
org.apache.sis.referencing.EPSGFactoryFallback.predefined(EPSGFactoryFallback.java:356)
at
org.apache.sis.referencing.EPSGFactoryFallback.createCoordinateReferenceSystem(EPSGFactoryFallback.java:231)
at
org.apache.sis.referencing.factory.AuthorityFactoryProxy$22.createFromAPI(AuthorityFactoryProxy.java:394)
at
org.apache.sis.referencing.factory.AuthorityFactoryProxy$22.createFromAPI(AuthorityFactoryProxy.java:389)
at
org.apache.sis.referencing.factory.MultiAuthoritiesFactory.create(MultiAuthoritiesFactory.java:857)
at
org.apache.sis.referencing.factory.MultiAuthoritiesFactory.createCoordinateReferenceSystem(MultiAuthoritiesFactory.java:918)
at org.apache.sis.referencing.CRS.forCode(CRS.java:251)
at io.test.SISProvider.getCRS(SISProvider.java:47)
at io.test.SISProvider.createCRSHandler(SISProvider.java:52)
at
io.test.ReprojectionProcessor.lambda$new$0(ReprojectionProcessor.java:85)
... 42 more
Failed to create CRSHandler for projection from [EPSG:4326] to [EPSG:3857]
When these tests are run individually they pass. When run as a full suite,
I get this error:
*Caused by: org.opengis.referencing.NoSuchAuthorityCodeException: No
‘CoordinateReferenceSystem’ object found for code “3857”. However, only a
subset of the EPSG geodetic dataset has been queried. See
https://sis.apache.org/epsg.html <https://sis.apache.org/epsg.html> for
instruction about how to install the full EPSG database.*
I assume it's a protection mechanism for running the full database in a
derby in-memory database, but is there a workaround? I've read the docs and
found this:
The performance issue can be avoided if the JAR file is uncompressed. But
uncompressed sis-embedded-data.jar file is more than 5 times larger than
the compressed file. Given that CRS.forCode(…) and
CRS.findCoordinateOperation(…) should not be invoked too often, and that
performance degradation does not apply to the CoordinateOperation instances
created by those method calls, the JAR file is distributed on the Maven
repository in its compressed form. If desired, better performance can be
achieved by using one of the other configurations described in this page,
or by uncompressing the sis-embedded-data.jar file locally.
Am I understanding that a work around for this would be to "un-jar" the
`sid-embedded.jar` file and load the derby database locally with the
contents in the jar? Or is there an easier solution?
Nicholas Knize, Ph.D., GISP
Chief Technology Officer | Lucenia <https://lucenia.io>
Apache Lucene PMC Member and Committer
[email protected]
On Wed, Dec 4, 2024 at 2:36 PM Martin Desruisseaux <
[email protected]> wrote:
> Just a quick reply on the easiest topics (I will look it more details
> the security topic tomorrow):
>
> Le 2024-12-04 à 19 h 09, Nicholas Knize a écrit :
>
> > My comment was more around the fact that, transitive or not, some
> > sensitive environments make it more difficult to bring in a "new"
> > project when it has so many dependencies that require special security
> > scanning (a concept we put into practice when working on Lucene core).
> >
> I sometime wondered if "sis-utility" and "sis-metata" modules should be
> merged into "sis-referencing", because I think that the two former are
> rarely used alone. Would it help?
>
>
> > I tried that method and the derby database does get shutdown but the
> > EPSGFactory thread does not.
> >
> Then it is a bug. I will investigate. Depending on when you would need
> the fix, it could be in a 1.4.1 release or a 1.5 one.
>
>
> > This is where I'm looking at creating my own jar'd up Lucene index and
> > using simple Lucene APIs to query the EPSG database instead.
> >
> It would be great and it is technically possible since the referencing
> engine can work with custom AuthorityFactory. But creating a complete
> authority factory, including the transformations between pairs of CRS
> and all the metadata (domain of validity + accuracy), would be a
> significant effort. Maybe Derby could be used in short term, and a
> Lucene-backed authority factory be a medium term goal?
>
>
> > The concern is that we have a "plugin" framework that enables users to
> > write extension points. I have to look at limiting this permission to
> > just the codebase needing it so users don't write nefarious shutdown
> > hooks in their plugin that could kill the process.
> >
> I will think to a replacement. Would a static method in
> `org.apache.sis.setup.Configuration` be okay?
>
>
> > If I'm not mistaken, SIS has the ability to support the OGC dynamic
> > CRS spec as well?
> >
> This is work in progress and will be available in SIS 1.5. Note that it
> requires version 10 or later of EPSG database, which has some
> significant changes compared to previous versions (which is why this
> upgrade takes more times than usual). It may be one reason for not doing
> the Lucene-embeded EPSG data now, since the schema will change a bit.
>
> Martin
>
>
