Re: [Geotools-devel] Proposal Replace Contribution Agreement
That is interesting, Jody. I am not opposed to formalising the role of representatives, just observing that we have not done so thus far. It might well be a good idea. Perhaps we can broaden the language to representative (but this has legal connotations), or even just person, together with capturing their relationship with the rights owner? Kind regards, Ben. On 05/02/13 11:13, Jody Garnett wrote: Thanks Ben, for reference I have been going through the eclipse stuff and … a) It also demands employers sign for each representative they have in the mix b) It is very clear (when you sign up) that you can reference an employer, or the organisations you are doing the work for as a contractor -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Proposal Replace Contribution Agreement
Proposal is up: http://docs.codehaus.org/display/GEOTOOLS/Replace+Contribution+Agreement I had a couple questions in the tasks section which may be worth discussion. -- Jody Garnett -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Proposal gt-grid extension
So let do this thing (if we take Andrea's feedback as a +1 you have enough votes to move) I am scheduled to release today (or at least this week). If we can move gt-grid over to extension land I am happy to kick the geotools release out as soon as you are ready. -- Jody Garnett On Thursday, 17 January 2013 at 10:44 PM, Michael Bedward wrote: On 17 January 2013 22:47, Andrea Aime andrea.a...@geo-solutions.it (mailto:andrea.a...@geo-solutions.it) wrote: +1 Thanks Andrea Mind, the proposal should also say who's the maintainer of the module Oops - just added note about me being maintainer (although happy if someone else wants it). Michael -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal gt-grid extension
Cool ! Should I do it as a pull request or is a direct commit OK ? On 21 January 2013 09:19, Jody Garnett jody.garn...@gmail.com wrote: So let do this thing (if we take Andrea's feedback as a +1 you have enough votes to move) I am scheduled to release today (or at least this week). If we can move gt-grid over to extension land I am happy to kick the geotools release out as soon as you are ready. -- Jody Garnett On Thursday, 17 January 2013 at 10:44 PM, Michael Bedward wrote: On 17 January 2013 22:47, Andrea Aime andrea.a...@geo-solutions.it wrote: +1 Thanks Andrea Mind, the proposal should also say who's the maintainer of the module Oops - just added note about me being maintainer (although happy if someone else wants it). Michael -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal gt-grid extension
Either works, just ping me when done and I can check locally. (Also if you are very kind you can move the doc page to be under extensions). -- Jody Garnett On Monday, 21 January 2013 at 10:48 AM, Michael Bedward wrote: Cool ! Should I do it as a pull request or is a direct commit OK ? On 21 January 2013 09:19, Jody Garnett jody.garn...@gmail.com (mailto:jody.garn...@gmail.com) wrote: So let do this thing (if we take Andrea's feedback as a +1 you have enough votes to move) I am scheduled to release today (or at least this week). If we can move gt-grid over to extension land I am happy to kick the geotools release out as soon as you are ready. -- Jody Garnett On Thursday, 17 January 2013 at 10:44 PM, Michael Bedward wrote: On 17 January 2013 22:47, Andrea Aime andrea.a...@geo-solutions.it (mailto:andrea.a...@geo-solutions.it) wrote: +1 Thanks Andrea Mind, the proposal should also say who's the maintainer of the module Oops - just added note about me being maintainer (although happy if someone else wants it). Michael -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On 07/01/13 22:31, Niels Charlier wrote: I think the reason might be that because of the existence of the app-schema-test package in geoserver there has been traditionally less test coverage in the gt-app-schema package itself, but now it becomes clear that some basic complex feature classes do need to be tested on their own behaviour. +1. gt-app-schema also lacks encoding test coverage, which is largely (and very heavily) provided by GeoServer app-schema-test. The latter has grown (*cough*) sophisticated test fixtures. (Giant integration tests rather than unit tests.) The original reason why all the encoding tests were in GeoServer-land was an XML Configuration dependency problem. If I recall correctly (and it was a long time ago), there was at least one essential Configuration (WFS?) needed for encoding full responses that was present or had a dependency only present in GeoServer. I remember noticing years later that this situation no longer exists. Refactoring would be welcome. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: java 7 try-with-resource
Looks pretty trivial at this point. Updated the proposal with my +1 On Wed, Jan 16, 2013 at 8:25 PM, Jody Garnett jody.garn...@gmail.comwrote: So the work was done, as part of the feature collection clean up … however our proposal is still sitting there with no votes (other than mine). Can I invite PMC members to check the following http://docs.codehaus.org/display/GEOTOOLS/Java+7+try-with-resource+compatibilityand see if anything was missed? -- Jody Garnett -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: java 7 try-with-resource
Agreed, moved it under the 9.x column. Thank for the +1 anyways Justin. -- Jody Garnett On Thursday, 17 January 2013 at 10:21 PM, Justin Deoliveira wrote: Looks pretty trivial at this point. Updated the proposal with my +1 On Wed, Jan 16, 2013 at 8:25 PM, Jody Garnett jody.garn...@gmail.com (mailto:jody.garn...@gmail.com) wrote: So the work was done, as part of the feature collection clean up … however our proposal is still sitting there with no votes (other than mine). Can I invite PMC members to check the following http://docs.codehaus.org/display/GEOTOOLS/Java+7+try-with-resource+compatibility and see if anything was missed? -- Jody Garnett -- Master Visual Studio, SharePoint, SQL, ASP.NET (http://ASP.NET), C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: java 7 try-with-resource
On Thu, Jan 17, 2013 at 1:21 PM, Justin Deoliveira jdeol...@opengeo.orgwrote: Looks pretty trivial at this point. Updated the proposal with my +1 Same here 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 --- -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: java 7 try-with-resource
+1 from me, updated the proposal Zitat von Andrea Aime andrea.a...@geo-solutions.it: On Thu, Jan 17, 2013 at 1:21 PM, Justin Deoliveira jdeol...@opengeo.orgwrote: Looks pretty trivial at this point. Updated the proposal with my +1 Same here 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 message was sent using IMP, the Internet Messaging Program. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Proposal: java 7 try-with-resource
So the work was done, as part of the feature collection clean up … however our proposal is still sitting there with no votes (other than mine). Can I invite PMC members to check the following http://docs.codehaus.org/display/GEOTOOLS/Java+7+try-with-resource+compatibility and see if anything was missed? -- Jody Garnett -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Mon, Jan 7, 2013 at 3:31 PM, Niels Charlier ni...@scitus.be wrote: The ones in xsd-core work only on SimpleFeatures. I never really understood their use, why would you need an x-path on a simple feature anyway? In any case, the complex x-path accessor should work on simple features too as a special case. In my opinion this can be completely removed. Interesting. Justin, any feedback on this one? Cheers Andrea (who enjoys a lot axing useless code) -- == 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 --- -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Tue, Jan 8, 2013 at 4:06 AM, Andrea Aime andrea.a...@geo-solutions.itwrote: On Mon, Jan 7, 2013 at 3:31 PM, Niels Charlier ni...@scitus.be wrote: The ones in xsd-core work only on SimpleFeatures. I never really understood their use, why would you need an x-path on a simple feature anyway? In any case, the complex x-path accessor should work on simple features too as a special case. In my opinion this can be completely removed. Interesting. Justin, any feedback on this one? Nice. This should mean we can kill the xpath stuff from xsd-core since as I understood it (incorrectly apparently) the only use case was for app-schema. This will be nice because it means dropping a dependency on jxpath. Cheers Andrea (who enjoys a lot axing useless code) -- == 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 --- -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On 12/28/2012 07:34 PM, Andrea Aime wrote: Hi, I did not see a review from Jody so far, so I've tried to make one myself instead (and seen that Rini made a review for the app-schema part last week). I did not do a line by line review, but from what I see things are looking good. I do have a couple of concerns though, but I don't see them as blocking the merge of the patch. The first one is testing related: the module complex module has a low-ish test coverage (29%), and all the classes contributed to main are without any kind of test. Now, from what I understand your work has been mostly refactoring of existing code, so I certainly cannot blame you for code coverage that was not there to begin with, or for coverage that was there when things were all togheter in a single module, and that is no more visible due to the split, yet the classes I see there seem testable in isolation... Complex feature people, any comment? I had noticed this myself, and had already expected this concern. I suggest that a separate task is created to improve complex feature test base, but I wanted to keep this patch strictly about refactoring. In other words, the changes are completely neutral with regards to test coverage. I think the reason might be that because of the existence of the app-schema-test package in geoserver there has been traditionally less test coverage in the gt-app-schema package itself, but now it becomes clear that some basic complex feature classes do need to be tested on their own behaviour. In a few cases the problem is also that some tests had to remain in app-schema even if the actual classes moved. For example ComplexAttributeConverterFactory, this class could perfectly be moved to gt-main but its current test class is totally app-schema based. The same issue with the FeatureRegistry that moved to gt-complex. New tests should be made that are more generic. However I do think that most stuff in gt-complex is in fact tested, even if there seems to be way less test classes than actual classes, don't forget the FeaturePropertyAccessorTest tests the whole bunch of x-path classes (which only work together). The other thing I'm working about is the xpath property accessor, I see there is another one in xsd-core, which is something that gt-complex depends onto. What is the relationship between the two? Is the duplication necessary? The ones in xsd-core work only on SimpleFeatures. I never really understood their use, why would you need an x-path on a simple feature anyway? In any case, the complex x-path accessor should work on simple features too as a special case. In my opinion this can be completely removed. Kind Regards Niels Niels -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Wed, Dec 19, 2012 at 1:30 AM, Niels Charlier ni...@scitus.be wrote: A pull request has been sent: https://github.com/geotools/geotools/pull/88 I assigned Rini, I guess she will be reviewing it? I also need a review for the changes in gt-main, I suppose Jody? Hi, I did not see a review from Jody so far, so I've tried to make one myself instead (and seen that Rini made a review for the app-schema part last week). I did not do a line by line review, but from what I see things are looking good. I do have a couple of concerns though, but I don't see them as blocking the merge of the patch. The first one is testing related: the module complex module has a low-ish test coverage (29%), and all the classes contributed to main are without any kind of test. Now, from what I understand your work has been mostly refactoring of existing code, so I certainly cannot blame you for code coverage that was not there to begin with, or for coverage that was there when things were all togheter in a single module, and that is no more visible due to the split, yet the classes I see there seem testable in isolation... Complex feature people, any comment? The other thing I'm working about is the xpath property accessor, I see there is another one in xsd-core, which is something that gt-complex depends onto. What is the relationship between the two? Is the duplication necessary? 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 --- -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Hi Ben, That is what I meant, proceed to the next step. I will of course let the actual patch still be reviewed. Kind Regards Niels On 12/18/2012 04:13 AM, Ben Caradoc-Davies wrote: On 17/12/12 18:58, Niels Charlier wrote: Cool, with no more objections and a +1 from the module maintainer and a few others I guess I can proceed? That depends what you mean by proceed: +1 is for the overarching API change proposal (which classes are in which modules). In my view, you should also seek approval from module maintainers for the final version before it is committed; this is likely to be quick as the main points of contention have been discussed. You can submit patches or github pull requests, which are also becoming popular. Thanks for progressing this work, Niels. It is a much-needed improvement. Kind regards, -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On 12/18/2012 04:13 AM, Ben Caradoc-Davies wrote: On 17/12/12 18:58, Niels Charlier wrote: Cool, with no more objections and a +1 from the module maintainer and a few others I guess I can proceed? That depends what you mean by proceed: +1 is for the overarching API change proposal (which classes are in which modules). In my view, you should also seek approval from module maintainers for the final version before it is committed; this is likely to be quick as the main points of contention have been discussed. You can submit patches or github pull requests, which are also becoming popular. Thanks for progressing this work, Niels. It is a much-needed improvement. Kind regards, A pull request has been sent: https://github.com/geotools/geotools/pull/88 I assigned Rini, I guess she will be reviewing it? I also need a review for the changes in gt-main, I suppose Jody? Thanks for everyone who has with helped with this, and thanks in advance for the reviews! Kind Regards Niels -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Thanks Niels. I'll take a look later. -Original Message- From: Niels Charlier [mailto:ni...@scitus.be] Sent: Wednesday, 19 December 2012 8:31 AM To: Caradoc-Davies, Ben (CESRE, Kensington) Cc: Jody Garnett; geotools-devel@lists.sourceforge.net; Angreani, Rini (CESRE, Kensington) Subject: Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema On 12/18/2012 04:13 AM, Ben Caradoc-Davies wrote: On 17/12/12 18:58, Niels Charlier wrote: Cool, with no more objections and a +1 from the module maintainer and a few others I guess I can proceed? That depends what you mean by proceed: +1 is for the overarching API change proposal (which classes are in which modules). In my view, you should also seek approval from module maintainers for the final version before it is committed; this is likely to be quick as the main points of contention have been discussed. You can submit patches or github pull requests, which are also becoming popular. Thanks for progressing this work, Niels. It is a much-needed improvement. Kind regards, A pull request has been sent: https://github.com/geotools/geotools/pull/88 I assigned Rini, I guess she will be reviewing it? I also need a review for the changes in gt-main, I suppose Jody? Thanks for everyone who has with helped with this, and thanks in advance for the reviews! Kind Regards Niels -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Cool, with no more objections and a +1 from the module maintainer and a few others I guess I can proceed? Cheers Niels On 12/14/2012 02:37 PM, Andrea Aime wrote: On Fri, Dec 14, 2012 at 12:13 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: Okay, I now changed the proposal to move everything to main that can be moved to main. Please have a look at the updated version. I hope we can get the needed +1's as soon as possible. Works for me, +1 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On 17/12/12 18:58, Niels Charlier wrote: Cool, with no more objections and a +1 from the module maintainer and a few others I guess I can proceed? That depends what you mean by proceed: +1 is for the overarching API change proposal (which classes are in which modules). In my view, you should also seek approval from module maintainers for the final version before it is committed; this is likely to be quick as the main points of contention have been discussed. You can submit patches or github pull requests, which are also becoming popular. Thanks for progressing this work, Niels. It is a much-needed improvement. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Fri, Dec 14, 2012 at 4:02 AM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au wrote: Niels, that is a very good point. Andrea, there is a bunch of XSD stuff like substitution groups that are not represented in GeoAPI. It makes it quite tricky to break this dependency. Niels knows because he implemented a lot of it. As future work, we could look at refactoring the way XSD information is handled in complex types. Perhaps we would be better off moving towards that goal one step at a time? Andrea, would it be OK to accept the dependencies listed by Niels? They will not prevent non-XML uses. Future refactoring could make this optional, and client code could (for example) inject an XML provider. I do not know if Niels is in a position to implement such a large refactoring at this time. I remain on my position, everything that is complex feature but does not require XSD should be merged in main (Feature is the base class, it's a bit ridicolous that in order to use it one has to add half of GeoTools in the classpath) and gt-complex should probably be renamed gt-complex-xsd to make things clear, that the module is useful only if you're messing with xml schemas. I know it's not idea, but still looks like a step forward compared to the current situation, where usage of complex features is basically limited to a single data store implementation. Hopefully in time we'll get a xpath property accessor that does not requires xsd and slowly move to a saner situation where using complex features can be done with just gt-main in the classpath. 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Okay, I now changed the proposal to move everything to main that can be moved to main. Please have a look at the updated version. I hope we can get the needed +1's as soon as possible. Cheers Niels On 12/14/2012 09:37 AM, Andrea Aime wrote: On Fri, Dec 14, 2012 at 4:02 AM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: Niels, that is a very good point. Andrea, there is a bunch of XSD stuff like substitution groups that are not represented in GeoAPI. It makes it quite tricky to break this dependency. Niels knows because he implemented a lot of it. As future work, we could look at refactoring the way XSD information is handled in complex types. Perhaps we would be better off moving towards that goal one step at a time? Andrea, would it be OK to accept the dependencies listed by Niels? They will not prevent non-XML uses. Future refactoring could make this optional, and client code could (for example) inject an XML provider. I do not know if Niels is in a position to implement such a large refactoring at this time. I remain on my position, everything that is complex feature but does not require XSD should be merged in main (Feature is the base class, it's a bit ridicolous that in order to use it one has to add half of GeoTools in the classpath) and gt-complex should probably be renamed gt-complex-xsd to make things clear, that the module is useful only if you're messing with xml schemas. I know it's not idea, but still looks like a step forward compared to the current situation, where usage of complex features is basically limited to a single data store implementation. Hopefully in time we'll get a xpath property accessor that does not requires xsd and slowly move to a saner situation where using complex features can be done with just gt-main in the classpath. 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Fri, Dec 14, 2012 at 12:13 PM, Niels Charlier ni...@scitus.be wrote: Okay, I now changed the proposal to move everything to main that can be moved to main. Please have a look at the updated version. I hope we can get the needed +1's as soon as possible. Works for me, +1 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
The XPath processor takes XSD information out of the user data in order to evaluate xml @attributes. That is why it is dependant on it. On 12/13/2012 08:09 AM, Andrea Aime wrote: On Wed, Dec 12, 2012 at 5:29 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: Well apart from the feature type parser, there is another important part in the module that relies on xsd stuff, i.e. the xpath property accessor. This I think is a very important part of complex features; without this you can't have filters on complex features. An xpath processor is built into the jdk, there is no need to depend on gt-xsd and friends to have it, e.g.: http://xml.apache.org/xalan-j/xpath_apis.html Even if that requires some external library, it's hard to believe it requires an entire xml parsing/encoding subsystem. 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Okay I would suggest we could maybe all have an IRC meeting so that we can come to a final consensus about what to do that everyone can be happy with? we really need to move forward with this as next week this project needs to be finished. On 12/13/2012 04:15 AM, Ben Caradoc-Davies wrote: It would be good if users could build and manipulate complex types and features without ever touching XML or needing an XML dependency. For example, they could build types and features programatically. Other output formats include JSON; complex relationships can be represented in JSON-LD. On 12/12/12 17:30, Andrea Aime wrote: Scratch scratch, could you clarify what dependencies would one end up having in the classpath in order to use gt-complex? -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Niels, that is a very good point. Andrea, there is a bunch of XSD stuff like substitution groups that are not represented in GeoAPI. It makes it quite tricky to break this dependency. Niels knows because he implemented a lot of it. As future work, we could look at refactoring the way XSD information is handled in complex types. Perhaps we would be better off moving towards that goal one step at a time? Andrea, would it be OK to accept the dependencies listed by Niels? They will not prevent non-XML uses. Future refactoring could make this optional, and client code could (for example) inject an XML provider. I do not know if Niels is in a position to implement such a large refactoring at this time. Kind regards, Ben. On 13/12/12 18:32, Niels Charlier wrote: The XPath processor takes XSD information out of the user data in order to evaluate xml @attributes. That is why it is dependant on it. On 12/13/2012 08:09 AM, Andrea Aime wrote: On Wed, Dec 12, 2012 at 5:29 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: Well apart from the feature type parser, there is another important part in the module that relies on xsd stuff, i.e. the xpath property accessor. This I think is a very important part of complex features; without this you can't have filters on complex features. An xpath processor is built into the jdk, there is no need to depend on gt-xsd and friends to have it, e.g.: http://xml.apache.org/xalan-j/xpath_apis.html Even if that requires some external library, it's hard to believe it requires an entire xml parsing/encoding subsystem. 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 --- -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Tue, Dec 11, 2012 at 12:15 PM, Niels Charlier ni...@scitus.be wrote: The Proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema Please vote, or provide criticism. Scratch scratch, could you clarify what dependencies would one end up having in the classpath in order to use gt-complex? A dependency:tree or dependency:list output of that module would help I'm also wondering, say we start building complex feature versions of the many decorating collections we have, where would you see them ending up, in main or gt-complex? 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
[INFO] org.geotools:gt-complex:jar:9-SNAPSHOT [INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile [INFO] | +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile [INFO] | | +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile [INFO] | | | \- org.geotools:gt-main:jar:9-SNAPSHOT:compile [INFO] | | | +- org.geotools:gt-api:jar:9-SNAPSHOT:compile [INFO] | | | | \- org.geotools:gt-referencing:jar:9-SNAPSHOT:compile [INFO] | | | | +- java3d:vecmath:jar:1.3.2:compile [INFO] | | | | +- commons-pool:commons-pool:jar:1.5.4:compile [INFO] | | | | +- org.geotools:gt-metadata:jar:9-SNAPSHOT:compile [INFO] | | | | | \- org.geotools:gt-opengis:jar:9-SNAPSHOT:compile [INFO] | | | | | \- net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile [INFO] | | | | \- jgridshift:jgridshift:jar:1.0:compile [INFO] | | | +- com.vividsolutions:jts:jar:1.12:compile [INFO] | | | \- jdom:jdom:jar:1.0:compile [INFO] | | +- picocontainer:picocontainer:jar:1.2:compile [INFO] | | | \- xml-apis:xml-apis:jar:1.3.04:compile (version managed from 1.0.b2) [INFO] | | +- xerces:xercesImpl:jar:2.7.1:compile [INFO] | | +- xml-apis:xml-apis-xerces:jar:2.7.1:compile [INFO] | | +- commons-jxpath:commons-jxpath:jar:1.3:compile [INFO] | | +- commons-collections:commons-collections:jar:3.1:compile [INFO] | | +- org.eclipse.emf:common:jar:2.6.0:compile [INFO] | | +- org.eclipse.emf:ecore:jar:2.6.1:compile [INFO] | | \- org.eclipse.xsd:xsd:jar:2.6.0:compile [INFO] | \- org.apache.xml:xml-commons-resolver:jar:1.2:compile [INFO] +- xpp3:xpp3_min:jar:1.1.4c:compile [INFO] +- javax.media:jai_core:jar:1.1.3:compile [INFO] \- junit:junit:jar:4.4:test On 12/12/2012 10:30 AM, Andrea Aime wrote: On Tue, Dec 11, 2012 at 12:15 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: The Proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema Please vote, or provide criticism. Scratch scratch, could you clarify what dependencies would one end up having in the classpath in order to use gt-complex? A dependency:tree or dependency:list output of that module would help I'm also wondering, say we start building complex feature versions of the many decorating collections we have, where would you see them ending up, in main or gt-complex? 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Wed, Dec 12, 2012 at 12:47 PM, Niels Charlier ni...@scitus.be wrote: [INFO] org.geotools:gt-complex:jar:9-SNAPSHOT [INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile [INFO] | +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile [INFO] | | +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile [INFO] | | | \- org.geotools:gt-main:jar:9-SNAPSHOT:compile [INFO] | | | +- org.geotools:gt-api:jar:9-SNAPSHOT:compile [INFO] | | | | \- org.geotools:gt-referencing:jar:9-SNAPSHOT:compile [INFO] | | | | +- java3d:vecmath:jar:1.3.2:compile [INFO] | | | | +- commons-pool:commons-pool:jar:1.5.4:compile [INFO] | | | | +- org.geotools:gt-metadata:jar:9-SNAPSHOT:compile [INFO] | | | | | \- org.geotools:gt-opengis:jar:9-SNAPSHOT:compile [INFO] | | | | | \- net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile [INFO] | | | | \- jgridshift:jgridshift:jar:1.0:compile [INFO] | | | +- com.vividsolutions:jts:jar:1.12:compile [INFO] | | | \- jdom:jdom:jar:1.0:compile [INFO] | | +- picocontainer:picocontainer:jar:1.2:compile [INFO] | | | \- xml-apis:xml-apis:jar:1.3.04:compile (version managed from 1.0.b2) [INFO] | | +- xerces:xercesImpl:jar:2.7.1:compile [INFO] | | +- xml-apis:xml-apis-xerces:jar:2.7.1:compile [INFO] | | +- commons-jxpath:commons-jxpath:jar:1.3:compile [INFO] | | +- commons-collections:commons-collections:jar:3.1:compile [INFO] | | +- org.eclipse.emf:common:jar:2.6.0:compile [INFO] | | +- org.eclipse.emf:ecore:jar:2.6.1:compile [INFO] | | \- org.eclipse.xsd:xsd:jar:2.6.0:compile [INFO] | \- org.apache.xml:xml-commons-resolver:jar:1.2:compile [INFO] +- xpp3:xpp3_min:jar:1.1.4c:compile [INFO] +- javax.media:jai_core:jar:1.1.3:compile [INFO] \- junit:junit:jar:4.4:test Eh, as I suspected, very tightly married to XML things, which is something I hope complex features remain free of. Don't get me wrong, being able to parse a feature type from a XSD is a very good feature, but these large set of dependencies should not be forced into whoever uses complex features. Is there a way to cut it so that generic complex feature stuff is on one side, and XML and XSD specific support is on the other? 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
I see. So what you'd suggest we move a bunch of that stuff in to gt-main. I have to have a look at which part will still remain. Perhaps too little to keep in a separate package. Maybe we should still move that stuff into gt-appschema-resolver but keep the name? On 12/12/2012 01:56 PM, Andrea Aime wrote: On Wed, Dec 12, 2012 at 12:47 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: [INFO] org.geotools:gt-complex:jar:9-SNAPSHOT [INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile [INFO] | +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile [INFO] | | +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile [INFO] | | | \- org.geotools:gt-main:jar:9-SNAPSHOT:compile [INFO] | | | +- org.geotools:gt-api:jar:9-SNAPSHOT:compile [INFO] | | | | \- org.geotools:gt-referencing:jar:9-SNAPSHOT:compile [INFO] | | | | +- java3d:vecmath:jar:1.3.2:compile [INFO] | | | | +- commons-pool:commons-pool:jar:1.5.4:compile [INFO] | | | | +- org.geotools:gt-metadata:jar:9-SNAPSHOT:compile [INFO] | | | | | \- org.geotools:gt-opengis:jar:9-SNAPSHOT:compile [INFO] | | | | | \- net.java.dev.jsr-275:jsr-275:jar:1.0-beta-2:compile [INFO] | | | | \- jgridshift:jgridshift:jar:1.0:compile [INFO] | | | +- com.vividsolutions:jts:jar:1.12:compile [INFO] | | | \- jdom:jdom:jar:1.0:compile [INFO] | | +- picocontainer:picocontainer:jar:1.2:compile [INFO] | | | \- xml-apis:xml-apis:jar:1.3.04:compile (version managed from 1.0.b2) [INFO] | | +- xerces:xercesImpl:jar:2.7.1:compile [INFO] | | +- xml-apis:xml-apis-xerces:jar:2.7.1:compile [INFO] | | +- commons-jxpath:commons-jxpath:jar:1.3:compile [INFO] | | +- commons-collections:commons-collections:jar:3.1:compile [INFO] | | +- org.eclipse.emf:common:jar:2.6.0:compile [INFO] | | +- org.eclipse.emf:ecore:jar:2.6.1:compile [INFO] | | \- org.eclipse.xsd:xsd:jar:2.6.0:compile [INFO] | \- org.apache.xml:xml-commons-resolver:jar:1.2:compile [INFO] +- xpp3:xpp3_min:jar:1.1.4c:compile [INFO] +- javax.media:jai_core:jar:1.1.3:compile [INFO] \- junit:junit:jar:4.4:test Eh, as I suspected, very tightly married to XML things, which is something I hope complex features remain free of. Don't get me wrong, being able to parse a feature type from a XSD is a very good feature, but these large set of dependencies should not be forced into whoever uses complex features. Is there a way to cut it so that generic complex feature stuff is on one side, and XML and XSD specific support is on the other? 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Wed, Dec 12, 2012 at 2:45 PM, Niels Charlier ni...@scitus.be wrote: I see. So what you'd suggest we move a bunch of that stuff in to gt-main. I have to have a look at which part will still remain. Perhaps too little to keep in a separate package. Maybe we should still move that stuff into gt-appschema-resolver but keep the name? It's going to be easier to tell once you figured out what remains. Please let us know :-) 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
Well apart from the feature type parser, there is another important part in the module that relies on xsd stuff, i.e. the xpath property accessor. This I think is a very important part of complex features; without this you can't have filters on complex features. The only thing that really remains xml free are a few very simple builder classes. Considering this, and seeing there was a consensus growing around it, I would personally prefer to stay with the current plan of a complex module. Kind Regards Niels Charlier On 12/12/2012 03:03 PM, Andrea Aime wrote: On Wed, Dec 12, 2012 at 2:45 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: I see. So what you'd suggest we move a bunch of that stuff in to gt-main. I have to have a look at which part will still remain. Perhaps too little to keep in a separate package. Maybe we should still move that stuff into gt-appschema-resolver but keep the name? It's going to be easier to tell once you figured out what remains. Please let us know :-) 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
It would be good if users could build and manipulate complex types and features without ever touching XML or needing an XML dependency. For example, they could build types and features programatically. Other output formats include JSON; complex relationships can be represented in JSON-LD. On 12/12/12 17:30, Andrea Aime wrote: Scratch scratch, could you clarify what dependencies would one end up having in the classpath in order to use gt-complex? -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
On Wed, Dec 12, 2012 at 5:29 PM, Niels Charlier ni...@scitus.be wrote: Well apart from the feature type parser, there is another important part in the module that relies on xsd stuff, i.e. the xpath property accessor. This I think is a very important part of complex features; without this you can't have filters on complex features. An xpath processor is built into the jdk, there is no need to depend on gt-xsd and friends to have it, e.g.: http://xml.apache.org/xalan-j/xpath_apis.html Even if that requires some external library, it's hard to believe it requires an entire xml parsing/encoding subsystem. 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 --- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
The Proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema Please vote, or provide criticism. Kind Regards Niels Charlier -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
+1. This change is long overdue and much needed. I have asked Rini and Adam to review the proposal. gt-app-schema changes should go for review to Rini as component lead. Kind regards, Ben. On 11/12/12 19:15, Niels Charlier wrote: The Proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema Please vote, or provide criticism. Kind Regards Niels Charlier -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ 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 Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Hi Andrea, Thank you for your time! On 08/12/2012 04:09 PM, Andrea Aime wrote: There is a mix of things that confuse me a bit here: * the method in the transformation is purely 2D anyways, you won't get a 3D envelope out of it (it samples the 2D perimeter of the original bounds to make an accurate transformation) * it may be legit to transform a 3D bbox into a 2D one, because maybe you are integrating it with some 2D data, the proper way to go from 3D to 2D should be a MathTransform. The method in ReferencedEnvelope3D uses the 2D transforming method, only looking at the first 2 dimensions, and getting a 2D envelope back, but then just restores the third coordinate so it stays the same and actually does return a 3D envelope. Proper 3D transformations is one of the challenges we face with the 3d integration. Makes sense, but makes me wonder at the same time, what happens if you return a 3D geometry instead? I guess you had something break? The problem is to make a proper geometry of a bounding box, you will need a three dimensional polygonal surface, to represent a cube. If I understand correctly, there is no support for this kind of geometries in geotools atm and it is basically a whole new JTS that needs to be written for this kind of support. At the same time, I think there might be other, more efficient ways to translate the 3D bbox query to sql. In general, given your experience with your proposal, what would you say are the missing bits/steps to work on (outside of this proposal) to make 3D data and queries really work? Well, the vividsolutions JTS library does support a third coordinate but in practice it only has support for 2D complex structures and algorithms. This is the biggest problem. I think to make 3d fully operational, I think we almost need to rewrite the whole JTS library. Regards Niels -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Wed, Aug 8, 2012 at 3:43 PM, Niels Charlier ni...@scitus.be wrote:
Okay,
The proposal has been updated and a new patch has been uploaded :)
Thanks Niels,
looked at the patch, seems like a solid improvement.
One part that still makes me wonder is this one:
diff --git
a/modules/library/api/src/main/java/org/geotools/geometry/jts/JTS.java
b/modules/library/api/src/main/java/org/geotools/geometry/jts/JTS.java
index 692b66c..e045d04 100644
--- a/modules/library/api/src/main/java/org/geotools/geometry/jts/JTS.java
+++ b/modules/library/api/src/main/java/org/geotools/geometry/jts/JTS.java
@@ -176,7 +176,8 @@ public final class JTS {
ensureNonNull(sourceEnvelope, sourceEnvelope);
ensureNonNull(transform, transform);
-if ((transform.getSourceDimensions() != 2) ||
(transform.getTargetDimensions() != 2)) {
+if (transform.getSourceDimensions() !=
transform.getTargetDimensions() ||
+transform.getSourceDimensions() 2){
throw new
MismatchedDimensionException(Errors.format(ErrorKeys.BAD_TRANSFORM_$1,
Classes.getShortClassName(transform)));
}
@@ -219,7 +220,7 @@ public final class JTS {
return targetEnvelope;
}
-
+
There is a mix of things that confuse me a bit here:
* the method in the transformation is purely 2D anyways, you won't get
a 3D envelope out of it (it samples the 2D perimeter of the original
bounds
to make an accurate transformation)
* it may be legit to transform a 3D bbox into a 2D one, because maybe you
are integrating it with some 2D data, the proper way to go from 3D to 2D
should be a MathTransform.
The other one is the following, in BBOX3DImpl:
+public Expression getExpression2() {
+ // in this case, the 3D BBOX falls back to regular 2D bbox behaviour
(until there is more support for 3D geometries)
+ // 3DBBOX must be run as a post-filter in order to support the third
coordinate.
+
+Coordinate[] coords = new Coordinate[5];
+coords[0] = new Coordinate(envelope.getMinX(), envelope.getMinY());
+coords[1] = new Coordinate(envelope.getMinX(), envelope.getMaxY());
+coords[2] = new Coordinate(envelope.getMaxX(), envelope.getMaxY());
+coords[3] = new Coordinate(envelope.getMaxX(), envelope.getMinY());
+coords[4] = new Coordinate(envelope.getMinX(), envelope.getMinY());
+
+LinearRing ring = null;
+
+GeometryFactory gfac = new GeometryFactory();
+try {
+ring = gfac.createLinearRing(coords);
+} catch (TopologyException tex) {
+throw new IllegalFilterException(tex.toString());
+}
+
+Polygon polygon = gfac.createPolygon(ring, null);
+if (envelope instanceof ReferencedEnvelope3D) {
+ReferencedEnvelope3D refEnv = (ReferencedEnvelope3D) envelope;
+polygon.setUserData(refEnv.getCoordinateReferenceSystem());
+}
+
+return factory.literal(polygon);
+}
Makes sense, but makes me wonder at the same time, what happens if you
return a 3D geometry instead? I guess you had something break?
In general, given your experience with your proposal, what would you say
are the
missing bits/steps to work on (outside of this proposal) to make 3D data
and queries
really work?
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 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
---
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Okay, The proposal has been updated and a new patch has been uploaded :) Regards Niels On 08/07/2012 10:57 AM, Andrea Aime wrote: On Mon, Aug 6, 2012 at 2:08 PM, Niels Charlier ni...@scitus.be wrote: Update Patch: + Implement ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method + Implement better Transform method + Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return SRS string in filter class + Remove filtervisitor hack and update DuplicatingFilterVisitor + Support for bbox3d in OGC post filters + change dimension/srs checking in ReferencedEnvelope from = to Proposal Text: + Add Implications for Filter Visitors (and docs) Does that cover it? I think so, yeah :) Cheers Andrea -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Mon, Aug 6, 2012 at 1:06 PM, Niels Charlier ni...@scitus.be wrote: On 08/06/2012 12:23 PM, Niels Charlier wrote: Afaik this works the way I explained before, that is, the Z dimension is left unaltered during the reprojection. Which is not true reprojection, but what we can afford given that the vertical transformation module is not working I reprojected from WGS84 to WGS66 which only differ in their Z dimension, and the values are being altered. I am currently in the process of doing the calculations to see if it is indeed mathematically correct, but it is definitely altered. And I can confirm that the 3d reprojection is indeed 100% mathematically accurate. Interesting, maybe it's working properly for full 3D systems (as opposed to compound ones where a 2d system is associated with a vertical CRS). What were the EPSG codes you used? 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Mon, Aug 6, 2012 at 2:08 PM, Niels Charlier ni...@scitus.be wrote: Update Patch: + Implement ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method + Implement better Transform method + Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return SRS string in filter class + Remove filtervisitor hack and update DuplicatingFilterVisitor + Support for bbox3d in OGC post filters + change dimension/srs checking in ReferencedEnvelope from = to Proposal Text: + Add Implications for Filter Visitors (and docs) Does that cover it? I think so, yeah :) 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Hi, I'm not saying that you have to do everything at once, can you answer the simple question above though? Restating it: How sure you are that you're going to implement proper encoding of 3D bboxes at the very least for JDBC stores (and possibly for shapefiles as well?) I am sorry, I cannot give you a guarantee about that at this moment. I have looked at the patch and I don't see where in the code you are handling the parsing of a BBOX filter coming from a OGC filter in a POST request, or a BBOX coming from a CQL filter. If you are not planning to support them please state so, if you are planning to do please clarify how and when The current patch and proposal does not include these features. However, I'd understand that WFS post requests need to at least support the same features as wfs get requests. Please let me know the minimum requirements with regards to this to get the patch approved. The proposal is effectively adding a new type of filter, normally that would require a change in the filter visitor API to handle such new filter explicitly, however this case is peculiar in that the new filter extends an existing one. This means the API might not be in need of change, but it has consequences on the API. In particular, all filter visitors dedicated to the manipulation of filters (including the simplifiying filter visitor) will create a copy that's a plain 2D BBOX, and the CQL encoder will encode the bbox as a 2D one. I see there is in the code: ... I'm sure this works with most/all of the existing code, but is this the right way to go? Given that most filters manipulating filters are extending from the duplicating filter visitor, wouldn't it be better to fix that one instead? Also, I believe the ReprojectingFilterVisitor won't work properly with the above hack, and that it might need some logic changes (a way consistent with geometry reprojection would be to reproject the 2d component of the bbox and leave the 3d part move unaltered to the result) Also, given this is an API change there should be some documentation on a upgrade to 9.x page telling people to expect this new kind of filter in their custom visitors, and probably some changes on the FilterVisitor javadocs are in order as well. This is one problematic area of the proposal, it would have been better to point it out in the proposal document instead of having people have to review the code in order to see it: a good proposal is also showing what is _not_ covered/done and what the potentially problematic areas are (and how the problems have been addressed). Yes, you have a point here, this is a weak part. I stole the code from your fastbbox, but it is indeed an ugly hack. I would be happy to change the filter visitors instead, but I was trying to minimise changes to the core. I am sorry I didn't point this out in the proposal, I will do something about it. This went a bit off the tangent, but here is the part that affects the filtering code. Say I have a layer in postgis that is declared as EPSG:4326 with dimension=3 (perfectly legit in postgis), how am I going to filter it using BBOX3D? It seems whatever I do I might be in some issue from some point of view: * if I state the crs is EPSG:4326 then the dimensionality check in ReferencedEnvelope3D.checkCoordinateReferenceSystemDimension() will make it impossible to build the filter * as a user I could know that I have to use EPSG:4327 instead, but this will make the CRS inconsistent with the one on the DBMS.. besides that, I don't see an immediate way for automated code to build the 3d equivalent of a 2d system, and the layer will be declared in the feature type as having EPSG:4326 (since that's what we reflect out of the database) The method checkCoordinateReferenceSystemDimension is identical to the one in its superclass, ReferencedEnvelope. (In fact, I should remove this copy-pasted method and instead make it protected instead of private in its superclass, this is left-over from changing the class structure). So the existing implementation already checks the srs's dimensionality against this. This means that is now forbidden to apply a 2D bbox against a 3D SRS. It only seemed logical for me to extend the same logic to situation the other way around. I would personally recommend to use a 3D SRS if you have 3D geometries, even in postgis, this seems to me like the best way to work. If this is not desired behaviour, I think it is not just my changes, but the existing code of the ReferencedEnvelope class that must be reviewed. Perhaps I could change the check to test if the dimension of SRS than the dimension of the bbox? Does that make any sense at all? I find it suprising that 3D reprojection works indeed. Afaik to do it one needs proper support for vertical CRSs, which is contained in referencing3D. I though that module was not complete, have you looked
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Andrea, I am trying to make an overview of all the changes that require me to do to the patch and proposal to get them passed. This is what I have so far: Patch: Implement ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method Implement better Transform method Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return SRS string in filter class ? Support for bbox3d in OGC post filters ? change dimension/srs checking in ReferencedEnvelope Proposal Text: Add Implications for Filter Visitors (and docs) Does that cover it? Cheers Niels On 08/06/2012 10:45 AM, Niels Charlier wrote: Hi, I'm not saying that you have to do everything at once, can you answer the simple question above though? Restating it: How sure you are that you're going to implement proper encoding of 3D bboxes at the very least for JDBC stores (and possibly for shapefiles as well?) I am sorry, I cannot give you a guarantee about that at this moment. I have looked at the patch and I don't see where in the code you are handling the parsing of a BBOX filter coming from a OGC filter in a POST request, or a BBOX coming from a CQL filter. If you are not planning to support them please state so, if you are planning to do please clarify how and when The current patch and proposal does not include these features. However, I'd understand that WFS post requests need to at least support the same features as wfs get requests. Please let me know the minimum requirements with regards to this to get the patch approved. The proposal is effectively adding a new type of filter, normally that would require a change in the filter visitor API to handle such new filter explicitly, however this case is peculiar in that the new filter extends an existing one. This means the API might not be in need of change, but it has consequences on the API. In particular, all filter visitors dedicated to the manipulation of filters (including the simplifiying filter visitor) will create a copy that's a plain 2D BBOX, and the CQL encoder will encode the bbox as a 2D one. I see there is in the code: ... I'm sure this works with most/all of the existing code, but is this the right way to go? Given that most filters manipulating filters are extending from the duplicating filter visitor, wouldn't it be better to fix that one instead? Also, I believe the ReprojectingFilterVisitor won't work properly with the above hack, and that it might need some logic changes (a way consistent with geometry reprojection would be to reproject the 2d component of the bbox and leave the 3d part move unaltered to the result) Also, given this is an API change there should be some documentation on a upgrade to 9.x page telling people to expect this new kind of filter in their custom visitors, and probably some changes on the FilterVisitor javadocs are in order as well. This is one problematic area of the proposal, it would have been better to point it out in the proposal document instead of having people have to review the code in order to see it: a good proposal is also showing what is _not_ covered/done and what the potentially problematic areas are (and how the problems have been addressed). Yes, you have a point here, this is a weak part. I stole the code from your fastbbox, but it is indeed an ugly hack. I would be happy to change the filter visitors instead, but I was trying to minimise changes to the core. I am sorry I didn't point this out in the proposal, I will do something about it. This went a bit off the tangent, but here is the part that affects the filtering code. Say I have a layer in postgis that is declared as EPSG:4326 with dimension=3 (perfectly legit in postgis), how am I going to filter it using BBOX3D? It seems whatever I do I might be in some issue from some point of view: * if I state the crs is EPSG:4326 then the dimensionality check in ReferencedEnvelope3D.checkCoordinateReferenceSystemDimension() will make it impossible to build the filter * as a user I could know that I have to use EPSG:4327 instead, but this will make the CRS inconsistent with the one on the DBMS.. besides that, I don't see an immediate way for automated code to build the 3d equivalent of a 2d system, and the layer will be declared in the feature type as having EPSG:4326 (since that's what we reflect out of the database) The method checkCoordinateReferenceSystemDimension is identical to the one in its superclass, ReferencedEnvelope. (In fact, I should remove this copy-pasted method and instead make it protected instead of private in its superclass, this is left-over from changing the class structure). So the existing implementation already checks the srs's dimensionality against this. This means that is now forbidden to apply a 2D bbox against a 3D SRS. It only seemed logical for me to extend the same logic to situation the other way around. I would personally recommend to use a 3D SRS if you have 3D geometries, even in
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Mon, Aug 6, 2012 at 10:45 AM, Niels Charlier ni...@scitus.be wrote: The current patch and proposal does not include these features. However, I'd understand that WFS post requests need to at least support the same features as wfs get requests. Please let me know the minimum requirements with regards to this to get the patch approved. The GeoTools part is not affected, but in order to commit the GeoServer part you will need to make sure POST requests are supported as well. Only some time ago Justin complained that some WFS functionalities have been added on GET requests only and that moving forward we should try to implement everything on both sides. Yes, you have a point here, this is a weak part. I stole the code from your fastbbox, but it is indeed an ugly hack. I would be happy to change the filter visitors instead, but I was trying to minimise changes to the core. I am sorry I didn't point this out in the proposal, I will do something about it. The hack makes sense in the FastBBOX case because it's just a faster alias to the BBOX filter, it's not a new type of filter, yours is a brand new one that implementors should be aware of. The method checkCoordinateReferenceSystemDimension is identical to the one in its superclass, ReferencedEnvelope. (In fact, I should remove this copy-pasted method and instead make it protected instead of private in its superclass, this is left-over from changing the class structure). So the existing implementation already checks the srs's dimensionality against this. This means that is now forbidden to apply a 2D bbox against a 3D SRS. It only seemed logical for me to extend the same logic to situation the other way around. I would personally recommend to use a 3D SRS if you have 3D geometries, even in postgis, this seems to me like the best way to work. If this is not desired behaviour, I think it is not just my changes, but the existing code of the ReferencedEnvelope class that must be reviewed. Perhaps I could change the check to test if the dimension of SRS than the dimension of the bbox? Does that make any sense at all? Hmm... I don't have a good answer to this one off the top of my head. While I agree that in theory one should just use a 3d system, the practice is difference and here we are not doing research, but industrial systems that must work in the real world. Whatever path is chosen imho it should allow to write 3d filters against a PostGIS store that has a 2d crs but has 3 dimensions in the geometry columns table. SRS than the dimensions of the bbox seems a bit hacky but indeed it might well be the only solution. I find it suprising that 3D reprojection works indeed. Afaik to do it one needs proper support for vertical CRSs, which is contained in referencing3D. I though that module was not complete, have you looked into it and found otherwise? As far as I know that module isn't functional. I admit I am not 100% knowledgeable about everything in this field, I have only been learning this SRS stuff the past few months, so there is still a lot I don't know. I am only needing to reproject point and linestring geometries with 3d coordinates. Perhaps that explains it. Afaik this works the way I explained before, that is, the Z dimension is left unaltered during the reprojection. Which is not true reprojection, but what we can afford given that the vertical transformation module is not working Cheres 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Afaik this works the way I explained before, that is, the Z dimension is left unaltered during the reprojection. Which is not true reprojection, but what we can afford given that the vertical transformation module is not working I reprojected from WGS84 to WGS66 which only differ in their Z dimension, and the values are being altered. I am currently in the process of doing the calculations to see if it is indeed mathematically correct, but it is definitely altered. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On 08/06/2012 12:23 PM, Niels Charlier wrote: Afaik this works the way I explained before, that is, the Z dimension is left unaltered during the reprojection. Which is not true reprojection, but what we can afford given that the vertical transformation module is not working I reprojected from WGS84 to WGS66 which only differ in their Z dimension, and the values are being altered. I am currently in the process of doing the calculations to see if it is indeed mathematically correct, but it is definitely altered. And I can confirm that the 3d reprojection is indeed 100% mathematically accurate. Regards Niels -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
* for the trasform method imho a better, but simple implementation would be to reproject the x,y and leave the Z unaltered (but preserve it). This is what JTS.tarnsform(Geometry, MathTransform) does today, so it would also preserve consistency within the library Actually, the current implementation already does exactly this. Because transform works by calling expandToInclude on 2 coordinates, the 2d boundaries are expanded but the 3d boundaries are simply left untouched. Is that what you meant? Kind Regards Niels -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On 08/06/2012 01:56 PM, Niels Charlier wrote: * for the trasform method imho a better, but simple implementation would be to reproject the x,y and leave the Z unaltered (but preserve it). This is what JTS.tarnsform(Geometry, MathTransform) does today, so it would also preserve consistency within the library Actually, the current implementation already does exactly this. Because transform works by calling expandToInclude on 2 coordinates, the 2d boundaries are expanded but the 3d boundaries are simply left untouched. Is that what you meant? Kind Regards Niels Sorry, I did still have to add the preservation of the 3d coordinate because it starts from an empty target before it call expand. So I just have to add one line that smuggles the third coordinate back in. Regards Niels -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Update Patch: + Implement ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method + Implement better Transform method + Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return SRS string in filter class + Remove filtervisitor hack and update DuplicatingFilterVisitor + Support for bbox3d in OGC post filters + change dimension/srs checking in ReferencedEnvelope from = to Proposal Text: + Add Implications for Filter Visitors (and docs) Does that cover it? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: dual license request
I support this proposal: +1 This proposal has now been significantly narrowed from a request for relicensing of entire modules to a request for relicensing of individual files on a case-by-case basis where contributors-in-agreement can be identified. In my view, this compromise provides a good deal of protection against the accidental capture of work by other contributors, while enabling the reuse of valuable code in another project for the benefit of users. Kind regards, Ben. On 04/08/12 08:02, Jody Garnett wrote: proposal from previous email request: - http://docs.codehaus.org/display/GEOTOOLS/Dual+License+Request PMC : Your prompt feedback appreciated, the OSGeo board has a meeting monday and I would like to know where we stand Contributors: This is an unusual request, please make use of the community support section. -- Jody Garnett -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Fri, Aug 3, 2012 at 11:55 PM, Andrea Aime andrea.a...@geo-solutions.itwrote: Take also into consideration the data sources, that has implication as well. In PostGIS you can declare a 2D CRS and then specify the number of dimensions is 3 or 4, that's perfectly fine with the database, and I guess we should be able to support 3D bboxes against that case too. How is that going to play if the plan is to only use the CRS to figure out the dimensions? Would having some information in the GeometryDescriptor user data section that provides the true dimension regardless of the chosen CRS work better in general? This went a bit off the tangent, but here is the part that affects the filtering code. Say I have a layer in postgis that is declared as EPSG:4326 with dimension=3 (perfectly legit in postgis), how am I going to filter it using BBOX3D? It seems whatever I do I might be in some issue from some point of view: * if I state the crs is EPSG:4326 then the dimensionality check in ReferencedEnvelope3D.checkCoordinateReferenceSystemDimension() will make it impossible to build the filter * as a user I could know that I have to use EPSG:4327 instead, but this will make the CRS inconsistent with the one on the DBMS.. besides that, I don't see an immediate way for automated code to build the 3d equivalent of a 2d system, and the layer will be declared in the feature type as having EPSG:4326 (since that's what we reflect out of the database) 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Mon, Jul 30, 2012 at 11:11 AM, Niels Charlier ni...@scitus.be wrote:
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Okay, so I decided to remove the Envelope3D class, and merge it with
ReferencedEvelope3D, and make ReferencedEvelope3D derived from
ReferencedEnvelope.
I hope this addresses the previously expressed concerns adequately.
Ah, forgot one more thing that affects the proposal.
The proposal is effectively adding a new type of filter, normally that
would require a change
in the filter visitor API to handle such new filter explicitly, however
this case is peculiar
in that the new filter extends an existing one.
This means the API might not be in need of change, but it has consequences
on the API.
In particular, all filter visitors dedicated to the manipulation of filters
(including the
simplifiying filter visitor) will create a copy that's a plain 2D BBOX, and
the CQL encoder
will encode the bbox as a 2D one.
I see there is in the code:
+public Object accept(FilterVisitor visitor, Object context) {
+Object result = visitor.visit(this, context);
+
+//hack - if the visitor tried to clone us but created a regular
bbox instead with replace it with a proper clone
+if (result instanceof BBOX) {
+BBOX clone = (BBOX) result;
+if(clone.getExpression1().equals(getExpression1())
clone.getExpression2().equals(getExpression2()))
+return new BBOX3DImpl(property, envelope, factory);
+
+}
+
+return result;
+}
I'm sure this works with most/all of the existing code, but is this the
right way to go?
Given that most filters manipulating filters are extending from the
duplicating filter visitor,
wouldn't it be better to fix that one instead?
Also, I believe the ReprojectingFilterVisitor won't work properly with the
above hack,
and that it might need some logic changes (a way consistent with geometry
reprojection
would be to reproject the 2d component of the bbox and leave the 3d part
move
unaltered to the result)
Also, given this is an API change there should be some documentation on a
upgrade to 9.x page telling people to expect this new kind of filter in
their custom
visitors, and probably some changes on the FilterVisitor javadocs are in
order as well.
This is one problematic area of the proposal, it would have been better to
point
it out in the proposal document instead of having people have to review the
code
in order to see it: a good proposal is also showing what is _not_
covered/done and
what the potentially problematic areas are (and how the problems have been
addressed).
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 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
---
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Hi Andrea, Thank you for look at it ! Here are some answers to your questions and concerns: Looked at the proposal and the patch, a few questions: * the proposal should tell how are you addressing the dicotomy between CoordinateReferenceSystem and the SRS string which is required by the BBOX interface (the CRS might not have a way to be represented as an SRS) How is this different than creating a BBOX filter from a non-3D ReferencedEnvelope. I notice the following method is used: CRS.toSRS( bounds.getCoordinateReferenceSystem() ) I could do this for ReferencedEnvelope3D 's too. At the moment, I am not even implementing the getSRS method because I partially based myself on the FastBBOX implementation who doesn't either. The method is deprecated anyway. In any case, this is not an issue that is specific of using a ReferencedEnvelope3D instead of a ReferencedEnvelope to represent the bounding box and crs. What do you think? * ReferencedEnvelope3D extends ReferenceEnvelope (not ReferenceEnvelope3D)... this is just a typo anyways * It would be nice to have ReferencedEnvelope.reference(org.opengis.geometry.Envelope) method building the proper ReferencedEnvelope object based on the number of dimensions of the provided Envelope Sure, can be done. * for the trasform method imho a better, but simple implementation would be to reproject the x,y and leave the Z unaltered (but preserve it). This is what JTS.tarnsform(Geometry, MathTransform) does today, so it would also preserve consistency within the library Okay, I can do that. * About the usage of the CRS to determine if the dimensions are 3 I have my doubts... the support for 3D CRS is not very good in GeoTools, I believe the common usage would be 2d+1 with a 2d crs with 3 ordinates I am not really sure I know what you mean here. I think only in the app-schema test code I take the dimensions from the CRS, but this seems to work fine, it seems to be in line with the official descriptions of the CRS's. Geoserver does accepts a third coordinate even when you use for example EPSG:4283, which is strictly a 2D CRS, but the correct way to do this is use the newer EPSG:4979 instead which does officially support 3 coordinates. I think the correct behaviour is used for testing and proven to past. * I see BBOX3D is a new type of filter that the stores need to implement support for. Which means right now we're going to have full in memory evaluation of these 3d bboxes for all stores, which is going to be tremendously slow. This is true. But I think in any case, the post-filter must initially be supported as a fallback at all times. Support on SQL level needs to be programmed for each DBMS type individually. I left this option open, but the changes do not include this. I think they should best be implemented afterwards to improve performance, once we have the core functionality implemented. * I see no support for building a BBOX3D filter by parsing XML or CQL, which means there is no real way to use it besides building it programmatically, how is this going to be handled? I am not sure if I understand you question completely, but is it possible the above answer apply to this also? Niels -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Fri, Aug 3, 2012 at 3:09 PM, Niels Charlier ni...@scitus.be wrote: Hi Andrea, Thank you for look at it ! Here are some answers to your questions and concerns: Looked at the proposal and the patch, a few questions: * the proposal should tell how are you addressing the dicotomy between CoordinateReferenceSystem and the SRS string which is required by the BBOX interface (the CRS might not have a way to be represented as an SRS) How is this different than creating a BBOX filter from a non-3D ReferencedEnvelope. I notice the following method is used: CRS.toSRS( bounds.**getCoordinateReferenceSystem() ) I could do this for ReferencedEnvelope3D 's too. At the moment, I am not even implementing the getSRS method because I partially based myself on the FastBBOX implementation who doesn't either. The method is deprecated anyway. In any case, this is not an issue that is specific of using a ReferencedEnvelope3D instead of a ReferencedEnvelope to represent the bounding box and crs. What do you think? That you need to implement that method, otherwise encoding filters in CQL/XML will be impossible. * About the usage of the CRS to determine if the dimensions are 3 I have my doubts... the support for 3D CRS is not very good in GeoTools, I believe the common usage would be 2d+1 with a 2d crs with 3 ordinates I am not really sure I know what you mean here. I think only in the app-schema test code I take the dimensions from the CRS, but this seems to work fine, it seems to be in line with the official descriptions of the CRS's. Geoserver does accepts a third coordinate even when you use for example EPSG:4283, which is strictly a 2D CRS, but the correct way to do this is use the newer EPSG:4979 instead which does officially support 3 coordinates. I think the correct behaviour is used for testing and proven to past. Have you tried to do any reprojection, or use compound CRSs, and/or try to switch from a compound one to a fully 3d one? Afaik none of these work. Reprojection in WMS and WFS is bread and butter, not being able to support it is going to be a serious issue. * I see BBOX3D is a new type of filter that the stores need to implement support for. Which means right now we're going to have full in memory evaluation of these 3d bboxes for all stores, which is going to be tremendously slow. This is true. But I think in any case, the post-filter must initially be supported as a fallback at all times. Support on SQL level needs to be programmed for each DBMS type individually. I left this option open, but the changes do not include this. I think they should best be implemented afterwards to improve performance, once we have the core functionality implemented. I can never related to this line of reasoning where we'll make it faster later due to two reasons: * performance can always be improved, high performance cannot be retrofitted though, it has to be designed * temporary solutions have the bad habit of becoming permanent, the risk of going out and releasing something that may kill a production system because the funds to make it faster dried up worries me quite a bit How sure you are that you're going to implement proper encoding of 3D bboxes at the very least for JDBC stores (and possibly for shapefiles as well?) * I see no support for building a BBOX3D filter by parsing XML or CQL, which means there is no real way to use it besides building it programmatically, how is this going to be handled? I am not sure if I understand you question completely, but is it possible the above answer apply to this also? Same concern here, if you cannot parse a 3D bbox how are you going to make WFS queries possible? WMS wise, how are you going to deal with the 3D bbox? What about CQL filtering, or in SLD filtering? All of these will need some way for 3D bboxes to be parsed and encoded back 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On 08/03/2012 03:55 PM, Andrea Aime wrote: On Fri, Aug 3, 2012 at 3:09 PM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: Hi Andrea, Thank you for look at it ! Here are some answers to your questions and concerns: Looked at the proposal and the patch, a few questions: * the proposal should tell how are you addressing the dicotomy between CoordinateReferenceSystem and the SRS string which is required by the BBOX interface (the CRS might not have a way to be represented as an SRS) How is this different than creating a BBOX filter from a non-3D ReferencedEnvelope. I notice the following method is used: CRS.toSRS( bounds.getCoordinateReferenceSystem() ) I could do this for ReferencedEnvelope3D 's too. At the moment, I am not even implementing the getSRS method because I partially based myself on the FastBBOX implementation who doesn't either. The method is deprecated anyway. In any case, this is not an issue that is specific of using a ReferencedEnvelope3D instead of a ReferencedEnvelope to represent the bounding box and crs. What do you think? That you need to implement that method, otherwise encoding filters in CQL/XML will be impossible. Okay, no problem, but is the above suggested solution good for you? This is how it happens for ReferencedEnvelope3D's. * About the usage of the CRS to determine if the dimensions are 3 I have my doubts... the support for 3D CRS is not very good in GeoTools, I believe the common usage would be 2d+1 with a 2d crs with 3 ordinates I am not really sure I know what you mean here. I think only in the app-schema test code I take the dimensions from the CRS, but this seems to work fine, it seems to be in line with the official descriptions of the CRS's. Geoserver does accepts a third coordinate even when you use for example EPSG:4283, which is strictly a 2D CRS, but the correct way to do this is use the newer EPSG:4979 instead which does officially support 3 coordinates. I think the correct behaviour is used for testing and proven to past. Have you tried to do any reprojection, or use compound CRSs, and/or try to switch from a compound one to a fully 3d one? Afaik none of these work. Reprojection in WMS and WFS is bread and butter, not being able to support it is going to be a serious issue. I am actually currently working on 3D reprojection atm, but it is a whole other feature. I am surprised you say this because I though a few months ago somebody on the list said that 3D reprojection should already work, and my tests seem to suggest this is in fact the case (with some minor changes). In any case, I am not really clear how this is in the way of the changes I am proposing here. Or, what is it exactly that you want me to change or improve here in my proposal or patch? I can never related to this line of reasoning where we'll make it faster later due to two reasons: * performance can always be improved, high performance cannot be retrofitted though, it has to be designed * temporary solutions have the bad habit of becoming permanent, the risk of going out and releasing something that may kill a production system because the funds to make it faster dried up worries me quite a bit How sure you are that you're going to implement proper encoding of 3D bboxes at the very least for JDBC stores (and possibly for shapefiles as well?) I do need to clarify: I am not saying : we are going to implement something a bad way now, and make it better later. That would be indeed a bad line of reasoning. What I am doing here is absolutely *necessary* work for 3d bbox filters, and there is nothing programmed in a bad quality there. The post-filter is the first requirement, so it is the first thing that needs to happen. It it better to have a post-filter implementation than no implementation at all (There are other things in geotools that only work with post-filters, functions like concat.) It cannot possibly hurt anyone to have this feature. I think we need to take it one step at a time, otherwise I need to make a patch so big that it is too big to review and if it doesn't get approved a lot of work is lost. The bounding box will need to be implemented for every possible dbms differently, and yes it will not be so easy at all. I think the post-filter implementation proves that it can work, and lays the foundations for further development in this direction. But we can't do and support everything at once. * I see no support for building a BBOX3D filter by parsing XML or CQL, which means there is no real way to use it besides building it programmatically, how is this going to be handled? I am not sure if I understand you question completely, but is it possible the above answer apply to this also? Same concern here, if you
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Fri, Aug 3, 2012 at 9:11 PM, Niels Charlier ni...@scitus.be wrote: That you need to implement that method, otherwise encoding filters in CQL/XML will be impossible. Okay, no problem, but is the above suggested solution good for you? This is how it happens for ReferencedEnvelope3D's. Works for me I can never related to this line of reasoning where we'll make it faster later due to two reasons: * performance can always be improved, high performance cannot be retrofitted though, it has to be designed * temporary solutions have the bad habit of becoming permanent, the risk of going out and releasing something that may kill a production system because the funds to make it faster dried up worries me quite a bit How sure you are that you're going to implement proper encoding of 3D bboxes at the very least for JDBC stores (and possibly for shapefiles as well?) I do need to clarify: I am not saying : we are going to implement something a bad way now, and make it better later. That would be indeed a bad line of reasoning. What I am doing here is absolutely *necessary* work for 3d bbox filters, and there is nothing programmed in a bad quality there. The post-filter is the first requirement, so it is the first thing that needs to happen. It it better to have a post-filter implementation than no implementation at all (There are other things in geotools that only work with post-filters, functions like concat.) It cannot possibly hurt anyone to have this feature. I think we need to take it one step at a time, otherwise I need to make a patch so big that it is too big to review and if it doesn't get approved a lot of work is lost. The bounding box will need to be implemented for every possible dbms differently, and yes it will not be so easy at all. I think the post-filter implementation proves that it can work, and lays the foundations for further development in this direction. But we can't do and support everything at once. I'm not saying that you have to do everything at once, can you answer the simple question above though? Restating it: How sure you are that you're going to implement proper encoding of 3D bboxes at the very least for JDBC stores (and possibly for shapefiles as well?) Same concern here, if you cannot parse a 3D bbox how are you going to make WFS queries possible? WMS wise, how are you going to deal with the 3D bbox? What about CQL filtering, or in SLD filtering? All of these will need some way for 3D bboxes to be parsed and encoded back There is no 3d bbox in WMS as of yet, this is only the implementation of a WFS 3d bbox. Again, we need to take it one step at a time. But in WFS, the 3d bbox works as proven in the unit tests included in the patch. I have looked at the patch and I don't see where in the code you are handling the parsing of a BBOX filter coming from a OGC filter in a POST request, or a BBOX coming from a CQL filter. If you are not planning to support them please state so, if you are planning to do please clarify how and when If you are planning to make a set of proposals that's fine, it would help a lot to see a roadmap of them, otherwise we have to evaluate them under the assumption that nothing will come after them, and what is in the proposal is all we're going to get, in the state that it's proposed, and drive conclusions about the resulting structure of the API, general stability and performance that results of just the changes that are in there. 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Fri, Aug 3, 2012 at 9:11 PM, Niels Charlier ni...@scitus.be wrote: I am actually currently working on 3D reprojection atm, but it is a whole other feature. I am surprised you say this because I though a few months ago somebody on the list said that 3D reprojection should already work, and my tests seem to suggest this is in fact the case (with some minor changes). In any case, I am not really clear how this is in the way of the changes I am proposing here. Or, what is it exactly that you want me to change or improve here in my proposal or patch? Forgot to address this one. I find it suprising that 3D reprojection works indeed. Afaik to do it one needs proper support for vertical CRSs, which is contained in referencing3D. I though that module was not complete, have you looked into it and found otherwise? How are you going to handle the difference between full 3D and compund CRS? In the EPSG database there is a lot of the latter type, a 3D system actually made of a 2D one in combination with a vertical CRS. Also, what are the implication for the uniformity of the library, as said before the current geometry reprojection engine treats the 3rd coordinate as something that is going to be passed by. You say this is another proposal, however the fact that 3D referencing actually works or not has consequences on the whether the decision to use the dimension of the CRS as the marker for 3D data is going to work or not in the long run. Take also into consideration the data sources, that has implication as well. In PostGIS you can declare a 2D CRS and then specify the number of dimensions is 3 or 4, that's perfectly fine with the database, and I guess we should be able to support 3D bboxes against that case too. How is that going to play if the plan is to only use the CRS to figure out the dimensions? Would having some information in the GeometryDescriptor user data section that provides the true dimension regardless of the chosen CRS work better in general? 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] proposal: dual license request
proposal from previous email request: - http://docs.codehaus.org/display/GEOTOOLS/Dual+License+Request PMC : Your prompt feedback appreciated, the OSGeo board has a meeting monday and I would like to know where we stand Contributors: This is an unusual request, please make use of the community support section. -- Jody Garnett -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
On Tue, Jul 31, 2012 at 5:44 PM, Niels Charlier ni...@scitus.be wrote: Oops it seems some new files are missing in the patch. My apologies, will upload complete patch in a minute. Looked at the proposal and the patch, a few questions: * the proposal should tell how are you addressing the dicotomy between CoordinateReferenceSystem and the SRS string which is required by the BBOX interface (the CRS might not have a way to be represented as an SRS) * ReferencedEnvelope3D extends ReferenceEnvelope (not ReferenceEnvelope3D)... this is just a typo anyways * It would be nice to have ReferencedEnvelope.reference(org.opengis.geometry.Envelope) method building the proper ReferencedEnvelope object based on the number of dimensions of the provided Envelope * for the trasform method imho a better, but simple implementation would be to reproject the x,y and leave the Z unaltered (but preserve it). This is what JTS.tarnsform(Geometry, MathTransform) does today, so it would also preserve consistency within the library * About the usage of the CRS to determine if the dimensions are 3 I have my doubts... the support for 3D CRS is not very good in GeoTools, I believe the common usage would be 2d+1 with a 2d crs with 3 ordinates * I see BBOX3D is a new type of filter that the stores need to implement support for. Which means right now we're going to have full in memory evaluation of these 3d bboxes for all stores, which is going to be tremendously slow. * I see no support for building a BBOX3D filter by parsing XML or CQL, which means there is no real way to use it besides building it programmatically, how is this going to be handled? 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Thanks Niels +1 For me now, and yes I was slack as I was supposed to help you fix up the proposal after voting -1 :( -- Jody Garnett On Monday, 30 July 2012 at 7:11 PM, Niels Charlier wrote: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Okay, so I decided to remove the Envelope3D class, and merge it with ReferencedEvelope3D, and make ReferencedEvelope3D derived from ReferencedEnvelope. I hope this addresses the previously expressed concerns adequately. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
+1 from me. On 30/07/12 17:11, Niels Charlier wrote: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Okay, so I decided to remove the Envelope3D class, and merge it with ReferencedEvelope3D, and make ReferencedEvelope3D derived from ReferencedEnvelope. I hope this addresses the previously expressed concerns adequately. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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 Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
I still don't see the new BBOX3D interface... looking at the latest patch here: http://jira.codehaus.org/browse/GEOS-5148 But all i wanted to see was if it extends the existing BBOX one which you confirmed. So I would say I am +1 on this. On Mon, Jul 30, 2012 at 11:13 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au wrote: +1 from me. On 30/07/12 17:11, Niels Charlier wrote: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Okay, so I decided to remove the Envelope3D class, and merge it with ReferencedEvelope3D, and make ReferencedEvelope3D derived from ReferencedEnvelope. I hope this addresses the previously expressed concerns adequately. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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 Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Oops it seems some new files are missing in the patch. My apologies, will upload complete patch in a minute. On 07/31/2012 04:38 PM, Justin Deoliveira wrote: I still don't see the new BBOX3D interface... looking at the latest patch here: http://jira.codehaus.org/browse/GEOS-5148 But all i wanted to see was if it extends the existing BBOX one which you confirmed. So I would say I am +1 on this. On Mon, Jul 30, 2012 at 11:13 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: +1 from me. On 30/07/12 17:11, Niels Charlier wrote: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Okay, so I decided to remove the Envelope3D class, and merge it with ReferencedEvelope3D, and make ReferencedEvelope3D derived from ReferencedEnvelope. I hope this addresses the previously expressed concerns adequately. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net mailto:GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net mailto:GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Okay, so I decided to remove the Envelope3D class, and merge it with ReferencedEvelope3D, and make ReferencedEvelope3D derived from ReferencedEnvelope. I hope this addresses the previously expressed concerns adequately. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Looking much better Niels, i think this will slot in much cleaner. Is BBOX3D a new interface? I was just looking through the patch and not seeing it defined there although i do see the BBOX3DImpl class defined. On Mon, Jul 30, 2012 at 2:11 AM, Niels Charlier ni...@scitus.be wrote: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Okay, so I decided to remove the Envelope3D class, and merge it with ReferencedEvelope3D, and make ReferencedEvelope3D derived from ReferencedEnvelope. I hope this addresses the previously expressed concerns adequately. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal* (new version): Support for three-dimensional envelopes and bounding box filters
Yeah it should definitely be in there. BBOX3D is the filter interface, which extends BBOX. On 07/30/2012 05:04 PM, Justin Deoliveira wrote: Looking much better Niels, i think this will slot in much cleaner. Is BBOX3D a new interface? I was just looking through the patch and not seeing it defined there although i do see the BBOX3DImpl class defined. On Mon, Jul 30, 2012 at 2:11 AM, Niels Charlier ni...@scitus.be mailto:ni...@scitus.be wrote: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Okay, so I decided to remove the Envelope3D class, and merge it with ReferencedEvelope3D, and make ReferencedEvelope3D derived from ReferencedEnvelope. I hope this addresses the previously expressed concerns adequately. Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net mailto:GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
What about maintaining two separate envelope classes? I didn't look at the patch but if there is any real hard work that goes on inside perhaps it could be deleted out to a utility class. On Wed, Jul 18, 2012 at 12:37 PM, Niels Charlier ni...@scitus.be wrote: Okay, but this is impossible because ReferencedEvelope3D cannot be derived from both Envelope3D and ReferencedEnvelope at the same time. Unless what you mean is that I drop Envelope3D all together and merge the two classes? I can look in to that option. Kind Regards Niels Charlier On 17/07/12 16:27, Justin Deoliveira wrote: When I first read over the proposal this was my thought as well. On Tue, Jul 17, 2012 at 5:47 AM, Jody Garnett jody.garn...@gmail.comwrote: That would work for me. -- Jody Garnett On 17/07/2012, at 7:38 PM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.comwrote: The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. Agreed; it would not be fun. We do have a couple implementations of the opengis Envelope interface to show us the way however. Still I would rather have one class that is tricky for us to write; then make something that is difficult for everyone else to use. Notes: - this single class solution prevents you from performing an instance of check to determine if 2D or 3D is supported - will that be a problem for your code? - A clean way to implement would be to have an optional internal delegate opengis Envelope, if it is non null we can delegate to that implementation. If it is null we can delegate to the JTSEnvelope superclass. Why can't we have a ReferencedEnvelope3D extends ReferencedEnvelope? It would allow the writing of the custom 3d logic without riddling the code with if statements, and would allow for an instanceof check. 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 962313 mob: +39 339 8844549 %2B39%20%C2%A0339%208844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing listGeoTools-Devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/geotools-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
On Thu, Jul 19, 2012 at 4:09 PM, Justin Deoliveira jdeol...@opengeo.orgwrote: What about maintaining two separate envelope classes? I didn't look at the patch but if there is any real hard work that goes on inside perhaps it could be deleted out to a utility class. The probem with two separate classes seems that ReferenceEnvelope3D would not just be usable in place of ReferencedEnvelope, which would make for another complication when writing code 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
On Thu, Jul 19, 2012 at 8:55 AM, Andrea Aime andrea.a...@geo-solutions.itwrote: On Thu, Jul 19, 2012 at 4:09 PM, Justin Deoliveira jdeol...@opengeo.orgwrote: What about maintaining two separate envelope classes? I didn't look at the patch but if there is any real hard work that goes on inside perhaps it could be deleted out to a utility class. The probem with two separate classes seems that ReferenceEnvelope3D would not just be usable in place of ReferencedEnvelope, which would make for another complication when writing code Sorry, what i meant was ReferencedEnvelope3D would extend ReferencedEnvelope and then whatever other concrete implementation required would extend the existing 2D implementation in the same pattern. So the two implementations could not sure a common super class (but could share a common interface) but should be a transparent drop in for existing code. 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
That means that referencedenvelope3d is not derived from en evelope3d any longer, which is impossible unless I drop envelope3d all together and merge them. Is that what you are suggesting? I will look in to this possibility. Sent from Samsung Mobile Justin Deoliveira jdeol...@opengeo.org wrote: When I first read over the proposal this was my thought as well. On Tue, Jul 17, 2012 at 5:47 AM, Jody Garnett jody.garn...@gmail.com wrote: That would work for me. -- Jody Garnett On 17/07/2012, at 7:38 PM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.com wrote: The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. Agreed; it would not be fun. We do have a couple implementations of the opengis Envelope interface to show us the way however. Still I would rather have one class that is tricky for us to write; then make something that is difficult for everyone else to use. Notes: - this single class solution prevents you from performing an instance of check to determine if 2D or 3D is supported - will that be a problem for your code? - A clean way to implement would be to have an optional internal delegate opengis Envelope, if it is non null we can delegate to that implementation. If it is null we can delegate to the JTSEnvelope superclass. Why can't we have a ReferencedEnvelope3D extends ReferencedEnvelope? It would allow the writing of the custom 3d logic without riddling the code with if statements, and would allow for an instanceof check. 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
On Wed, Jul 18, 2012 at 9:30 AM, Niels ni...@scitus.be wrote: That means that referencedenvelope3d is not derived from en evelope3d any longer, which is impossible unless I drop envelope3d all together and merge them. Is that what you are suggesting? I will look in to this possibility. Yep, that's the idea 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
Okay, but this is impossible because ReferencedEvelope3D cannot be derived from both Envelope3D and ReferencedEnvelope at the same time. Unless what you mean is that I drop Envelope3D all together and merge the two classes? I can look in to that option. Kind Regards Niels Charlier On 17/07/12 16:27, Justin Deoliveira wrote: When I first read over the proposal this was my thought as well. On Tue, Jul 17, 2012 at 5:47 AM, Jody Garnett jody.garn...@gmail.com mailto:jody.garn...@gmail.com wrote: That would work for me. -- Jody Garnett On 17/07/2012, at 7:38 PM, Andrea Aime andrea.a...@geo-solutions.it mailto:andrea.a...@geo-solutions.it wrote: On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.com mailto:jody.garn...@gmail.com wrote: The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. Agreed; it would not be fun. We do have a couple implementations of the opengis Envelope interface to show us the way however. Still I would rather have one class that is tricky for us to write; then make something that is difficult for everyone else to use. Notes: - this single class solution prevents you from performing an instance of check to determine if 2D or 3D is supported - will that be a problem for your code? - A clean way to implement would be to have an optional internal delegate opengis Envelope, if it is non null we can delegate to that implementation. If it is null we can delegate to the JTSEnvelope superclass. Why can't we have a ReferencedEnvelope3D extends ReferencedEnvelope? It would allow the writing of the custom 3d logic without riddling the code with if statements, and would allow for an instanceof check. 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 tel:%2B39%200584%20962313 fax: +39 0584 962313 tel:%2B39%200584%20962313 mob: +39 339 8844549 tel:%2B39%20%C2%A0339%208844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net mailto:GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. On 07/17/2012 03:54 AM, Jody Garnett wrote: So I kind of see where you are going with this. It gets a bit strange around the ReferencedEnvelope / ReferencedEnvelope3D level. -1 The FeatureCollections.getBounds() contract cannot be respected for your ReferenceEnvelope or ReferenceEnvelope3D. I know you only want to use this as part of a query, but I don't want our envelope story to get even more strange if we can avoid it. I don't want to impose a ReferenceEnvelope interface as that defeats the purpose of making ReferenceEnvelope an easy to use middle ground between JTS Envelope and the BoundingBox interface. If we had to go this way we would end up going with BoundingBox / Envelope interface and modifying them to be more method compatible with JTS Envelope. Can you consider switching around your class hierarchy? 1) BBoxEnvelope extension of JTS Envelope - Write this so it can work as a 2D or 3D envelope (depending on how the constructor is called) - the existing BoundingBox / Envelope interfaces should be sufficient? 2) Make ReferencedEnvelope extend BBoxEnvelope; and allow it to cover the 2D or 3D use-case Finally there is no need to make FilterFactory more crazy, treat your ReferencedEnvelope as a prameter object: BBOX3D bbox( Expression geometry, ReferencedEnvelope bbox, MatchAction matchAction); Waiting your reply, I am afraid we cannot make a ReferencedEnvelope interface (as an implementation class lots of downstream code makes direct reference to this one). -- Jody Garnett Forwarded message: *From:* Niels Charlier ni...@scitus.be *To:* geotools-devel@lists.sourceforge.net *Date:* Tuesday, 17 July 2012 6:09:35 AM *Subject:* [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters Hi Everyone, Please have a look at my proposal: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Please review. Kind Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net mailto:GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. Agreed; it would not be fun. We do have a couple implementations of the opengis Envelope interface to show us the way however. Still I would rather have one class that is tricky for us to write; then make something that is difficult for everyone else to use. Notes: - this single class solution prevents you from performing an instance of check to determine if 2D or 3D is supported - will that be a problem for your code? - A clean way to implement would be to have an optional internal delegate opengis Envelope, if it is non null we can delegate to that implementation. If it is null we can delegate to the JTSEnvelope superclass. Jody -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.comwrote: The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. Agreed; it would not be fun. We do have a couple implementations of the opengis Envelope interface to show us the way however. Still I would rather have one class that is tricky for us to write; then make something that is difficult for everyone else to use. Notes: - this single class solution prevents you from performing an instance of check to determine if 2D or 3D is supported - will that be a problem for your code? - A clean way to implement would be to have an optional internal delegate opengis Envelope, if it is non null we can delegate to that implementation. If it is null we can delegate to the JTSEnvelope superclass. Why can't we have a ReferencedEnvelope3D extends ReferencedEnvelope? It would allow the writing of the custom 3d logic without riddling the code with if statements, and would allow for an instanceof check. 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
That would work for me. -- Jody Garnett On 17/07/2012, at 7:38 PM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.comwrote: The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. Agreed; it would not be fun. We do have a couple implementations of the opengis Envelope interface to show us the way however. Still I would rather have one class that is tricky for us to write; then make something that is difficult for everyone else to use. Notes: - this single class solution prevents you from performing an instance of check to determine if 2D or 3D is supported - will that be a problem for your code? - A clean way to implement would be to have an optional internal delegate opengis Envelope, if it is non null we can delegate to that implementation. If it is null we can delegate to the JTSEnvelope superclass. Why can't we have a ReferencedEnvelope3D extends ReferencedEnvelope? It would allow the writing of the custom 3d logic without riddling the code with if statements, and would allow for an instanceof check. 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
When I first read over the proposal this was my thought as well. On Tue, Jul 17, 2012 at 5:47 AM, Jody Garnett jody.garn...@gmail.comwrote: That would work for me. -- Jody Garnett On 17/07/2012, at 7:38 PM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.comwrote: The interface was just an idea I threw in there, because there were concerns about ReferencedEnvelope3D not being a ReferencedEnvelope. But the idea of not making separate classes and make the current ones support 3D, I think is quite tricky too. The algorithms aren't necessarily the same with 2d and 3d. Basically, every method would need to have a check whether there is a 3rd dimension or not. Agreed; it would not be fun. We do have a couple implementations of the opengis Envelope interface to show us the way however. Still I would rather have one class that is tricky for us to write; then make something that is difficult for everyone else to use. Notes: - this single class solution prevents you from performing an instance of check to determine if 2D or 3D is supported - will that be a problem for your code? - A clean way to implement would be to have an optional internal delegate opengis Envelope, if it is non null we can delegate to that implementation. If it is null we can delegate to the JTSEnvelope superclass. Why can't we have a ReferencedEnvelope3D extends ReferencedEnvelope? It would allow the writing of the custom 3d logic without riddling the code with if statements, and would allow for an instanceof check. 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 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
Hi Everyone, Please have a look at my proposal: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Please review. Kind Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
So I kind of see where you are going with this. It gets a bit strange around the ReferencedEnvelope / ReferencedEnvelope3D level. -1 The FeatureCollections.getBounds() contract cannot be respected for your ReferenceEnvelope or ReferenceEnvelope3D. I know you only want to use this as part of a query, but I don't want our envelope story to get even more strange if we can avoid it. I don't want to impose a ReferenceEnvelope interface as that defeats the purpose of making ReferenceEnvelope an easy to use middle ground between JTS Envelope and the BoundingBox interface. If we had to go this way we would end up going with BoundingBox / Envelope interface and modifying them to be more method compatible with JTS Envelope. Can you consider switching around your class hierarchy? 1) BBoxEnvelope extension of JTS Envelope - Write this so it can work as a 2D or 3D envelope (depending on how the constructor is called) - the existing BoundingBox / Envelope interfaces should be sufficient? 2) Make ReferencedEnvelope extend BBoxEnvelope; and allow it to cover the 2D or 3D use-case Finally there is no need to make FilterFactory more crazy, treat your ReferencedEnvelope as a prameter object: BBOX3D bbox( Expression geometry, ReferencedEnvelope bbox, MatchAction matchAction); Waiting your reply, I am afraid we cannot make a ReferencedEnvelope interface (as an implementation class lots of downstream code makes direct reference to this one). -- Jody Garnett Forwarded message: From: Niels Charlier ni...@scitus.be To: geotools-devel@lists.sourceforge.net Date: Tuesday, 17 July 2012 6:09:35 AM Subject: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters Hi Everyone, Please have a look at my proposal: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Please review. Kind Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
Another doc page for your proposal: - http://docs.geotools.org/latest/userguide/library/api/envelope.html -- Jody Garnett On Tuesday, 17 July 2012 at 11:54 AM, Jody Garnett wrote: So I kind of see where you are going with this. It gets a bit strange around the ReferencedEnvelope / ReferencedEnvelope3D level. -1 The FeatureCollections.getBounds() contract cannot be respected for your ReferenceEnvelope or ReferenceEnvelope3D. I know you only want to use this as part of a query, but I don't want our envelope story to get even more strange if we can avoid it. I don't want to impose a ReferenceEnvelope interface as that defeats the purpose of making ReferenceEnvelope an easy to use middle ground between JTS Envelope and the BoundingBox interface. If we had to go this way we would end up going with BoundingBox / Envelope interface and modifying them to be more method compatible with JTS Envelope. Can you consider switching around your class hierarchy? 1) BBoxEnvelope extension of JTS Envelope - Write this so it can work as a 2D or 3D envelope (depending on how the constructor is called) - the existing BoundingBox / Envelope interfaces should be sufficient? 2) Make ReferencedEnvelope extend BBoxEnvelope; and allow it to cover the 2D or 3D use-case Finally there is no need to make FilterFactory more crazy, treat your ReferencedEnvelope as a prameter object: BBOX3D bbox( Expression geometry, ReferencedEnvelope bbox, MatchAction matchAction); Waiting your reply, I am afraid we cannot make a ReferencedEnvelope interface (as an implementation class lots of downstream code makes direct reference to this one). -- Jody Garnett Forwarded message: From: Niels Charlier ni...@scitus.be (mailto:ni...@scitus.be) To: geotools-devel@lists.sourceforge.net (mailto:geotools-devel@lists.sourceforge.net) Date: Tuesday, 17 July 2012 6:09:35 AM Subject: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters Hi Everyone, Please have a look at my proposal: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Please review. Kind Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] *proposal*: Support for three-dimensional envelopes and bounding box filters
I'm not even going to vote as Jody is our API supremo and you will need to address his concerns. Thanks, Jody, for providing suggestions to Niels. My only comment is unrelated: I suggest a slight clarification to the language describing BBOX, as discussed in GEOS-5148: Original text: we receive only geometries with one or more points in that 3D bounding box Suggested replacement: we receive only geometries not disjoint with that 3D bounding box http://jira.codehaus.org/browse/GEOS-5148 Kind regards, Ben. On 17/07/12 04:09, Niels Charlier wrote: Hi Everyone, Please have a look at my proposal: http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters Please review. Kind Regards Niels Charlier -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ 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 Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
Did the proposal also want to remove (deprecate in this case) the collection listeners? Or was it just the discussion block in the jira? The CollectionEvent support is replaced by FeatureEvent (i.e. feature source level) as per another already approved proposal. Indeed it was completing that work that led me on to this proposal. Is there anything using that functionality (and providing support for it?) There is some bridging code that listens for CollectionEvents and throws FeatureEvents, that is all I found. Jody -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
Sorry I did not look closely at the proposal, I only deprecated what it described, and left the sort and subCollection methods in place (as it also described). I will double check the remaining methods and update the proposal page if you like. I am more focused on the patch right now. The comments in the jira should be removed them, they are misleading. Reading; ah yes that was just part of a very old email discussion. I would also remove the commented out portion out of the patch, as they add more confusion as well Okay, it was basically what would happen for the 9.x branch. But yeah can do that then. I think getDescriptor() is simply missing. Still don't get it. The need is either clear or it should be left out. I don't get what you don't get :( getSchema(): FeatureType (holds the type of the element of the feature collection), consider rename to getType()? getDescriptor(): AttribtueDescriptor (holds the name of the elements of the feature collection) There is a separate proposal to add getDescriptor(), we can choose if we want to have getType() at that point in time, rather then hold up this pre release deprecation check. Jody -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
On Sun, Jun 24, 2012 at 11:32 AM, Jody Garnett jody.garn...@gmail.comwrote: I think getDescriptor() is simply missing. Still don't get it. The need is either clear or it should be left out. I don't get what you don't get :( getSchema(): FeatureType (holds the type of the element of the feature collection), consider rename to getType()? getDescriptor(): AttribtueDescriptor (holds the name of the elements of the feature collection) There is a separate proposal to add getDescriptor(), we can choose if we want to have getType() at that point in time, rather then hold up this pre release deprecation check. Well, I don't get why we need the name to start with. In my mind a feature collection is either a stand alone container, for which I don't see the need of a descriptor, or it could be the value of a complex feature property, but in the latter case the property already has its own descriptor. What's the use case for having a descriptor of a collection? Cheres Andrea -- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob:+39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
Okay I get where the confusion comes from … This is not the descriptor of the feature collection (which you are correct would be handled by whatever is containing it). This is instead only talking about getting a better handle on the contents of our feature collection. My impression this is the GML difference between the name of feature members (something like country) and the type of the feature members (something like CountryType). From the WFS spec they have an example with Person and PersionType: wfs:FeatureCollection …. … gml:featureMember Person myns:lastNameSmith/myns:lastName myns:firstNameFred/myns:firstName myns:age35/myns:age myns:sexMale/myns:sex myns:location gml:Pointgml:pos15 15/gml:pos/gml:Point /myns:location ... /Person /gml:featureMember /wfs:FeatureCollection Backed by the schema: xsd:element name=Person type=myns:PersonType substitutionGroup=gml:_Feature/ xsd:complexType name=PersonType xsd:complexContent xsd:extension base=gml:AbstractFeatureType xsd:sequence … /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType Currently that shows up in GeoTools as a FeatureCollection with: - getSchema(): PersonType information And Ben did some amazing hack to look up Person when encoding the result … The request is to make: - getSchema(): PersonType information - getDescriptor(): An attribute descriptor Person indicating the contents are of type PersonType -- Jody Garnett On Sunday, 24 June 2012 at 8:11 PM, Andrea Aime wrote: Well, I don't get why we need the name to start with. In my mind a feature collection is either a stand alone container, for which I don't see the need of a descriptor, or it could be the value of a complex feature property, but in the latter case the property already has its own descriptor. What's the use case for having a descriptor of a collection? Cheres Andrea -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
On Thu, Jun 21, 2012 at 9:36 AM, Jody Garnett jody.garn...@gmail.comwrote: Ugh, implemented as you suggest it will affect performance of WPS chaining a lot. This is due to the removal of the subCollection methods, which are the only way to have a streaming process (one that returns a computing collection) compute less data if a downstream process needs less. This approach is not used much now, but killing it right away will make it impossible to setup process chaing that efficiently work in pull mode. subCollection(Query) method is still there. Sorry I did not look closely at the proposal, I only deprecated what it described, and left the sort and subCollection methods in place (as it also described). I will double check the remaining methods and update the proposal page if you like. I am more focused on the patch right now. The comments in the jira should be removed them, they are misleading. I would also remove the commented out portion out of the patch, as they add more confusion as well I think it was a request for consistency, when this proposal was first written we had just made all the feature/attribute methods have a getTypeMethod(). I think getDescriptor() is simply missing. Still don't get it. The need is either clear or it should be left out. The rest about removing all the modification oriented methods from feature collection seems reasonable to me, I always think about feature collections in terms of something that is a view of a store. Real in memory collections can offer modification methods of course, and we should update demo and tutorial code accordingly. Yep, indeed I updated he addFeatures example to use a ListFeatureCollection rather than DefaultFeatureCollection yesterday. Nice One thing that still bothers me a lot about current collections is that they never throw a IOException, this is still a vestigial decision from the collection is a memory thing times, and makes it harder to write an implementation that actually does I/O (ouch, this code does IO but I cannot declare these IO exceptions...). I understand changing this would break a lot of client code, just ranting here. It is a good rant I understand. My own rant was a wish that FeatureIterator (and FeatureReader) would implement Closable. Hum... I believe it could be done on the new trunk, but Closeable throws IOException. If we need to have one method thwoing that excpetion, better have them all, no? Cheers Andrea -- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob:+39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
On Thu, Jun 21, 2012 at 3:09 AM, Jody Garnett jody.garn...@gmail.comwrote: A very old proposal removing the methods that assume an in memory model: - http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+revolution I have a small non-destructive patch providing the remaining deprecations outlined in the proposal: - https://jira.codehaus.org/browse/GEOT-4181 Can I ask for a review as I would like to apply this change prior to 8.0.x rolling out in order to respect our deprecation cycle. Ugh, implemented as you suggest it will affect performance of WPS chaining a lot. This is due to the removal of the subCollection methods, which are the only way to have a streaming process (one that returns a computing collection) compute less data if a downstream process needs less. This approach is not used much now, but killing it right away will make it impossible to setup process chaing that efficiently work in pull mode. If at all, what I'm realy missing there is a subCollection(Query) method that would replace subCollection(Filter) and subCollection(SortBy). Generally speaking asking users to use FeatureSource.getFeatures(Query) is a bad move, not because it's wrong per se, but because you might have long lost any reference to the feature source. I'm confused by getType and getDescriptor in the patch (https://jira.codehaus.org/secure/attachment/60308/geot-3181.patch) Read about it in the proposal, but still does not make sense to me... why should we go and replace getSchema with getType, it seems to do most harm than good? The rest about removing all the modification oriented methods from feature collection seems reasonable to me, I always think about feature collections in terms of something that is a view of a store. Real in memory collections can offer modification methods of course, and we should update demo and tutorial code accordingly. One thing that still bothers me a lot about current collections is that they never throw a IOException, this is still a vestigial decision from the collection is a memory thing times, and makes it harder to write an implementation that actually does I/O (ouch, this code does IO but I cannot declare these IO exceptions...). I understand changing this would break a lot of client code, just ranting here. Cheers Andrea -- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob:+39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
Ugh, implemented as you suggest it will affect performance of WPS chaining a lot. This is due to the removal of the subCollection methods, which are the only way to have a streaming process (one that returns a computing collection) compute less data if a downstream process needs less. This approach is not used much now, but killing it right away will make it impossible to setup process chaing that efficiently work in pull mode. subCollection(Query) method is still there. Sorry I did not look closely at the proposal, I only deprecated what it described, and left the sort and subCollection methods in place (as it also described). I will double check the remaining methods and update the proposal page if you like. I am more focused on the patch right now. If at all, what I'm realy missing there is a subCollection(Query) method that would replace subCollection(Filter) and subCollection(SortBy). Generally speaking asking users to use FeatureSource.getFeatures(Query) is a bad move, not because it's wrong per se, but because you might have long lost any reference to the feature source. Agreed (for my two cents). I'm confused by getType and getDescriptor in the patch (https://jira.codehaus.org/secure/attachment/60308/geot-3181.patch) Read about it in the proposal, but still does not make sense to me... why should we go and replace getSchema with getType, it seems to do most harm than good? I think it was a request for consistency, when this proposal was first written we had just made all the feature/attribute methods have a getTypeMethod(). I think getDescriptor() is simply missing. The rest about removing all the modification oriented methods from feature collection seems reasonable to me, I always think about feature collections in terms of something that is a view of a store. Real in memory collections can offer modification methods of course, and we should update demo and tutorial code accordingly. Yep, indeed I updated he addFeatures example to use a ListFeatureCollection rather than DefaultFeatureCollection yesterday. One thing that still bothers me a lot about current collections is that they never throw a IOException, this is still a vestigial decision from the collection is a memory thing times, and makes it harder to write an implementation that actually does I/O (ouch, this code does IO but I cannot declare these IO exceptions...). I understand changing this would break a lot of client code, just ranting here. It is a good rant I understand. My own rant was a wish that FeatureIterator (and FeatureReader) would implement Closable. Jody-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Proposal (old) ready for review and deprecation patch for 8.x patch
A very old proposal removing the methods that assume an in memory model: - http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+revolution I have a small non-destructive patch providing the remaining deprecations outlined in the proposal: - https://jira.codehaus.org/browse/GEOT-4181 Can I ask for a review as I would like to apply this change prior to 8.0.x rolling out in order to respect our deprecation cycle. -- Jody Garnett -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: ResourceId
In taking the patch for a spin, we've found some test failures in gt-xsd-fes. testParseId fails because the xml snippet being parsed contains a fes:ResourceId with no version attribute. As per spec, this is acceptable, but the ResourceIdImpl requires a Version or date range. I have no problem with requiring a version, but we need some default behaviour in the case where it's not provided. The spec seems to be silent on the matter, but my preference is to use LAST as the default. Does this make sense, or am I coming at the problem from the right side? On a side note, GeoGIT proved no trouble and I now have a resourceid branch in my fork with the few changes needed. Will worry about a pull request once these issues have been killed. -- Mark On 26 October 2011 01:36, Gabriel Roldan grol...@opengeo.org wrote: I like it. I don't expect it to be much of a trouble for GeoGit. What we'll need to review is the usage on the wfs2 versioning branch. As for GeoGit, the main addition is ability to mix attribute/spatial query with dataset history, instead of just one or the other through ResourceId, which is much welcomed. I'm looking forward to work on it (as I'd have to to update the wfs2-v branch). Cheers, Gabriel On Tue, Oct 25, 2011 at 4:28 AM, Jody Garnett jody.garn...@gmail.com wrote: Thanks for the review Mark. I will check test cases again tomorrow (mostly in the xml bindings) and then I am ready to commit. I would kind of like feedback from Gabriel (I have already done everything he indicated was required; but an extra pair of eyes would be good). -- Jody Garnett On Tuesday, 25 October 2011 at 4:01 PM, Mark Leslie wrote: The code examples make things clearer :) I haven't managed to apply the patch to my local and see what the damage would be to GeoGIT, but that's still on my list. I expect nothing scary in that regard, but will let you know when I get that done. -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com On 24 October 2011 03:07, Jody Garnett jody.garn...@gmail.com wrote: Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career
Re: [Geotools-devel] Proposal: ResourceId
You got it right. In that case we would use a featureid. Let us relax that constraint so someone can make a SetResourceId. -- Jody Garnett On 26/10/2011, at 5:07 PM, Mark Leslie mrk.les...@gmail.com wrote: In taking the patch for a spin, we've found some test failures in gt-xsd-fes. testParseId fails because the xml snippet being parsed contains a fes:ResourceId with no version attribute. As per spec, this is acceptable, but the ResourceIdImpl requires a Version or date range. I have no problem with requiring a version, but we need some default behaviour in the case where it's not provided. The spec seems to be silent on the matter, but my preference is to use LAST as the default. Does this make sense, or am I coming at the problem from the right side? On a side note, GeoGIT proved no trouble and I now have a resourceid branch in my fork with the few changes needed. Will worry about a pull request once these issues have been killed. -- Mark On 26 October 2011 01:36, Gabriel Roldan grol...@opengeo.org wrote: I like it. I don't expect it to be much of a trouble for GeoGit. What we'll need to review is the usage on the wfs2 versioning branch. As for GeoGit, the main addition is ability to mix attribute/spatial query with dataset history, instead of just one or the other through ResourceId, which is much welcomed. I'm looking forward to work on it (as I'd have to to update the wfs2-v branch). Cheers, Gabriel On Tue, Oct 25, 2011 at 4:28 AM, Jody Garnett jody.garn...@gmail.com wrote: Thanks for the review Mark. I will check test cases again tomorrow (mostly in the xml bindings) and then I am ready to commit. I would kind of like feedback from Gabriel (I have already done everything he indicated was required; but an extra pair of eyes would be good). -- Jody Garnett On Tuesday, 25 October 2011 at 4:01 PM, Mark Leslie wrote: The code examples make things clearer :) I haven't managed to apply the patch to my local and see what the damage would be to GeoGIT, but that's still on my list. I expect nothing scary in that regard, but will let you know when I get that done. -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com On 24 October 2011 03:07, Jody Garnett jody.garn...@gmail.com wrote: Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. -- The
Re: [Geotools-devel] Proposal: ResourceId
I've attached a patch to jira that cleans up the remaining test failures (thanks john). The solution to my problem was to create an explicit ResourceIdImpl constructor that takes no version or dates and create the default version. Then ResourceIdTypeBinding needs to look to version to determine which installer to invoke. -- Mark On 26 October 2011 21:28, Jody Garnett jody.garn...@gmail.com wrote: You got it right. In that case we would use a featureid. Let us relax that constraint so someone can make a SetResourceId. -- Jody Garnett On 26/10/2011, at 5:07 PM, Mark Leslie mrk.les...@gmail.com wrote: In taking the patch for a spin, we've found some test failures in gt-xsd-fes. testParseId fails because the xml snippet being parsed contains a fes:ResourceId with no version attribute. As per spec, this is acceptable, but the ResourceIdImpl requires a Version or date range. I have no problem with requiring a version, but we need some default behaviour in the case where it's not provided. The spec seems to be silent on the matter, but my preference is to use LAST as the default. Does this make sense, or am I coming at the problem from the right side? On a side note, GeoGIT proved no trouble and I now have a resourceid branch in my fork with the few changes needed. Will worry about a pull request once these issues have been killed. -- Mark On 26 October 2011 01:36, Gabriel Roldan grol...@opengeo.org wrote: I like it. I don't expect it to be much of a trouble for GeoGit. What we'll need to review is the usage on the wfs2 versioning branch. As for GeoGit, the main addition is ability to mix attribute/spatial query with dataset history, instead of just one or the other through ResourceId, which is much welcomed. I'm looking forward to work on it (as I'd have to to update the wfs2-v branch). Cheers, Gabriel On Tue, Oct 25, 2011 at 4:28 AM, Jody Garnett jody.garn...@gmail.com wrote: Thanks for the review Mark. I will check test cases again tomorrow (mostly in the xml bindings) and then I am ready to commit. I would kind of like feedback from Gabriel (I have already done everything he indicated was required; but an extra pair of eyes would be good). -- Jody Garnett On Tuesday, 25 October 2011 at 4:01 PM, Mark Leslie wrote: The code examples make things clearer :) I haven't managed to apply the patch to my local and see what the damage would be to GeoGIT, but that's still on my list. I expect nothing scary in that regard, but will let you know when I get that done. -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com On 24 October 2011 03:07, Jody Garnett jody.garn...@gmail.com wrote: Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities.
Re: [Geotools-devel] Proposal: ResourceId
Thanks Mark, I grabbed a fresh copy of the resourceid patches, applied them and all tests are passing. -Original Message- From: Mark Leslie [mailto:mrk.les...@gmail.com] Sent: Thursday, 27 October 2011 10:44 AM To: Jody Garnett Cc: Geotools-devel@lists.sourceforge.net Subject: Re: [Geotools-devel] Proposal: ResourceId I've attached a patch to jira that cleans up the remaining test failures (thanks john). The solution to my problem was to create an explicit ResourceIdImpl constructor that takes no version or dates and create the default version. Then ResourceIdTypeBinding needs to look to version to determine which installer to invoke. -- Mark On 26 October 2011 21:28, Jody Garnett jody.garn...@gmail.com wrote: You got it right. In that case we would use a featureid. Let us relax that constraint so someone can make a SetResourceId. -- Jody Garnett On 26/10/2011, at 5:07 PM, Mark Leslie mrk.les...@gmail.com wrote: In taking the patch for a spin, we've found some test failures in gt-xsd-fes. testParseId fails because the xml snippet being parsed contains a fes:ResourceId with no version attribute. As per spec, this is acceptable, but the ResourceIdImpl requires a Version or date range. I have no problem with requiring a version, but we need some default behaviour in the case where it's not provided. The spec seems to be silent on the matter, but my preference is to use LAST as the default. Does this make sense, or am I coming at the problem from the right side? On a side note, GeoGIT proved no trouble and I now have a resourceid branch in my fork with the few changes needed. Will worry about a pull request once these issues have been killed. -- Mark On 26 October 2011 01:36, Gabriel Roldan grol...@opengeo.org wrote: I like it. I don't expect it to be much of a trouble for GeoGit. What we'll need to review is the usage on the wfs2 versioning branch. As for GeoGit, the main addition is ability to mix attribute/spatial query with dataset history, instead of just one or the other through ResourceId, which is much welcomed. I'm looking forward to work on it (as I'd have to to update the wfs2-v branch). Cheers, Gabriel On Tue, Oct 25, 2011 at 4:28 AM, Jody Garnett jody.garn...@gmail.com wrote: Thanks for the review Mark. I will check test cases again tomorrow (mostly in the xml bindings) and then I am ready to commit. I would kind of like feedback from Gabriel (I have already done everything he indicated was required; but an extra pair of eyes would be good). -- Jody Garnett On Tuesday, 25 October 2011 at 4:01 PM, Mark Leslie wrote: The code examples make things clearer :) I haven't managed to apply the patch to my local and see what the damage would be to GeoGIT, but that's still on my list. I expect nothing scary in that regard, but will let you know when I get that done. -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com On 24 October 2011 03:07, Jody Garnett jody.garn...@gmail.com wrote: Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett --- --- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: ResourceId
The code examples make things clearer :) I haven't managed to apply the patch to my local and see what the damage would be to GeoGIT, but that's still on my list. I expect nothing scary in that regard, but will let you know when I get that done. -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com On 24 October 2011 03:07, Jody Garnett jody.garn...@gmail.com wrote: Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: ResourceId
Thanks for the review Mark. I will check test cases again tomorrow (mostly in the xml bindings) and then I am ready to commit. I would kind of like feedback from Gabriel (I have already done everything he indicated was required; but an extra pair of eyes would be good). -- Jody Garnett On Tuesday, 25 October 2011 at 4:01 PM, Mark Leslie wrote: The code examples make things clearer :) I haven't managed to apply the patch to my local and see what the damage would be to GeoGIT, but that's still on my list. I expect nothing scary in that regard, but will let you know when I get that done. -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com On 24 October 2011 03:07, Jody Garnett jody.garn...@gmail.com (mailto:jody.garn...@gmail.com) wrote: Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net (mailto:Geotools-devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Proposal: Moving GT-2.7.x to ImageIO-Ext 1.1.x (instead of 1.0.x)
Hi lists, first of all, sorry for cross posting. We were thinking about aligning GT 2.7 to depend on ImageIO-Ext 1.1.x, as we have already done for GT-Trunk. With respect to older ImageIO-Ext 1.0.x series, 1.1.x provides improvements like: - Support for GDAL 1.7.3 (Currently ImageIO-Ext 1.0.8 still uses a very old GDAL 1.4.5) - Support for BigTIFF (Breaking the 4GB TIFF limit). - Support for destinationRegion param to support oversampling/subsampling without specifying sourceSubSamplinghttp://download.oracle.com/javase/6/docs/api/javax/imageio/IIOParam.html#setSourceSubsampling%28int,%20int,%20int,%20int%29parameters. This may be used when dealing with readers which internally take care of performing subSampling/overSampling, as the gdal readers. In case there isn't any objection, I will open a JIRA in the next days and afterwards, I'll start working on that topic. Please, let me know. Best Regards, Daniele -- --- Ing. Daniele Romagnoli GeoSolutions S.A.S. Software Engineer Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://it.linkedin.com/in/danieleromagnoli --- -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: ResourceId
I like it. I don't expect it to be much of a trouble for GeoGit. What we'll need to review is the usage on the wfs2 versioning branch. As for GeoGit, the main addition is ability to mix attribute/spatial query with dataset history, instead of just one or the other through ResourceId, which is much welcomed. I'm looking forward to work on it (as I'd have to to update the wfs2-v branch). Cheers, Gabriel On Tue, Oct 25, 2011 at 4:28 AM, Jody Garnett jody.garn...@gmail.comwrote: Thanks for the review Mark. I will check test cases again tomorrow (mostly in the xml bindings) and then I am ready to commit. I would kind of like feedback from Gabriel (I have already done everything he indicated was required; but an extra pair of eyes would be good). -- Jody Garnett On Tuesday, 25 October 2011 at 4:01 PM, Mark Leslie wrote: The code examples make things clearer :) I haven't managed to apply the patch to my local and see what the damage would be to GeoGIT, but that's still on my list. I expect nothing scary in that regard, but will let you know when I get that done. -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com On 24 October 2011 03:07, Jody Garnett jody.garn...@gmail.com wrote: Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: ResourceId
Okay the Proposal is updated ... and more importantly an updated patch is provided against the Jira. http://docs.codehaus.org/display/GEOTOOLS/ResouceId http://jira.codehaus.org/browse/GEOT-3921 This represents a good compromise; and has code examples of a few common queries, diagrams etc... -- Jody Garnett On Wednesday, 19 October 2011 at 11:00 AM, Jody Garnett wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: ResourceId
I am going to have a run at making a patch on Monday; if I can manage it I would like to go with FeatureId option. If not I will use your ResourceId option as a fall back position. (I am not crazy I am going to start with your ResourceId patch and then refactor; deprecating the non used RecordId and ObjectId as I go). All in all I expect this to be a low risk change. I am still keen to get feedback from Gabriel especially with respect the functions that query based on time range. I am not sure I completely understood what the wfs2 specification was on about here as they seemed very vague. -- Jody Garnett On Wednesday, 19 October 2011 at 1:58 PM, Justin Deoliveira wrote: Thanks for putting the proposal together Jody. Tough to say which option is the way to go.. I actually do like the option of just rolling all the ResourceId stuff into feature id... seems a bit simpler and cleaner, and definitely easy on client code to not have to do the instanceof check. On Tue, Oct 18, 2011 at 7:00 PM, Jody Garnett jody.garn...@gmail.com (mailto:jody.garn...@gmail.com) wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net (mailto:Geotools-devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: ResourceId
I'm slowly coming round to the FeatureId option. I don't really like the idea of carrying around the extra version information when 98% of the time it's going to be placeholders, but it will keep client efforts cleaner. I should also clarify my confusion in comparing FeatureId to ResourceId. I basically wrote a test case that created a SimpleFeature with a FeatureId and saved it into the versioned store. On reading it out, I assertedEquals that they were the same. The versioned store created a ResourceId on read, so the ResourceId.equals(FeatureId) failed, yet the FeatureId.equals(ResourceId) succeeded. The FeatureId option would (should?) fail consistently both ways. There is an existing method that I simply didn't notice soon enough in Identifier.matches(..) that is the appropriate way to do things. I have no preference between equalsFid and matches, but equals should continue to be the same complete equality that caught me, ie. the proposed equalsExact. -- Mark On 19 October 2011 17:21, Jody Garnett jody.garn...@gmail.com wrote: I am going to have a run at making a patch on Monday; if I can manage it I would like to go with FeatureId option. If not I will use your ResourceId option as a fall back position. (I am not crazy I am going to start with your ResourceId patch and then refactor; deprecating the non used RecordId and ObjectId as I go). All in all I expect this to be a low risk change. I am still keen to get feedback from Gabriel especially with respect the functions that query based on time range. I am not sure I completely understood what the wfs2 specification was on about here as they seemed very vague. -- Jody Garnett On Wednesday, 19 October 2011 at 1:58 PM, Justin Deoliveira wrote: Thanks for putting the proposal together Jody. Tough to say which option is the way to go.. I actually do like the option of just rolling all the ResourceId stuff into feature id... seems a bit simpler and cleaner, and definitely easy on client code to not have to do the instanceof check. On Tue, Oct 18, 2011 at 7:00 PM, Jody Garnett jody.garn...@gmail.com wrote: Morning: I have a development team that has been working in a fork of GeoTools while the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the wfs2 work (I still need to write some docs before it is done); and I have now written up a proposal for the ResourceId change. - http://docs.codehaus.org/display/GEOTOOLS/ResouceId Since I have a development team waiting on this I will start work on Monday; and would like to collect any input people feel is necessary before that time. The work should not take very long; there are however two options on the table. -- Jody Garnett -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Mark Leslie Geospatial Software Architect LISAsoft - Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 - LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
