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: 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
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
