It is more that I am finishing things up this weekend one way or another; I
want to move on to gt-process.
--
Jody Garnett
On Sunday, 17 April 2011 at 1:40 PM, Michael Bedward wrote:
> Are you on performance-enhancing substances Jody ? It's fantastic to
> have all of this material in sphinx.
>
So this would be an API addition so you should bang up a proposal page; on the
bright side the page can link to the existing docs and should be quick to write
up?
But yes I would be all for moving this into supported (by virtue of merging
with gt-data).
You seem to have all the needed bits:
-
Are you on performance-enhancing substances Jody ? It's fantastic to
have all of this material in sphinx.
I'll do some editing on the swing docs later today.
Michael
On 16 April 2011 23:10, Jody Garnett wrote:
> Docs are up:
> http://docs.geotools.org/latest/userguide/unsupported/swing/index.h
Thanks Jody. Well, in that case perhaps it's ready for a proposal to
merge it into gt-data on trunk so that at least the basic stuff that
is there becomes more visible. What do you think ?
I've just done a few edits to the docs. I'd forgotten what was there
and it was a pleasant surprise to find m
It could of been either of us; if it is possible it would allow people to work
with massive grids without wasting memory.
However that is a change you could do behind the scenes - as as long as people
only ever get a FeaureCollection from you they won't have to care how you
implement iterator()
Proposal up:
-
http://docs.codehaus.org/display/GEOTOOLS/Function+Description+with+FilterFactory+cleanup
Patch will be attached to Jira shortly:
- https://jira.codehaus.org/browse/GEOT-3519
Previously I caused some concern by leaving only 12 days between starting
discussion and finishing up a p
FilterFactory functionName should support argument description
--
Key: GEOT-3519
URL: http://jira.codehaus.org/browse/GEOT-3519
Project: GeoTools
Issue Type: Wish
Componen
Ah, just after posting that question I see there is a comment at the
front of the docs about FeatureIterator :)
On 17 April 2011 10:55, Michael Bedward wrote:
> Cool ! Looking at the docs now.
>
> Yes, it would be great to promote it and merging it into gt-data
> sounds like a good idea. I think
Cool ! Looking at the docs now.
Yes, it would be great to promote it and merging it into gt-data
sounds like a good idea. I think you and/or Andrea had suggested it
would be better if re-written to stream features on demand rather than
create them up front. Do you remember ?
Michael
On 16 April
Hi Andrea:
I have ported your docs over to the geotools user guide; could you kindly link
from your jgrass wiki page?
- http://docs.geotools.org/latest/userguide/unsupported/swt/index.html
Cheers,
--
Jody Garnett
--
Be
Grid doc is up for your review Michael:
- http://docs.geotools.org/latest/userguide/unsupported/grid.html
It looks good; are you ever considering moving this to supported? Would it come
in as its own module; or as extra couple of classes for gt-data (as it concerns
data generation).
--
Jody G
Docs are up:
http://docs.geotools.org/latest/userguide/unsupported/swing/index.html
Looks pretty good; I am not sure it is 100% up to date (we should probably move
the code examples into Java). I do notice there are more examples in demo then
made it into the docs; so there should be some easy
Hi Ben:
App schema doc is up:
- http://docs.geotools.org/latest/userguide/unsupported/app-schema.html
I am still missing the minimum; a code example for a GeoTools developer.
--
Jody Garnett --
Benefiting from Server Vi
Docs ported to sphinx; if you need to update them:
- http://docs.geotools.org/latest/userguide/library/render/wkt.html
One thing that was not clear to me until I read the docs was that we could not
add additional property files without placing them into the jar?
I would like to sort out a way ot
On Sat, Apr 16, 2011 at 12:00 PM, Andrea Aime
wrote:
> That's why I was suggesting having wrappers both way, you get the simplicity
> of the new API but also real world usefulness from day one, and also build on
> a system that while complex and in sore need of better API has proven to
> work on t
That's OK, curiosity is always a positive thing in my book. I'm going to
include the proposal text in my thesis anyway. So the feedback is much
appreciated. Be warned though, I have a lot to say about this subject, and
it is going to be somewhat technical :-)
2011/4/16 Michael Bedward
> Hi Kenne
On 16 April 2011 19:44, Jody Garnett wrote:
> 1. create mess
> svn
> mv http://svn.osgeo.org/geotools/trunk/docs/user http://svn.osgeo.org/geotools/branches/docs/user
> 2. clean up mess
> --
Ah... techno-talk :)
Michael
---
Just going to chime in with a second reply. I am in favour of experimenting in
an unsupported module.
However I would still like to see what we have there documented; out of all the
docs the stuff for gt-coverage had the highest noise to signal ratio.
Indeed I would expect that these docs are l
On Sat, Apr 16, 2011 at 11:24 AM, Michael Bedward
wrote:
> That's fine.
>
> The problem with "interesting work" in the coverage module is that
> little of it gets out to the wider user community.
Drawing from past experience also the referencing subsystem was impenetrable
to users until Jody wrot
1. create mess
svn mv http://svn.osgeo.org/geotools/trunk/docs/user
http://svn.osgeo.org/geotools/branches/docs/user
2. clean up mess
--
Jody Garnett
On Saturday, 16 April 2011 at 6:32 PM, Michael Bedward wrote:
> On 16 April 2011 18:10, Jody Garnett wrote:
> > - If anyone is interested in d
That's fine.
The problem with "interesting work" in the coverage module is that
little of it gets out to the wider user community.
On 16 April 2011 19:21, Andrea Aime wrote:
> On Sat, Apr 16, 2011 at 10:08 AM, Michael Bedward
> wrote:
>> On 16 April 2011 17:52, Andrea Aime wrote:
>>> I can't
On Sat, Apr 16, 2011 at 10:08 AM, Michael Bedward
wrote:
> On 16 April 2011 17:52, Andrea Aime wrote:
>> I can't imagine a system without it. You sure all of the coverages that
>> people are interested into will be created directly in memory?
>> Nobody reading an arcgrid or a geotiff file? :-)
>>
On 16 April 2011 18:10, Jody Garnett wrote:
> - If anyone is interested in doing an svn copy we may be able to get the
> docs going for 2.7 as well
Hi Jody: do you just mean copying docs/user from trunk to 2.7.x ?
Michael
-
PS. forgive the sloppy "GridCoverage2D split into two" metaphor. I
know in reality its already split into many parts (GridGeometry etc)
but I just wanted a back of the envelope phrase for the purposes of
discussion.
On 16 April 2011 18:08, Michael Bedward wrote:
> On 16 April 2011 17:52, Andrea
Got the content ported over to trunk ... 11 words according to this word
processor thing - hey that does not include the tutorials so it is probably a
bit more.
Next up:
- I would like to make a 8-M0 milestone release to capture this thing
- make a blog post; and shut off our user guide wiki
On 16 April 2011 17:52, Andrea Aime wrote:
> I can't imagine a system without it. You sure all of the coverages that
> people are interested into will be created directly in memory?
> Nobody reading an arcgrid or a geotiff file? :-)
>
Mmm... I think I didn't express myself very well before, or pe
On Sat, Apr 16, 2011 at 9:32 AM, Michael Bedward
wrote:
> Yes - I've thought about having a simple -> coverage bridge so that,
> for example, a user might take advantage of easier creation methods
> with the simple module and then move into coverage-land for
> processing. I haven't thought about a
Hi Andrea,
> Agree with most of what you say below, using current grid coverages is
> painful,
> so having a simpler way to work with them is going to be an improvement.
> Back at the times when I started working with those I was frustrated
> and complaining too.
>
> What worries me is that all th
On Sat, Apr 16, 2011 at 5:49 AM, Michael Bedward
wrote:
> Hi all,
>
> For some time I've been thinking about how to ease the pain that some
> users experience when coming to grips with GridCoverage2D and its
> friends. My impression, based on questions on the user list over the
> last couple of ye
29 matches
Mail list logo
