Re: [Geotools-devel] (no subject)
Thank you for your advice. I will choose to use the way you recommended Best wishes! Tiandy Ian Turton 于2023年5月22日 周一下午11:48写道： > As Mark suggested please try to use `gt-geojson-core` as we are trying to > deprecate the `gt-geojson` module which relies on an older and unsupported > dependency. > > Ian > > On Mon, 22 May 2023 at 16:22, pengfei tian wrote: > >> Hi, >> I found GeoJSONUtil.parse(featureCollectionHandler, >> featureCollectionJson,false) cant return FeatureCollection, so I think >> FeatureCollectionHandler >> should extends DelegatingHandler >> >> GeoJSONUtil: >> https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/GeoJSONUtil.java >> >> FeatureCollectionHandler:https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/feature/FeatureCollectionHandler.java >> >> If this need to be fixed , please let me try to do that. >> >> >> ___ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > -- > Ian Turton > ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
As Mark suggested please try to use `gt-geojson-core` as we are trying to deprecate the `gt-geojson` module which relies on an older and unsupported dependency. Ian On Mon, 22 May 2023 at 16:22, pengfei tian wrote: > Hi, > I found GeoJSONUtil.parse(featureCollectionHandler, > featureCollectionJson,false) cant return FeatureCollection, so I think > FeatureCollectionHandler > should extends DelegatingHandler > > GeoJSONUtil: > https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/GeoJSONUtil.java > > FeatureCollectionHandler:https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/feature/FeatureCollectionHandler.java > > If this need to be fixed , please let me try to do that. > > Best wishes! > Tiandy > > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ian Turton ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
You are free to try and propose a pull request. Alternatively you could look into the geojson-core module and https://github.com/geotools/geotools/blob/48547967e75f2ef841751c3950b01e88cd5683e7/modules/unsupported/geojson-core/src/main/java/org/geotools/data/geojson/GeoJSONReader.java#L300 Op ma 22 mei 2023 om 17:22 schreef pengfei tian : > Hi, > I found GeoJSONUtil.parse(featureCollectionHandler, > featureCollectionJson,false) cant return FeatureCollection, so I think > FeatureCollectionHandler > should extends DelegatingHandler > > GeoJSONUtil: > https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/GeoJSONUtil.java > > FeatureCollectionHandler:https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/feature/FeatureCollectionHandler.java > > If this need to be fixed , please let me try to do that. > > Best wishes! > Tiandy > > ___ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Disclaimer; This message is just a reflection of what I thought at the time of sending. The message may contain information that is not intended for you or that you don't understand. ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Hi, I found GeoJSONUtil.parse(featureCollectionHandler, featureCollectionJson,false) cant return FeatureCollection, so I think FeatureCollectionHandler should extends DelegatingHandler GeoJSONUtil: https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/GeoJSONUtil.java FeatureCollectionHandler:https://github.com/geotools/geotools/blob/main/modules/unsupported/geojson/src/main/java/org/geotools/geojson/feature/FeatureCollectionHandler.java If this need to be fixed , please let me try to do that. Best wishes! Tiandy ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Hi Jim: We need to jump through a couple of hoops here; some evidence you have read the developers guide; sign a code contribution agreement etc. The developers guide has the details here: - http://docs.codehaus.org/display/GEOT/2+Committers You can get back to the email list when you have an osgeo id and have sent away the code contribution agreement. I also note that the process module is unsupported; however it does have two module maintainers listed (Michael and Graham). One of them will need to review your work; or otherwise indicate that they are happy working with you. The wps module is only manned by Graham right now (who we have not heard from in over a year). As such we may be able to mark it as up for grabs if you or John would like to look after it? The xsd-wps module is managed by Justin so you will need to submit any patches to him. Jody On Wed, Mar 17, 2010 at 1:00 PM, Jim Groffen jim.grof...@lisasoft.com wrote: Hello all, My name is Jim Groffen and I work at LISASoft in Adelaide, Australia. I'm working with Landgate in WA on improvements to the uDig and GeoTools WPS support to coincide with the OWS-7 testbed. This work will involve testing support for WPS 1.0.0 and general feature enhancements in uDig. It looks like there are a few other people looking at the WPS module around the same time - that's handy :) Could I get commit access to WPS module? Thanks! Jim Groffen. The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Jody Garnett ha scritto: Hi Jim: We need to jump through a couple of hoops here; some evidence you have read the developers guide; sign a code contribution agreement etc. The developers guide has the details here: - http://docs.codehaus.org/display/GEOT/2+Committers You can get back to the email list when you have an osgeo id and have sent away the code contribution agreement. I also note that the process module is unsupported; however it does have two module maintainers listed (Michael and Graham). One of them will need to review your work; or otherwise indicate that they are happy working with you. The wps module is only manned by Graham right now (who we have not heard from in over a year). As such we may be able to mark it as up for grabs if you or John would like to look after it? The xsd-wps module is managed by Justin so you will need to submit any patches to him. I'm going to work some on GeoServer WPS in the following months so I'd like to review the patches if possible Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
The wps module is only manned by Graham right now (who we have not heard from in over a year). As such we may be able to mark it as up for grabs if you or John would like to look after it? I'm going to work some on GeoServer WPS in the following months so I'd like to review the patches if possible Thanks Andrea that would be kinder then throwing Jim / John to the wolves. Jody -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Michael Bedward ha scritto: We have wolves ? Oddly enough for Jody's answer, I use the represent myself as one: http://www.ohloh.net/accounts/aaime But I guess Jody was referring to committing changes without the safety net of a review. Cheers Andrea On 17 March 2010 18:55, Jody Garnett wrote: Thanks Andrea that would be kinder then throwing Jim / John to the wolves. Jody -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Ah - this explains the low growling and gnashing of teeth that I can hear in the background sometimes when there's been one too many dumb questions on the user list. On 17 March 2010 21:23, Andrea Aime aa...@opengeo.org wrote: Michael Bedward ha scritto: We have wolves ? Oddly enough for Jody's answer, I use the represent myself as one: http://www.ohloh.net/accounts/aaime -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
We can provide dingoes if required. On 17/03/10 18:22, Michael Bedward wrote: We have wolves ? On 17 March 2010 18:55, Jody Garnett wrote: Thanks Andrea that would be kinder then throwing Jim / John to the wolves. Jody -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Hello all, My name is Jim Groffen and I work at LISASoft in Adelaide, Australia. I'm working with Landgate in WA on improvements to the uDig and GeoTools WPS support to coincide with the OWS-7 testbed. This work will involve testing support for WPS 1.0.0 and general feature enhancements in uDig. It looks like there are a few other people looking at the WPS module around the same time - that's handy :) Could I get commit access to WPS module? Thanks! Jim Groffen. The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Hi all, We have 16bit geotiff bathymetrical data ( 1 band ). We serve this now via Geoserver, after we have converted these 16bit gray into a 24bit colored geotiff. This coloring, so the converting from 16bit gray into 24bit color should happen on the fly, so that the user can provide an extra parameter in the html get request that he is making. Can anybody give me an idea about how I could solve this by probably programming some extra decoder or so Thanks, Stephen --- This e-mail, any attachments and the information it contains are confidential and meant only for the use of the addressee(s) only. Access to this e-mail by anyone other than the addressee(s) is unauthorized. If you are not the intended addressee (or responsible for delivery of the message to such person), you may not use, copy, distribute or deliver to anyone this message (or any part of its contents) or take any action in reliance on it. In such case, you should destroy this message and notify the sender immediately. If you have received this e-mail in error, please notify us immediately by e-mail or telephone and delete the e-mail from any computer. All reasonable precautions have been taken to ensure no viruses are present in this e-mail and its attachments. As our company cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments we recommend that you subject these to your virus checking procedures prior to use. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Since I need the db2 plugin I tested the following: 1) Duplicate all classes from org.geotools.data.mysql, renaming MySql* to DB2*. 2) Adapting the classes and tests for DB2 Spatial Extender 3) Copy DB2SqlEncoder from David Now I am tried to run the tests. 90% of them result in failures or errors. Some first investigations resulted in the 2 following bugs. GEOT-1991 GEOT-1992 There are some other issues like the method wirteLiteral(..) which has no handling for Date, Timestamp and so on. The next issue is that there is no DB2PrepeardFilterToSQL class. These encodings are rather complex, e.g using a line wkb param needs the following sql expression db2gse.st_linefromwkb(CAST(? as BLOB(2G),srid) Conclusion: I think there is something to do. The question is if I should investigate further to migrate Davids db2 module in the new structure (which has the advantage of the test suite) or should I stop ?. A matter of fact is that at the moment my customer has some problems using the db2 module with geoserver, GEOT-1992 is one of the reasons. Whats your opinion ? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Hi Felipe, On Wednesday 02 April 2008 03:02:31 am felipe gutierrez wrote: Hi, Do I need a database EPSG to create a program only to open an image of a directory on my pc and Show in a JFrame? short answer is yes. You can barely do anything geospatial without a referencing system. The EPSG database is where getotools gets the coordinate reference system definitions from. It does not mean you need to set up a complicated database yourself, but just make sure one and only one of the epsg implementations in geotools is in your classpath. Probably the safer option is to use the epsg-hsql module. Someone have one code source that do it ? I need quickly. look at http://svn.geotools.org/geotools/branches/2.4.x/demo/introduction regards, Gabriel _ Cansado de espaço para só 50 fotos? Conheça o Spaces, o site de relacionamentos com até 6,000 fotos! http://www.amigosdomessenger.com.br !DSPAM:4045,47f2db3794101137850744! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
We have answered this question several times; I think we are somehow having difficulty communicating. Literally all we want you to do Felip is have the gt2-epsg-hsql.jar and a hsql jdbc driver on your classpath (the jar will do the rest; it will unpack the database into a temporary directory and use it). Jody Hi Felipe, On Wednesday 02 April 2008 03:02:31 am felipe gutierrez wrote: Hi, Do I need a database EPSG to create a program only to open an image of a directory on my pc and Show in a JFrame? short answer is yes. You can barely do anything geospatial without a referencing system. The EPSG database is where getotools gets the coordinate reference system definitions from. It does not mean you need to set up a complicated database yourself, but just make sure one and only one of the epsg implementations in geotools is in your classpath. Probably the safer option is to use the epsg-hsql module. Someone have one code source that do it ? I need quickly. look at http://svn.geotools.org/geotools/branches/2.4.x/demo/introduction regards, Gabriel _ Cansado de espaço para só 50 fotos? Conheça o Spaces, o site de relacionamentos com até 6,000 fotos! http://www.amigosdomessenger.com.br !DSPAM:4045,47f2db3794101137850744! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Hello Felipe Gutierrez, This kind of question belongs on the user list so I am including that in the CC list and future discussion should be there. First, we can't possibly help you with so little information; with what you have given us we can only guess at what is going on. Second, you need to understand the role of geospatial 'referencing' in GIS programs. You will learn that it's unlikely anyone can do anything interesting that doesn't fundamentally require referencing work and therefore the geotools referencing module. Once you understand that, you will see that the 'referencing' module, again to do anything interesting needs comparative parameters, for which we use EPSG. There are a bunch of alternative implementations of EPSG in our code base and you need to use one and only one, i.e. make sure there's one jar on your classpath (with all the other jars). After you figure that out, if you need more help on the list, please give us a specific report: what your setup is, what you are trying to do, where in your code the error is triggered, the full error log... Asking a good question is half the battle to getting a good answer. cheers, adrian On Sun, 2008-03-30 at 16:26 -0300, felipe gutierrez wrote: Hi , I have the following problems with my program, but he executed what I want but prints that error and others errors : org.geotools.referencing.factory.epsg.FactoryOnAccess isAvailable WARNING: Unavailable authority factory: European Petroleum Survey Group org.opengis.referencing.FactoryException: Failed to connect to the EPSG database. I am not using EPSG database , and Why it appeared when I compiled? I did not understand. __ Notícias direto do New York Times, gols do Lance, videocassetadas e muitos outros vídeos no MSN Videos! Confira já! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Hi , I have the following problems with my program, but he executed what I want but prints that error and others errors : org.geotools.referencing.factory.epsg.FactoryOnAccess isAvailable WARNING: Unavailable authority factory: European Petroleum Survey Group org.opengis.referencing.FactoryException: Failed to connect to the EPSG database. I am not using EPSG database , and Why it appeared when I compiled? I did not understand. _ Confira vídeos com notícias do NY Times, gols direto do Lance, videocassetadas e muito mais no MSN Video! http://video.msn.com/?mkt=pt-br- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Hi, Someone knows how I solve the following problem at NetBeans ? If someone wants the source code I post it here . thanks Exception in thread AWT-EventQueue-0 java.lang.NoClassDefFoundError: javax/media/jai/util/Range at ShapeFileInfo.init(ShapeFileInfo.java:37) at DisplayShapefile.init(DisplayShapefile.java:26) at DisplayShapefile$1.run(DisplayShapefile.java:64) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160) at java.awt.EventDispatchThread.run(EventDispatchThread.java:121) _ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
I just had a talk with a scientist co-worker in my laboratory (this laboratory is fully dedicaced to remote sensing), and he suggested that while binding the sampleToGeophysics transform to SampleDimension seems raisonable, the sampleToGeophysics name may be part of the problem. For some scientifics, sample to geophysics means something much more complex than just the conversion from a packed form of data to a floating point form (which is the intend of sampleToGeophysics). He suggested sampleToUnit, which is close in spirit to gridToCRS - in both cases we more from integer values in sample or grid space to floating point values in Unit or CRS space. In both case the target space is fully specified by a method in the same class: Coverage.getCoordinateReferenceSystem() in the case of gridToCRS and SampleDimension.getUnit() in the case of sampleToUnit. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
[EMAIL PROTECTED] a écrit : Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support I had a quick look to the interfaces at: http://svn.geotools.org/geotools/branches/2.4.x_rs/modules/library/render/src/main/java/org/geotools/renderer/coverage/category/ I noticed that those interfaces are pretty close to the API that I created in org.geotools.coverage, except that they are interfaces rather than classes, and: * CategoryList has been made public, while it was package-privated in my implementation. Which CategoryList's service are required that can not be assured by SampleDimension (extending the later if needed)? And does CategoryUtilities really needs to be public? * Category (and CategoryList) has been splitted in some subinterfaces: TransformCategory, VizualizationCategory. Each of them contains a single method. Why this extra-level of complexity? Why not just keep the extra-method in a single Category class, like I did, and just returns null if there is no transform? Is it for type-safety? Furthermore TransformCategory.getTransform() is confusing. Is it a sample to geophysics transform? If not, which kind of transform is it, for what purpose? And why TransformCategory extends MathTransform1D in addition of having a getTransform() method? Is it the same transform? If so why this duplication? Why Category.getRange() has been renamed getInputRange() in your flavor, given that a category is not a transformer with input and output (the sample to geophysics transform is, but not the category itself). Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Thanks for taking some time to review martin... On Fri, Feb 22, 2008 at 4:17 PM, Martin Desruisseaux [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] a écrit : Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support I had a quick look to the interfaces at: http://svn.geotools.org/geotools/branches/2.4.x_rs/modules/library/render/src/main/java/org/geotools/renderer/coverage/category/ I noticed that those interfaces are pretty close to the API that I created in org.geotools.coverage, except that they are interfaces rather than classes, and: Yes, they are. I do not remember if Alessio mentioned that in the proposal, but if yuo remember when we talked at FOSS4g back in october I mentioned that I had a few weeks to revisit the category and geophysics thing and this is what I have been able to do using that time. As you might remember, I would like to separate the geophysics non geophysics duality from the coverage themselves so that we stop running into the duality images vs models this is trying to push some time in that direction. * CategoryList has been made public, while it was package-privated in my implementation. Which CategoryList's service are required that can not be assured by SampleDimension (extending the later if needed)? I was not 100% sure about this, so for the moment I just tried to underline basic behavior using interfaces. The point for this is that you can create new categorylists reusing the provided implementation and feed an agnostic sampledimension which would simply rely on the interface and add behavior as/if needed. And does CategoryUtilities really needs to be public? It could be in the package scope, but then people extending this code in the future would have to stick with this package naming in order to reuse these methods. I would have to check again those methods to give a final answer. * Category (and CategoryList) has been splitted in some subinterfaces: TransformCategory, VizualizationCategory. Each of them contains a single method. Why this extra-level of complexity? Why not just keep the extra-method in a single Category class, like I did, and just returns null if there is no transform? I am not a fan of null values even though I have used them a lot in the past :-). I tried to make these classes easy to understand for people. If I just need a simple category I do not want to specify a transformation and a color. Is it for type-safety? That was another reason. Furthermore TransformCategory.getTransform() is confusing. Is it a sample to geophysics transform? If not, which kind of transform is it, for what purpose? And why TransformCategory extends MathTransform1D in addition of having a getTransform() method? Is it the same transform? If so why this duplication? I quickly checked the code and i agree with you that the getTransform method should not be part of the interface because it is an implementation detail. I am going to move it to the DefaultTransformCategory implementation. Let me point out that the transform is a generic transform, so it can be a sample to geophysics as it could be a custom transformation to implement custom contrast enhancement on rgb images (like for example a piecewise that actually works, not like th JAI one, or it could be a logarihmic one, etc. etc.). Why Category.getRange() has been renamed getInputRange() in your flavor, given that a category is not a transformer with input and output (the sample to geophysics transform is, but not the category itself). You are right, going to apply this change. I am going to share more thoughts during the weekend on this since I think it could be a good starting point to improve the geophysics non gephysics duality. Simone. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- --- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Thanks for taking some time to review martin... On Fri, Feb 22, 2008 at 4:17 PM, Martin Desruisseaux [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] a écrit : Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support I had a quick look to the interfaces at: http://svn.geotools.org/geotools/branches/2.4.x_rs/modules/library/render/src/main/java/org/geotools/renderer/coverage/category/ I noticed that those interfaces are pretty close to the API that I created in org.geotools.coverage, except that they are interfaces rather than classes, and: Yes, they are. I do not remember if Alessio mentioned that in the proposal, but if yuo remember when we talked at FOSS4g back in october I mentioned that I had a few weeks to revisit the category and geophysics thing and this is what I have been able to do using that time. As you might remember, I would like to separate the geophysics non geophysics duality from the coverage themselves so that we stop running into the duality images vs models this is trying to push some time in that direction. * CategoryList has been made public, while it was package-privated in my implementation. Which CategoryList's service are required that can not be assured by SampleDimension (extending the later if needed)? I was not 100% sure about this, so for the moment I just tried to underline basic behavior using interfaces. The point for this is that you can create new categorylists reusing the provided implementation and feed an agnostic sampledimension which would simply rely on the interface and add behavior as/if needed. And does CategoryUtilities really needs to be public? It could be in the package scope, but then people extending this code in the future would have to stick with this package naming in order to reuse these methods. I would have to check again those methods to give a final answer. * Category (and CategoryList) has been splitted in some subinterfaces: TransformCategory, VizualizationCategory. Each of them contains a single method. Why this extra-level of complexity? Why not just keep the extra-method in a single Category class, like I did, and just returns null if there is no transform? I am not a fan of null values even though I have used them a lot in the past :-). I tried to make these classes easy to understand for people. If I just need a simple category I do not want to specify a transformation and a color. Is it for type-safety? That was another reason. Furthermore TransformCategory.getTransform() is confusing. Is it a sample to geophysics transform? If not, which kind of transform is it, for what purpose? And why TransformCategory extends MathTransform1D in addition of having a getTransform() method? Is it the same transform? If so why this duplication? I don't see how a category called TransformCategory extending category and MathTransform1D can be confusing. It is a category that specify a 1D transform between input values and output values. This transform can be anything. Why Category.getRange() has been renamed getInputRange() in your flavor, given that a category is not a transformer with input and output (the sample to geophysics transform is, but not the category itself). You are right, going to apply this change. Btw, I realize that I could add a child page to explain more in detail the rationale behind this and also how it could be used on coverage. Simone. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- --- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Simone Giannecchini a écrit : As you might remember, I would like to separate the geophysics non geophysics duality from the coverage themselves so that we stop running into the duality images vs models this is trying to push some time in that direction. Giving more though to that since that time, I now believe that it would not be appropriate. This duality is closely linked to the nature of the data - it is not something that we can treat as an ordinary operation, because it is not an operation that we apply at one specific point and then forget about it. Knowing that a data is geophysics is a knowledge that must accompagnish the coverage all the way in the processing chain. Example: (coverage) ---resample--- (coverage) ---convolution--- (coverage) If interpolation is bilinear, we must switch to geophysics view before the resample operation. But if the interpolation is nearest neighboard, we can switch to geophysics view only after resample, before convolution. As you can see, this is not something that the user decides like an ordinary operation: I want to convert to geophysics view now. For efficienty the decision is taken by the coverage framework at a moment that depends on the nature of the operation. If this handling of geophysics data is not desired, we must provide a mechanism that allows user to declare that a coverage must be handled as photographic. But for those who work with geophysics data, I believe that we need this mechanism. This is related to the unit of measurement. Units are an essential information that must accompagnish geophysics data all the way - not something that you put in an operation and then forget about it. It is possible to declare the units of a packed view in such a way that Unit A = packedView.getUnit(); Unit B = geophysicsView.getUnit(); UnitConverter C = A.convertTo(B); Where C is exactly the sampleToGeophysics conversion, but as a UnitConverter object rather than a MathTransform1D. If we understand that sampleToGeophysics is actually the definition of the units of pixel values in a packed coverage, we understand that this is something that must really accompagnish the coverage all the way - you can not separate it. I will make that clearer (and implement the above) when we will switch from JSR-108 to JSR-275: http://jcp.org/en/jsr/detail?id=275 (note that I'm a member of JSR-275 - I care about this issue since a long time). For record there how we define a Unit from a converter: http://jscience.org/api/javax/measure/units/Unit.html#transform(javax.measure.converters.UnitConverter) I am not a fan of null values even though I have used them a lot in the past :-). Given that a large amount of code in GeoTools just cast object without checking the instance, replacing optional value by sub-interfaces is replacing a risk of NullPointerException by a risk of ClassCastException. Returning null for an optional value is common practice. Declaring an interface for each optional values or operations leads exponential growth of interface. If the purpose was type safety, then TransformCategory and VisualizationCategory are not enough. You also need the combinaison of those, starting with TransformVisualizationCategory and yet more if other interfaces are added. The authors of java.util.Collection faced a similar issue (why Collection optional operations are not declared in a separated interfaces)? There is their answer: http://java.sun.com/javase/6/docs/technotes/guides/collections/designfaq.html#1 I don't see how a category called TransformCategory extending category and MathTransform1D can be confusing. It is a category that specify a 1D transform between input values and output values. This transform can be anything. The fact that the transform can be anything is the problem. The confusing part is not that we don't know the object type - as you said it is very clear from the interface name and method signature. The problem is that we don't know what this transform is. Imagine that GridCoverage.getGridToCRS() was renamed GridCoverage.getTransform() - This is a transform from what to what? Grid to CRS or CRS to Grid? Or is it the transform between the lenght of my feet at the captain's age? If we do not define the *source* and the *target* (or in other words, the purpose of the transform), it become useless. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
I'm repeating my self, but I want to stretch very loudly the following: -- The sample to geophysics transform defines the conversion from pixel units to geophysics units. -- as such, it is a unit conversion. It appears everywhere Coverage units appears. Because Unit of Measurement must be tied to every coverages in every steps of the chain, so is the sample to geophysics transform which is part of the unit definition for a packed coverage. If the units (and consequently the sample to geophysics transform) are unknown we can set them to null. But conceptually this is not an optional property (we accept null value because in real life it is often unknown), so I don't think that putting them in a separated interface as if it was an extra feature is a good catch of the concept behind it. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Martin Desruisseaux ha scritto: Simone Giannecchini a écrit : As you might remember, I would like to separate the geophysics non geophysics duality from the coverage themselves so that we stop running into the duality images vs models this is trying to push some time in that direction. Giving more though to that since that time, I now believe that it would not be appropriate. Guys, we're going completely off track. Can we talk about the merits of the raster symbolizer proposal and eventually spawn another thread on what the best coverage model is? Cheers Andrea - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Andrea Aime a écrit : Guys, we're going completely off track. Can we talk about the merits of the raster symbolizer proposal and eventually spawn another thread on what the best coverage model is? Andrea, have you seen the proposal? the Raster symbolizer is not just a raster symbolizer proposal - it redefines a brand new hierarchy of category classes. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
I agree, so should we vote? Should me and Alessio proceed without a formal vote? I will send a last separate email for the old thread, Simone. On Fri, Feb 22, 2008 at 7:39 PM, Andrea Aime [EMAIL PROTECTED] wrote: Martin Desruisseaux ha scritto: Simone Giannecchini a écrit : As you might remember, I would like to separate the geophysics non geophysics duality from the coverage themselves so that we stop running into the duality images vs models this is trying to push some time in that direction. Giving more though to that since that time, I now believe that it would not be appropriate. Guys, we're going completely off track. Can we talk about the merits of the raster symbolizer proposal and eventually spawn another thread on what the best coverage model is? Cheers Andrea -- --- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Martin Desruisseaux ha scritto: Andrea Aime a écrit : Guys, we're going completely off track. Can we talk about the merits of the raster symbolizer proposal and eventually spawn another thread on what the best coverage model is? Andrea, have you seen the proposal? the Raster symbolizer is not just a raster symbolizer proposal - it redefines a brand new hierarchy of category classes. No, I'm sick (fever) and I can't intelligently read the proposal today. Anyways, from a cursory look it seems that the hierarchy is not meant to replace the one in coverage, it's in a different package and it's used only to drive coverage coloring? I guess the standard coverage category support was not functional enough to support raster symbolization? (don't know, just trying to foster discussion). Cheers Andrea - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
On Fri, Feb 22, 2008 at 7:42 PM, Martin Desruisseaux [EMAIL PROTECTED] wrote: Andrea Aime a écrit : Guys, we're going completely off track. Can we talk about the merits of the raster symbolizer proposal and eventually spawn another thread on what the best coverage model is? Andrea, have you seen the proposal? the Raster symbolizer is not just a raster symbolizer proposal - it redefines a brand new hierarchy of category classes. Martin Martin, you are right but also andrea is right! Those categories are NOT intended to replace NOW any code in the coverage module, but are just a starting point for discussion. My fault that should have been stated more clearly in the proposal. The code that is really useful is represented by the node that does the actual processing. If needed I can add these statements to the proposal, and we can keep discussing this thing on a separate thread or on the wiki. Simone. -- --- Eng. Simone Giannecchini President /CEO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Hi all, the GeoTools Raster Symbolizer support proposal page is ready. Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support We should now open a Jira to track progresses, start voting and finish the remaining tasks. Regards, Alessio. --- Eng. Alessio Fabiani Vice-President /CTO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 349 8227000 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
I've been looking at this proposal and am pretty excited. I'd like to do a shout out to all the Geotoolers that can vote to take a look at this. I'm waiting on the proposal to do some funded work. Thanks, Jesse Le 20-Feb-08 à 7:28 AM, [EMAIL PROTECTED] a écrit : Hi all, the GeoTools Raster Symbolizer support proposal page is ready. Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support We should now open a Jira to track progresses, start voting and finish the remaining tasks. Regards, Alessio. --- Eng. Alessio Fabiani Vice-President /CTO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 349 8227000 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
May be a dumb question, but I wonder if a proposal were needed at all? Developers guide says proposals are for API changes [1]. The proposal[2] says it adds API: The structure of the proposed API allows a developer to chain nodes as desired. and no API change is needed: It is worth to point out that the proposed solution does not face GeoTools API change. :/ Gabriel. [1]http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal [2]http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support On Thursday 21 February 2008 09:04:47 pm Jesse Eichar wrote: I've been looking at this proposal and am pretty excited. I'd like to do a shout out to all the Geotoolers that can vote to take a look at this. I'm waiting on the proposal to do some funded work. Thanks, Jesse Le 20-Feb-08 à 7:28 AM, [EMAIL PROTECTED] a écrit : Hi all, the GeoTools Raster Symbolizer support proposal page is ready. Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support We should now open a Jira to track progresses, start voting and finish the remaining tasks. Regards, Alessio. --- Eng. Alessio Fabiani Vice-President /CTO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 349 8227000 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel !DSPAM:4045,47bdd96d147051961014482! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Its all a mystery to me. Can we get a confirmation about this? Jesse Le 21-Feb-08 à 12:29 PM, Gabriel Roldán a écrit : May be a dumb question, but I wonder if a proposal were needed at all? Developers guide says proposals are for API changes [1]. The proposal[2] says it adds API: The structure of the proposed API allows a developer to chain nodes as desired. and no API change is needed: It is worth to point out that the proposed solution does not face GeoTools API change. :/ Gabriel. [1]http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal [2]http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support On Thursday 21 February 2008 09:04:47 pm Jesse Eichar wrote: I've been looking at this proposal and am pretty excited. I'd like to do a shout out to all the Geotoolers that can vote to take a look at this. I'm waiting on the proposal to do some funded work. Thanks, Jesse Le 20-Feb-08 à 7:28 AM, [EMAIL PROTECTED] a écrit : Hi all, the GeoTools Raster Symbolizer support proposal page is ready. Please take a look and review at http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support We should now open a Jira to track progresses, start voting and finish the remaining tasks. Regards, Alessio. --- Eng. Alessio Fabiani Vice-President /CTO GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 349 8227000 http://www.geo-solutions.it --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel !DSPAM:4045,47bdd96d147051961014482! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Martin Desruisseaux wrote: [EMAIL PROTECTED] a écrit : Okay, its there now. I had awful problem moving the changes from 2.2.x to trunk. Thanks, it seems to compile file now. I noticed the addition of the following dependency: import EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap; Is it appropriate if I had the following comment? // TODO: replace by java.util.concurrent.ConcurrentHashMap // when we will be allowed to target J2SE 1.5. I dont know anything about this -- where is it used? dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Alessio Fabiani wrote: Hi all, this would be nice for me: http://timeanddate.com/worldclock/fixedtime.html?day=1month=5year=2006hour=22min=0sec=0p1=37 This sounds like a good time for me (monday 1:00pm). I'll be back in vancouver. If its easier for martin to attend, we could move it forward or back by 1/2 (or a whole) hour. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Martin Desruisseaux wrote: gt/module/render/src/org/geotools/renderer/lite/LiteShape2.java:[62,16] cannot find symbol symbol : class LineIterator2 location: class org.geotools.renderer.lite.LiteShape2 Okay, its there now. I had awful problem moving the changes from 2.2.x to trunk. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
[EMAIL PROTECTED] a écrit : Okay, its there now. I had awful problem moving the changes from 2.2.x to trunk. Thanks, it seems to compile file now. I noticed the addition of the following dependency: import EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap; Is it appropriate if I had the following comment? // TODO: replace by java.util.concurrent.ConcurrentHashMap // when we will be allowed to target J2SE 1.5. Martin. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
I read the IRC of yesterday and I'd like to add a few opinion about containers and factories. They are, obviously, plain IMHOs. Bye Paolo Rizzi 1) Constructors should _only_ take immutable parameters. That is values that cannot change after the object has been constructed, hence there should be no setter for them. If a value has an associated setter, it means it _can_ change during the life of the object, so the object has to be prepared for it to change and also for it to become null or invalid. So if an object has some parameters it _needs_ to function but those params have a setter, than they shouldn't go in the constructor, but the object has to be prepared to be in a state of not ready, or something like that, until all needed params are set. 2) IoC containers like Spring have _no_ problems working with factories. They're able to construct objects in whatever style: constructor injection, property injection, static factories, etc. So I really see no need to modify anything to prepare GeoTools objects to be instantiated from a container. You can even call DataStoreFinder.getDataStore(Map) from a IoC. For example in Spring you can do something like this: bean id=mainDataStore class=org.geotools.data.DataStoreFinder factory-method=getDataStore constructor-arg map entry key=dbtypevaluepostgis/value/entry entry key=hostvaluelocalhost/value/entry entry key=port bean class=java.lang.Integer constructor-arg value5432/value /constructor-arg /bean /entry entry key=databasevaluetest/value/entry entry key=uservalueuuu/value/entry entry key=passwdvalueppp/value/entry /map /constructor-arg /bean And more or less the same you can do with JBoss Microcontainer: bean name=mainDataStore class=java.lang.Object constructor factoryClass=org.geotools.data.DataStoreFinder factoryMethod=getDataStore parameter class=java.util.Map value class=java.util.Properties dbtype=postgis host=localhost port=5432 database=test user=uuu passwd=ppp /value /parameter /constructor /bean 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 riceveste 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; costituisce comportamento contrario ai principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] (no subject)
Hi Paolo, P.Rizzi Ag.Mobilità Ambiente wrote: I read the IRC of yesterday and I'd like to add a few opinion about containers and factories. They are, obviously, plain IMHOs. Bye Paolo Rizzi 1) Constructors should _only_ take immutable parameters. That is values that cannot change after the object has been constructed, hence there should be no setter for them. If a value has an associated setter, it means it _can_ change during the life of the object, so the object has to be prepared for it to change and also for it to become null or invalid. So if an object has some parameters it _needs_ to function but those params have a setter, than they shouldn't go in the constructor, but the object has to be prepared to be in a state of not ready, or something like that, until all needed params are set. 2) IoC containers like Spring have _no_ problems working with factories. They're able to construct objects in whatever style: constructor injection, property injection, static factories, etc. So I really see no need to modify anything to prepare GeoTools objects to be instantiated from a container. You can even call DataStoreFinder.getDataStore(Map) from a IoC. For example in Spring you can do something like this: bean id=mainDataStore class=org.geotools.data.DataStoreFinder factory-method=getDataStore constructor-arg map entry key=dbtypevaluepostgis/value/entry entry key=hostvaluelocalhost/value/entry entry key=port bean class=java.lang.Integer constructor-arg value5432/value /constructor-arg /bean /entry entry key=databasevaluetest/value/entry entry key=uservalueuuu/value/entry entry key=passwdvalueppp/value/entry /map /constructor-arg /bean And more or less the same you can do with JBoss Microcontainer: bean name=mainDataStore class=java.lang.Object constructor factoryClass=org.geotools.data.DataStoreFinder factoryMethod=getDataStore parameter class=java.util.Map value class=java.util.Properties dbtype=postgis host=localhost port=5432 database=test user=uuu passwd=ppp /value /parameter /constructor /bean Having objects injectible is only half the battle. And as you say with most containers you can provide enough metadata to be able to so do. However, the problem is that many of the factories dont allow dependencies to be set via a setter or a constructor. The dependency is in essence hardcoded inside the class. Or the dependency is pulled out of a hashmap based on some key. It may be tricky to get spring to inject a dependency in this manner, although probably possible. Also, not all containers support the addition of xml to describe the objects living in the container. PicoContainer for instance doesn't really have this and is one of the more popular containers (its close relative nanocontainer does but that is besides the point). I think what we are shooting for is to allow clients to use any container they wish, and because the geotools factories are good citizens, everything should gel. Justin 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 riceveste 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; costituisce comportamento contrario ai principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira The
