Re: [Geotools-devel] Updated contributor guide to reflect small-patch policy
Just a quick query. Where is this information recorded? Who signed which agreement and when. I haven't seen it in the code base (I could be wrong). Are there other sources of administrative documents? Are these restricted to the PMC? I understand if this is so. Or have I muddied the waters even further? -Original Message- From: Ben Caradoc-Davies [mailto:ben.caradoc-dav...@csiro.au] Sent: Monday, 17 June 2013 1:24 PM To: Andrea Aime Cc: geotools-devel@lists.sourceforge.net Subject: Re: [Geotools-devel] Updated contributor guide to reflect small-patch policy On 14/06/13 16:28, Andrea Aime wrote: > What worries me is that we demand a test to be added for each > contribution, so people will be hard pressed to find an existing class > to use in order to contribute the fix without having to add a file. > Maybe we can be gentle and add a empty test class for them to work in > :-p There are heaps of test classes. Anyone needing a new one can sign a contributor agreement. The new process is easy. An even easier one would be a form in which a contributor fills in the blanks and sends a plain text email to osgeo and themself. Timestamps and recorded IP addresses should be sufficient, but then I am not a lawyer. Kind regards, -- Ben Caradoc-Davies Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Updated contributor guide to reflect small-patch policy
Allegedly here: http://wiki.osgeo.org/wiki/Contributor_Agreements_Received#GeoTools Does not seem up-to-date. On 17/06/13 11:54, Brett Walker wrote: > Just a quick query. > > Where is this information recorded? > Who signed which agreement and when. I haven't seen it in the code base (I > could be wrong). Are there other sources of administrative documents? Are > these restricted to the PMC? I understand if this is so. > > Or have I muddied the waters even further? > > > -Original Message- > From: Ben Caradoc-Davies [mailto:ben.caradoc-dav...@csiro.au] > Sent: Monday, 17 June 2013 1:24 PM > To: Andrea Aime > Cc: geotools-devel@lists.sourceforge.net > Subject: Re: [Geotools-devel] Updated contributor guide to reflect > small-patch policy > > On 14/06/13 16:28, Andrea Aime wrote: >> What worries me is that we demand a test to be added for each >> contribution, so people will be hard pressed to find an existing class >> to use in order to contribute the fix without having to add a file. >> Maybe we can be gentle and add a empty test class for them to work in >> :-p > > There are heaps of test classes. Anyone needing a new one can sign a > contributor agreement. > > The new process is easy. An even easier one would be a form in which a > contributor fills in the blanks and sends a plain text email to osgeo and > themself. Timestamps and recorded IP addresses should be sufficient, but then > I am not a lawyer. > > Kind regards, > > -- > Ben Caradoc-Davies Software Engineer CSIRO > Earth Science and Resource Engineering Australian Resources Research Centre > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > -- Ben Caradoc-Davies Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Updated contributor guide to reflect small-patch policy
On 14/06/13 16:28, Andrea Aime wrote: > What worries me is that we demand a test to be added for each > contribution, so people will be hard pressed > to find an existing class to use in order to contribute the fix without > having to add a file. > Maybe we can be gentle and add a empty test class for them to work in :-p There are heaps of test classes. Anyone needing a new one can sign a contributor agreement. The new process is easy. An even easier one would be a form in which a contributor fills in the blanks and sends a plain text email to osgeo and themself. Timestamps and recorded IP addresses should be sufficient, but then I am not a lawyer. Kind regards, -- Ben Caradoc-Davies Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Graduating gt-transform to supported status
+1 for putting it in library. This looks almost like it could go into main, but keeping it in a separate module is great if you can. -0 for factories. I think this is a component that could in the future be used to build a transforming factory; I do not think that you should feel obliged to write one now. Kind regards, Ben. On 14/06/13 20:22, Andrea Aime wrote: > Hi, > I'm writing you to start the process to graduate the gt-transform module > to supported status. > > For those that don't know, the gt-transform module provides a way to > create wrappers around SimpleFeatureSource/SimpleFeatureStore that do > alter the attributes exposed via: > * attribute selection > * attribute renaming > * creation of new attributes as expressions of other attributes > > All of the above is achieved by associating the new set of attributes > each with a OGC Expression, like in the test cases, see the three > methods setting up some transformations: > > https://github.com/geotools/geotools/blob/master/modules/unsupported/transform/src/test/java/org/geotools/data/transform/AbstractTransformTest.java > > The module takes care of all needed filter and name transformations, and > if the transformations are invertible (that is, pretty much just > attribute rename at the moment) then it also preserves the writability > of the original SimpleFeatureStore. > > The test coverage is good (69%), IP wise there are no issues, wrote all > the code myself (though I guess I need to add a review.txt in there, > right?), there are no bug reports in jira. > There are no docs, but I plan to add a page of docs turning the unit > tests into examples along with the pull request that will graduate the > module. > > Ah, the final location is a bit of a mystery... this thing is not a > plugin in the strict sense, there is no factory and no store, you are > supposed to call TransformFactory.transform(source, targetName, > listOfAttributeDefinitions) > in order to get the transformed source/store. > As such is more similar to a ReprojectingFeatureCollection than a stand > alone data store... so... where should it go? Library? > However, setting up a factory and store is not un-thinkable, but it > would be a bit odd to have a store whose one of the source params is > another store... > > Any feedback? > > Cheers > Andrea > > > -- > == > Our support, Your Success! Visit http://opensdi.geo-solutions.it for > more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > --- > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > > > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ben Caradoc-Davies Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Sosnoski license <> sos no kill license?
Updated pages: - http://docs.geotools.org/latest/userguide/welcome/license.html - http://docs.geotools.org/latest/userguide/library/main/index.html - http://docs.geotools.org/stable/userguide/welcome/license.html - http://docs.geotools.org/stable/userguide/library/main/index.html -- Jody Garnett On Monday, 17 June 2013 at 12:01 AM, Jody Garnett wrote: > Okay It is fixed, also managed to fix the links in the README.html (a fair > number were broken when we moved build instructions to the user guide) > > -- > Jody Garnett > > > On Wednesday, 12 June 2013 at 12:09 PM, Ben Caradoc-Davies wrote: > > > Please. I thought it was a standing joke! > > > > On 11/06/13 16:38, Jody Garnett wrote: > > > Evening Ben: > > > > > > Reviewing meeting notes from a couple weeks ago, you mentioned that the > > > SOSNOKILL license appears to be BSD? Indeed Sosnoski-License. > > > > > > While I am the first to admire the power of a typo, if this is indeed > > > the case I would like to fix our docs. > > > > > > -- > > > Jody Garnett > > > > > > > > > -- > > Ben Caradoc-Davies > (mailto:ben.caradoc-dav...@csiro.au)> > > Software Engineer > > CSIRO Earth Science and Resource Engineering > > Australian Resources Research Centre > > > > > > > > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4494) Improve ImagePyramidFormat accepts checks
Simone Giannecchini created GEOT-4494 Improve ImagePyramidFormat accepts checks Issue Type: Improvement Affects Versions: 10-beta Assignee: Unassigned Components: imagepyramid plugin Created: 16/Jun/13 5:55 PM Description: We need to improve the way we perform the checks in the accepts method of ImagePyramidFormat since right now it is too broad and interferes with ImageMosaic. Project: GeoTools Priority: Minor Reporter: Simone Giannecchini This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] A pull request with scalability related improvements
Hi, while working on some benchmarks for an improved pisces renderer for OpenJDK 8 (see http://mail.openjdk.java.net/pipermail/2d-dev/2013-June/003475.html, sorry for the table formatting, it's HTML...) I stumbled into three significant roadblocks in the GeoTools code base that limited scalability, and tried to fix them: https://jira.codehaus.org/browse/GEOT-4491 https://jira.codehaus.org/browse/GEOT-4492 https://jira.codehaus.org/browse/GEOT-4493 The pull request with the three commits is here: https://github.com/geotools/geotools/pull/213 I'd be happy if someone could give it a review. In particular the first one also limits scalability for raster data access, as coverage factories also need the default hints (Simone was just telling me about that a few days ago) Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4493) CRS repeated checks for axis flipping system variable hampers scalability
Andrea Aime created GEOT-4493 CRS repeated checks for axis flipping system variable hampers scalability Issue Type: Bug Assignee: Andrea Aime Components: referencing Created: 16/Jun/13 3:15 PM Description: The system variable takes effect only when the factories are being fetched the first time, so evaluate it once there and reset it on CRS.reset, but avoid computing it over and over Project: GeoTools Priority: Major Reporter: Andrea Aime This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4492) DataUtilities.fileToURL checks system variable fo OS every time, hampering scalability
Andrea Aime created GEOT-4492 DataUtilities.fileToURL checks system variable fo OS every time, hampering scalability Issue Type: Bug Assignee: Andrea Aime Components: main Created: 16/Jun/13 3:14 PM Description: Access to System.getProperty() is synchronized internally, accessing it over and over to check if the OS changed is not useful and hampers scalability Project: GeoTools Priority: Major Reporter: Andrea Aime This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4491) Hints.getDefault() implementation hampers scalability
Andrea Aime created GEOT-4491 Hints.getDefault() implementation hampers scalability Issue Type: Bug Assignee: Andrea Aime Components: metadata Created: 16/Jun/13 3:12 PM Description: The GLOBAL hints are synchronized in each and every access, this hampers scalability as many bits of code (factories, attribute builders) need to get the default hints. Use a concurrent hash map instead. Project: GeoTools Priority: Major Reporter: Andrea Aime This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Sosnoski license <> sos no kill license?
Okay It is fixed, also managed to fix the links in the README.html (a fair number were broken when we moved build instructions to the user guide) -- Jody Garnett On Wednesday, 12 June 2013 at 12:09 PM, Ben Caradoc-Davies wrote: > Please. I thought it was a standing joke! > > On 11/06/13 16:38, Jody Garnett wrote: > > Evening Ben: > > > > Reviewing meeting notes from a couple weeks ago, you mentioned that the > > SOSNOKILL license appears to be BSD? Indeed Sosnoski-License. > > > > While I am the first to admire the power of a typo, if this is indeed > > the case I would like to fix our docs. > > > > -- > > Jody Garnett > > > > > -- > Ben Caradoc-Davies (mailto:ben.caradoc-dav...@csiro.au)> > Software Engineer > CSIRO Earth Science and Resource Engineering > Australian Resources Research Centre > > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Graduating gt-transform to supported status
Move it later if/when that happens. Oh and +1 it is a great bit of functionality. -- Jody Garnett On Saturday, 15 June 2013 at 4:41 PM, Andrea Aime wrote: > On Sat, Jun 15, 2013 at 8:21 AM, Jody Garnett (mailto:jody.garn...@gmail.com)> wrote: > > > Ah, the final location is a bit of a mystery... this thing is not a > > > plugin in the strict sense, there is no factory and no store, you are > > > supposed to call TransformFactory.transform(source, targetName, > > > listOfAttributeDefinitions) in order to get the transformed source/store. > > You could consider it for extension then? (i.e. additional functionality > > built onto of the core library). > > That works for me as well, have no strong opinion on the location. > > > > As such is more similar to a ReprojectingFeatureCollection than a stand > > > alone data store... so... where should it go? Library? > > > However, setting up a factory and store is not un-thinkable, but it would > > > be a bit odd to have a store whose one of the source params is another > > > store... > > > > > > > > > > > > > > > Actually that is valid, if you look at pre generalised feature support, the > > connection parameters are used to "lookup" other stores in the hosting > > application's catalog. > > > > > Right. Which would bring the module closer to plugin, but as I said, at the > moment there is no plan to make a store out of it, just > FeatureSource/FeatureStore > wrappers. Should we put it in plugins under the hope that someone will write > a datastore with it? Or move it later if/when that happens? > > Cheers > Andrea > > > -- > == > Our support, Your Success! Visit http://opensdi.geo-solutions.it for more > information. > == > > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > --- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4490) DB2 extent calculation performance for large data sets is not acceptable
Christian Mueller created GEOT-4490 DB2 extent calculation performance for large data sets is not acceptable Issue Type: Bug Affects Versions: 9.2 Assignee: Christian Mueller Components: jdbc-db2 plugin Created: 16/Jun/13 4:15 AM Description: The official way to calculate an extent is a statement like this. SELECT ST_GetAggrResult(MAX(ST_BuildMBRAggr (geometry))) FROM sample_points Unfortunately, this performs badly for large data sets. (Tested with 8 million rows containing simple squares --> 90 seconds). The alternative is select min(st_minx(geom),min(st_miny(geom),. This statement needs only 20 seconds. Additionally, since DB2 V10 the extent calculation can be done during registering a spatial attribute. (Registering the attribute after populating the table). The fix checks for precalculated extents in the system table before calculating the extent on the fly. Project: GeoTools Priority: Major Reporter: Christian Mueller This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4489) JDBCDataStore - incorrect extent calculation in case of multiple geometry attributes
Christian Mueller created GEOT-4489 JDBCDataStore - incorrect extent calculation in case of multiple geometry attributes Issue Type: Bug Affects Versions: 9.2 Assignee: Christian Mueller Components: jdbc Created: 16/Jun/13 3:32 AM Description: The method buildEnvelopeAggregates iterates over all geometry columns but always passes the SQL attribute name of the default geometry to the SQL dialect. Project: GeoTools Priority: Major Reporter: Christian Mueller This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
