GeoTools : 2004-05-24 Weekly IRC

aaime: Hi<BR>
jmacgill: Sounds like its a holidy in Canada, but I think Jody said he would be here...<BR>
jeichar: hi a holiday it is<BR>
ian: for what?<BR>
acuster: fun<BR>
jeichar: Victoria day? I think.<BR>
ian: Ah I remember - we used to have that in Edinburgh<BR>
jmacgill: Well, I'll start taking adgenda items...<BR>
jmacgill: 1) post merge fall out<BR>
jmacgill: 2) location of resouce/data files for unit tests<BR>
jmacgill: 3) renderer issues (should take up the rest of the day)<BR>
jmacgill: anything else?<BR>
aaime: Nothing really... just a side note... I managed to install Oracle 10g on my pc, so next week I should be able to close fid-exp...<BR>
*groldan:*DataStore.getView(Query) as part of the DataStore interface?<BR>
jgarnett: Sorry I am late had a parade to wade through.<BR>
jgarnett: (Victoria day - for the queen, in a town called Victoria)<BR>
jmacgill: ok, my list of adgenda items so far - post merge fallout/report<BR>
jmacgill: 2) test data location<BR>
jmacgill: renderer discuassion<BR>
jmacgill: 4) DataStore.getView(Query)<BR>
Martin_: I will be away for about 20 minutes... I will log the message in the main time and read them when I will be back.<BR>
jmacgill: We can leave rendering until then<BR>
jgarnett: 5) meta-exp<BR>
jmacgill: Martin_ note that I just fixed the build to do the RMI stubs agsin<BR>
jmacgill: ok, Jody can you start with a brief overview of current svn status?<BR>
jgarnett: right<BR>
jgarnett: trunk has everything in the correct spot.<BR>
jgarnett: I was going to get maven working again and then tag it.<BR>
jgarnett: But Martin snuck it with more code (ce la vie).<BR>
jgarnett: So once we have maven set up for the new structure, we will tag and be done.<BR>
jgarnett: (Did I miss anything?)<BR>
aaime: "c'est la vie" (wink)<BR>
aaime: Hum, how is the build at the moment? <BR>
jgarnett: The structure looks very good, I am already fond of it. The build needs help - I think James is working on it?<BR>
jmacgill: The main module can be compiled with a 'maven java:compile' <BR>
jgarnett: It is the test cases that are broken (see agenda item 2)<BR>
jmacgill: The main module fails a lot of tests at the moment, though I have resolved a number of issues (e.g. test location, rmi stub generation)<BR>
jgarnett: Aside: the merge of fid-exp did test out on the merge-exp branch, it should not be an issue when you are done fid-exp aaime.<BR>
jmacgill: I'm working on these, though I would like to resolve data location before going much futher<BR>
jgarnett: Should we just move on to agenda item 2 then? It is hard to say much about the module merge (other than it took along time)<BR>
jmacgill: rather more importantly though I'd like to think about test data in general. i.e. main can't be dependent on plugins (e.g. shapefile)<BR>
aaime: Happy to hear it Jody (it took me a whole day to install Oracle 10g so I'm late on fixing the branch). Could you be so kind to provide some directions on how to do it? I was thinking to try to merge the trunk on fid-exp, fix eventual problems, and then go back... is this feasible?<BR>
jgarnett: James I did set up a second additional maven:reactor tag as an experiment and got plugin/ext to start - I am not sure on how you plan to intergrate the additional directories (the maven documentation was a bit thin)<BR>
aaime: James, you are right, but I'm worried about using something (gml) that is going thru a full rewrite...<BR>
jgarnett: aaime - I had a script that was evil (ended up rm directories in the process of merging them, I ended up going through and moving things by hand.<BR>
jgarnett: we could use wkt - I could rescue the *.properties data store from its tutorial.<BR>
jgarnett: It could also be that legend belongs in ext?<BR>
aaime: I see... would be you so kind to post a few directions about how to move? Sorry, it's just that in the past week I had to learn both svn and oracle administration and my head still hurts a bit (wink)<BR>
aaime: ext means? Everything that is nor code nor plugin?<BR>
jmacgill: It may well, however, we almost certanly need some form of test data loading if we are going to have good coverage.<BR>
jgarnett: finding the link for you aaime<BR>
jgarnett: From <A HREF="http://docs.codehaus.org/display/GEOTOOLS/Module+Merge:">http://docs.codehaus.org/display/GEOTOOLS/Module+Merge:</A><BR>
jgarnett: * main: core geotools2 library<BR>
jgarnett: * plugins: modules that intergrate at runtime with the whole via a Plugin or Facotry interface<BR>
jgarnett: * extentions: independent libraries built on top of the main<BR>
aaime: In this case yes, it should be in extensions<BR>
jgarnett: Something else to move then.<BR>
jmacgill: Would you see the properties DataStore as living inside main or as a module which main depended on? <BR>
jmacgill: Do we allow ext to depend on plugins?<BR>
jgarnett: Than svn book is your best reference on how to merge aaime - svn merge kind of makes a diff that you can use to drag changes across.<BR>
jgarnett: For anything that is totally not on the trunk, I recomend svn move as it will preserve history.<BR>
aaime: My opinion: the property data store is probably small enough to fit into main and that would save us headaches... ext should depend on plugins, yes, seems to be a good idea...<BR>
jgarnett: They have some convention about mentioning the revision number when you merge - since svn does not preserve history during merge process.<BR>
aaime: Jody, yes, I've already read the whole svn book (that's how I spent the last week sunday)... <BR>
jgarnett: The script I was using for a bit is located at - <A HREF="http://svn.geotools.org/geotools/trunk/scripts/">http://svn.geotools.org/geotools/trunk/scripts/</A><BR>
aaime: I'll have a look at it, thank you<BR>
jgarnett: making ext depends on plug-ins makes sense.<BR>
jmacgill: That would allow legend to use shapefile<BR>
jgarnett: Shall we try and figure out test data?<BR>
jmacgill: yes<BR>
jmacgill: ok, couple of things to note...<BR>
jmacgill: first, unless the project.xml file in main lists the file extention for a resource it will not be copied over to the compiled test classes directory in target<BR>
jmacgill: I've added .txt, .xml and .wkt to that list and this has helped a few of the failed tests<BR>
IanS <I>~cholmes@dsl092-183-037.sfo1.dsl.speakeasy.net</I> entered the room.<BR>
<FONT COLOR="#b22222" sml="IRC"><FONT SIZE="2">(13:13:58) jmacgill:</FONT> Second, unit tests which used the relative path to data worked fine, those that wanted a top level dataFolder tended to fail<BR>
jmacgill: I personaly prefere org.geotools.thing.test-data or org.geotools.thing.testResources as it makes it easier to work out what data is related to what set of tests<BR>
aaime: In that respect, IanS prepared a good superclass for unit tests that I've copied over to my modules, I this this is something that should be centralized (but how?)<BR>
aaime: The class is called TestCaseSupport, helps in locating test resources, for example...<BR>
aaime: having it as the superclass for our test classes would simplify them and make them more consistent...<BR>
jgarnett: I have also needed a TestCase super class in data, I actually put it in the src directory as it needed to be reused by plugin implementors.<BR>
jgarnett: So how = move to a src directory (maybe utils?)<BR>
aaime: This makes the modules dependent on junit thought<BR>
Martin_: I'm back<BR>
jgarnett: They are already if they are doing test cases.<BR>
aaime: anyway, if it's just a compile time dependency, no problem<BR>
jmacgill: Not explicity<BR>
jmacgill: maven makes junit available during testing even if junit is not listed as a dep<BR>
jgarnett: I see the point, can the "magic" that this superclass be done as a utility method in utils package? Can still set up a superclass for modules to test with.<BR>
jgarnett: But wait this is testdata we are talking about - the superclass idea should be fine.<BR>
jgarnett: (main already depends on junit, because data did)<BR>
jgarnett: Back to the test data location, we seemed to like the idea of relative paths for the location?<BR>
jgarnett: Do we want to just go with that?<BR>
jgarnett: Only wrinkle is things like PostgisDataStore which wants a properties file describing a victim database it can abuse, that should not be relative.<BR>
aaime: Relative path means classpath references? If so, I agree.<BR>
jgarnett: I can agree with classpath references as well.<BR>
jgarnett: move the data closer to where it is used.<BR>
aaime: So does MySQL in fid-exp (and probably will Oracle too)<BR>
jgarnett: I was thinking the properties file should be filesystem relative, developers can create if they have a local database to abuse?<BR>
jgarnett: (propertie file a simple mapping of connection parameters)<BR>
jgarnett: James does the idea of classpath relative work for you?<BR>
aaime: The property file is there anyway, it's just that the test is disabled in the maven build... and as far as i remember we can load a property file from an inputstream too (cheking...)<BR>
jmacgill: yes, classpath relative is my 'prefered solution'<BR>
jgarnett: It would be nice to set up maven to only run the test if the properties file is there (james can this be done?)<BR>
jgarnett: Lets vote then, database connection parameters will have to be handled differently.<BR>
jgarnett: +1<BR>
aaime: Yep, the Properties class accept also an input stream, so we can load those properties with an input stream got from the classpath<BR>
ian: +1<BR>
aaime: Jody, it would be better to leave the file so that you have an example on how to set it up...<BR>
aaime: Maybe we can leave it there with a different name, if you need to run the tests just copy, rename and adapt the contents?<BR>
aaime: +1<BR>
IanS: +1<BR>
jgarnett: Hey wait do I get a vote? My module was sucked up in the merge (smile)<BR>
jmacgill: +1<BR>
aaime: I thought we were voting for classpath relative references to resources<BR>
jgarnett: yes we are<BR>
jmacgill: Thsts what I voted for (wink)<BR>
Martin_: +1 for classpath relative data (I hope I'm not misunderstanding)<BR>
Martin_: Also suggest data-test or test-data directory, for consistency with doc-files and META-INF directories which are standards in J2SE (i.e. directory for non-java class often has XXX-YYY name).<BR>
Martin_: So they can't be confused with a package.<BR>
jgarnett: okay<BR>
jgarnett: We better update our developers guide :-P<BR>
jmacgill: test-data seems to be the current favorate<BR>
Martin_: +1 for test-data<BR>
aaime: +1 for test-data<BR>
jgarnett: +1<BR>
IanS: +1 for test-data<BR>
ian: 0<BR>
jgarnett: James is that enough for you to be going foward with?<BR>
jmacgill: yes.<BR>
jgarnett: Raster is next ...<BR>
jmacgill: Can I make a bit of a plea here with regards making this work on windows with spaces in file name<BR>
jgarnett: I will try and update the developers guide<BR>
jmacgill: i.e.<BR>
jmacgill: getClass().getResource(path).openStream())) works<BR>
jmacgill: new InputStreamReader(<BR>
jmacgill: getClass().getClassLoader().getResourceAsStream(path))); does not<BR>
jmacgill: Similarly File f = new file(getResounce("path).toString()) fails<BR>
aaime: This seems the work for a superclass or for an utility class. What about moving the above TestCaseSupport to main and add/modify the methods as needed?<BR>
jmacgill: but File f = new File(URLDecoder.decode(getResouce(path)).toStirng() passes<BR>
jmacgill: ok, will look at that as I fix failing tests<BR>
Martin_: TestCaseSupport in main: I guess you mean in the main/test directory?<BR>
jgarnett: I was thinking in src - so that other modules can use it<BR>
aaime: No, it needs to be in main/src to make it available to ther tests<BR>
jmacgill: That would add a global dep on junit<BR>
aaime: It's already there, see project.xml in main<BR>
jmacgill: true, but I think that is a mistake<BR>
aaime: That's why I was thinking about compile time dependency (tolerable) vs run time dependency (not)<BR>
Martin_: Could test in other module depends on main/test?<BR>
jmacgill: no (sad)<BR>
jgarnett: I am starting to convert Developers Guide sections 4. Conventions and will try and put some of this knowledge in there<BR>
jmacgill: would - TestUtility.getResouce(this,path) be acceptable?<BR>
jgarnett: How about TestData.getResource( this, path ) (smile)<BR>
aaime: In fact having the same methods in an utility class would be better...<BR>
jgarnett: could even suck our "test-data" convention into such a class.<BR>
aaime: the dependency is TestCaseSupport is there just because it's a subclass of TestCase<BR>
jgarnett: As a luser I would still like this in a TestCase super class (but I am lazy)<BR>
aaime: What about short named singleton? (wink)<BR>
jgarnett: TestData is a good idea - would prevent main from having a junit dependeny.<BR>
jmacgill: and we could simplify it to TestData.getResource( this, name )<BR>
jmacgill: with the test-data being implied<BR>
Martin_: I suggest to put it in org.geotools.resources then (the "hidden package").<BR>
jgarnett: Okay I do think we have a winner resources.TestData.getResource( this, name ) <BR>
jgarnett: redundancy and everything.<BR>
aaime: redundancy?<BR>
Martin_: Oups! (package name + method name)<BR>
Martin_: TestData.getInputStreqm(this, name) then?<BR>
Martin_: Typo: TestData.getInputStream<BR>
Martin_: Woud allows to add TestData.getReader as well.<BR>
Martin_: And any kind of other usefull resources.<BR>
jgarnett: resources.Test.data( this, name )<BR>
Martin_: org.geotools.resources.TestData.getInputStream(this, name);<BR>
aaime: Fine, but org.getools.reources doesn't need to be there when you type (we do have the import statement (wink) )<BR>
Martin_: Yes, sure (smile)<BR>
jgarnett: I tell you what James is doing the work I am sure he will do the right thing <BR>
Martin_: So we can add getReader(this, name) as well (would returns a java.io.Reader)<BR>
jmacgill: Yeah, I have enough to go on now. Expect a TestData class with handy dany methods<BR>
aaime: Excellent<BR>
jgarnett: Raster?<BR>
Martin_: Okay for me<BR>
aaime: Yep<BR>
Martin_: I have to refactor GridCoverage as an implementation of the new org.opengis.coverage interfaces.<BR>
aaime: I hope this will be short since I will have to to in 30 minutes...<BR>
Martin_: Should not be that hard, since the API is the same (just change CoordinateSystem --> CoordinateReferenceSystem)<BR>
Abstract^ left the room (quit: Read error: 60 (Operation timed out)).<BR>
<FONT COLOR="#2f4f4f" sml="IRC"><FONT SIZE="2">(13:51:39) Martin_:</FONT> I will try to commit at least SampleDimension and Coverage tomorrow.<BR>
jgarnett: The moment you are done that we were goign to have another stab at GridCoverageExchange.<BR>
Martin_: Yes. I hope it will be in the next few days.<BR>
jeichar: what else depends on grid coverage? Other than GCE?<BR>
Martin_: J2D Renderer.<BR>
aaime: Lite renderer too<BR>
Martin_: GTOPO30<BR>
aaime: ImageDataSource<BR>
aaime: ArcGrid<BR>
jeichar: So not a small job.<BR>
jeichar: the functionality should be close though...<BR>
aaime: Not big as changing the Feature interfance, but similar (smaller only because still we don't use GridCoverage much)<BR>
Martin_: Actually, the hard part is not really the GridCoverage refactoring (since there is no change in the API). This is the changes from CoordinateSystem to CoordinateReferenceSystem, which appears in many corners of Geotools, including GridCoverage.<BR>
jeichar: There isn't an API change. I looked at them and they looked quite different. What did I see then?<BR>
Martin_: You means CoordinateSystem and CoordinateReferenceSystem? They are different. This is what I wanted to say.<BR>
Martin_: (i.e. the hardest part will be the change from CS to CRS).<BR>
jeichar: No geotools.GridCoverage and geoapi.GridCoverage. (not exactly those packages)<BR>
Martin_: They should be similar.<BR>
Martin_: opengis.GridCoverage has some method that I didn't implemented in Geotools.<BR>
jeichar: I looked at them this week. Similar yes. The functionality should be the same I'd think. Maybe mostly different method names and moving the code around?<BR>
jeichar: I'm looking at the javadocs now<BR>
Martin_: Same method name, except for metadata, and except for method related to CRS. For example 'getCoordinateSystem()' is now 'getCoordinateReferenceSystem()'.<BR>
Martin_: But the functionality is the same.<BR>
Martin_: I pretty sure of that, since I did the interface in GeoAPI (smile)<BR>
Martin_: Both Geotools implementation and GeoAPI interfaces are derived from the same OGC specification.<BR>
jeichar: so evaluate(Point2d, float[]) is equivalent to getDataBlock(GridRange, float[])<BR>
Martin_: Since the OGC specification didn't changed yet, the API didn't changed neither.<BR>
Martin_: No. evaluate(Point2D, float[]) is inherited from Coverage<BR>
Martin_: So this method still there.<BR>
Martin_: getDataBlock was a method in the OGC specification which I ommited in the Geotools implementation.<BR>
jeichar: ok I see now. thank you.<BR>
Martin_: But since GeoAPI is supposed to follow OGC specification, I added the getDataBlock method in GeoAPI interfaces.<BR>
Martin_: I will have to implements them when I will refactor GridCoverage...<BR>
jeichar: sorry for derailing the conversation. I just had to make sure I understood. So now...<BR>
jgarnett: We kind of got stuck here, updating the code base to CRS probably deserves its own agenda item.<BR>
jgarnett: (sorry my irc froze up, it seems we are not stuck)<BR>
jgarnett: One thing that has been keeping the email list busy is a constant stream of ideas and questions from us at refractions.<BR>
Martin_: It was a good thing (smile)<BR>
jgarnett: Most of this has been trying to get our heads around the great work avialable in geotools. A lot of it I had not seen until I went throught the module merge.<BR>
aaime: Yes, very busy (I'm having a hard time to keep the page, but it's a good thing)<BR>
jgarnett: The good news is that we are going to keep anwering questions, Jessie is the lead on the rendering front - so please be kind.<BR>
Martin_: It was one reason why I wanted the module merge: having a better view of the whole Geotools core under the eyes.<BR>
jgarnett: As I understand the recent bout of email martin is recomending we go up a level of abstraction based on some ISO recomendation.<BR>
jgarnett: And them to come back shopping when we were actually interested in painting on to a graphics 2d?<BR>
jmacgill: yes (except that the abstraction is based on GO-1, a proposed OGC spec rather than an ISO one)<BR>
Martin_: Note: GO-1 is not an ISO specification (geometry and CRS are, but not GO-1). But yes, I would suggest to at least consider GO-1 interfaces. But I'm not yet sure if they will fit well.<BR>
jmacgill: Martin, when is the OGC meeting?<BR>
aaime: ISO recommendation == GO-1? It seems to me that GO-1 has merits, but it's not cooked up to a point it's usable (I'm just plain wrong?)<BR>
Martin_: OGC meeting at London around June 15-20 I think.<BR>
jgarnett: Are the GO-1 interfaces fixed? Having a starting point is still worthwhile.<BR>
Martin_: I got all implementations removed from GO-1<BR>
jgarnett: Asking a user level abstraction out of j2d and lite renderer is where we were going wrong.<BR>
jmacgill: In that cae, uDIG team, you have until June 15th to find things wrong with GO-1<BR>
Martin_: I convinced them to remove SpatialschemaFactory as well.<BR>
jgarnett: That is great news.<BR>
ian: I think OGC meeting is in Southampton<BR>
jmacgill: You can still formaly file comments on the spec proposal by email and they will be raised at the meeting.<BR>
Martin_: Andrea, GO-1 != ISO recommendation. GO-1 are just the org.opengis.go.* package.<BR>
jgarnett: Okay can we have a nice breakdown for those following at home?<BR>
aaime: I see... my point was another one... is it ok to use GO-1 as it is now?<BR>
Martin_: Hard to say before we try it.<BR>
Abstract^ <I>~abstract@ibiza-gw.hiof.no</I> entered the room.<BR>
<FONT COLOR="#2f4f4f" sml="IRC"><FONT SIZE="2">(14:12:18) Martin_:</FONT> But if we start using it, we will have a better opportunity to change it if thing need to be fixed.<BR>
jmacgill: The BEST thing that could happen is to TRY GO-1 in time to file changes before June 15th<BR>
Martin_: One thing sure: an implementation based on GO-1 is possible, since Polexis made at least one.<BR>
Martin_: Doesn't means that it would be the best implementation possible.<BR>
jgarnett: Well I doubt we will try it at a code level, but we can at least abuse it from a design standpoint.<BR>
Martin_: Yes.<BR>
jmacgill: yes! and when you think it is failing from a design stand point (e.g. poor seperation of concerns) then write a report about it!<BR>
aaime: Hum... in fact what we have now, udig design and go-1 seems to be three different beasts (but I had no time to think it over)<BR>
jgarnett: One practicle question here, where is the best place to have this email? Geotools is where all our friends live. GeoAPI seems involved at the GO-1 level, and the uDig email list is a bit lonely untill we have a release out.<BR>
Martin_: Maybe cc one those 3 lists? (when an issue concern GO-1 interfaces)<BR>
jgarnett: problem is we then have three threads to cross post between - and we are all signed up for all the lists.<BR>
Martin_: Then I would suggest the GeoAPI list when the question is about GO-1 design.<BR>
Martin_: or any GO-1 interfaces.<BR>
Martin_: I think that Polexis's guy would be happy to hear feedback.<BR>
jgarnett: And keep bothering geotools with rendering questions. Okay we can deal.<BR>
jgarnett: You have ansered a few of my questions already Martin (j2rendering would need to be extended to handle events).<BR>
Martin_: Yes.<BR>
jgarnett: And a few things I am still lost on - does GC have an event model?<BR>
Martin_: Note that GO-1 has interfaces for some event.<BR>
jeichar: Can I get my hands on what the polexis guy is doing? <BR>
aaime: J2d badly needs refactoring... I have a feeling that some things are too much separated into small classes, whilst others are just too big...<BR>
Martin_: GC has no event model, since they are mostly immutable (except for pixel values)<BR>
Martin_: Andrea, this is very true... (sad)<BR>
jgarnett: Interestesting - the main problem is trying to serve WMS as a GC.<BR>
jgarnett: It may be a bad idea, a WMS kind of has infinit details and so on.<BR>
Martin_: Polexis guy: I don't know much about this compagny, but they made GO-1 interfaces and a reference implementation which is actually Java wrappers object around ArcObject I think.<BR>
jgarnett: May warrent its own rendering pipeline in lite/j2rendering.<BR>
aaime: WMS is in fact a kind or remote renderer... it should be in the same league as LiteRenderer and j2d<BR>
aaime: (a kind of)<BR>
jgarnett: Now that is an interesting spin, I like it.<BR>
Martin_: I'm not sure that serving WMS as GC would be the nice thing to do. One important thing with GC is that GC is not a plain image with a CRS. It is more than that. It is better to see it as a matrix than as an image, i.e. it gives a signification to each pixel value.<BR>
ian: I'm confused, mostly due to iminemt need for sleep...<BR>
Martin_: This is why wrapping a JPEG image in a GridCoverage make nosence for example.<BR>
ian: but I use lite for wms <BR>
aaime: In this respect you need something that can work with different renderers... I wonder, is there a way to split out the layers from j2d and have a common manager class that can ask various layers to render themselves?<BR>
Martin_: Andrea, I would like that.<BR>
Martin_: I have the feeling that GO-1 may provides some material for that.<BR>
aaime: Ian, from the point of view of a client, the WMS is a remote renderer. Client -> uDig making map requests on Geoserver<BR>
Martin_: For example in my understanding of GO-1, 'Canvas' is what we call 'Renderer'<BR>
ian: I see<BR>
jgarnett: I like these ideas a lot, I am still trying to keep up (too many ideas, and I am not sleepy).<BR>
Martin_: and 'Graphics' is what J2D call RenderedLayer. Note that there is many Graphics subclass, like we have many RenderedLayer subclasses.<BR>
Martin_: For example GraphicsScaledImage is a little bit the equivalent of RenderedGridCoverage (except that it work with plain RenderedImage instead of GridCoverage).<BR>
aaime: Turning Lite into something that renderers just a layer and leave the map composition to something else if obviously easy<BR>
jgarnett: You guys are idea machines, I would like to lock you up in your own little IRC when you are both awake and jessie and I have had a chance to prepair.<BR>
Martin_: Well... the problem is that we need a little bit of time in order to try the idea...<BR>
aaime: Sorry, but I'm usually busy... I can barely manage to keep up with the mails (and try to complete that fid-exp branch)<BR>
aaime: (wink)<BR>
jgarnett: Can I help with the fid-exp branch aaime, you are more useful to jessie then me right now.<BR>
ian: sorry I'm going to have to go to bed - I'll check the logs<BR>
ian left the room (quit: ).<BR>
<FONT COLOR="#7d26cd" sml="IRC"><FONT SIZE="2">(14:28:59) jgarnett:</FONT> Still it sounds like we have a bunch of clear directions from the group, look into Go-1, consider treating WMS in just the same manner as J2renderer and do composition elsewhere.<BR>
aaime: Only the Oracle data source needs to be fixed. I have Oracle installed, and I've started to read the docs... for the moment I guess we can do nothing more than design, since things are quite far from any decent state...<BR>
jgarnett: We can run with that for this week.<BR>
groldan: I'm going to bed too, let the getView question to some caritative soul on the email list<BR>
groldan: bye all<BR>
groldan left the room (quit: "ChatZilla 0.9.63b 1.6/20040206").<BR>
<FONT COLOR="#b22222" sml="IRC"><FONT SIZE="2">(14:29:30) jmacgill:</FONT> time for me to head home<BR>
jgarnett: Darn getView had an easy answer (Query has taken most of its job away).<BR>
jgarnett: And talking about metadata always puts them to sleep - I was going to steal the Filter implementation.<BR>
jgarnett: Did we want to talk about getView?<BR>
aaime: Which is what? The ability to perform joins?<BR>
jgarnett: No<BR>
aaime: Then what?<BR>
jgarnett: the ability to have a derived query (where you can rename typeName, and the attribute names)<BR>
jgarnett: Although maybe he did mean the ability to do joins ...<BR>
aaime: Then lets see his e-mail on the mailing list (smile)<BR>
jgarnett: I am checking out dataStore.getView() that is what he was talking about<BR>
jgarnett: I wrote it as a proposal ages ago when we still had FeatureType kicking around for query purposes.<BR>
aaime: As far as the udig design is concerned, having a couple of image buffer per layer won't scale much in my opinion... (at least for common screens)<BR>
jgarnett: Not sure I understand?<BR>
jgarnett: J2d and JUMP both keep image buffers for each "layer"<BR>
aaime: j2d does not<BR>
jgarnett: Hrm I thought it did?<BR>
aaime: Jump does, and it's slow because it uses BufferedImages instead of VolatileImages that are kept in the graphics card memory<BR>
Martin_: J2D can keep image buffer.<BR>
aaime: The latter allows for accelerated drawing and fast image composition, but the graphics card memory is limited<BR>
aaime: J2D can but usually we don't use them, right? (in MapPane, I mean)<BR>
jgarnett: Having two is a bit of a head fake, we were thinking of an additional band for selection.<BR>
jeichar: can jai use volatile images?<BR>
Martin_: Yes, but the API is there.<BR>
Martin_: No JAI can't use VolatileImage<BR>
aaime: I guess not but I'm not sure<BR>
Martin_: But it is not necessary.<BR>
jgarnett: Found what getView is about:<BR>
Martin_: I mean, VolatileImage is not for computation purpose.<BR>
jgarnett: public FeatureSource getView(Query query) throws java.io.IOException<BR>
aaime: Yes, it's for fast drawing<BR>
Martin_: More about J2D: It lets you choose about BufferedImage or VolatileImage. And using buffer in J2D is just one method call away<BR>
jgarnett: seems to be a convience method for having a FeatureSource restricted by a provided Query. When that Query provides reprojection etc.. life becomes interesting.<BR>
jeichar: hmmm. SO j2d normally uses the stored geometry for fast panning, not the buffered images?<BR>
aaime: Martin, this is one thing that in my opinion should be left to some other class<BR>
jgarnett: It is a good idea - I would call it getFeatureSource( Query ) and save getView( ... ) for joins later.<BR>
Martin_: rendered.setOffscreenBuffer(ImageType.VOLATILE, 100, 200) or something like that will automaticall buffer all layer with z value between 100 and 200, no matter how many layer there is.<BR>
Martin_: Yes, J2D use stored geometry for fast panning.<BR>
Martin_: But if a selection layer changed without any change in the layer under it, the buffered image is used for the layers under the selection layer.<BR>
jeichar: interesting... <BR>
aaime: Which is a good idea, I just question the fact that it should be in the j2d class (I mean, this logic is independent on how you renderer the data)<BR>
Martin_: Andrea, yes we can investigate for a way to refactor buffering in an other class. We can put that on a TODO list.<BR>
aaime: it could be used with layers rendered with lite or with a wms with no change, no?<BR>
Martin_: There is a reason why it is on the Renderer class right now:<BR>
jgarnett: Do we still have enough people for a vote on getView?<BR>
Martin_: The content of VolatileImage can be lost at any time.<BR>
jeichar: So you have to check if the VolatileImage is available everytime you want it and if not rerender.<BR>
Martin_: So with buffering management right into Renderer, it is easier for the renderer to detect when the VolatileImage content has been lost, and redo the drawn immediately instead of finishing what it have started before redoing it again.<BR>
aaime: I know... but if you leave image composition to another class you can check the VolatileImage state before starting to render another layer<BR>
Martin_: I mean the VolatileImage content may be lost at the very precise them where the rendering is in process...<BR>
Martin_: So the Renderer checks often if the VolatileImage still valid.<BR>
Martin_: Andrea, yes.<BR>
Martin_: Lets put that on a TODO list.<BR>
aaime: checks often means it does it also in the paint method of a rendered layer? Guess not?<BR>
Martin_: No<BR>
Martin_: Actually "check often" means before each RenderedLayer.<BR>
Martin_: Which is not that often, I admit.<BR>
aaime: So again it's something implementation independent, if we end up having interfaces for rendered layers that could be implemented by j2d, lite and wms<BR>
Martin_: Agree.<BR>
aaime: (uhm... wms would be some kind of a group of layer thought...)<BR>
jgarnett: yes wms is always evil<BR>
aaime: Hum... too late here, need to get to sleep... can we recap this a bit with a mail message on the list and go on there?<BR>
Martin_: Fine for me...<BR>
jgarnett: um getView( Query )?<BR>
Martin_: I would not be of much help for getView I'm afraid...<BR>
aaime: Jody, mailing list and next week for that too? I'm falling (wink)<BR>
jgarnett: .. sigh<BR>
jgarnett: Thanks so much aaime.<BR>
jgarnett: and _martin.<BR>
jgarnett: I am afraid I have left everyone with a broken build after that module merge - it will be a fun week.<BR>
aaime: There is no reason we cannot discuss view on the mailing list and vote there too.<BR>
jgarnett: I suppose you are right, I am used to votes being done on irc<BR>
aaime: Bye everybody, I'm really going now.<BR>
aaime left the room.<BR>
<FONT COLOR="#2f4f4f" sml="IRC"><FONT SIZE="2">(14:49:37) Martin_:</FONT> I will go soon too.<BR>
jgarnett: I missed the first part<BR>
Martin_: Thank Jody for all yours great work (the module merge and everything)<BR>
jgarnett: can someone email me the logs?<BR>
Martin_: I missed the first part too.<BR>
jgarnett: Am glad you like it martin - my first tough PMC thing.<BR>
jgarnett: I will save what I have<BR>
Martin_: I was hopping this module merge for a long time.<BR>
Martin_: I will go now. By all<BR>