[Geotools-devel] Extending the DescribeParameter annotation
Hi I am doing a bit of work on the GeoServer WPS builder interface, adding, among oter things, validation of numerical values to check if they are is between allowed min and max values. Unfortunately, there are no processes that have those values defined. The problem is that they can go on the metadata of the parameter, but cannot be defined using the annotation, so no process defines them, since almost all use annotations. Is it OK to extend to annotation with those parameters (minValue and maxValue) and adapt the AnnotationDrivenProcessFactory class to it? that would make it easier to enter those values, and I could improve the processes by defining them. That would give sense to the WPS builder checking. Thanks in advance Victor -- 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_feb ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Getting output type of rendering transform in SLD
Great. I was thinking about that, but wanted to check if there was already a way of doing it without having to change anything, or any particular reason why it should be package private I can make that change and issue a pull request, if that is fine with you and no one else is against the idea. Thanks! On Fri, Feb 15, 2013 at 11:35 AM, Andrea Aime wrote: > On Fri, Feb 15, 2013 at 11:05 AM, Victor Olaya wrote: >> >> Hi all, >> >> I am trying to find out the type of data that will result from >> applying a SLD with a rendering transformation. The >> getTransformation() method in the FeatureTypeStyle class gives me an >> Expression object, and (as far as I have seen, correct me if I am >> wrong) this is a always a ProcessFunction in the case of a rendering >> trasformation. >> >> Getting the process name and asking the corresponding >> ProcessFunctionFactory about its outputs should be enough for what I >> want to do, but the ProcessFunction class is package local and it does >> not expose the information about the underlying process. >> >> Any suggestions about how to do this? > > > I would be ok with making the ProcessFunction non package private > and eventually adding a getProcess() method to it > > 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 > > --- -- 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] Getting output type of rendering transform in SLD
Hi all, I am trying to find out the type of data that will result from applying a SLD with a rendering transformation. The getTransformation() method in the FeatureTypeStyle class gives me an Expression object, and (as far as I have seen, correct me if I am wrong) this is a always a ProcessFunction in the case of a rendering trasformation. Getting the process name and asking the corresponding ProcessFunctionFactory about its outputs should be enough for what I want to do, but the ProcessFunction class is package local and it does not expose the information about the underlying process. Any suggestions about how to do this? Thanks in advance -- 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
Re: [Geotools-devel] Proposing new module
Jody Thanks for pointing me there! Sorry for not having found that doc myself... I will read it and follow those steps Thanks again! Victor -- 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_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Proposing new module
Hi all I would like to ask which is the best way to propose a new module for geotools. i think that my gt-process-external module [1] (a module wrappping processes from external apps, currently GRASS and SAGA) is kinda ready to be further tested, and that will greatly improve its visibility (and hopefully be useful to someone...) Please, tell me how to do it so I can propose it to the GeoTools community If someone wants to read a bit more about this work, I wrote some words about it in [2] that might help Thanks in advance! Victor [1] https://github.com/volaya/gt-process-external/ [2] http://geolaya.blogspot.fr/2012/10/introducing-process-external-module-for.html -- 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_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] registering new process factory
> How are you running GeoServer victor? From resources? If so unless the > GeoServer web/app module depends directly or transitively on your module it > won't be included on the classpath. If you look at web/app/pom.xml you will > see a bunch of profiles that drag in various community and extension > modules. >> Thanks for the advice! I guess that my problem is in the GeoServer wps module. It includes dependencies to the gt-process-xxx jars, so, since mine is not there, it is not going to find it... -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] registering new process factory
Sorry, I think I was testing it the wrong way. I have found out that doing it like you told me (the way it is also in the Geotools documentation), it works, as I can call Processors.getProcessFactories() and mine is in the returned set. However, I was trying to test in in GeoServer and see if my processes where there, adding the jar along with the other gt-process-xxx jars. This is what doesn't work, but I guess the problem is not in how the jar is created (which is identical to the other ones with process factories and works when called as I mentioned), but somewhere else. I have seen that GeoServerProcessors takes processes form Processors as well, so must be a classpath problem (just figuring out, as I do not know how GeoServer works on this...) thanks again! Victor On Wed, Oct 10, 2012 at 1:58 PM, Andrea Aime wrote: > On Wed, Oct 10, 2012 at 10:09 AM, Victor Olaya wrote: >> >> Hi >> >> I am trying to publish processes from a new process factory I have >> created. I have added the org.geotools.process.ProcessFactory file in >> META-INF/services in the jar file containing my factory, and included >> its class name in that file, but it doesn't seem to work. That should >> be enough to hook to the Factory SPI, right? Am I doing something >> wrong or is there any other step needed? > > > There is no other step. Have a look in gt-process, there are several > factories registered there. > > May it be that META-INF/services does not end up in the jar? > For it to go there in the GT2 maven build it has to be placed in > src/main/resources > > 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 > > --- > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] registering new process factory
> This is stupid but sometimes you need an extra line feed after the last > entry. Just tried...but no success :-(. Maybe there is some typo in my code or something like that. I am going to check it more carefully, once again thanks! -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] registering new process factory
Hi I am trying to publish processes from a new process factory I have created. I have added the org.geotools.process.ProcessFactory file in META-INF/services in the jar file containing my factory, and included its class name in that file, but it doesn't seem to work. That should be enough to hook to the Factory SPI, right? Am I doing something wrong or is there any other step needed? Thanks in advance. Victor -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Modification to Parameter class for geoprocesses
> > Could we have more than one relationship? How do we handle it? You mean one parameter related to many other ones? That could be useful, but I guess it risks making it difficult to handle, since probably additional information was needed to fully describe that more complex relation. Can you put an example of a case where that could be used? To be honest, I just proposed this improvement for the "attribute-from-vector-layer" case, which is very common and I thought it should be addresed with a better semantic that what is done now if the GT processes that have that case, but I didn't think much about other possible cases, as they are not so likely to appear... In this case, many parameters representing attributes might depend on the same parameter representing a FeatureCollection, but the relationship is still simple (basically just what is needed to tell the UI that when a different FC is selected, it should change the available attributes to select from, just like it is implemented in almost every geoprocessing UI in the most common Desktop GISs...). More complex relationships should definitely require a more detailed analysis to be implemented correctly and robustly. -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Modification to Parameter class for geoprocesses
> RELATE
>
> How to describe the nature of the relationship? Using strings below? Perhaps
> best handled with ENUM.
>
> Parameter SNAPPING = new Parameter("snapping",
> Boolean.class, "Enable Snapping", "True to enable snapping, requires use of
> 'distance' parameter", true, 1, 1, new KVP( RELATED, "distance",
> RELATIONSHIP, "requires" ) );
> Parameter DISTANCE = new Parameter("distance", Double.class,
> "Snapping Distance", "Snapping distance used, required when 'snapping'
> parameter is True.", false, 0, 1, new KVP( RELATED, "snapping",
> RELATIONSHIP, "enable") );
Sounds great to me. I guess it's better to use an enum, instead of
string, but the syntax of those examples is perfect from my point of
view
>
> GROUP
>
> Groups seem straight forward, we already have the idea of "level" which has
> been used to group parameters into different wizard pages (or mark them for
> pragmatic use only).
>
> Parameter DEM = new Parameter("dem", File.class, "DEM File",
> "File to import", true, 1, 1, new KVP( GROUP, "elevation") );
> Parameter METADATA = new Parameter("metadata", File.class,
> "Metadata", "DEM Metadata", false, 0, 1, new KVP( GROUP, "elevation",
> RELATED, "dem") );
hmmm, I do not understand this one. The GROUP parameter I was
proposing was to define a group of parameters which are mutually
exclusive, meaning that just one of them can be used at a time to
configure the process. That is really a relation, so it could be put
as another type of relationship and use the syntax of the RELATE hint,
but in this case is a many-to-many relation, so it might be a bit
akward
I would propose something like this (adapted from the idea in the
ContourProcess process):
Parameter interval= new Parameter("interval",
Double.class, "Interval ",
"Interval between contour values (ignored if levels parameter is
supplied)", false, 1, 1, new KVP( GROUP, "contours") );
Parameter levels= new Parameter("levels",
Double[].class, "Fixed contour elevations",
"Values of levels at which to generate contours", false, 1, null, new
KVP( GROUP, "contours") );
So by adding this information, the UI might know that at least one of
the params is needed. Notice that this does not match the declaration
of the parameters, whether they are declared as mandatory or not,
since all are really optional, but what is mandatory is to have at
least one from the group they belong to. I do not see clearly how to
manage this, now that I realize it...
Anyway, the first hint seems to me more important now, as there is no
way of getting something similar otherwise. The case where several
parameters form a group of options is easily handled by dividing the
process into several ones with different arguments, which in my
opinion is not a bad thing, and even can be benefitial,since results
in a more atomized set of processes.
Cheers
Victor
--
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] Modification to Parameter class for geoprocesses
> > One advantage to hard-coding the relationship is that it gives better > type-checking and IDE support. Are there likely to be more than a few > different relationships that need to be expressed? I just can think of a band index from a raster layer (talking from what I have seen in GRASS processes and other similar ones). For sure, there might be more complex relationships, like parameters to be used only if a given option is selected in another parameter, but I would leave those aside, as they might make things more complex. I thing in those cases is better to rethink the process inputs and maybe split it in several ones, so a generic UI can understand their semantic perfectly, and a customized one can join them into one single process (in terms of what the user will see) if needed. Atomizing processes is, IMHO, a good thing > Might want to use a slightly more explicit name, like "choiceGroup" or > "optionGroup". > I agree with that. Both of them sound good enough to me. Victor -- 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] Modification to Parameter class for geoprocesses
> Just to be clear the new stuff would be part of the Parameter class directly > right? and available to all process implementors, not just ones using the > annotation based stuff? Yes, I think that if it goes in the Parameter class it will be available to all processes. In fact, I think there are some current hints which are not available using annotations (I am speaking from a quick look at the anottation classes, maybe i am wrong and it is not like that) >> > I wonder if calling this a "relationship" rather than a dependency makes > more sense. What sort of other information will the relationship/dependency > relay? Like for instance, in this could be good to create the relationship, > but also state the semantic as well, something like: relate(attribute, > features, "attributeOf") or something. Just an idea. > It could be made to have not just a relationship declared, but just the type of it, as you say. And maybe a predefined set of possible relationships types could be added. >> - A hint describing the group of optional one a parameter belongs to. >> Some processes have a set of 2 or 3 parameters, from which just one >> has to be used (see the ContourProcess for example). If these grouping >> is not explicitly described, the UI will let the user fill all >> parameters or none of them, instead of enforcing using only one of >> them. >> > Any ideas how this would be implemented? Maybe something like creating an > instance of Parameter called "Or" or something and then have it actually > wrap up the individual parameters that are in its mutual exclusive group. I was thinking about something simpler than that, just adding a value called "group" or somthing like that, with the name of the group of options. If it is null, then the parameter is not a part of anything. The UI should be capable of just grouping parameters with the same non-null group name and behaving accordingly when checking if the parameter values are valid. -- 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] Modification to Parameter class for geoprocesses
Hi all I would like to propose two simple modifications to the Parameter class, to enhance the semantics of geoprocesses. They both can be implemented as new hints, and made available through the DescribeParameter annotation - A hint describing dependence of one parameter to another. The most typical use for that would be to indicate the relation between a String parameter representign and attribute and a FeatureCollection. That would allow the user interface to make it easier for the user to select the field, as it could be taken from the list of available ones for the selected FC - A hint describing the group of optional one a parameter belongs to. Some processes have a set of 2 or 3 parameters, from which just one has to be used (see the ContourProcess for example). If these grouping is not explicitly described, the UI will let the user fill all parameters or none of them, instead of enforcing using only one of them. As you can see, it is a very simple thing, but I think that would add more robustness to the process semantics. Adapting existing processes to this change is trivial and should take little time to do. Looking forward to knowing your opinion on this. Regards Victor -- 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] Using DecoratingSimpleFeatureCollection and on-the-fly calculations
Andrea, thanks for your detailed answer > > And keep it in memory? It may work on a desktop or a batch software, > where you have all the heap for yourself, but in a server where you > have hundreds of concurrent requests it's a recipe for OOM. No, I did not meant storing in memory. I was just trying to know if that solution you propose was somehow already into Geotools so, although it looks it recalculates everything, it does not since there is some kind of smart cache somewhere. I am no expert on geotools, but (and I know I might be asking too much :-) ) , from the point of view of a process developer, the ideal thing would be to tell Geotools that you are going to create a new FeatureCollection...and let it take care of how it deals with the amout of data. Unfortunately, most of the people (like myself) creating geoprocesses do know about the foundations of spatial data analysis and their interpretation...but lack the knowledge that people like you have about data handling and storage, or server technologies :-( Since you mention JAI, I have been looking at the code of some raster algorihtms, and whether they create the data array in memory (bad recipe, as you said...), or they rely in JAI. Is there no way of creating a raster layer and populate it yourself with the result of your process (written in your geotools process without needing to add some process to JAI), and letting Geotools handle the internal complexity of storing the data? In other words (and in my ideal day-dreaming world of a geoprocess developer...),creating a raster layer for, let's say, a process calculating slope from a DEM, should be done the same way whether the final result is a 10x10 tiny raster or one with a trillion cells. Internally, Geotools would work in a completely different manner. From the outside, however, it would be the same. I should focus on the slope algorithm (which is what I know about...), not the caching/tiling/heap space limits, etc... The underlying library (Geotools in this case) will do it. Once again, I know that I am asking too much, and that the complexity of what I am asking for is enormous :-) In short, for raster processes, which is your recommendation? Should I use JAI then? Many thanks in advance! Victor -- 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] Using DecoratingSimpleFeatureCollection and on-the-fly calculations
Hi all, I am trying to write down a process and I am following the existing algorithms as examples, so as to write mine in a similar way. I have noticed the usage of the DecoratingSimpleFeatureCollection to create processes in which the result is calculated on the fly as an input layer is iterated. Is that recommended for processes that are intense in terms of computing? I might not be understanding how it works, but it seems that if the result of the process is then iterated several times (for instance, if it is used as input in several different processes), the calculations will be done each time that happens. Is that right? If so, what would be the way to do it? would it be better to just create a new FeatureCollection with resulting features already calculated? Thanks in advance Victor -- 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] SEXTANTE programming guide
Hi all, Since there have been some people from the GeoTools/GeoServer teams who have showed interest in SEXTANTE and in using it for new developments, I would like to announce that you can already find a first draft of the "SEXTANTE programming guide" in the SEXTANTE website[1] (go to the "SEXTANTE for developers" section from the main page). I am still working on it, but I think it can already help people get started and understand the fundamental ideas about SEXTANTE programming Comments are welcome. Regards Victor [1]htp://www.sextantegis.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] A Sextante GeoTools module?
Hi Andrea, > Now, the module is already using the GT2 process API, and my current > plan is to develop vector modules against it. > For raster modules Sextante is there, and it makes a lot of sense to > use it instead of reinventing the wheel. Though it contains more raster geoalgorithms, around one third of all the algorithms implemented in SEXTANTE are vector analysis ones. Check the list of available algorithms before you start implementing yours, maybe it is already implemented. If not, why not implementing them in SEXTANTE instead of directly using the GT process API?? that way, they could be used in any of the applications currently using SEXTANTE (uDig, gvSIG, SDI...) or the ones that will use it in the future, and also used as GT processes, since there is already a wrapper class. > >> Bindings for GT2.2, GT2.4 and GT2.5 are already developed and available >> in >> the SVN repository. > > You mean, in the Sextante repository? Yes, in the SEXTANTE repository. Here is the URL: https://svn.forge.osor.eu/svn/sextante You will find them in the soft/bindings folder. Check the geotools25 folder. I contains bindings for data objects and also those classes I mentioned for wrapping SEXTANTE processes so they implement the geotools process API. There are also a few examples, fully commented, that should help you understand how to use SEXTANTE. Jesse wrote most of these bindings, and they are working fine, but feel free to have a look at the code and point out any errors or improvements that you find. For sure you know more about geotools than me... Since you are going to use all this for a WPS module in GeoServer, I would like to tell you that the people at 52North have started creating a new module to incorporate SEXTNATE in their WPS server (you can already find some code in their SVN). They are not using the geotools process API, but 52N uses geotools. I do not know if it would be easy to share ideas between 52N and GeoServer, but it looks like you are both trying to do something similar, so maybe it would be worth to have a look at what they do. As I said, I would like to help you as much as possible. Like you, I am also doing this on a voluntary basis, since WPS services are not the interest of those funding SEXTANTE, but I believe it is a great opportunity to join such an important project as GeoServer, so I will try to spend sometime with this if necessary. I am writing a small manual about SEXTANTE for programmers, which will show how to add new geoalgorithms or how to use the library. I hope to have it ready soon. Anyway, if you have questions, feel free to ask me, ok? Regards, and thanks again for your interest. Victor - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] A Sextante GeoTools module?
Andrea, The uDig integration is not bridging the GeoTools process API with Sextante. It just calls the Sextante algorithms, feeding them with GeoTools data objects. The bridge is between the geotools data model and the Sextante data model(which is just a set of interfaces). This is the way Sextante can be linked to any GIS or geodata library, just wrapping data objects so they implement the corresponding Sextante interfaces and Sextante can take from them the data it needs to perform analysis. Bindings for GT2.2, GT2.4 and GT2.5 are already developed and available in the SVN repository. Also, there is a package that contains classes that implement the GeoTools process API and are based on Sextante algorithms, wrapping them, but as far as I know, this is not being used in uDig (or anywhere else...). These classes haven't been tested much, but they could be used for that Sextante-based GeoTools module that you propose (which I think is a great idea). If so, I would be pleased to contribute and work improving those classes or whatever you might consider necessary. Regards Victor - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
