Do I have to initiate the merger in jira from #2213 or is this something you do from #1169?
On Sun, Jan 23, 2022 at 10:59 PM Andy Seaborne <[email protected]> wrote: > Would the best way to move forward be to merge #1169 (which has to be > done before 4.4.0) then you can provide PR to update the tests to be > appropriate for OSGB which can be done at leisure (before or after > 4.4.0)? I don't see any non-test changes below. > > Andy > > On 22/01/2022 19:33, Marco Neumann wrote: > > in addition to the change to the pom.xml to bump SIS up to 1.1 > > > > these two files needs to be changed > > > > modified: > > > jena-geosparql/src/test/java/org/apache/jena/geosparql/implementation/SRSInfoTest.java > > Line 102 > Envelope expResult = new Envelope(-118397.00138845091, > > 751441.7790901454, -16627.734375018626, 1272149.3463499574); > > Line 102 < Envelope expResult = new Envelope(-104009.35713717458, > > 688806.0073395987, -16627.734528041445, 1256558.4455361878); > > > > modified: > > > jena-geosparql/src/test/java/org/apache/jena/geosparql/spatial/SearchEnvelopeTest.java > > > > Line 64 < public static final double OS_X1 = -104009.35713717458; > > Line 65 < public static final double OS_X2 = 688806.0073395987; > > Line 66 < public static final double OS_Y1 = -16627.734528041445; > > Line 67 < public static final double OS_Y2 = 1256558.4455361878; > > > > /** > > * Test of build method, of class SearchEnvelope. > > */ > > @Test > > public void testBuild_NORTH_OSGB() { > > > > GeometryWrapper geometryWrapper = GeometryWrapper.extract("< > > http://www.opengis.net/def/crs/EPSG/0/27700> POINT(52.33022 -3.766409)", > > WKTDatatype.URI); > > CardinalDirection direction = CardinalDirection.NORTH; > > SearchEnvelope expResult = new SearchEnvelope(new > Envelope(OS_X1, > > OS_X2, -3.766409, OS_Y2), SpatialIndexTestData.OSGB_SRS_INFO); > > SearchEnvelope result = SearchEnvelope.build(geometryWrapper, > > SpatialIndexTestData.OSGB_SRS_INFO, direction); > > assertEquals(expResult, result); > > } > > > > /** > > * Test of build method, of class SearchEnvelope. > > */ > > @Test > > public void testBuild_SOUTH_OSGB() { > > > > GeometryWrapper geometryWrapper = GeometryWrapper.extract("< > > http://www.opengis.net/def/crs/EPSG/0/27700> POINT(52.33022 -3.766409)", > > WKTDatatype.URI); > > CardinalDirection direction = CardinalDirection.SOUTH; > > SearchEnvelope expResult = new SearchEnvelope(new > Envelope(OS_X1, > > OS_X2, OS_Y1, -3.766409), SpatialIndexTestData.OSGB_SRS_INFO); > > SearchEnvelope result = SearchEnvelope.build(geometryWrapper, > > SpatialIndexTestData.OSGB_SRS_INFO, direction); > > assertEquals(expResult, result); > > } > > > > /** > > * Test of build method, of class SearchEnvelope. > > */ > > @Test > > public void testBuild_EAST_OSGB() { > > > > GeometryWrapper geometryWrapper = GeometryWrapper.extract("< > > http://www.opengis.net/def/crs/EPSG/0/27700> POINT(52.33022 -3.766409)", > > WKTDatatype.URI); > > CardinalDirection direction = CardinalDirection.EAST; > > SearchEnvelope expResult = new SearchEnvelope(new > > Envelope(52.33022, OS_X2, OS_Y1, OS_Y2), > > SpatialIndexTestData.OSGB_SRS_INFO); > > SearchEnvelope result = SearchEnvelope.build(geometryWrapper, > > SpatialIndexTestData.OSGB_SRS_INFO, direction); > > assertEquals(expResult, result); > > } > > > > /** > > * Test of build method, of class SearchEnvelope. > > */ > > @Test > > public void testBuild_WEST_OSGB() { > > > > GeometryWrapper geometryWrapper = GeometryWrapper.extract("< > > http://www.opengis.net/def/crs/EPSG/0/27700> POINT(52.33022 -3.766409)", > > WKTDatatype.URI); > > CardinalDirection direction = CardinalDirection.WEST; > > SearchEnvelope expResult = new SearchEnvelope(new > Envelope(OS_X1, > > 52.33022, OS_Y1, OS_Y2), SpatialIndexTestData.OSGB_SRS_INFO); > > SearchEnvelope result = SearchEnvelope.build(geometryWrapper, > > SpatialIndexTestData.OSGB_SRS_INFO, direction); > > assertEquals(expResult, result); > > } > > > > > > On Sat, Jan 22, 2022 at 7:22 PM Andy Seaborne <[email protected]> wrote: > > > >> > >> > >> On 22/01/2022 17:34, Marco Neumann wrote: > >>> I have not seen this in the pull request yet, but this may work. I have > >>> also made changes to the reference position as it isn't appropriate for > >>> OSGB. > >> > >> Sound like it would be better than 1169. > >> > >>> > >>> but 1169 may work as is. > >>> > >>> On Sat, Jan 22, 2022 at 5:17 PM Andy Seaborne <[email protected]> wrote: > >>> > >>>> How is it different to > >>>> > >>>> https://github.com/apache/jena/pull/1169 > >>>> > >>>> ? (which is the Diff on the ticket, after cleaning up a bit) > >>>> > >>>> On 22/01/2022 15:58, Marco Neumann wrote: > >>>>> I have created a fix for > >> https://issues.apache.org/jira/browse/JENA-2213 > >>>>> > >>>>> this involves an upgrade to SIS1.1 > >>>>> > >>>>> How are we going to include this in Jena 4.4.0? Should I ask for a > pull > >>>>> request? > >>>>> > >>>>> Marco > >>>>> > >>>>> > >>>>> On Sat, Jan 22, 2022 at 3:07 PM Andy Seaborne <[email protected]> > wrote: > >>>>> > >>>>>> Things are looking on-track for a release. > >>>>>> > >>>>>> A couple of JIRA have come in recently - one's now got a PR, and the > >>>>>> LiteralLabel looks OK, just needs trying out. > >>>>>> > >>>>>> Builds: > >>>>>> > >>>>>> Some of the Jenkins is broken (that take 2 mins ... which is a > little > >>>>>> too fast!) and despite "success" the snapshot repos is unchanged. > >>>>>> There's a suspicious warning from Jenkins: INFRA-22769 and it seems > to > >>>>>> only touch the top level directory. > >>>>>> > >>>>>> I have done a snapshot deploy directly (from local maven run, not > >>>>>> jenkins) with no issues. > >>>>>> > >>>>>> GH actions work ... there does seem to be one timing related issue > in > >>>>>> test cleanup in jena-fuseki-webaccess when the GH actions might be > >> under > >>>>>> load. It does not look to be related to what is being tested > (deleting > >>>>>> databases). > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> On 15/01/2022 22:08, Bruno P. Kinoshita wrote: > >>>>>>> Looks good to me! > >>>>>>> > >>>>>>> Thanks Andy > >>>>>>> Bruno > >>>>>>> > >>>>>>> On Sunday, 16 January 2022, 06:53:40 am NZDT, Andy > Seaborne < > >>>>>> [email protected]> wrote: > >>>>>>> > >>>>>>> The idea was to have 4.4.0 quite soon because the Fuseki UI > work > >>>> only > >>>>>>> just missing 4.3.0 > >>>>>>> > >>>>>>> Despite everything, we seem to be still on track for end-ish > January! > >>>>>>> > >>>>>>> Resolved tickets for 4.4.0: > >>>>>>> https://s.apache.org/jena-4.4.0-jira > >>>>>>> > >>>>>>> Does that fit with PMC members? > >>>>>>> > >>>>>>> Andy > >>>>>>> > >>>>>>> Contributions: > >>>>>>> > >>>>>>> Erich Bremer > >>>>>>> Update of Titanium. > >>>>>>> > >>>>>>> == Fuseki: > >>>>>>> > >>>>>>> More on Fuseki : > >>>>>>> https://lists.apache.org/thread/rrvy84t79ljhpxkpccc7l70tgt9o21lk > >>>>>>> > >>>>>>> * New UI > >>>>>>> > >>>>>>> A rewritten UI using Vue. Much better easier to take forward and > much > >>>>>>> easier to manage the dependencies and licensing. > >>>>>>> > >>>>>>> Thanks Bruno! > >>>>>>> > >>>>>>> * TDB2 > >>>>>>> > >>>>>>> The UI options for databases are "in-memory" and "TDB2". > >>>>>>> > >>>>>>> TDB1 is not a visible option. > >>>>>>> > >>>>>>> * Fuseki modules > >>>>>>> > >>>>>>> https://jena.apache.org/documentation/fuseki2/fuseki-modules > >>>>>>> > >>>>>>> * WAR file > >>>>>>> > >>>>>>> The WAR file will be on the project downloads page, not in the > >>>>>>> apache-jena-fuseki assembled file. This halves the size of the > >>>> zip/tar.gz > >>>>>>> > >>>>>>> It is part of evolving Fuseki in the future so the standalone > server > >> is > >>>>>>> Fuseki Main + Fuseki modules for UI and administration. > >>>>>>> > >>>>>>> The WAR file will remain while it is being used but it's > incompatible > >>>>>>> with drop-in Fuseki-module extensions. > >>>>>>> > >>>>>>> * Tomcat 10 > >>>>>>> > >>>>>>> The WAR file is not compatible with Tomcat 10 which is using > >> "jakarta" > >>>>>>> APIs, not "javax" APIs. > >>>>>>> > >>>>>>> There is a conversion tool > >>>>>>> https://tomcat.apache.org/download-migration.cgi > >>>>>>> is someone would like to try it out. > >>>>>>> > >>>>>>> ** HTML file upload. > >>>>>>> > >>>>>>> The HTML file upload functionality, "serviceUpload", is no longer > >>>>>>> included in new default configurations. > >>>>>>> > >>>>>>> This is not GSP. GSP does support multifile uploads. > >>>>>>> > >>>>>>> == Assembler for GeoSPARQL > >>>>>>> > >>>>>>> This makes it easier to use GeoPSARQL in a plain Fuseki. > >>>>>>> > >>>>>>> == xloader > >>>>>>> > >>>>>>> TDB2 xloader has usability improvements based on our wikidata > testing > >>>> by > >>>>>>> Øyvind, Lorenz and Marco, including full wikiData (16.7B triples) > as > >>>>>>> well as "truthy" (6.6B triples). > >>>>>>> > >>>>>>> In particular, it now has "--threads=" -- Lorenz reported goo > >>>>>>> improvements (if the server has the hardware!). > >>>>>>> > >>>>>>> > >>>>>>> TDB1 xloader is still the old tdbloader2 with some of the earlier > >>>>>>> improvements of TDB2 xloader. > >>>>>>> > >>>>>>> For me, TDB2 is the preferred database. > >>>>>>> TDB1 exists because it is out there; it may get back ports, it may > >> not. > >>>>>>> > >>>>>>> == Other: > >>>>>>> > >>>>>>> Dependencies up to date: log4j 2.17.1; Update to Titanium 1.2.0 > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > -- --- Marco Neumann KONA
