View • Attachments (0) • Info
JGrassTalk
### Log session started at Wed Jan 31 17:49:47 2007 ###
(17:49:47) moovida (n=moovida@194.242.208.236) has joined #udig
(17:49:51) sterling.freenode.net (@) has set channel mode +n
(17:49:51) Channel was created at Wed Jan 24 07:10:43 2007
(17:49:55) Channel synchronized in 7.0 seconds
(17:49:57) Jesse_Eichar77 (n=Jesse_Ei@mail.refractions.net) has joined #udig
(17:53:01) mlucas (n=mlucas@rrcs-67-78-243-153.se.biz.rr.com) has joined #udig
(18:15:56) mlucas (n=mlucas@rrcs-67-78-243-153.se.biz.rr.com) has quit IRC:
(18:16:31) mlucas (n=mlucas@rrcs-67-78-243-153.se.biz.rr.com) has joined #udig
(18:24:12) horner (n=chorner@mail.refractions.net) has joined #udig
(18:31:05) ahamm (n=Miranda@p54A5CE54.dip.t-dialin.net) has joined #udig
(18:31:47) moovida welcomes andreas, if it is him 
and thanks for assisting
(18:32:25) ahamm (n=Miranda@p54A5CE54.dip.t-dialin.net) has quit IRC: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org"
(18:32:56) holmes (n=chatzill@cpe-66-108-80-238.nyc.res.rr.com) has joined #udig
(18:33:35) <rgould> moovida, i don't think he's around. He goes by "aaime"
(18:33:52) ahamm (n=Miranda@p54A5CE54.dip.t-dialin.net) has joined #udig
(18:33:54) <chorner> there are many andreas now
(18:34:06) <moovida> yes
(18:34:17) <moovida> I meant ahamm...
(18:35:08) moovida is happy that some old and future people of the JGrass team will assist
(18:35:34) <rgould> oh, i'll be quiet then
(18:36:07) <moovida> but you are right, I hope Andrea and Simone will be here soon
(18:43:25) aaime (n=IceChat7@87.19.45.55) has joined #udig
(18:48:03) silli (n=silli@194.242.208.236) has joined #udig
(18:51:00) ericajg (n=user@84.18.138.236) has joined #udig
(18:52:39) <ahamm> Hallo everyone. I was invited by 'moovida' to join the session. I think, in the main time I will be acting as an spectator because of insufficient knowledge about both projects. I'll be back at seven o'clock - have to smoke a cigarette.
(18:53:22) <moovida> we'll wait for you
(18:56:07) <Jesse_Eichar77> hey folks
(18:56:16) <silli> Hallo everyone. I was invited by Moovida to join the session. I am in the JGrass team but only as modelling developer, so I will be a spectator during this chat.
(18:56:42) <moovida> hi everyone
(18:56:57) <ericajg> Hello
(18:57:05) mlucas_ (n=mlucas@rrcs-67-78-243-153.se.biz.rr.com) has joined #udig
(18:57:57) <moovida> Who's gonna moderate that all?
(18:58:05) <moovida> Jesse?
(18:58:16) <Jesse_Eichar77> Ok
(18:58:19) <Jesse_Eichar77> I suppose I can.
(18:58:21) <moovida> great
(18:58:21) mlucas (n=mlucas@rrcs-67-78-243-153.se.biz.rr.com) has quit IRC: Connection reset by peer
(18:58:25) <Jesse_Eichar77> there's a first for everything
(18:58:35) <moovida> hold a second,
(18:58:49) <moovida> I go and take Simone from the geotools chat 
(18:58:55) <moovida> I try at least
(18:59:52) simboss__ (n=chatzill@host20-221.pool80117.interbusiness.it) has joined #udig
(19:00:17) <moovida> fine
(19:00:20) <Jesse_Eichar77> ok lets start by setting up a agenda
(19:00:23) <simboss__> hi everybody
(19:00:31) <moovida> hi Simone
(19:00:49) <Jesse_Eichar77> What questions do you want answered?
(19:00:54) <simboss__> sorry I got distracted by MrSid and GeoServer
(19:00:56) <simboss__>
(19:01:01) <moovida> alright Jesse, I made a list of points I wanted at least touch
(19:01:15) <moovida> I post them right now, so we can decide how to go
(19:01:46) <moovida> licensing
(19:01:46) <moovida> raster
(19:01:46) <moovida> - analysis
(19:01:46) <moovida> - active working region
(19:01:46) <moovida> - resolution
(19:01:46) <moovida> - rendering
(19:01:46) <moovida> - applications = oprations
(19:01:46) <moovida> - openMi compliancy and chaining and visual console
(19:01:46) <moovida> console engine - R-project
(19:01:46) <moovida> datamodel
(19:01:46) <moovida> GRASS compatibility raster/vector/volume
(19:01:47) Jesse_Eichar77_ (n=Jesse_Ei@mail.refractions.net) has joined #udig
(19:01:52) Jesse_Eichar77_ (n=Jesse_Ei@mail.refractions.net) has quit IRC: Remote closed the connection
(19:02:14) <moovida> Jesse's gone?
(19:02:22) <moovida> was it too much? 
(19:02:23) Jesse_Eichar77_ (n=Jesse_Ei@mail.refractions.net) has joined #udig
(19:02:34) <Jesse_Eichar77_> ping
(19:02:36) <Jesse_Eichar77_> hows my connection?
(19:02:38) <Jesse_Eichar77_> am I here?
(19:02:42) <moovida> yes you are
(19:02:44) <moovida>
(19:02:50) <Jesse_Eichar77_> ok sorry about that
(19:02:57) <moovida> you have the list?
(19:03:08) <Jesse_Eichar77_> no I had connection problems
(19:03:09) <moovida> should I pst it again?
(19:03:12) <Jesse_Eichar77_> please
(19:03:14) <moovida> ok, then again
(19:03:24) <moovida> licensing
(19:03:24) <moovida> raster
(19:03:24) <moovida> - analysis
(19:03:24) <moovida> - active working region
(19:03:24) <moovida> - resolution
(19:03:24) <moovida> - rendering
(19:03:24) <moovida> - applications = oprations
(19:03:24) <moovida> - openMi compliancy and chaining and visual console
(19:03:24) <moovida> console engine - R-project
(19:03:24) <moovida> datamodel
(19:03:24) <moovida> GRASS compatibility raster/vector/volume
(19:03:49) <moovida> licensing was my last, but I guess it will influence, so a short chat about it
(19:04:11) <Jesse_Eichar77_> ok lots of topics
(19:04:29) <Jesse_Eichar77_> start with licensing?
(19:04:31) <moovida> I know, just give me the hints, I will bother you all in the lists then
(19:04:38) <moovida> yes
(19:05:00) <Jesse_Eichar77_> as you know uDig is LGPL and I understand that JGrass is at least in part GPL
(19:05:01) <Jesse_Eichar77_> correct?
(19:05:12) <moovida> absolutely yes
(19:05:33) <Jesse_Eichar77_> ok so we discussed this a bit yesterday.
(19:05:48) <Jesse_Eichar77_> this means that uDig cannot have grass as part of it because of the licensing
(19:06:18) <Jesse_Eichar77_> However JGrass can be available as plugins which can easily available via the built-in update site
(19:06:42) <Jesse_Eichar77_> it simplify things for user we can add the update site to be one of the default update sites that uDig searches.
(19:06:52) <Jesse_Eichar77_> questions?
(19:06:59) <moovida> no, that is a good alternative
(19:07:14) <moovida> I hoped in some deeper marriage... but...
(19:07:32) <moovida> just to understand:
(19:07:44) <moovida> we have to create a plugin with its own perspective and views?
(19:07:56) <moovida> and also keep our sources and repositories?
(19:08:16) <Jesse_Eichar77_> correct. It can heavily leverage what we have in uDig.
(19:08:18) <Jesse_Eichar77_> of course.
(19:08:48) <moovida> of course, we will talk if we need something
(19:09:01) <moovida> and some parts, I hope will be contributed
(19:09:10) <Jesse_Eichar77_> we can have closer relationship if both teams have both sets of plugins in the development work space
(19:09:35) <Jesse_Eichar77_> for example uDig developers will include all the JGrass plugins in their work space.
(19:09:44) <Jesse_Eichar77_> and same for JGrass developers.
(19:09:53) <moovida> alright, that makes sense to me
(19:10:00) <Jesse_Eichar77_> This "should" make the awareness of the other project more explicit.
(19:10:24) <moovida> you guys did it already in the ossim port?
(19:10:29) <Jesse_Eichar77_> My concern with that is if we have different repositories.
(19:10:31) <moovida> no dependency issues?
(19:10:39) <Jesse_Eichar77_> that's right.
(19:10:59) <moovida> we can't use the refraction repository?
(19:11:02) <Jesse_Eichar77_> it was fine.
(19:11:15) <Jesse_Eichar77_> I think so I just didn't know if you wanted to move to the refractions repository.
(19:11:26) <Jesse_Eichar77_> I personally would like to see that for that exact reason.
(19:11:44) <moovida> I do not see big issues, should I?
(19:12:14) <Jesse_Eichar77_> Do you have a repository already? do you want to keep your history? is the current repository SVN CVS?
(19:12:21) <moovida> i would prefer to have things ordered in one place
(19:12:23) <Jesse_Eichar77_> how do you want to merge repositories...
(19:12:34) <moovida> we use SVN and have a repository
(19:12:47) <Jesse_Eichar77_> ok. So it should be pretty easy to merge the repositories.
(19:12:52) <moovida> however the migration will be from scratch
(19:12:54) <moovida>
(19:13:03) <Jesse_Eichar77_> ahhhh. ok
(19:13:10) <moovida> we will have to clean a lot of code and change things
(19:13:22) <moovida> so... no merging problem
(19:13:50) <Jesse_Eichar77_> ok good
(19:13:56) <Jesse_Eichar77_> any more issues with licensing?
(19:14:03) <moovida> not for me
(19:14:18) <Jesse_Eichar77_> 3
(19:14:20) <Jesse_Eichar77_> 2
(19:14:23) <Jesse_Eichar77_> 1
(19:14:27) <Jesse_Eichar77_> ok next topic
(19:14:33) <Jesse_Eichar77_> raster
(19:14:43) <moovida> there is a lot to say
(19:14:55) <moovida> obviously
(19:15:04) <moovida> let me start with this
(19:15:20) <moovida> we use raster maps for doing analyses on them
(19:15:35) <moovida> they are rendered with some colortable
(19:15:43) <moovida> but mainly they are read as numbers
(19:15:58) <moovida> there are two mandatory concepts in this
(19:16:06) <moovida> that I feel are missing in udig
(19:16:16) <moovida> 1) the active working region
(19:16:30) <moovida> i.e. the region on which the map will be processed
(19:16:35) <moovida> example:
(19:16:47) <moovida> I have a map of 4 gigs
(19:17:03) <moovida> an elevation model of whole europe
(19:17:17) <moovida> and I want to process only the german part
(19:17:43) <moovida> I have to be able to see the whole map but define with a windows the part I'm going to process
(19:18:18) <moovida> did I explain myself somehow
(19:18:20) <moovida> ?
(19:18:31) <Jesse_Eichar77_> currently for each layer we have the concept of a "Filter" which indicates what is to be processed. It is more general than the active working region
(19:18:53) <moovida> fine, then let me just add 2 and we talk
(19:18:56) Jesse_Eichar77 (n=Jesse_Ei@mail.refractions.net) has quit IRC: Read error: 113 (No route to host)
(19:19:06) <Jesse_Eichar77_> ok
(19:19:22) <moovida> 2) the concept of processing resolution
(19:19:57) <moovida> example: my 4 gigs map of europe is a 1000x1000 meter cells resolution
(19:20:10) <moovida> I want to do processing on the whole map
(19:20:21) <moovida> 4 gigs would be too much
(19:20:46) <moovida> so I read the map at a lower resolution, example 10000x10000 meters
(19:21:06) <Jesse_Eichar77_> makes sense
(19:21:07) <moovida> this information should be part of the active window
(19:21:29) <Jesse_Eichar77_> ready to discuss?
(19:21:33) <moovida> yes
(19:21:35) <Jesse_Eichar77_> ok
(19:21:56) <Jesse_Eichar77_> first both maps and layers have "Map Blackboards" for plugin collaboration.
(19:22:09) <Jesse_Eichar77_> So rather than try to think of everything every application might want
(19:22:25) <Jesse_Eichar77_> we added Blackboards to each layer and each map
(19:22:48) <Jesse_Eichar77_> plugins can put information on the blackboards that they need for collaboration.
(19:22:52) <Jesse_Eichar77_> that is one possibility
(19:23:01) <moovida> you mean the once that style and renderers use?
(19:23:03) <Jesse_Eichar77_> I have more ideas but first comments on that.
(19:23:16) <moovida> alright, there is one problem
(19:23:22) <moovida> with that I think
(19:23:22) <Jesse_Eichar77_> no that is a different blackboard with a very specific purpose.
(19:23:33) <moovida> ok
(19:24:03) <Jesse_Eichar77_> ok what's the problems you see.
(19:24:13) <moovida> region and resolution is something that should be part of the workspace
(19:24:28) <moovida> because throught all the processed maps
(19:24:35) <moovida> we need consistency,
(19:24:43) <moovida> example
(19:25:02) <moovida> I create a map in which I fill the sinks
(19:25:10) <moovida> to be used for flowdirections
(19:25:18) <moovida> then I create the flowdirections map
(19:25:29) <moovida> and the contributing area map
(19:25:47) <moovida> If the resolution of one of those is different for any reason
(19:25:55) <moovida> the processing gets inconsistent
(19:26:17) <moovida> so the user should be forced to define a region for the whole workspace
(19:27:00) <moovida> what do you think?
(19:27:14) <Jesse_Eichar77_> I'm not yet convinced but I have heard similar arguments before.
(19:27:28) <moovida> convince me, I'm here for that reason
(19:27:42) <moovida>
(19:28:06) <Jesse_Eichar77_> In many typical GIS applications there is typically a single map that is open.
(19:28:24) <Jesse_Eichar77_> so it makes sense to put this type of information on the workbench
(19:28:35) <moovida> one map? how do you mean?
(19:28:39) <Jesse_Eichar77_> however in uDig we have a slightly different paradigm
(19:29:02) <moovida> I'm listening
(19:29:36) <Jesse_Eichar77_> we can have many maps open. but only one is the "control" and can be considered the workbench in traditional sense.
(19:29:47) <Jesse_Eichar77_> Lets take arc view as the standard.
(19:30:02) <Jesse_Eichar77_> You can have views and tables open
(19:30:16) <Jesse_Eichar77_> but there is typically one map that is under analysis
(19:30:25) <Jesse_Eichar77_> (that is my understanding feel free to correct me)
(19:30:37) <moovida> we see it different
(19:30:40) <Jesse_Eichar77_> ok
(19:30:44) <moovida> no need to have a visible map
(19:31:07) <moovida> you can do 20 maps step by step and visualize only the last
(19:31:13) <moovida> the workspace has the info
(19:31:25) <moovida> of processing region, resolution, projection
(19:31:59) <moovida> your turn
(19:32:01) <Jesse_Eichar77_> What do you define as a map
(19:32:12) <moovida> that is the right question
(19:32:15) <Jesse_Eichar77_> sounds like what I consider a layer
(19:32:23) <moovida> I'm used to say map
(19:32:29) <moovida> exactly
(19:32:39) <moovida> that is it, sorry for confusing
(19:32:52) <Jesse_Eichar77_> Its all good
(19:32:54) <moovida> we do not have what you call map
(19:33:12) <moovida> just different layers, grouped by type
(19:33:50) <Jesse_Eichar77_> right
(19:34:04) <Jesse_Eichar77_> so to me it sounds like a map in uDig is a workspace in your terms
(19:34:05) jgarnett (n=chatzill@mail.refractions.net) has joined #udig
(19:34:10) <Jesse_Eichar77_> and a map==layer
(19:34:30) <moovida> yes, alright
(19:34:42) <jgarnett> morning; sorry I am late
(19:34:46) <moovida> ok, ok, let me browse back again
(19:35:10) <Jesse_Eichar77_> ok. So given that it could make sense to put the information (area and resolution) on the map blackboard.
(19:35:14) <moovida> I got it
(19:35:23) <moovida> yes, sorry for racting late
(19:35:33) <moovida> what you call map
(19:35:40) <moovida> is what we call session
(19:35:47) <Jesse_Eichar77_> not at all. I had this conversation last week
(19:35:50) <moovida> and can have different projections, too
(19:36:06) <moovida> great then
(19:36:25) <moovida> so adding something visible that defines the region
(19:36:25) <Jesse_Eichar77_> There are other ideas as well. That is one.
(19:36:40) <moovida> and keeping things in the map blackboard is no problem
(19:36:49) <moovida> alright, go
(19:37:01) <Jesse_Eichar77_> It is simple to do.
(19:38:12) <Jesse_Eichar77_> Another idea is slightly more forward looking
(19:38:16) <Jesse_Eichar77_> Vitali
(19:38:19) <moovida> oh, oh
(19:38:28) <Jesse_Eichar77_>
(19:38:35) <moovida> Vitali?
(19:38:38) <moovida> :S
(19:38:43) <moovida> what is that?
(19:38:46) <Jesse_Eichar77_> a finnish developer has been working on the selection service
(19:38:54) <jgarnett> I am catching up; are we talking only visualization here?
(19:39:04) <jgarnett> If so can we limit the region to what is on screen;
(19:39:35) <moovida> no not visualization
(19:39:43) aaime (n=IceChat7@87.19.45.55) has quit IRC: "A fine is a tax for doing wrong. A tax is a fine for doing well"
(19:39:44) <moovida> it is about data processing
(19:39:53) <Jesse_Eichar77_> I'm going to send Jody the log
(19:40:02) <Jesse_Eichar77_> so he can catch up
(19:40:04) <jgarnett> okay got it then; trying to isolate a region for processing.
(19:40:06) <moovida> alright
(19:40:26) <jgarnett> sweet - we have a couple examples of applications doing that (DivaGIS defined a gridselection and then did processing with respect to that)
(19:41:13) <moovida> alright, who's next
(19:41:13) <Jesse_Eichar77_> ok done
(19:41:20) <moovida> Jody, Vitali?
(19:41:30) <Jesse_Eichar77_> I'm going to explain Vitali's work
(19:41:37) <Jesse_Eichar77_> as I understand it
(19:42:00) <Jesse_Eichar77_> Currently selection is handled on a per layer basis.
(19:42:17) <Jesse_Eichar77_> and is just a filter
(19:42:39) <Jesse_Eichar77_> which is a very generic way of saying what is "selected"
(19:42:50) <Jesse_Eichar77_> Vitali is added a SelectionService to each map
(19:43:16) <Jesse_Eichar77_> Which is based on Eclipse's SelectionService but knows about GIS specific information
(19:43:40) <Jesse_Eichar77_> Also it is extensible for a give application or tool.
(19:44:08) <moovida> is this already working?
(19:44:18) <Jesse_Eichar77_> yes but it is on a branch.
(19:44:27) <Jesse_Eichar77_> I would have to talk to him about when he can merge it
(19:44:42) <Jesse_Eichar77_> he has mentioned that he will have time in february.
(19:44:57) <moovida> what do you think?
(19:44:58) <Jesse_Eichar77_> so this construct could be used for your "area and resolution"
(19:45:07) <moovida> the blackboard looks nice to me
(19:45:10) <Jesse_Eichar77_> I think you should use the blackboard so you can start now.
(19:45:21) <Jesse_Eichar77_> and when it gets merged consider migrating to that.
(19:45:23) <jgarnett> blackboard has a history of working; and you can look at examples.
(19:45:42) <moovida> great! That is the best start
(19:46:06) <moovida> alright, the other side of the moon then
(19:46:06) <Jesse_Eichar77_> ok
(19:46:18) <moovida> GRASS binrary format
(19:46:21) <jgarnett> I am sure jesse went over this workflow: 1) define a tool that places your "region" on the black board 2) define opperations that use the "region" to do some processing
(19:46:48) <Jesse_Eichar77_> As I understand that is the existing workflow?
(19:46:54) <moovida> great, same as we hav e
(19:46:57) <moovida> yes
(19:47:20) <Jesse_Eichar77_> ok go on
(19:47:30) <moovida> the format
(19:47:52) <moovida> they keep the data matrix compressed ro by row
(19:48:07) <moovida> with a header that keeps row addresses
(19:48:17) <simboss__> no tiling?
(19:48:22) <moovida> in order to read only the active region
(19:48:31) <moovida> no way man, no tiling
(19:48:39) <moovida> which is also the problem in rendering
(19:48:44) <simboss__> so you do things in stripes
(19:48:50) <simboss__> which compression?
(19:48:52) jgarnett (n=chatzill@mail.refractions.net) has changed topic to "1) licensing 2) raster (analysis, active working region, resolution, rendering, operations, openMi & chaining) 3) console engine 4) datamodel 5) grass compatibility"
(19:48:56) <moovida> deflate
(19:49:08) <simboss__> k
(19:49:26) <moovida> so when an operation choses a raster map for processing
(19:49:28) <simboss__> which info do you have in the header?
(19:49:33) <simboss__> (sorry )
(19:49:42) <moovida> (I come back to that)
(19:50:00) <moovida> the map is read with the active region bounds and resolution
(19:50:21) <moovida> can this be done with the actual coverage code?
(19:50:44) <simboss__> I think so
(19:50:54) <simboss__> can I ask a couple of questions?
(19:50:58) <moovida> sure
(19:51:19) <simboss__> 1which info can I find in the header?
(19:51:38) <moovida> there are more files that form the concept of header
(19:52:01) <moovida> the binary file has a byte defining the size of the row address
(19:52:08) <moovida> then the addresses
(19:52:14) <moovida> and then the zipped rows
(19:52:23) <moovida> then there are files that keep:
(19:52:43) <moovida> - the region bounds and resolution of the map file
(19:52:51) <moovida> - the cond of compression
(19:52:56) <moovida> - the data type
(19:53:00) <simboss__> (cond?)
(19:53:08) <moovida> (sorry kind)
(19:53:17) <simboss__> k
(19:53:40) <moovida> and there is a bitmap that defines the novalues
(19:53:57) <moovida> 0 = novalue, 1 = vaulue
(19:54:06) <moovida> both are read and mapped on another
(19:54:13) <moovida> result = the read map
(19:54:14) <simboss__> what do you mean exactly by a bitmap
(19:54:21) <moovida> a file of bits
(19:54:40) <moovida> of number of bits equal to rwosxcols of the file
(19:54:56) moovida is losing the ability to write
(19:54:57) <simboss__> k
(19:55:10) <simboss__> which data types you need
(19:55:10) mlucas_ (n=mlucas@rrcs-67-78-243-153.se.biz.rr.com) has quit IRC:
(19:55:31) <moovida> there should be support for integers, float and double
(19:55:35) mlucas (n=mlucas@rrcs-67-78-243-153.se.biz.rr.com) has joined #udig
(19:55:54) <moovida> but we only write doubles to disk
(19:56:02) <simboss__> k
(19:56:46) <simboss__> what do you mean by we only write doubles?
(19:57:13) <moovida> in fact float and doubles, I never wrote the part that writes integers
(19:57:25) <moovida> I had enough of writing bites with java
(19:57:34) <moovida> bytes
(19:57:49) <moovida> just that
(19:57:55) <simboss__> k
(19:57:57) <simboss__> FYI
(19:58:13) <simboss__> we already support the ascii grass raster format
(19:58:19) <simboss__> this would be a nice addition
(19:58:21) <simboss__>
(19:58:25) <moovida> yes I know
(19:58:39) <moovida> but you always saw those as images, right?
(19:58:45) <moovida> something to render
(19:58:48) <simboss__> no actually
(19:58:55) <moovida> that is good
(19:59:02) <simboss__> I have used them for doing ocean colors products
(19:59:09) <simboss__> from seawifs
(19:59:14) <simboss__> modis and meris
(19:59:16) <simboss__>
(19:59:33) <moovida> great
(19:59:51) <moovida> so I will have to talk with you about how i will get my data
(19:59:59) <simboss__> k
(20:00:06) <moovida> I assume we will have to write a Datastore
(20:00:13) <moovida> or how it is called
(20:00:27) moovida doesn't know well all the names yet
(20:00:31) <simboss__> hopefully soon a CoverageStore
(20:00:39) <moovida> alright
(20:01:13) <moovida> for rendering we can use the same that the ascii grass raster uses
(20:01:17) <moovida> right?
(20:01:25) <simboss__> what do you mean?
(20:01:27) <moovida> it supports colormaps?
(20:01:36) <Jesse_Eichar77_> Do we really need this Simboss?
(20:01:42) <moovida> we would not need to write a renderer
(20:01:48) <simboss__> this==?
(20:01:58) <Jesse_Eichar77_> can they just offer the GridCoverageRendere with a SLD and a GridCoverage?
(20:02:04) <simboss__> yeah
(20:02:09) <simboss__> I was about to say that
(20:02:29) <simboss__> I have money for spendin 1 month on improving the GridCoverageRenderer
(20:02:32) <simboss__> for rendering
(20:02:43) <Jesse_Eichar77_> ok so moovida if you have read/write software you don't necessaryily need to create a geotools reader/writer
(20:02:43) <simboss__> data
(20:02:54) <simboss__> with no implicit color interpretation
(20:02:57) <simboss__> which is the case now
(20:03:07) <Jesse_Eichar77_> you just need to create an adapter from your model to GridCoverage
(20:03:13) <Jesse_Eichar77_> and pass that to the GridCoverageRenderer.
(20:03:17) <Jesse_Eichar77_> right?
(20:03:24) <moovida> right Simone?
(20:03:31) moovida lost himself a bit
(20:03:41) <simboss__> in principle it woul work
(20:03:46) <simboss__> but it will be inefficient
(20:04:03) <simboss__> it is why I rewrote most plugins
(20:04:05) <simboss__>
(20:04:14) <Jesse_Eichar77_> are the readers used by the gridcoverage renderer?
(20:04:18) <simboss__> yeah
(20:04:23) <Jesse_Eichar77_> how?
(20:04:34) <Jesse_Eichar77_> I thought you just pass in the gridcoverage
(20:04:45) <simboss__> the StreamingRenderer ask the reader
(20:04:49) <simboss__> to create a coverage
(20:05:05) <simboss__> giving a envelope and viewport
(20:05:10) <simboss__> the reader selects the best one
(20:05:31) <simboss__> depending on the requested resolution and on the capabilities of the format
(20:05:35) <simboss__> in terms of overviews
(20:05:37) <simboss__> and decimation
(20:05:42) <simboss__> in this special case
(20:05:42) <Jesse_Eichar77_> I see.
(20:05:52) <moovida> but if the map has no tiles
(20:05:52) <simboss__> we could do subsetting and decimation on the fly
(20:06:03) <simboss__> your map has stripes
(20:06:08) <simboss__> like striped geotiff
(20:06:22) <simboss__> (data not map sorry)
(20:06:27) <simboss__> so in the end
(20:06:30) <simboss__> what you do
(20:06:31) <simboss__> is
(20:06:40) <simboss__> you load only the right stripes
(20:06:43) <simboss__> and of each stripe
(20:06:47) <simboss__> only the needed part
(20:06:57) <simboss__> possibly with a bit of multithreading
(20:07:03) <moovida> alright, let me do an example
(20:07:18) <simboss__> this way you can process a lot of data with a small amount of memory
(20:07:42) <moovida> I have a region set on europe
(20:08:02) <moovida> and the data map is just a piece of Italy
(20:08:15) <moovida> I visualize it and it takes 4 pixels
(20:08:26) <moovida> what do I read from disk in that case?
(20:08:35) <moovida> then I zoom
(20:08:40) <moovida> zoom in
(20:08:49) <moovida> and I see the whole map
(20:08:58) <moovida> I will have to reread it, right?
(20:09:48) <Jesse_Eichar77_> simboss?
(20:09:51) <Jesse_Eichar77_> comments?
(20:09:53) <simboss__> it depends
(20:10:05) <simboss__> the way I do that yes
(20:10:08) <simboss__> because each time
(20:10:12) <simboss__> I read only what I need
(20:10:17) <simboss__> so first time
(20:10:22) <moovida> that is what we did in JGrass
(20:10:23) <simboss__> I would read only 4 pixel
(20:10:28) <simboss__> (more or less)
(20:10:30) <simboss__> secondo time
(20:10:33) <simboss__> you would have to read more
(20:10:47) <simboss__> there are various trick that we can use to speed things up
(20:10:52) <simboss__> 1external overviews
(20:11:20) <simboss__> 2internal pyramid
(20:11:36) <moovida> can these things already be done?
(20:11:42) <moovida> is there code for it?
(20:11:54) <simboss__> 1we add (it's easy) support for external overviews like in gdal
(20:12:05) <moovida> for me having an indexed raster would be nice
(20:12:07) <simboss__> 2(not as easy) use an in-memory pyramid
(20:12:18) <simboss__> I coded 2 for geotif
(20:12:23) <simboss__> but I never tested enough
(20:12:29) <simboss__> to release
(20:12:35) <simboss__> it can be very fast
(20:12:42) <simboss__> but it is still unstable
(20:12:48) <simboss__> 1 would be easy
(20:13:02) <simboss__> and reasinably fast
(20:13:13) <simboss__> it would only require to preprocess the raster
(20:13:20) <simboss__> like you do in arcview
(20:13:22) <simboss__> or gdal
(20:13:29) <simboss__> and so on
(20:13:31) <moovida> we could take that into account
(20:13:32) <simboss__> because
(20:13:34) <moovida> however
(20:13:43) <moovida> I'm not sure the others are interested in that detail. I think that we could discuss this offlist
(20:13:50) <moovida> Jesse? other comments?
(20:14:12) <simboss__> with a format like yours working at lower res could be a bit slow
(20:14:12) <moovida> Simboss, we will talk about that if it is ok for you
(20:14:13) <jgarnett> Jesse had to step away
(20:14:16) <simboss__> k
(20:14:41) <moovida> alright, we lost the moderator
(20:15:07) <Jesse_Eichar77_> hi
(20:15:08) <jgarnett> Simboss I am more concerned about getting things on screen; and the JGrass raster applications experience. Rendering is always an adventure in compromise (one uDig is good at facilitating)
(20:15:15) <Jesse_Eichar77_> back
(20:15:21) <Jesse_Eichar77_> boss grabbed me for a second
(20:15:23) <jgarnett> Shall we proceed to the next agenda item?
(20:15:32) <jgarnett> I was going to just confirm that the viewport model defined in udig
(20:15:42) <jgarnett> and the fact we use GeoAPI CoordinateReferenceSystem
(20:15:49) <jgarnett> was going to work out okay for everyone involved...
(20:16:07) <jgarnett> (I know technical detail; but it has tripped us up when we worked with OSSIM)
(20:16:31) <jgarnett> the CRS is available as WKT (in case you need to bridge to your own definition of projection?)
(20:17:00) <moovida> yes that is another. What about raster reprojection?
(20:17:09) <moovida> we use the proj package
(20:17:40) <moovida> I would like to not stay with a foot in two shoes
(20:17:41) <jgarnett> we use geotools; but uDig will not mind what you use (just so long as we can communicate what is needed to you...)
(20:18:03) <jgarnett> proj does more
(20:18:22) <moovida> more projections or more precise or more what?
(20:18:43) <jgarnett> proj however does WKT so I am confident we can pass information.
(20:18:48) <jgarnett> more transformations
(20:19:08) <jgarnett> both vary on percision; we often start with proj code when adding a new transformation
(20:19:37) <Jesse_Eichar77_> this shouldn't matter too much.
(20:19:49) <Jesse_Eichar77_> the main time is when you are obtaining information from our ViewportModel.
(20:20:00) <Jesse_Eichar77_> and need to send it to your plugins.
(20:20:16) <jgarnett> catching up, Jesse recomended an "adapter" to GridCoverage; you may also wish to render you raster model directly (it is an option)
(20:20:22) <Jesse_Eichar77_> I don't expect you to do your operations in terms of geotools interfaces.
(20:20:28) <Jesse_Eichar77_> I was going to get to that next.
(20:20:40) <Jesse_Eichar77_> I see 3 ways to do rendering right now.
(20:20:59) <Jesse_Eichar77_> 1. You can write a geotools reader for your raster format
(20:21:22) <Jesse_Eichar77_> 2. You can adapt your Object model to the GridCoverage in geotools
(20:21:44) <Jesse_Eichar77_> 3. create a renderer for your raster data/object model which has not geotools dependencies.
(20:21:58) <moovida> alright I see
(20:22:01) <Jesse_Eichar77_> There are benefites to each.
(20:22:05) <Jesse_Eichar77_> 2 is quickest
(20:22:25) <Jesse_Eichar77_> 1 is a pretty good solution in general but may be some work. I'm not totally sure on the amount
(20:22:41) <Jesse_Eichar77_> 3. lets you do most anything you want But is proabably the most work
(20:23:08) <moovida> there is no definition of an "internal udig" coverage format, right?
(20:23:18) <moovida> something that resides in the workspace?
(20:23:31) <Jesse_Eichar77_> no there isn't. The closest would be the Geotools GridCoverage
(20:23:34) <moovida> so that maps could be imported to that
(20:23:42) <moovida> that would have helped
(20:24:01) <moovida> alright, I ot an idea, I will think about it
(20:24:12) <Jesse_Eichar77_> ok.
(20:24:17) <moovida> alright then, if you don't mind then the big piece fo the agenda comes
(20:24:22) <Jesse_Eichar77_> so next? operations?
(20:24:30) <Jesse_Eichar77_> haha
(20:24:30) <moovida> exactly
(20:24:43) <jgarnett> uDig tries to be an intergration platform; no preferences give - bare minimum of GeoAPI interfaces used to define the view port model etc.
(20:25:09) <jgarnett> 2) operations
(20:25:14) <moovida> operations - chaining - openmi - console - R
(20:25:21) <moovida> this is the logical chain
(20:25:32) <moovida> I would love to have
(20:25:44) <moovida> let me explain how we had it
(20:26:17) <moovida> we defined a beanshell environment
(20:26:28) <moovida> that executed all the operations
(20:26:39) <moovida> in the console environment
(20:26:59) <moovida> so a command from gui went also through this
(20:27:16) <moovida> and everything was one and one for all
(20:27:26) <moovida> we need an environment
(20:27:51) <moovida> that lets us chain models together and they should be executed
(20:28:05) <Jesse_Eichar77_> hmmmm. We don't have anything there as of yet.
(20:28:10) <moovida> from the console engine as well as from toolbar
(20:28:21) <moovida> yes, I see
(20:28:25) <Jesse_Eichar77_> A console is certainly possible you could probably port much of your console code over
(20:28:52) <Jesse_Eichar77_> you could create a nice visual way to compose operation chains using GEF
(20:29:05) <moovida> that sounds interesting
(20:29:11) pramsey (n=pramsey@mail.refractions.net) has joined #udig
(20:29:11) <Jesse_Eichar77_> it provides much of the connection layout etc... framework.
(20:29:16) <moovida> but first
(20:29:24) <moovida> were will all this reside?
(20:29:25) <simboss__> brb
(20:29:32) <moovida> one single namespace?
(20:29:37) <moovida> a plugin?
(20:29:39) <moovida> a what?
(20:29:44) <moovida> (brb?)
(20:29:45) <Jesse_Eichar77_> a plugin I would say
(20:29:55) <Jesse_Eichar77_> brb=be right back
(20:30:01) <moovida> ahhh, thanks
(20:30:06) <moovida> a plugin?
(20:30:11) <moovida> with all in it?
(20:30:19) <moovida> it would be a very big one
(20:30:20) <Jesse_Eichar77_> It doesn't have to be a single plugin.
(20:30:33) <jgarnett> Eclipse plug-ins are good for that
(20:30:41) <Jesse_Eichar77_> If you look at most eclispse based systems you often have:
(20:30:51) <Jesse_Eichar77_> model (no UI)
(20:30:55) <Jesse_Eichar77_> ui
(20:31:01) <Jesse_Eichar77_> then maybe
(20:31:01) <jgarnett> you would probably define "Extenstion points" so other plugins can contribute additional operations
(20:31:04) <Jesse_Eichar77_> ui.console
(20:31:09) <Jesse_Eichar77_> ui.gef
(20:31:24) <Jesse_Eichar77_> jgarnett I agree
(20:31:42) <Jesse_Eichar77_> also extension points for chaining methods are an option.
(20:31:59) <Jesse_Eichar77_> point is that you will have to do some design here.
(20:32:05) <moovida> that would be the openmi package place?
(20:32:06) <Jesse_Eichar77_> We have extension points for tools and basic operations
(20:32:39) <moovida> yes, I see, Andreas, that will be a nice working together
(20:32:42) <Jesse_Eichar77_> but you will have to make a framework for your more advanced needs. If it is a nice design we may be able to integrate it deeper into uDig
(20:33:03) <Jesse_Eichar77_> what I mean by nice
(20:33:11) <Jesse_Eichar77_> is if it is generic and not JGrass specific
(20:33:33) <Jesse_Eichar77_> you follow?
(20:33:35) <moovida> yes, I see... what you mean by framework?
(20:33:46) <moovida> the chaining mechanics
(20:33:56) <moovida> and the design around
(20:34:01) <moovida> right?
(20:34:05) <jgarnett> document the way in which new chains can be added; to the point where other developers can contribute
(20:34:18) <Jesse_Eichar77_> yes. to both of you.
(20:34:30) <moovida> good, that is ok
(20:35:03) <moovida> a question to join things together and understand names
(20:35:15) <moovida> In my nameing:
(20:35:31) <moovida> I click on an icon to launch my console
(20:35:41) <moovida> and there i start my model.
(20:35:48) <moovida> model = operation
(20:35:57) <moovida> console = ?
(20:36:23) <Jesse_Eichar77_> ummm
(20:36:28) <Jesse_Eichar77_> yes 
(20:36:41) <moovida> yes?
(20:36:42) <Jesse_Eichar77_> As far as I know we don't have the concept of a console
(20:36:56) <moovida> but what would I start?
(20:37:07) <moovida> it is a plguin perhaps, but the action type is?
(20:37:19) <moovida> a command, a tool, a ...
(20:37:37) <Jesse_Eichar77_> Actions are typically in the toolbar or in a menu
(20:37:43) <jgarnett> I would start with what you have now...
(20:37:53) JCamara (n=Javi@180.Red-88-22-29.staticIP.rima-tde.net) has joined #udig
(20:38:00) <Jesse_Eichar77_> and it would start up your console.
(20:38:10) <moovida> that is the equivalent of an eclipse view
(20:38:12) <moovida> ?
(20:38:25) <moovida> could be always there?
(20:38:36) <Jesse_Eichar77_> That is an option certainly.
(20:38:54) <moovida> but...?
(20:38:58) <moovida> is there a but?
(20:39:39) <Jesse_Eichar77_> No really. Views are nice but it is a trade off whether you want a view or a dialog.
(20:40:32) <moovida> in fact a dialog, since we need to make the console R compatible
(20:40:53) <Jesse_Eichar77_> A view takes up screen space. But can be a "fast" view so it doesn't take up space until you open it in which case it acts similar as a dialog only it maintains its previous state where a dialog is re-created each time
(20:40:53) <moovida> and there is already a client from which we could start
(20:41:11) <Jesse_Eichar77_> any reason that it couldn't be put in a view?
(20:41:31) <moovida> no, honestly not... I was thinking of swing
(20:41:42) <moovida> but I will have to forget about swing for a while
(20:41:57) <Jesse_Eichar77_> swing and AWT can be put in views without difficulty
(20:42:17) <moovida> yes? is there a mixed mode? I never worked with swt
(20:42:24) <Jesse_Eichar77_> we've done it before. But removed most of it because of outstanding bugs on Mac OSX. Which I thing are mostly fixed.
(20:42:45) <moovida> alright, so it would be better to always use SWT?
(20:42:48) <Jesse_Eichar77_> there is. You can create a SWT Control with is a AWT frame
(20:42:53) <Jesse_Eichar77_> it is better
(20:43:05) <moovida> good
(20:43:05) <Jesse_Eichar77_> but for migration purposes it not required.
(20:43:17) <Jesse_Eichar77_> so you can get things going by doing the embedding
(20:43:25) <Jesse_Eichar77_> then migrate to SWT
(20:43:39) <moovida> alright, sounds good
(20:43:42) <Jesse_Eichar77_> Its nice not having to do all work up front
(20:43:54) <moovida>
(20:43:56) <moovida> so the console and the visual console could be views
(20:44:06) <moovida> but who triggers them?
(20:44:14) <Jesse_Eichar77_> well there are a few ways.
(20:44:16) <moovida> they will need to get the map environment
(20:44:24) <moovida> they can listen to that?
(20:44:28) <moovida> right?
(20:44:30) <Jesse_Eichar77_> Yes
(20:44:36) <Jesse_Eichar77_> there are a few ways to get a view
(20:44:37) <Jesse_Eichar77_> 1.
(20:44:50) <Jesse_Eichar77_> an action (on toolbar or in menu) can open it.
(20:45:24) <Jesse_Eichar77_> 2. If the view is a "fast" view then the fast view button can be pressed and the view will open. Try turning some views into fast views in eclipse
(20:45:32) <Jesse_Eichar77_> a fast view acts slightly different from a normal view.
(20:45:39) <moovida> I use them
(20:45:54) <Jesse_Eichar77_> they can also be turned into normal view if a particular use prefers it that way.
(20:45:59) <moovida> i like them, but the console is a heaaaaavy thing
(20:45:59) <Jesse_Eichar77_> ok so there you go.
(20:46:35) <Jesse_Eichar77_> What I like about the fast view is that you can open it up without affecting the layout of the perspective
(20:46:43) <Jesse_Eichar77_> the hide it and reopen it without loosing any state
(20:47:00) <Jesse_Eichar77_> But i would have to think if it is worth it.
(20:47:28) <moovida> alright, I will have a look at this
(20:47:35) <Jesse_Eichar77_> I was playing with making Groovy plugins for uDig and I actually ended up liking dialogs. Although I haven't tried fast views but I found a normal view is really kind of small for a console with inputs
(20:47:54) <Jesse_Eichar77_> I mean a console where you do very much work.
(20:48:08) <Jesse_Eichar77_> of course maximization is always an option
(20:48:21) <Jesse_Eichar77_> any more questions with that?
(20:48:24) <moovida> yes, something to think about
(20:48:30) <Jesse_Eichar77_> 3
(20:48:31) <moovida> no, I'm alright with that
(20:48:33) <Jesse_Eichar77_> 2
(20:48:37) <Jesse_Eichar77_> 1
(20:48:46) <moovida> good
(20:48:48) <Jesse_Eichar77_> ummm looking at agenda what is next?
(20:48:55) <moovida> two last small things
(20:48:56) <Jesse_Eichar77_> datamodel?
(20:49:03) <Jesse_Eichar77_> (looks like it is after console engine
(20:49:08) <moovida> yes, that is just a question
(20:49:16) <moovida> I have for you guys
(20:49:33) <moovida> do you know the datamodel of the VISAD project?
(20:49:51) <Jesse_Eichar77_> not
(20:50:03) <moovida> I'm thinking forward to 3d processing
(20:50:14) <moovida> (not rendering for now, just processing)
(20:50:22) <moovida> like volumes processing
(20:50:31) <moovida> what to do if i want that?
(20:50:37) <moovida> coverage has any idea?
(20:50:55) moovida not sure Simone is here
(20:51:01) <simboss__> yeas I am
(20:51:03) <simboss__>
(20:51:07) <Jesse_Eichar77_> what technology is required for that?
(20:51:08) <moovida> oh great
(20:51:15) <jgarnett> heh
(20:51:24) <moovida> there is the need for a proper datamodel
(20:51:31) <moovida> and VISAD has it
(20:51:42) <moovida> apart of having a much bigger datamodel
(20:51:42) <jgarnett> We have been hoping to look at N dimensional coverages for a while; we are going to track the ISO Coverage model.
(20:51:46) <jgarnett> (does that help?)
(20:52:03) <moovida> I don't know that much about the ISO model
(20:52:07) <simboss__> Andrea is thinking about something different
(20:52:25) <simboss__> talking
(20:52:37) <simboss__> at least slightly different
(20:52:39) <moovida> I have an article that describes the difference between the GIS datamodel and the "sciences" model
(20:52:49) <moovida> but i got it too late for reading it
(20:52:50) <simboss__> share it
(20:52:57) <moovida> absolutely!
(20:53:10) <moovida> is there a way to send files i those IRCs?
(20:53:32) <simboss__> I think andrea is referring to processing of data in x,y,z instead of in x,y
(20:53:36) <moovida> I've seen the work ISO often and they are talking about VISAD also
(20:53:44) <moovida> yes exactly
(20:53:45) <simboss__> volumes instead of planes
(20:53:49) <moovida> voxels
(20:53:53) <moovida> not pixels
(20:53:56) <moovida> yup
(20:54:02) <simboss__> I was afraid of saying voxels
(20:54:37) <simboss__> that is something that actually is not addressed at all
(20:54:41) <Jesse_Eichar77_> you can send the document to me and I can post it on the uDIg site or you can. Maybe in a community area.
(20:54:57) <simboss__> at least not in geotools
(20:55:00) <moovida> great, at which address?
(20:55:07) <moovida> (sorry)
(20:55:10) <Jesse_Eichar77_> jeichar@refractions.net
(20:55:26) <Jesse_Eichar77_> do you have a model for it in JGrass?
(20:55:38) <Jesse_Eichar77_> is there any reason that you can't use the VISAD model?
(20:56:11) <moovida> no, but before stepping to udig migration, I wanted to use visad as model and renderer
(20:56:19) <moovida> so I prototyped a lot
(20:56:24) <moovida> nice stuff
(20:56:30) <moovida> to answer Jessy
(20:56:34) <moovida> Jesse
(20:56:38) <moovida> (sorry )
(20:56:47) <Jesse_Eichar77_>
(20:57:16) <moovida> Since in JGrass we had almost no defined rules
(20:57:31) <moovida> everything was difficult to be kept in order
(20:57:37) <moovida> ordered way
(20:57:53) <Jesse_Eichar77_> ok
(20:57:57) <moovida> I came to udig and geotools because you seem to be the most organised
(20:58:02) <moovida>
(20:58:24) <moovida> so I didn't want to bring too much stuff that is different from the actual concept
(20:58:31) <Jesse_Eichar77_> nice Give Jody some credit for that I think.
(20:58:43) moovida gives thanks to Jody
(20:59:23) <Jesse_Eichar77_> Well I think this is a topic we can continue to discuss for a while
(20:59:29) <moovida> but the problem of volumes stays
(20:59:41) <moovida> and you are right Jesse, mine was just a question
(20:59:45) <Jesse_Eichar77_> we might be able to talk to the geotools/geoAPI guys
(20:59:58) <Jesse_Eichar77_> also can look at possible collaboration with VISAD
(21:00:03) <moovida> also the datamodel has time
(21:00:03) <Jesse_Eichar77_> shall we move on?
(21:00:06) <moovida> yes
(21:00:10) <Jesse_Eichar77_> ok
(21:00:15) <Jesse_Eichar77_> grass compatilibity
(21:00:17) <moovida> last but not least
(21:00:19) <moovida> yes
(21:00:28) <moovida> that is your turn guys
(21:00:45) <Jesse_Eichar77_> ? Maybe explain the item a bit more for me.
(21:00:59) <moovida> udig has different projection handling
(21:01:08) <moovida> different workspace idea
(21:01:29) <moovida> we love to be able to work inside a workspace
(21:01:54) <Jesse_Eichar77_> Define workspace for me.
(21:02:17) <moovida> an ordered filestructure on filesystem
(21:02:26) <moovida> (apart of remote files)
(21:02:39) <moovida> the different feeling is the following
(21:02:59) <moovida> you click to add a "map" to a udig layer
(21:03:23) <moovida> in GRASS there is a place for rasters, vectors and whatever
(21:03:34) <moovida> to work with them, you have to import them
(21:03:45) <jgarnett> My impression is a "project" is just that ... we did talk about projects holding onto their data (ie shapefile and coverages in their directory)
(21:03:49) <moovida> if you process lots of data, that gets important
(21:04:05) <moovida> ah, that would be good
(21:04:05) <jgarnett> you are correct that our "default" assumption is that the data is remote (ie in a databsae, or on a shared folder used by a team)
(21:04:30) <moovida> yes, I know, but for rasters that gets too heavy most of the time
(21:04:38) <jgarnett> indeed we have some constructs aimed towards helping a 'team" work through data processing chores.
(21:04:50) <jgarnett> This is where you guys are the expert(s)
(21:04:59) <Jesse_Eichar77_> so there are a couple of structures uDig has that may be of interest.
(21:05:04) <moovida> so you mean giving permissions and so
(21:05:04) <Jesse_Eichar77_> 1. Project
(21:05:05) <moovida> ?
(21:05:12) <Jesse_Eichar77_> 2. catalog
(21:05:18) <Jesse_Eichar77_> I'll let jody finish
(21:05:44) <jgarnett> aside: you can capture the idea of your "workspace" directly in the udig catalog as a "Service", the resources in that service would be the different raster data.
(21:06:17) <jgarnett> Alternatively workspace sounds like a catalog ... ie a place where the data resources are "tracked"
(21:06:27) <moovida> you mean I could create a service that maps directly on a GRASS workspace
(21:06:28) <moovida> ?
(21:06:43) <jgarnett> (and I see Jesse just made the exact same point - Jesse++ )
(21:06:44) <moovida> perhaps yes, I feel confused
(21:07:02) <Jesse_Eichar77_> lets step through this slower maybe
(21:07:02) <jgarnett> moovida - yes; remember uDig is an intergration platform.
(21:07:26) <Jesse_Eichar77_> I not sure I completely understand a "workspace"
(21:07:28) <moovida> alright
(21:07:33) <moovida> go
(21:07:38) <Jesse_Eichar77_> you import data into your workspace.
(21:07:46) <Jesse_Eichar77_> vectors,rasters, etc...
(21:07:52) <moovida> yes
(21:08:03) <Jesse_Eichar77_> when you import are you actually making the data local, IE copying to the workspace?
(21:08:18) <Jesse_Eichar77_> or is it a catalog of the data that you will work with?
(21:08:22) <moovida> raster usually yes
(21:08:36) <moovida> features not necessarily
(21:08:41) <Jesse_Eichar77_> ok
(21:09:01) <Jesse_Eichar77_> so like I said we have a project and a catalog.
(21:09:20) <moovida> alright, sounds good
(21:09:30) <Jesse_Eichar77_> typically projects are for organizing maps but can contain other objects as well.
(21:10:07) <Jesse_Eichar77_> a catalog maintains the data we are interested in. Normally it is not copied to a local folder.
(21:10:10) pombred1 (n=pombreda@c-69-181-78-241.hsd1.ca.comcast.net) has quit IRC: Read error: 104 (Connection reset by peer)
(21:10:17) <Jesse_Eichar77_> so perhaps that is an issue we want to address
(21:10:26) <moovida> alright, I got it
(21:10:44) <moovida> but what do you put inside a project as it is now?
(21:10:49) <moovida> preferences?
(21:10:54) <Jesse_Eichar77_> It is easy to add an operation that will import the data, remove the old entry and add the new (which now references the new copy)
(21:11:03) <moovida> histories and settings and urls
(21:11:18) <Jesse_Eichar77_> right now it is just maps and Pages (essentially maps that are layed out for printing).
(21:11:35) <Jesse_Eichar77_> but it is extensible like so many things in uDig
(21:11:36) <moovida> yes, but then again no internal format?
(21:11:36) <jgarnett> the project does record what data it uses (so you can email the project to someone else)
(21:12:08) <jgarnett> but when they "open it" the local catalog will be used to track the connections to live data.
(21:12:30) <Jesse_Eichar77_> And when the maps are saved the information for connecting to the data is persisted along with some information on the map blackboard and each layer's style
(21:12:32) <moovida> yes Jody, but remember we have mainly raster data
(21:12:35) <jgarnett> It sounds like the goal for "workspace" is to manage some disk space so raster opperations have a place to play?
(21:12:57) <moovida> yes, exactly
(21:13:08) <jgarnett> which is different from the goals of project (ie share a map) and catalog (organize geo resources)
(21:13:09) <moovida> and the format should be the most performant
(21:13:26) <moovida> ok, we are getting closer
(21:13:29) <Jesse_Eichar77_> As things stand now
(21:13:33) <jgarnett> cool - moovida having new use cases helps.
(21:13:37) <Jesse_Eichar77_> we could do the following:
(21:13:42) <moovida>
(21:13:53) <Jesse_Eichar77_> (just an idea not necessarily the only way/right way to do).
(21:14:46) <Jesse_Eichar77_> 1. add an decorator (it is an extension that can modify how the text and image in a viewer, catalog in our case is shown)
(21:15:02) <Jesse_Eichar77_> the decorator could show a layer as imported or not.
(21:15:19) <Jesse_Eichar77_> 2. add an import to workspace action/operation
(21:15:23) <Jesse_Eichar77_> one idea.
(21:15:44) <Jesse_Eichar77_> another would be to add categories to the catalog so that you can see local vs remote data
(21:16:37) <Jesse_Eichar77_> really the catalog view should be an entire perspective and we've discussed making it one. But haven't had the incentive as of yet.
(21:17:00) <Jesse_Eichar77_> we could make a catalog perspective which has more functionality than the single view we have now.
(21:17:09) <Jesse_Eichar77_> comments?
(21:17:12) <jgarnett> indeed if this disctinction matters (and it does in this case) it would be motivation for a catalog perspective.
(21:17:43) <moovida> I'm starting to think that it will take years to migrate
(21:18:13) <moovida> one thing
(21:18:22) <jgarnett> I actually don't mind "workspace" as a name for resources that have been dragged locally for processing; in general we try to 'do the right thing" - in this case it would be to let people run opperations on a remote WCS; the opperation woudl first fetch the data into the workspace - and then proceed as normal.
(21:18:28) <jgarnett> (bad jody too much typing)
(21:18:35) <Jesse_Eichar77_> hmmm. I am hoping that we can do it quicker.
(21:18:53) <Jesse_Eichar77_> get a basic integration
(21:19:05) <moovida> how do you expect for example a use case in which a GRASS user
(21:19:09) <Jesse_Eichar77_> then more slowly get a proper "marriage" between the two.
(21:19:31) <moovida> approaches udig and wants to use its GRASS workspace
(21:19:33) <moovida> ?
(21:19:53) <moovida> lets imagine to simplify
(21:20:05) <moovida> that he has only rasters and we have the reader for it
(21:20:10) <moovida> what happens?
(21:20:26) <jgarnett> moovida you have switched to talking about user experience yes?
(21:20:27) <moovida> he looses his backward compatibility
(21:20:31) <jgarnett> (or are we still talking code...)
(21:20:47) <moovida> I feel that is directly linked to it
(21:20:52) <Jesse_Eichar77_> I think I understand your point... He has an existing workspace?
(21:21:02) <moovida> yes
(21:21:15) <moovida> and after playing with userfriendly udig
(21:21:16) <Jesse_Eichar77_> does a typicall single user have multiple workspaces?
(21:21:34) <moovida> he has to give it back to the tecnical guy that goes on with GRASS
(21:21:43) <moovida> yes, usually yes
(21:21:51) <Jesse_Eichar77_> ok.
(21:21:55) <moovida> GRASS has the following folder organisation
(21:22:08) <moovida> the root of the grass database
(21:22:11) <jgarnett> got it; you want to work from your existing workspace - rather then "project"
(21:22:27) <moovida> yes Jody, that would be great
(21:22:31) <jgarnett> because you are sharing that workspace with a GRASS operator....
(21:22:50) <jgarnett> moovida; we are in need of a few more workflow examples (I thought you were talking code)
(21:23:09) <jgarnett> thinking.
(21:23:10) <moovida> my fault
(21:23:21) <moovida> but I wanted to be sure you have an idea
(21:23:37) <moovida> the maps do not have projection info
(21:23:51) <moovida> let me quickly explain the grass database
(21:23:56) <moovida> very quickly
(21:24:01) <jgarnett> okay
(21:24:10) <moovida> in the root folder there are LOCATIONS
(21:24:20) <moovida> as many as you like
(21:24:35) <moovida> LOCATION is keeper of the projection information
(21:24:57) <moovida> as well as the region bounds in which the choosen projection makes sense
(21:25:11) <moovida> inside of every LOCATION we have MAPSETS
(21:25:36) <moovida> one particular, called PERMANENT
(21:25:48) <moovida> that is shared by everyone
(21:26:02) <moovida> and others that the user creates to work inside
(21:26:17) <moovida> the playing around Jody was talking about
(21:26:31) <moovida> this was based on a multiuser concept
(21:26:50) <moovida> and there can be permissions on the mapsets
(21:26:57) <moovida> that was it
(21:27:08) <jgarnett> cool
(21:27:13) <Jesse_Eichar77_> Ok
(21:27:17) <jgarnett> q:
(21:27:25) <moovida> go
(21:27:33) <jgarnett> interacting with this workflow is still front and center a priority for you?
(21:27:39) <jgarnett> (ie the "why")
(21:28:10) <moovida> if this is possible without going against all udig rules, yes
(21:28:17) <jgarnett> I am imaginging teams; where they have workspaces defined with outstanding work or processing to be done etc...
(21:28:40) <jgarnett> moovida; uDig is a intergration framework; people have built a number of GIS applications ontop of it (using the parts)
(21:28:47) <jgarnett> this should be no different
(21:28:54) <moovida> I know, I know
(21:28:59) <jgarnett> indeed it should be fun
(21:29:06) <moovida> but I didn't want to get that far away from the core
(21:29:14) <Jesse_Eichar77_> So to do a bit of brainstorming:
(21:29:18) <Jesse_Eichar77_> so the idea of creating a service that represents a grass workspace is not a bad one. It would allow workspaces to be added and removed easily. It could handle permissions.
(21:29:35) <Jesse_Eichar77_> could be dynamic and have special operations for it.
(21:29:52) <moovida> could use the udig catalog
(21:30:01) <moovida> yes
(21:30:04) <Jesse_Eichar77_> services are the top level items in the catalog.
(21:30:04) <jgarnett> the idea of publishing "new stuff" to a service is established, and in agrement with what a workspace does
(21:30:28) <Jesse_Eichar77_> each child is normally a georesource.
(21:30:59) <Jesse_Eichar77_> the members of your workspace service could be rasters and vectors.
(21:31:03) <jgarnett> can I ask a question; does the worksspace define anything visual? ie is mapset data or visualization?
(21:31:36) <moovida> you mean what you call style?
(21:31:44) <moovida> Jesse - yes
(21:31:46) <jgarnett> I mean what I call "Map"
(21:32:14) <moovida> just the active processing region
(21:32:21) <moovida> if that is one
(21:32:22) <Jesse_Eichar77_> in this way they could be added to maps like any other resource. But because they are part of the special service they can be managed in certain ways. You could add resources to it by dragging and dropping files or other resources into it.
(21:32:44) <moovida> that would be very nice
(21:32:49) <Jesse_Eichar77_> but it sounds like the workspace is more than just a catalog right?
(21:32:49) <jgarnett> that is a good story as well Jesse.
(21:32:57) <jgarnett> can I offer one more :-D
(21:33:04) <moovida> I'm afraid
(21:33:07) <Jesse_Eichar77_> it also has our ideas of a map defined in it as well.
(21:33:42) <Jesse_Eichar77_> I'm talking about how it declares the area of processing for example
(21:33:51) <Jesse_Eichar77_> which is what we were considering putting on the map blackboard.
(21:33:58) <moovida> yes and therefore in it we can use all GRASS modules,
(21:34:25) <moovida> and exploit all (not all, but...) the power of two worlds
(21:34:39) <Jesse_Eichar77_> so if we had this service we could also possible create a map from the service.
(21:34:54) ticheler (n=ticheler@d83-181-227-194.cust.tele2.it) has joined #udig
(21:35:20) <Jesse_Eichar77_> the only difficulty with that is that changes to the map ( processing area ) would necessarily be reflected back in the grass workspace.
(21:35:37) <Jesse_Eichar77_> (I'm essentially thinking out loud so feel free to step in)
(21:35:37) <moovida> mean what do you mean
(21:35:44) <moovida> sorry,
(21:35:49) <moovida> what do you mean
(21:35:58) <Jesse_Eichar77_> at the beginning of our IRC
(21:36:19) <Jesse_Eichar77_> we discussed putting the Area for processing and the resolution on a map blackboard and we would run operations on the map.
(21:36:23) <Jesse_Eichar77_> right?
(21:36:28) <moovida> yes
(21:36:32) <Jesse_Eichar77_> or on layers in the map.
(21:37:02) <Jesse_Eichar77_> now I see that the are for processing (and I'm guessing the resolution) can also be defined in the workspace
(21:37:20) <Jesse_Eichar77_> I'm I still on the correct path?
(21:37:30) <moovida> yes and those should be kept in sync
(21:37:48) <Jesse_Eichar77_> It would be nice if they did.
(21:38:02) <Jesse_Eichar77_> I can think of ways to do it but I'd like a clean way if possible.
(21:38:12) <moovida> but if you change the projection there will be a mess
(21:38:27) <moovida> because the whole workspace should then be reprojected
(21:38:37) <moovida> that is no way to go
(21:38:48) <moovida> in that case the projection should be fixed
(21:39:03) <moovida> or a big big big warning should appear
(21:39:08) <Jesse_Eichar77_>
(21:39:38) <moovida> but back to region and resolution
(21:39:42) <Jesse_Eichar77_> I don't see any problems with any of this. There will be some complexity to make the GRASS workspace be in sync with the map
(21:39:44) <moovida> you were saying
(21:39:57) <Jesse_Eichar77_> and some complexity to ensure that the user can't do something stupid.
(21:39:58) <moovida> that should not be a big issue
(21:40:07) <moovida> we had that all in JGrass
(21:40:12) <Jesse_Eichar77_> like reproject the map.
(21:40:26) <moovida> we were able to work with both JGrass and GRASS in the same space
(21:40:41) <moovida> (a bit dangerous in fact)
(21:40:46) <moovida> but funny
(21:40:47) <moovida>
(21:40:50) <Jesse_Eichar77_>
(21:40:51) <moovida> I agree with you
(21:41:25) <Jesse_Eichar77_> To summarize that little thread:
(21:41:31) <Jesse_Eichar77_> 1. Service for a workspace
(21:41:39) <Jesse_Eichar77_> 2. be able to create a map from the workspace
(21:41:58) <Jesse_Eichar77_> 3. operate on maps so that the operations are not tied to a grass workspace but can in theory work on any uDig map.
(21:42:24) <Jesse_Eichar77_> Is that it in simple terms?
(21:42:37) <moovida> yes, it sounds good
(21:42:41) <Jesse_Eichar77_> ok cool.
(21:42:59) <Jesse_Eichar77_> Coordinate Reference System compatibility I think should not be too bad
(21:43:08) <Jesse_Eichar77_> both can go to and from WKT I'm pretty sure
(21:43:19) <Jesse_Eichar77_> so we at least have a method for communication.
(21:43:54) <Jesse_Eichar77_> any other compatibility concerns?
(21:43:57) <moovida> yes, I assume yes
(21:44:03) <moovida> hmmm...
(21:44:05) <Jesse_Eichar77_> I think yes
(21:44:09) <Jesse_Eichar77_> (pretty sure)
(21:44:24) <moovida> I'm fainting, so I'm not sure
(21:44:25) <moovida>
(21:44:56) <Jesse_Eichar77_> ok
(21:45:03) <Jesse_Eichar77_> we lets continue on the email list then
(21:45:07) <moovida> if the workspace is kept, all the ways are opened for further compatibility
(21:45:09) <jgarnett> are we done
(21:45:16) <moovida> yes agreed
(21:45:18) <Jesse_Eichar77_> This has been an incredibly long meeting.
(21:45:31) <Jesse_Eichar77_> I hope fruitful thoug
(21:45:32) <moovida> I will need some time to think about it and talk to the other guys
(21:45:33) <jgarnett> post the logs
(21:45:43) <Jesse_Eichar77_> Will do
(21:45:44) <jgarnett> moovida can we meet the other guys?
(21:45:45) <moovida> yes, long and devastating,
(21:46:06) <moovida> but I now understand a lot more
(21:46:10) <jgarnett> heh you should try a geoserver meeting ....
(21:46:24) <moovida> is that worse?
(21:46:34) <jgarnett> and thanks moovida; I understand a lot more as well.
(21:46:46) <Jesse_Eichar77_> Well lets keep up the communication and I will do what I can do help you get moving.
(21:46:59) <moovida> the other guys are here right now, if they are not fainted as well or fallen asleep
(21:47:13) <moovida> that you very much guys!
(21:47:24) <Jesse_Eichar77_> I had a great time.
(21:47:29) <moovida> One last question
(21:47:32) <Jesse_Eichar77_> sure
(21:47:46) <moovida> for things like wiki, docs, repos...
(21:47:54) <moovida> do we come to your home?
(21:48:11) <Jesse_Eichar77_> I think so.
(21:48:13) <moovida> I will start a page on what happend here tonight
(21:48:31) <moovida> to see if we understood each other
(21:48:33) <Jesse_Eichar77_> sounds good. I believe anyone can create an account to the wiki
(21:48:38) <Jesse_Eichar77_> good plan
(21:49:03) <moovida> I'm not sure about were to put it, can you create me a place
(21:49:11) <moovida> and from there I start?
(21:49:48) <jgarnett> moovida do you want your own "wiki space" to track the intergration ...
(21:50:15) <moovida> that would be nice indeed
(21:50:27) <moovida> so confusions could be kept alone
(21:50:43) <moovida> but it is important that you guys sometimes give a look at it
(21:50:54) <moovida> so it has to be near your place
(21:51:54) <jgarnett> no no; we will set up a wiki space on our confluence box
(21:51:59) <jgarnett> (think package, but for wiki pages)
(21:52:13) <Jesse_Eichar77_> ok we'll set you up a space and send you the link.
(21:52:25) <moovida> aright, thanks men!
(21:52:25) <jgarnett> stay online - doing it now
(21:52:49) <jgarnett> What shall I call it?
(21:52:54) <jgarnett> JGRASS
(21:53:02) <moovida> my possibilities without eating and going to the bathroom is finising
(21:53:13) <moovida> JGrass is ok
(21:53:27) <jgarnett> okay; I will email the link to the udig-devel list; and the IRC chat will be here when you get back
(21:53:46) <moovida> great Jody, thanks
(21:54:12) <jgarnett> http://udig.refractions.net/confluence/display/JGRASS/Home
(21:54:45) <moovida> alright, it askes me for login
(21:54:54) <jgarnett> getting there
(21:54:57) <moovida>
(21:55:16) <moovida> I have to check my account in the firefox preferences
(21:55:41) <moovida> alright, if I have trouble I shout
(21:55:56) <moovida> is there a link to the style to use?
(21:55:59) <jgarnett> try now?
(21:56:08) <jgarnett> style to use/
(21:56:10) <jgarnett> for the wiki?
(21:56:15) <moovida> yes
(21:56:20) <Jesse_Eichar77_> brb
(21:56:20) <jgarnett> I suppose there is ... let me find it.
(21:57:02) <jgarnett> most of our style guidelines are for writing user documentation, we try to use parent page / child page to structure our table of contents (but that is because we are lazy)
(21:57:23) <jgarnett> http://udig.refractions.net/confluence/display/UDIG/Project+Guide
(21:57:28) <jgarnett> has Wiki Guidelines
(21:57:33) <jgarnett> and Confluence Reference
(21:57:37) <jgarnett> (ha organized!)
(21:57:42) <jgarnett> http://udig.refractions.net/confluence/display/UDIG/Confluence+Reference
(21:57:46) <jgarnett> http://udig.refractions.net/confluence/display/UDIG/Wiki+Guidelines
(21:57:56) <moovida> good, in the meanwhile I'm in
(21:57:57) <jgarnett> (which is different from useful)
(21:58:04) <moovida> he he
(21:58:51) <moovida> alright, I think we are done, right?
(21:58:58) <moovida> at least I am...
(21:59:00) <moovida>
(21:59:03) <jgarnett> yep
(22:00:11) <moovida> alright, then thanks for the chat (3 hours )
(22:00:23) <silli> \part
(22:00:36) silli (n=silli@194.242.208.236) has left #udig
(22:00:42) <moovida> talk to you soon
(22:01:02) <moovida> when all the doubts rasie from the devils kitchen
(22:01:05) <moovida> bye
(22:01:16) <ericajg> bye
(22:01:33) <ericajg> \part #udig
(22:01:34) <moovida> erica, we talk in the next days
(22:01:41) <moovida> it is slahs
(22:01:53) <moovida> slash, not backslash
(22:02:10) ericajg (n=user@84.18.138.236) has left #udig
(22:02:10) Sent part request, waiting for reply...
