Re: [Geotools-devel] code sprint update w/ JSR 363 transition
Regarding GWC: I've not tried to recompile GWC, since I'm not familiar with its code-base, so I don't know if changes will be required. I just adapted Geoserver, which is able to compile and pass tests. César On 5 April 2018 at 19:44, Jody Garnett <jody.garn...@gmail.com> wrote: > Were any changes needed to the GWC project (which GeoServer depends on). > > I do not mind if we flatten history, generally I prefer to rebase against > master. > > Before we do, I had a couple usability ideas to bounce off you to make these > easier for upgraders. > > Make use of our Units utility class to make upgrading easier: > > * unit.getName() --> Units.toName( unit ); > * Unit.valueOf(unitString) --> Units.valueOf( unitString ); // our current > search and replace is quite long > > > > -- > Jody Garnett > > On 5 April 2018 at 10:21, César Martínez Izquierdo <cesar@gmail.com> > wrote: >> >> Hi Andrea, >> >> You are right, the branch was created around March 21th, so changes >> done after that date are missing. >> I've now tested that Geoserver fully compiles when compiled against a >> test_units_jsr363 branch which includes latest Geotools master >> changes. >> Should I merge Geotools master in the test_units_jsr363 branch, or >> will this pollute history? >> >> Regards. >> >> On 5 April 2018 at 18:28, Andrea Aime <andrea.a...@geo-solutions.it> >> wrote: >> > Hi Cesar, >> > probably your GeoTools branch is out of date, there is a new >> > copyNamespaceSupport method that >> > has been added March 21th >> > >> > Cheers >> > Andrea >> > >> > On Thu, Apr 5, 2018 at 6:17 PM, César Martínez Izquierdo >> > <cesar@gmail.com> wrote: >> >> >> >> Hi again, >> >> >> >> Geoserver is properly compiling and passing tests now in the branch, >> >> using: >> >> mvn -fn clean install >> >> >> >> There is only one compilation error in the wfs module which seems to >> >> be unrelated with the JSR migration (PropertyNameTypeBinding is >> >> expecting a method in GML3EncodingUtils which does not exist). So it >> >> seems we are coming closer to completing the migration. >> >> >> >> César >> >> >> >> On 5 April 2018 at 17:01, César Martínez Izquierdo >> >> <cesar@gmail.com> >> >> wrote: >> >> > Hi, I've created a branch for working on Geoserver adaptation: >> >> > https://github.com/dispiste/geoserver/tree/jsr363_units >> >> > >> >> > I've also created a PR to allow collaboration: >> >> > https://github.com/geoserver/geoserver/pull/2828 >> >> > >> >> > Best regards, >> >> > >> >> > César >> >> > >> >> > On 5 April 2018 at 10:17, Jody Garnett <jody.garn...@gmail.com> >> >> > wrote: >> >> >> I understand, the high number of files is due a series of search and >> >> >> replaces (as outlined in the proposal). If it helps I have a few key >> >> >> "huh" >> >> >> areas where I would like your experienced viewpoint (since your name >> >> >> is >> >> >> on >> >> >> the EPSG and ESRI unit formatters). I will go back and start a >> >> >> conversation >> >> >> on those points. >> >> >> >> >> >> Still I am happy enough with these changes to start a branch on GWC >> >> >> and >> >> >> GeoServer. >> >> >> >> >> >> -- >> >> >> Jody Garnett >> >> >> >> >> >> On 5 April 2018 at 00:17, Andrea Aime <andrea.a...@geo-solutions.it> >> >> >> wrote: >> >> >>> >> >> >>> Hi Jody, >> >> >>> whoa this is massive, 229 files changed? >> >> >>> I won't be able to look at it soon, next week I'm in the US and >> >> >>> travelling >> >> >>> there during the weekend, next weekend I'll probably be wiped and >> >> >>> get >> >> >>> some >> >> >>> rest. >> >> >>> >> >> >>> Cheers >> >> >>> Andrea >> >> >>> >> >> >>> >> >> >>> On Thu, Apr 5, 2018 a
Re: [Geotools-devel] code sprint update w/ JSR 363 transition
Hi again, For the moment I have created a new branch (test_units_jsr363_resync) based on the one we have been working. This new branch has been merged with master, so it can be used to test Geoserver. Regarding rebasing: I think it is OK to rebase when the PR is ready to be merged, since we'll not further work on that branch. So Jody, you can rebase when you feel the PR is ready (and maybe you can also squash all the commits into a single one, since you prefer atomic PR commits). Regards, César On 5 April 2018 at 19:48, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Thu, Apr 5, 2018 at 7:44 PM, Jody Garnett <jody.garn...@gmail.com> wrote: >> >> Were any changes needed to the GWC project (which GeoServer depends on). >> >> I do not mind if we flatten history, generally I prefer to rebase against >> master. > > > Yep, so do I when I work alone... but rebasing against master on a shared > branch can be problematic (it will require a force push > and the other devs will have to re-checkout it). So best organize with each > other in case you want to follow > that path. > > Cheers > Andrea > > == > > GeoServer Professional Services from the experts! Visit http://goo.gl/it488V > for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via di Montramito 3/A > 55054 Massarosa (LU) > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 > > Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i > file/s allegato/i sono da considerarsi strettamente riservate. Il loro > utilizzo è consentito esclusivamente al destinatario del messaggio, per le > finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio > senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia > via e-mail e di procedere alla distruzione del messaggio stesso, > cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo > anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per > finalità diverse, costituisce comportamento contrario ai principi dettati > dal D.Lgs. 196/2003. > > The information in this message and/or attachments, is intended solely for > the attention and use of the named addressee(s) and may be confidential or > proprietary in nature or covered by the provisions of privacy act > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection > Code).Any use not in accord with its purpose, any disclosure, reproduction, > copying, distribution, or either dissemination, either whole or partial, is > strictly forbidden except previous formal approval of the named > addressee(s). If you are not the intended recipient, please contact > immediately the sender by telephone, fax or e-mail and delete the > information in this message that has been received in error. The sender does > not give any warranty or accept liability as the content, accuracy or > completeness of sent messages and accepts no responsibility for changes > made after they were sent or for other risks which arise as a result of > e-mail transmission, viruses, etc. > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - SCOLAB: http://www.scolab.es - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] code sprint update w/ JSR 363 transition
Hi Andrea, You are right, the branch was created around March 21th, so changes done after that date are missing. I've now tested that Geoserver fully compiles when compiled against a test_units_jsr363 branch which includes latest Geotools master changes. Should I merge Geotools master in the test_units_jsr363 branch, or will this pollute history? Regards. On 5 April 2018 at 18:28, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi Cesar, > probably your GeoTools branch is out of date, there is a new > copyNamespaceSupport method that > has been added March 21th > > Cheers > Andrea > > On Thu, Apr 5, 2018 at 6:17 PM, César Martínez Izquierdo > <cesar@gmail.com> wrote: >> >> Hi again, >> >> Geoserver is properly compiling and passing tests now in the branch, >> using: >> mvn -fn clean install >> >> There is only one compilation error in the wfs module which seems to >> be unrelated with the JSR migration (PropertyNameTypeBinding is >> expecting a method in GML3EncodingUtils which does not exist). So it >> seems we are coming closer to completing the migration. >> >> César >> >> On 5 April 2018 at 17:01, César Martínez Izquierdo <cesar@gmail.com> >> wrote: >> > Hi, I've created a branch for working on Geoserver adaptation: >> > https://github.com/dispiste/geoserver/tree/jsr363_units >> > >> > I've also created a PR to allow collaboration: >> > https://github.com/geoserver/geoserver/pull/2828 >> > >> > Best regards, >> > >> > César >> > >> > On 5 April 2018 at 10:17, Jody Garnett <jody.garn...@gmail.com> wrote: >> >> I understand, the high number of files is due a series of search and >> >> replaces (as outlined in the proposal). If it helps I have a few key >> >> "huh" >> >> areas where I would like your experienced viewpoint (since your name is >> >> on >> >> the EPSG and ESRI unit formatters). I will go back and start a >> >> conversation >> >> on those points. >> >> >> >> Still I am happy enough with these changes to start a branch on GWC and >> >> GeoServer. >> >> >> >> -- >> >> Jody Garnett >> >> >> >> On 5 April 2018 at 00:17, Andrea Aime <andrea.a...@geo-solutions.it> >> >> wrote: >> >>> >> >>> Hi Jody, >> >>> whoa this is massive, 229 files changed? >> >>> I won't be able to look at it soon, next week I'm in the US and >> >>> travelling >> >>> there during the weekend, next weekend I'll probably be wiped and get >> >>> some >> >>> rest. >> >>> >> >>> Cheers >> >>> Andrea >> >>> >> >>> >> >>> On Thu, Apr 5, 2018 at 8:40 AM, Jody Garnett <jody.garn...@gmail.com> >> >>> wrote: >> >>>> >> >>>> And now some days later, the pull request passes tests and is ready >> >>>> for >> >>>> review: >> >>>> >> >>>> - https://github.com/geotools/geotools/pull/1834 >> >>>> >> >>>> I have continued to update the proposal with notes about any api >> >>>> changes >> >>>> (especially bulk search and replace). >> >>>> >> >>>> -- >> >>>> Jody Garnett >> >>>> >> >>>> On 26 March 2018 at 22:04, Jody Garnett <jody.garn...@gmail.com> >> >>>> wrote: >> >>>>> >> >>>>> The proposal page >> >>>>> (https://github.com/geotools/geotools/wiki/Migrate-Units-to-JSR-363) >> >>>>> has >> >>>>> been updated over the course of the sprint. >> >>>>> >> >>>>> The PR (https://github.com/geotools/geotools/pull/1834) is not quite >> >>>>> ready yet :( >> >>>>> >> >>>>> Cesar and myself traded of migration tasks over the course of the >> >>>>> week: >> >>>>> >> >>>>> We found the land scape of implementations to be complicated by two >> >>>>> things: >> >>>>> >> >>>>> 1) There component has both a standard implementation and a >> >>>>> reference >> >>>>> implementation . The refer
Re: [Geotools-devel] code sprint update w/ JSR 363 transition
Hi again, Geoserver is properly compiling and passing tests now in the branch, using: mvn -fn clean install There is only one compilation error in the wfs module which seems to be unrelated with the JSR migration (PropertyNameTypeBinding is expecting a method in GML3EncodingUtils which does not exist). So it seems we are coming closer to completing the migration. César On 5 April 2018 at 17:01, César Martínez Izquierdo <cesar@gmail.com> wrote: > Hi, I've created a branch for working on Geoserver adaptation: > https://github.com/dispiste/geoserver/tree/jsr363_units > > I've also created a PR to allow collaboration: > https://github.com/geoserver/geoserver/pull/2828 > > Best regards, > > César > > On 5 April 2018 at 10:17, Jody Garnett <jody.garn...@gmail.com> wrote: >> I understand, the high number of files is due a series of search and >> replaces (as outlined in the proposal). If it helps I have a few key "huh" >> areas where I would like your experienced viewpoint (since your name is on >> the EPSG and ESRI unit formatters). I will go back and start a conversation >> on those points. >> >> Still I am happy enough with these changes to start a branch on GWC and >> GeoServer. >> >> -- >> Jody Garnett >> >> On 5 April 2018 at 00:17, Andrea Aime <andrea.a...@geo-solutions.it> wrote: >>> >>> Hi Jody, >>> whoa this is massive, 229 files changed? >>> I won't be able to look at it soon, next week I'm in the US and travelling >>> there during the weekend, next weekend I'll probably be wiped and get some >>> rest. >>> >>> Cheers >>> Andrea >>> >>> >>> On Thu, Apr 5, 2018 at 8:40 AM, Jody Garnett <jody.garn...@gmail.com> >>> wrote: >>>> >>>> And now some days later, the pull request passes tests and is ready for >>>> review: >>>> >>>> - https://github.com/geotools/geotools/pull/1834 >>>> >>>> I have continued to update the proposal with notes about any api changes >>>> (especially bulk search and replace). >>>> >>>> -- >>>> Jody Garnett >>>> >>>> On 26 March 2018 at 22:04, Jody Garnett <jody.garn...@gmail.com> wrote: >>>>> >>>>> The proposal page >>>>> (https://github.com/geotools/geotools/wiki/Migrate-Units-to-JSR-363) has >>>>> been updated over the course of the sprint. >>>>> >>>>> The PR (https://github.com/geotools/geotools/pull/1834) is not quite >>>>> ready yet :( >>>>> >>>>> Cesar and myself traded of migration tasks over the course of the week: >>>>> >>>>> We found the land scape of implementations to be complicated by two >>>>> things: >>>>> >>>>> 1) There component has both a standard implementation and a reference >>>>> implementation . The reference implementation was done in floats as a toy, >>>>> and of course put into production for mobile. >>>>> >>>>> 2) Each jar has both a normal implementation, and a java8 implementation >>>>> - I presume in response to jigsaw >>>>> >>>>> Currently I am stuck on a gap in JSR 363: >>>>> >>>>> * Measure<V,Q extends Quantity>, we make use of DecimalMeasure and >>>>> VectorMeasure in the gt-coverage module. >>>>> >>>>> There is some discussion here: >>>>> https://github.com/unitsofmeasurement/unit-ri/issues/61 >>>>> >>>>> A way forward to to add to our org.geotools.util, or >>>>> org.geotools.measure class to define similar constructs. However I am not >>>>> sure how valuable these abstractions are. >>>>> -- >>>>> Jody Garnett >>>> >>>> >>>> >>>> >>>> -- >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> ___ >>>> GeoTools-Devel mailing list >>>> GeoTools-Devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Andrea Aime >>> >>> ==
Re: [Geotools-devel] code sprint update w/ JSR 363 transition
o >> senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia >> via e-mail e di procedere alla distruzione del messaggio stesso, >> cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo >> anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per >> finalità diverse, costituisce comportamento contrario ai principi dettati >> dal D.Lgs. 196/2003. >> >> The information in this message and/or attachments, is intended solely for >> the attention and use of the named addressee(s) and may be confidential or >> proprietary in nature or covered by the provisions of privacy act >> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection >> Code).Any use not in accord with its purpose, any disclosure, reproduction, >> copying, distribution, or either dissemination, either whole or partial, is >> strictly forbidden except previous formal approval of the named >> addressee(s). If you are not the intended recipient, please contact >> immediately the sender by telephone, fax or e-mail and delete the >> information in this message that has been received in error. The sender does >> not give any warranty or accept liability as the content, accuracy or >> completeness of sent messages and accepts no responsibility for changes >> made after they were sent or for other risks which arise as a result of >> e-mail transmission, viruses, etc. >> >> > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - SCOLAB: http://www.scolab.es - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Replace JScience JSR275 with JSR363
Hi, It is my intention to provide GWS/GS pull requests if needed, obviously I'll be happy if someone wants to help on it. For the moment I'm going to work on a PR for Geotools, then I'll evaluate how painful it was and what is needed for GWC/GS. Best regards, César On 19 March 2018 at 16:05, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi Jody, > looks good, will you also have corresponding GWC/GS pull requests (if at all > needed, of course)? > > Cheers > Andrea > > On Mon, Mar 19, 2018 at 3:56 PM, Jody Garnett <jody.garn...@gmail.com> > wrote: >> >> We have been working today and have made the following proposal: >> - https://github.com/geotools/geotools/wiki/Migrate-Units-to-JSR-363 >> >> So far no surprises, we will be in tomorrows GeoTools meeting if there are >> any questions, and would like to proceed with a pull request this week. >> >> -- >> Jody Garnett >> >> On 7 March 2018 at 10:28, César Martínez Izquierdo <cesar@gmail.com> >> wrote: >>> >>> Thanks Andrea and Jody for your very kind offers. >>> >>> I will be at the Bonn code sprint. I've committed to work on some >>> other tasks, but I think I could keep some time (maybe a day?) for >>> pushing this task. >>> In any case, I'll try to advance some work before the code sprint. >>> >>> I think I will start by updating the proposal you linked and trying to >>> figure out how to use unit-ri/unit-se (JSR 363 implementations). >>> Any suggestion is welcome. >>> >>> Regards, >>> >>> César >>> >>> >>> On 7 March 2018 at 08:41, Jody Garnett <jody.garn...@gmail.com> wrote: >>> > I saw the activity on jira and found the “withdrawn” proposal - >>> > https://github.com/geotools/geotools/wiki/Replace-JSR-275-Units-Library >>> > >>> > If we can update this with a plan I would be pleased to work on this >>> > during >>> > the OSGeo code sprint. >>> > On Tue, Mar 6, 2018 at 9:21 AM Jens Auer <jens.a...@betaversion.net> >>> > wrote: >>> >> >>> >> Hi, >>> >> >>> >> I have to admit that I sent the mails last year and wanted to work on >>> >> migrating to jsr363. However, when I quickly ran into problems when I >>> >> wanted >>> >> to use jsr363 in our project in a limited way just in our own classes. >>> >> We >>> >> have multiple dependencies that depend on JScience /jsr275, and using >>> >> both >>> >> jsr363 and jsr275 in a project leads to many problems because both use >>> >> the >>> >> javax.measure package and some identical class names. I guess it would >>> >> have >>> >> been easier if jsr363 used another package, but because of these >>> >> issues I >>> >> stopped working on the migration. >>> >> >>> >> Best wishes, >>> >> Jens >>> >> >>> >> -Ursprüngliche Nachricht- >>> >> Von: César Martínez Izquierdo <cesar@gmail.com> >>> >> Gesendet: Freitag, 2. März 2018 11:28 >>> >> An: geotools-devel@lists.sourceforge.net >>> >> Cc: jens.a...@betaversion.net; Jody Garnett <jody.garn...@gmail.com> >>> >> Betreff: Replace JScience JSR275 with JSR363 >>> >> >>> >> Hi, >>> >> Last year there was a thread on the list regarding the migration from >>> >> JScience/JSR275 to JSR363, although I assume that no progress was >>> >> finally >>> >> achieved: >>> >> >>> >> >>> >> >>> >> https://www.mail-archive.com/geotools-devel@lists.sourceforge.net/msg38174.html >>> >> >>> >> I'd like to help on this effort, if there is still interest in >>> >> migrating >>> >> to JSR363. >>> >> >>> >> The use of JSR275 is a problem since there are collisions on >>> >> package/classes/method signatures between JSR363 and JSR363, so you >>> >> can't >>> >> combine Geotools with any library using JS363. >>> >> >>> >> Note that JSR275 is used by the "forked" GeoAPI APIs used in Geotools, >>> >> so >>> >> this change will imply some method signature modifications on that >>> >> API. >>> >>
Re: [Geotools-devel] Potential contributions to referenging module
Hi, I have finally prepared a pull request to add a "findOperations" method to CoordinateOperationFactory: https://github.com/geotools/geotools/pull/1821 The goal of the method is to be able to find all the available operations from a source to a target CRS (by contrast with the existing "createOperation" method, which only returns the default operation). This is particularly useful for CRSs having different datums, for which many operations are sometimes defined, producing very different results. Now, regarding implementation, I had to modify a number of methods in DefaultCoordinateOperationFactory, which are central for selecting of transformations. This change also concerns the createOperation method (the one used by the CRS.findMathTransform method). I'd like to provide a simpler patch, but these methods are recursively called and the "default" selection happens very deep in this recursion. Overall, I am quite confident about the correctness of the code, but anyway I'd appreciate some suggestions regarding some ESPG codes to test the most unusual transformation paths (such as compound CRS to Geographic3D and compound to compound CRSs). I'd then add tests cases for them. Best regards, César Martínez On 4 March 2018 at 09:59, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi Cesar, > the referencing module second name is indeed "painful". Nothing new there > I'm afraid :-) > > Cheers > Andrea > > > On Fri, Mar 2, 2018 at 5:32 PM, César Martínez Izquierdo > <cesar@gmail.com> wrote: >> >> Thanks Andrea for the pointers, >> >> I am working on it, although it is becoming more painful that I expected. >> Anyway, I will create a pull request when it is ready, then we can >> discuss if it is suitable to be included in trunk. >> >> Best regards, >> >> César >> >> On 23 February 2018 at 18:01, Andrea Aime <andrea.a...@geo-solutions.it> >> wrote: >> > Hi Cesar, >> > sure, it seems like a nice addition. >> > >> > Just in case you have not found these already, here are the contribution >> > guides: >> > http://docs.geotools.org/latest/developer/procedures/contribute.html >> > https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md >> > >> > If you have any questions, ask away :-) >> > >> > Cheers >> > Andrea >> > >> > >> > On Fri, Feb 23, 2018 at 3:24 PM, César Martínez Izquierdo >> > <cesar@gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> We are evaluating using Geotools as the basis for our CRS management >> >> libraries on gvSIG project (a desktop, Java-based GIS application). >> >> >> >> We have performed some tests to ensure we can implement all our >> >> current use-cases using Geotools. Most of them can be easily >> >> implemented, but I don't find an evident way to list available >> >> operations to convert/transform between two CRSs (when more than one >> >> operation is available on the EPSG database). >> >> >> >> I am aware it is possible to use CRS.findOperation(source, target) to >> >> get "the preferred operation", but in this way we can't offer the >> >> users the possibility to choose the transformation themselves. >> >> >> >> Ideally, I would expect a method like: >> >> Set ops = CRS.findOperations(source, target); >> >> >> >> which would mean adding a new method in CoordinateOperationFactory: >> >> >> >> Set listOperations(sourceCRS, targetCRS) >> >> >> >> I believe it would be quite simple to add this method in >> >> CoordinateOperationFactory. As far as I've seen, it would need some >> >> changes in DefaultCoordinateOperationFactory, >> >> BufferedCoordinateOperationFactory and AuthorityBackedFactory, but >> >> they are mostly method additions and some code refactoring. >> >> >> >> We are wondering if you would accept this contribution, as it is >> >> currently the main blocker for going forward. >> >> >> >> Best regards, >> >> >> >> César Martínez Izquierdo >> >> >> >> >> >> >> >> >> >> -- >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> >>César Martínez Izquierdo >> >>GIS developer >> >>- - - - - - - - - - - - - - - - - - - - >> >>SCOLAB: http://www.sco
Re: [Geotools-devel] Replace JScience JSR275 with JSR363
Thanks Andrea and Jody for your very kind offers. I will be at the Bonn code sprint. I've committed to work on some other tasks, but I think I could keep some time (maybe a day?) for pushing this task. In any case, I'll try to advance some work before the code sprint. I think I will start by updating the proposal you linked and trying to figure out how to use unit-ri/unit-se (JSR 363 implementations). Any suggestion is welcome. Regards, César On 7 March 2018 at 08:41, Jody Garnett <jody.garn...@gmail.com> wrote: > I saw the activity on jira and found the “withdrawn” proposal - > https://github.com/geotools/geotools/wiki/Replace-JSR-275-Units-Library > > If we can update this with a plan I would be pleased to work on this during > the OSGeo code sprint. > On Tue, Mar 6, 2018 at 9:21 AM Jens Auer <jens.a...@betaversion.net> wrote: >> >> Hi, >> >> I have to admit that I sent the mails last year and wanted to work on >> migrating to jsr363. However, when I quickly ran into problems when I wanted >> to use jsr363 in our project in a limited way just in our own classes. We >> have multiple dependencies that depend on JScience /jsr275, and using both >> jsr363 and jsr275 in a project leads to many problems because both use the >> javax.measure package and some identical class names. I guess it would have >> been easier if jsr363 used another package, but because of these issues I >> stopped working on the migration. >> >> Best wishes, >> Jens >> >> -Ursprüngliche Nachricht- >> Von: César Martínez Izquierdo <cesar@gmail.com> >> Gesendet: Freitag, 2. März 2018 11:28 >> An: geotools-devel@lists.sourceforge.net >> Cc: jens.a...@betaversion.net; Jody Garnett <jody.garn...@gmail.com> >> Betreff: Replace JScience JSR275 with JSR363 >> >> Hi, >> Last year there was a thread on the list regarding the migration from >> JScience/JSR275 to JSR363, although I assume that no progress was finally >> achieved: >> >> >> https://www.mail-archive.com/geotools-devel@lists.sourceforge.net/msg38174.html >> >> I'd like to help on this effort, if there is still interest in migrating >> to JSR363. >> >> The use of JSR275 is a problem since there are collisions on >> package/classes/method signatures between JSR363 and JSR363, so you can't >> combine Geotools with any library using JS363. >> >> Note that JSR275 is used by the "forked" GeoAPI APIs used in Geotools, so >> this change will imply some method signature modifications on that API. >> >> Best regards, >> >> César Martínez >> >> >> -- >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>César Martínez Izquierdo >>GIS developer >>- - - - - - - - - - - - - - - - - - - - >>SCOLAB: http://www.scolab.es >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> --- >> Diese E-Mail wurde von AVG auf Viren geprüft. >> http://www.avg.com >> >> > -- > -- > Jody Garnett -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - SCOLAB: http://www.scolab.es - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Replace JScience JSR275 with JSR363
Hi, Last year there was a thread on the list regarding the migration from JScience/JSR275 to JSR363, although I assume that no progress was finally achieved: https://www.mail-archive.com/geotools-devel@lists.sourceforge.net/msg38174.html I'd like to help on this effort, if there is still interest in migrating to JSR363. The use of JSR275 is a problem since there are collisions on package/classes/method signatures between JSR363 and JSR363, so you can't combine Geotools with any library using JS363. Note that JSR275 is used by the "forked" GeoAPI APIs used in Geotools, so this change will imply some method signature modifications on that API. Best regards, César Martínez -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - SCOLAB: http://www.scolab.es - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Potential contributions to referenging module
Thanks Andrea for the pointers, I am working on it, although it is becoming more painful that I expected. Anyway, I will create a pull request when it is ready, then we can discuss if it is suitable to be included in trunk. Best regards, César On 23 February 2018 at 18:01, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi Cesar, > sure, it seems like a nice addition. > > Just in case you have not found these already, here are the contribution > guides: > http://docs.geotools.org/latest/developer/procedures/contribute.html > https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md > > If you have any questions, ask away :-) > > Cheers > Andrea > > > On Fri, Feb 23, 2018 at 3:24 PM, César Martínez Izquierdo > <cesar@gmail.com> wrote: >> >> Hi, >> >> We are evaluating using Geotools as the basis for our CRS management >> libraries on gvSIG project (a desktop, Java-based GIS application). >> >> We have performed some tests to ensure we can implement all our >> current use-cases using Geotools. Most of them can be easily >> implemented, but I don't find an evident way to list available >> operations to convert/transform between two CRSs (when more than one >> operation is available on the EPSG database). >> >> I am aware it is possible to use CRS.findOperation(source, target) to >> get "the preferred operation", but in this way we can't offer the >> users the possibility to choose the transformation themselves. >> >> Ideally, I would expect a method like: >> Set ops = CRS.findOperations(source, target); >> >> which would mean adding a new method in CoordinateOperationFactory: >> >> Set listOperations(sourceCRS, targetCRS) >> >> I believe it would be quite simple to add this method in >> CoordinateOperationFactory. As far as I've seen, it would need some >> changes in DefaultCoordinateOperationFactory, >> BufferedCoordinateOperationFactory and AuthorityBackedFactory, but >> they are mostly method additions and some code refactoring. >> >> We are wondering if you would accept this contribution, as it is >> currently the main blocker for going forward. >> >> Best regards, >> >> César Martínez Izquierdo >> >> >> >> >> -- >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>César Martínez Izquierdo >>GIS developer >>- - - - - - - - - - - - - - - - - - - - >>SCOLAB: http://www.scolab.es >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > > -- > > Regards, > > Andrea Aime > > == > GeoServer Professional Services from the experts! Visit http://goo.gl/it488V > for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via di Montramito 3/A > 55054 Massarosa (LU) > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 > > Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i > file/s allegato/i sono da considerarsi strettamente riservate. Il loro > utilizzo è consentito esclusivamente al destinatario del messaggio, per le > finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio > senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia > via e-mail e di procedere alla distruzione del messaggio stesso, > cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo > anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per > finalità diverse, costituisce comportamento contrario ai principi dettati > dal D.Lgs. 196/2003. > > The information in this message and/or attachments, is intended solely for > the attention and use of the named addressee(s) and may be confidential or > proprietary in nature or covered by the provisions of privacy act > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection > Code).Any use not in accord with its purpose, any disclosure, reproduction, > copying, distributio
[Geotools-devel] Potential contributions to referenging module
Hi, We are evaluating using Geotools as the basis for our CRS management libraries on gvSIG project (a desktop, Java-based GIS application). We have performed some tests to ensure we can implement all our current use-cases using Geotools. Most of them can be easily implemented, but I don't find an evident way to list available operations to convert/transform between two CRSs (when more than one operation is available on the EPSG database). I am aware it is possible to use CRS.findOperation(source, target) to get "the preferred operation", but in this way we can't offer the users the possibility to choose the transformation themselves. Ideally, I would expect a method like: Set ops = CRS.findOperations(source, target); which would mean adding a new method in CoordinateOperationFactory: Set listOperations(sourceCRS, targetCRS) I believe it would be quite simple to add this method in CoordinateOperationFactory. As far as I've seen, it would need some changes in DefaultCoordinateOperationFactory, BufferedCoordinateOperationFactory and AuthorityBackedFactory, but they are mostly method additions and some code refactoring. We are wondering if you would accept this contribution, as it is currently the main blocker for going forward. Best regards, César Martínez Izquierdo -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - SCOLAB: http://www.scolab.es - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Revisiting the UniqueVisitor
Some weeks ago, I asked about the UniqueVisitor on the user mailing list (see [1]) for building queries similar to: SELECT DISTINCT(name) FROM osmadmlv2 ORDER BY name asc OFFSET 2 LIMIT 4 The conclusion is that UniqueVisitor can't currently produce this result. It was suggested that the optimized implementation on JDBCDataStore could be modified to take into account sorting, while a TreeSet could be used for the general UniqueVisitor implementation. However, I think there is a deeper, conceptual problem on this approach and I am thinking on a cleaner way to solve this problem. The real problem is that a visitor is supposed to visit *only* the elements of a feature collection, but the optimized JDBCDataStore implementation is running a new query potentially bringing new elements to the result. This is necessary because ORDER BY and DISTINCT has to be calculated first, then offset and limit is applied (otherwise the result is totally different). So probably this is not really fitting on a visitor but should be architectured in a different way. To make it clearer, think on the following records: [sun, bean, blue, pea, red, pea, red, blue, green, clock]. The original query will produce: [clock, green, pea, red] Implementing the UniqueVisitor using a TreeSet, together with the proper Query (SortBy, startIndex, maxFeatures) would produce: [bean, blue, blue, clock] (original collection) - [bean, blue, clock] (visited collection) which is a totally different result. So maybe this should be implemented in a different way (a Hint was suggested in the past, see [2]). Note that I am still not offering myself to implement it, but I might do it depending on the expected amount of work to do so. Does it sound reasonable for you? Best regards, César Martínez [1] http://osgeo-org.1560.x6.nabble.com/UniqueVisitor-and-sorted-and-paged-queries-td5135576.html [2] http://osgeo-org.1560.x6.nabble.com/distinct-query-hint-td5049204.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - Blog: http://geotechnotes.wordpress.com/ ETC-SIA: http://sia.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] DbaseFileWriter and number of registers
El día 18 de octubre de 2009 23:33, Andrea Aime aa...@opengeo.org escribió: [SNIP] As sorry, I misread your patch. Yeah, I will have a look about integrating it. No promises on when, this week we have FOSS4G going and we're all busy with it. Cheers Andrea OK, I'll be patient. I've opened an issue in JIRA so that it doesn't get forgotten: http://jira.codehaus.org/browse/GEOT-2794 Regards, César -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - ETC-LUSI: http://etc-lusi.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] DbaseFileWriter and number of registers
2009/10/17 Andrea Aime aa...@opengeo.org: [SNIP] If you want to make it easier to use the patch could look into recording the number of records in a field and then have the close method (or add a flush method) that does write out the header. Hello Andreas, that is exactly what my patch does (just writing the header in the close method). Would you consider including this changes in GeoTools? Best regards, César -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - ETC-LUSI: http://etc-lusi.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] DbaseFileWriter and number of registers
Yesterday I sent this to user's list, but I think is most suitable here.
Note that I've created a patch which solves the problem, please have a
look at it.
I've been working on 2.5.x branch.
Original message:
--
Hello list,
I'm writing a DBF file using a code like this:
DbaseFileHeader header = getHeader();
WritableByteChannel out = new FileOutputStream(filename).getChannel();
DbaseFileWriter writer = new DbaseFileWriter(header, out);
for (int i=0; iNUMROWS; i++) {
writer.write(getRow());
}
writer.close();
I'd expect that when I close the file, the number of registers gets
updated in the DBF header.
However, it seems that it is not actually updated and the header ends
with a value of 0 (zero) registers, which means that
DbaseFileReader.hasNext() will always return false for this file.
This is a pity, it means I can't write a proper DBF unless I know the
number of registers in advance.
Am I missing something here?
Regards,
César
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
César Martínez Izquierdo
GIS developer
- - - - - - - - - - - - - - - - - - - -
ETC-LUSI: http://etc-lusi.eionet.europa.eu/
Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DbaseFileWriter.java.patch
Description: Binary data
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
