[Geotools-devel] [jira] Created: (GEOT-2033) JDBCFeatureReader featuer building code limits scalability
JDBCFeatureReader featuer building code limits scalability -- Key: GEOT-2033 URL: http://jira.codehaus.org/browse/GEOT-2033 Project: GeoTools Issue Type: Improvement Reporter: Andrea Aime Assignee: Andrea Aime Fix For: 2.5.0, 2.6-M0 As it uses SimpleFeatureBuilder static methods, that in turn lookup for a factory each time (CommonFactoryFinder kiss of death). A single builder should be created and reused over and over instead -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[Geotools-devel] [jira] Created: (GEOT-2034) Shapefile renderer reads all DBF attributes when only a subset is needed
Shapefile renderer reads all DBF attributes when only a subset is needed Key: GEOT-2034 URL: http://jira.codehaus.org/browse/GEOT-2034 Project: GeoTools Issue Type: Improvement Components: ext shapefilerender Reporter: Andrea Aime Assignee: Andrea Aime Fix For: 2.5.0, 2.6-M0 Shapefile renderer gets the whole record of attribues from DBaseReader even if only a few records will be needed. DBaseReader API should be expanded so that it's possible to read only a subset of them, avoiding the parsing of the ones that aren't needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[Geotools-devel] [jira] Created: (GEOT-2035) Shapefile renderer needlessly clones style elements
Shapefile renderer needlessly clones style elements --- Key: GEOT-2035 URL: http://jira.codehaus.org/browse/GEOT-2035 Project: GeoTools Issue Type: Improvement Reporter: Andrea Aime Assignee: Andrea Aime Fix For: 2.5.0, 2.6-M0 Shapefile renderer clones rules in order to avoid modyfing them when geometyr filters are reprojected to the screen space (since the geometries are read from the storage already reproejcted in screen space). Yet, a geometry filter in an SLD is quite uncommon, before duplicating the filter (and thus loosing the caches stored in the literal expressions) it's better to check if there is an actual need for it. A simple visitor can assess if cloning the rules is really necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[Geotools-devel] First take on GridCoverage documentation
Hey all, We had hoped to generate this documentation earlier in the summer but better late than ... The page http://docs.codehaus.org/display/GEOTDOC/08+Grid+Coverage and the first few subsections hold our first draft of an explanation of how the coverage module works at a programmatic level. Probably there is a lot still to explain---we just realized that we should have a "Why is this so complicated?" section---and we hope to have more examples, possibly demo code of some sort. Anyhow, if anyone is playing around with some interesting GridCoverage format and feels like trying to decipher our explanations, feedback, comments, or edits are welcome. cheers, --adrian - 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] First take on GridCoverage documentation
This is great - thanks Adrian ! I just had a very quick look and I've already learned something (that I don't have to go down to JAI level to do a crop). I'll read it properly later today and see if there's anything useful that I can contribute to it. I've been working on some raster algorithms recently (raster to vector, edge cell tracing, region buffering...) some of which may be useful demos - though probably after a lot of refactoring of my code :) cheers Michael 2008/9/15 Adrian Custer <[EMAIL PROTECTED]>: > Hey all, > > We had hoped to generate this documentation earlier in the summer but > better late than ... > > The page http://docs.codehaus.org/display/GEOTDOC/08+Grid+Coverage > and the first few subsections hold our first draft of an explanation of > how the coverage module works at a programmatic level. Probably there is > a lot still to explain---we just realized that we should have a "Why is > this so complicated?" section---and we hope to have more examples, > possibly demo code of some sort. > > Anyhow, if anyone is playing around with some interesting GridCoverage > format and feels like trying to decipher our explanations, feedback, > comments, or edits are welcome. > > cheers, > --adrian > > > - > 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 > - 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] going back to -r30106 FAIL? Is our history gone ...
Adrian Custer wrote: > That said, > svn co -r 30106 http://svn.geotools.org/trunk > works perfectly for me. Of course it does not build because we depend on > geoapi snapshots and not releases which seems like an increasingly bad > idea from my point of view. But you know that already. > Thanks Adrian; I was able to check out a milestone build and roll it back to -r30107 as mentioned in a previous email. I was also able to account for the compile error and use a milestone geoapi build. I understand that for a branch I should of changed the dependency to a specific geoapi snapshot. All the best, Jody - 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] First take on GridCoverage documentation
Reading the notes about operations from the perspective of a relative
beginner, it's not clear to me what the reasons / pros / cons are for
invoking an operation via Operations.DEFAULT (as with the resample
example on the Use a GridCoverage page) versus using the
DefaultProcessor.doOperation method.
Are they basically equivalent ? Or are a subset of operations best
invoked using only one or other method ? If someone could enlighten
me I'd be happy to edit the docs in return.
Michael
2008/9/15 Jody Garnett <[EMAIL PROTECTED]>:
> Thanks Adrian; I added a {children} macro to that page so people can see
> the contents.
> Jody
>
> Adrian Custer wrote:
>> Hey all,
>>
>> We had hoped to generate this documentation earlier in the summer but
>> better late than ...
>>
>> The page http://docs.codehaus.org/display/GEOTDOC/08+Grid+Coverage
>> and the first few subsections hold our first draft of an explanation of
>> how the coverage module works at a programmatic level. Probably there is
>> a lot still to explain---we just realized that we should have a "Why is
>> this so complicated?" section---and we hope to have more examples,
>> possibly demo code of some sort.
>>
>> Anyhow, if anyone is playing around with some interesting GridCoverage
>> format and feels like trying to decipher our explanations, feedback,
>> comments, or edits are welcome.
>>
>> cheers,
>> --adrian
>>
>>
>> -
>> 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
>>
>
>
> -
> 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
>
-
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] First take on GridCoverage documentation
Thanks Adrian; I added a {children} macro to that page so people can see
the contents.
Jody
Adrian Custer wrote:
> Hey all,
>
> We had hoped to generate this documentation earlier in the summer but
> better late than ...
>
> The page http://docs.codehaus.org/display/GEOTDOC/08+Grid+Coverage
> and the first few subsections hold our first draft of an explanation of
> how the coverage module works at a programmatic level. Probably there is
> a lot still to explain---we just realized that we should have a "Why is
> this so complicated?" section---and we hope to have more examples,
> possibly demo code of some sort.
>
> Anyhow, if anyone is playing around with some interesting GridCoverage
> format and feels like trying to decipher our explanations, feedback,
> comments, or edits are welcome.
>
> cheers,
> --adrian
>
>
> -
> 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
>
-
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
