Sent the PNG direct to your email. Also, a more general question. I noticed the `x` and `y` for DirectPosition2D doesn't mean anything (per the docs) and that if passing in WGS84 Lat, Lon coordinates, it should still pass them into DirectPosition2D in Lat, Lon order, and not x == Lon, y == Lat order. Is this correct? I confirmed in a test comparing proj4j w/ SIS results (which were first terribly off from logically setting x = Lon, y = Lat) but I thought I'd explicitly ask here to verify.
Thanks! Nicholas Knize, Ph.D., GISP Chief Technology Officer | Lucenia <https://lucenia.io> Apache Lucene PMC Member and Committer nkn...@apache.org On Thu, Dec 5, 2024 at 11:34 AM Nicholas Knize <nkn...@gmail.com> wrote: > Thanks so much! I'll send the PNG directly to your email in a bit. I'm > going to be OOTO for the next few hours. > > I was able to work around some of the issues by further reducing the calls > to CRS.forCode; my gut tells me the exception is related to Derby > internals. I did notice another interesting behavior that I'll share in a > follow up email. In short, I'm checking the Coordinate reference system > name() in my test, sometimes it comes back WGS 84, sometimes it comes back > EPSG:WGS 84. I'm guessing more Derby internal weirdness that's probably due > to query performance and caching or something. For now I'm able to move > forward and work around these behaviors but I'll send more details when I'm > back in office. > > Thanks again for all the help! > > On Thu, Dec 5, 2024, 10:35 AM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > >> Hello Nicholas >> >> After a second check, I saw that SIS still have some `catch >> (SecurityException)` statements. We removed the calls to >> AccessController.doPrivileged(…) in SIS 1.2 [1], but not yet the >> SecurityException. Therefore, I added some missing `catch >> (SecurityException)` statements around the use of `StackWalker` when a >> fallback exists, but it would be good to keep the >> "getStackWalkerWithClassReference" permission anyway for better results. >> >> I added `catch (SecurityException)` statements around the registration >> and unregistration of the shutdown hook. Therefore, it should be okay to >> not give that permission to SIS. The result will only be a log record at >> Level.FINE. In replacement, I added a `Configuration.shutdown()` method >> (it is a bit strange to have that method in a configuration class, but I >> do not really see a better location at this time). >> >> The `catch (SecurityException)` statements will probably be removed in >> some future SIS version (when SIS will depend on Java 24 or when >> SecurityException will be deprecated), but probably not before a few >> years. >> >> >> Le 2024-12-04 à 20 h 00, Nicholas Knize a écrit : >> >> > It looks like the ConcurrentAuthorityFactory#ShutdownHook is not >> > actually shutting down the TimerThread which is created by Derby from >> > the LocalDataSource#getConnection method. Here's the stack trace where >> > the thread is being created all the way down to Derby: >> >> The PNG image seems to have been lost on the mailing list. Would it be >> possible to send it directly to my email address? >> >> Martin >> >> [1]https://issues.apache.org/jira/browse/SIS-525 >> >
