Skip to end of metadata
Go to start of metadata

Image metadata, sample dimensions, ISO 19123 status.

[31/08/2005 07:10] =-= Topic for #geotools is ``GC''
[31/08/2005 07:10] =-= Topic for #geotools was set by Jody_ on mercredi 31 août 2005 07:02:09
[31/08/2005 07:10] <bnordgren> http://docs.codehaus.org/display/GEOTOOLS/Second+IRC+Meeting
[31/08/2005 07:10] <simone> I guess we are waiting for martin...
[31/08/2005 07:10] <bnordgren> Yup.
[31/08/2005 07:10] <Martin> I'm here.
[31/08/2005 07:10] <simone> ops
[31/08/2005 07:10] <simone> here he is!
[31/08/2005 07:10] <bnordgren> Eggsellent
[31/08/2005 07:11] <bnordgren> So...What's first here...
[31/08/2005 07:11] <Martin> Sorry for being late...
[31/08/2005 07:11] <bnordgren> We were late too.  No problem
[31/08/2005 07:11] <bnordgren> First thing is: new people.  Who's been ensnared since the last meeting?
[31/08/2005 07:12] <bnordgren> Are there any of them here?
[31/08/2005 07:12] <bnordgren> Ok.  Sounds like 1] no one; and 2] no.
[31/08/2005 07:13] <bnordgren> Simone, can you summarize what you've been up to since we last met?
[31/08/2005 07:13] <simone> ok
[31/08/2005 07:13] <simone> I have been inspecting the option of integrating
[31/08/2005 07:13] <Martin> As a side note, a (very initial) set of ISO 19123 is documented here: http://geoapi.sourceforge.net/pending/javadoc/index.html
[31/08/2005 07:13] <simone> plugins inside ImageIO directly
[31/08/2005 07:14] <simone> using my small (in)famous Grib library
[31/08/2005 07:14] <simone> trying to geto confident with IIOMetadata and IIOMetadataFormat 
[31/08/2005 07:15] <simone> and to understand the limits of this mechanism with respect to XML-SCHEMA
[31/08/2005 07:15] <Jody_> Um can someone give me some background on IIOMetadata? Is this like Citaion and friends? Dublin core ...
[31/08/2005 07:16] <Martin> IIOMetadata is part of J2SE (so it is not our own API).
[31/08/2005 07:16] <Martin> In my understanding, it is basically a XML tree.
[31/08/2005 07:16] <Martin> bundled in images.
[31/08/2005 07:16] <Martin> We can put whatever we want in it. Actually, the content of an IIOMetadata is image format-dependent.
[31/08/2005 07:16] <simone> I started to write something on the wiki page here http://www.geotools.org/J2SE+ImageIO+in+2D
[31/08/2005 07:17] <Martin> However, J2SE provides a mechanism for translating an IIOMetadata from one format to an other.
[31/08/2005 07:17] <Martin> (Thanks Simone)
[31/08/2005 07:17] <simone> (transcoding)
[31/08/2005 07:18] <Jody_> Intereting take on a type system there with IIOMetadataFormat ...
[31/08/2005 07:18] <Martin> So it is possible to defines a kind of "standard" IIOMetadata format to be understood by Geotools.
[31/08/2005 07:19] <simone> exactly!
[31/08/2005 07:19] <simone> if you look at the page I  mentioned above
[31/08/2005 07:19] <simone> you can see the concept of XML metadata
[31/08/2005 07:19] <simone> and XML tree
[31/08/2005 07:20] <simone> basically I made a very small ImageIO plugin that reads a set of grib files and produces a 5D cube
[31/08/2005 07:20] <simone> and provide an XML tree as a description of its metadata in a format I specified (it is fairly simple)
[31/08/2005 07:21] <Jody_> Wonder if we could find out what the JPEG2lk types did, they were going to standardize stuffing GML3 into an image format
[31/08/2005 07:21] <Jody_> (to capture CRS etc...)
[31/08/2005 07:22] <Martin> Yes. It was my proposition to adopt at least a subset of the "GML in JPEG 2000" specification as our standard IIOMetadataFormat.
[31/08/2005 07:22] <normanbarker> a version of this is in gdal
[31/08/2005 07:22] <Jody_> (okay so I am just stating the obvious - got it ;-) )
[31/08/2005 07:23] <normanbarker> I am also working a lot on Jpeg2000
[31/08/2005 07:23] <bnordgren> Jpeg2K has a lot of fluff we don't need, but it's core is pretty sound.  Supporting the entire thing looks pretty painful 
[31/08/2005 07:23] <simone> I think we are a step back of that though
[31/08/2005 07:24] <simone> from my point of view
[31/08/2005 07:24] <simone> the problem right now is
[31/08/2005 07:24] <simone> how can we bend IIOMetadata to our needs
[31/08/2005 07:25] <simone> since if we followed ImageIO rules strictly we would not be able to leverage any quite complex XML-SCHEMA
[31/08/2005 07:25] <Jody_> Thanks for answer my question, we should probably head back to that agenda: http://docs.codehaus.org/display/GEOTOOLS/Second+IRC+Meeting
[31/08/2005 07:25] <bnordgren> Simone, perhaps I should look at your page, but how do you describe a 5D cube in terms of a CRS?  All of the CRS definitions seem to be limited to 1,2,3D + time separate, but no "sample axis"
[31/08/2005 07:25] <simone> as almost everybody pointed out in the comments at the end of the page above
[31/08/2005 07:26] <simone> this is one of the other problems I see here, which means what we want to describe really about a coverage, just the 2D crs of a widedr set of metadata?
[31/08/2005 07:26] <simone> just to set up an order
[31/08/2005 07:26] <simone> I would first discuss the IIOMetadata approach
[31/08/2005 07:27] <bnordgren> I think we want to support fully 3D CRS, 2D+1D CRS, and all of these +time.  
[31/08/2005 07:27] <simone> then what standard metadata set we want to use (GMLinJPEG2K, xml/gml)
[31/08/2005 07:27] <Martin> So agenda 1) IIOMetadata 2) Axis (and we should fit the agenda item at http://docs.codehaus.org/display/GEOTOOLS/Second+IRC+Meeting there too)?
[31/08/2005 07:27] <simone> (etc...)
[31/08/2005 07:27] <simone> cool
[31/08/2005 07:28] <simone> we can add something more in the followinbg...
[31/08/2005 07:28] <simone> that is my suggestion of course
[31/08/2005 07:28] <Martin> Since we are already talking about IIOMetadata, I suggest to continue on that path.
[31/08/2005 07:29] <Martin> In my understanding, one difference between IIOMetadata and "GML in JPEG 2000" is that IIOMetadata can stores Java objects (it doesn't have to be plain text).
[31/08/2005 07:29] <bnordgren> Yes.  Sorry I get distracted as I pop out to type notes.
[31/08/2005 07:29] <simone> IIOMetadata itself is a foggy issue
[31/08/2005 07:29] -->| andresco (n=Abaco@200.74.148.154) has joined #geotools
[31/08/2005 07:29] <simone> rules for it say that you cannot store text
[31/08/2005 07:30] <simone> but I did it
[31/08/2005 07:30] <--| andresco has left #geotools
[31/08/2005 07:30] <simone> and it worked
[31/08/2005 07:30] <bnordgren> So do we want to follow the rules that not even Sun is following or
[31/08/2005 07:30] <simone> the point is that
[31/08/2005 07:30] <bnordgren> do we want to violate them and be rebels?
[31/08/2005 07:31] <Martin> I'm a little bit surprised here: how a set of metadata can said that we can't store text?
[31/08/2005 07:31] <Martin> I mean, which rule said that we can't store text?
[31/08/2005 07:31] <simone> we can force a IIOMetadata subclass to return a tree that violates the rules that SUN put there
[31/08/2005 07:32] <simone> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/metadata/IIOMetadataFormat.html
[31/08/2005 07:32] <simone> rule 1
[31/08/2005 07:32] <simone>  Elements may not contain text or mix text with embedded tags.
[31/08/2005 07:32] <simone> elemts may carry around text only as attributes
[31/08/2005 07:32] <simone> but if you look at the example I prepared I stored text ina DOM tree as the object value
[31/08/2005 07:33] <Martin> May reading of this rule is that an element is allowed to not contains text, not that containing text is forbidden...
[31/08/2005 07:33] <Martin> "Element may not contains text" doesn't mean "Element can't contains text" to me (but I may be wrong)...
[31/08/2005 07:34] *lilo* [Global Notice] Good evening, all. We've resolved our segfault problems with 1.0.1 and will be upgrading to a new version which should be missing those problems. The high-impact part of the upgrade will be done early morning UTC. For more information, please see http://freenode.net/news.shtml .... thanks, and thank you for using freenode!
[31/08/2005 07:35] <Martin> Actually, it bring me to the point raised above: a difference between IIOMetadata and a plain XML tree is that each element in a XML tree is a text, while an element in IIOMetadata is allowed to be a full bledged Java object.
[31/08/2005 07:35] <simone> I guess you are right, I am trying to find the guide to see if I was completely wrong (a problem less! :-) )
[31/08/2005 07:35] <Jody_> Note: DATATYPE_STRING 
[31/08/2005 07:35] <simone> DATATYPE_STRING should be for attributes
[31/08/2005 07:35] <Jody_> not text - pretty sure text means something specific to the XML hackers.
[31/08/2005 07:35] <Jody_> right ... sigh
[31/08/2005 07:36] <normanbarker> you mean CDATA
[31/08/2005 07:36] <normanbarker> ?
[31/08/2005 07:37] <bnordgren> Ok, so Simone is going to check on this text thing between now and the next meeting.  (1st entry in "Stuckee")  What's next?
[31/08/2005 07:37] <Martin> (I'm not sure what CDATA is? Unfortunatly my knolwedge of XML is a little bit minimal)
[31/08/2005 07:37] <normanbarker> two type CDATA and PCDATA
[31/08/2005 07:37] <simone> character  data
[31/08/2005 07:38] <Martin> So, it is possible to store a "real" CoordinateReferenceSystem object in an IIOMetadata without the need to dig in the full XML specification for CRS.
[31/08/2005 07:38] -->| bowens (n=brentowe@S01060004e2287d2f.gv.shawcable.net) has joined #geotools
[31/08/2005 07:38] <simone> yeah
[31/08/2005 07:38] <simone> it should be possible
[31/08/2005 07:38] <Jody_> (As a type system this is a fairly interesting contrast to the FeatureModel gabriel has been working on for GeoAPI/GeoTools)
[31/08/2005 07:38] <simone> I am doing some experiments with that in these days
[31/08/2005 07:38] <bnordgren> Is storing the whole ting desirable?  Then we have every plugin 
[31/08/2005 07:39] <Martin> I'm not sure which path is the easiest one: build a CRS object or write it down in XML.
[31/08/2005 07:39] <bnordgren> constructing CRS instead of providing metadata of which a CRS is a subset.
[31/08/2005 07:40] <Martin> CRS can be see as metadata. Whatever this metadata is provided as a CoordinateReferenceSystem object or as plain XML text can be seen as a formatting issue. IIOMetadata can stores both formats.
[31/08/2005 07:41] <simone> I would go with XML in order to isolate ImageIO plugins from geotools
[31/08/2005 07:41] <Martin> We can force one format (Object vs text), or we can let the choice to image plugin. I don't know at this stage which approach is preferable.
[31/08/2005 07:42] <bnordgren> I agree with Simone.
[31/08/2005 07:42] <Jody_> Um guys - I do have a plan for letting you not care how the metadata is stored (at an object level).
[31/08/2005 07:42] <Martin> Yes, we can go with XML (but we will need to write an XML parser for CRS). Note that providing a CoordinateReferenceSystem object can still keep plugin isolated from Geotools, since CoordinateReferenceSystem is a GeoAPI interface.
[31/08/2005 07:43] <simone> that is tru
[31/08/2005 07:43] <simone> *true*
[31/08/2005 07:43] <Jody_> Agreed martin, dumping XML randomly throughout an API does not help.
[31/08/2005 07:44] <bnordgren> I don't think storing XML as text in the file was ever in scope.  
[31/08/2005 07:44] <Martin> Thanks Jody. Does peoples have some suggestion about what should be our politic here: ask for CoordinateReferenceSystem in IIOMetadata, ask for text, or lets the choice to plugins?
[31/08/2005 07:44] <bnordgren> I thought if we were going to harness the GML3.1.1 schema,  
[31/08/2005 07:45] <bnordgren> it would just be implemented as the IIOMetadataNode objects.
[31/08/2005 07:45] <bnordgren> Format in file left unspecified.
[31/08/2005 07:45] <bnordgren> o
[31/08/2005 07:45] <Jody_> I would define the model you want at the API level, and leave the individual implementations GIF, JPEG, to map in and out of their own metadata support. You can have a set of guidelines to help 
[31/08/2005 07:46] <Martin> Agreed. Asking for CRS in text (or as object) doesn't means that it have to be stored as text in the image format.
[31/08/2005 07:46] <Martin> As jody said, is it plugin's job to maps the image internal format to our "standard" IIOMetadataFormat.
[31/08/2005 07:47] <bnordgren> (Martin: I vote for a DOM tree which describes CRS).
[31/08/2005 07:48] <bnordgren> Lest we get too distracted with CRS: current; there may need to be some work done on CRS to fully describe trhe dataset axes.  Might not want to tie ourselves to the OGC interfaces so quickly.

[31/08/2005 07:49] <Martin> Stephane Fellah as some suggestions about axes. We can go back on this topic when we will reach this agenda item.
[31/08/2005 07:49] <bnordgren> What is the consensus?  Shall we defer for the moment?
[31/08/2005 07:49] <Jody_> Just to backup, are you expecting end-user client code to use IIOMetadata? I would hope they just ask for the CRS (and eveything else is magic?)
[31/08/2005 07:50] <Jody_> I already have 4 metadata systems in geotools, I don't need another.
[31/08/2005 07:50] <Martin> Yes. I see IIOMetadata as a find of "transfert" format between Image I/O plugin and a single GridCoverageExchange instance.
[31/08/2005 07:50] <bnordgren> To use a J2SE ImageIO Plugin, one does not necessarily have to be
[31/08/2005 07:50] <bnordgren> spatially cognizant.
[31/08/2005 07:50] <Martin> (typo: as a kind of...)
[31/08/2005 07:51] <bnordgren> For our use, of course, we'd harness the spatially aware 
[31/08/2005 07:51] <bnordgren> acpects of it.
[31/08/2005 07:51] <Martin> IIOMetadata would not need to be know outside Image I/O plugin writter and GridCoverageExchange implementor. I expect it to be invisible outside this scope.
[31/08/2005 07:52] <bnordgren> Yes.  I expect it to be invisible outside that scope too.
[31/08/2005 07:52] <Jody_> (thanks - just checking, sorry for the distraction)
[31/08/2005 07:52] <Martin> It was a good point Jody.
[31/08/2005 07:52] <Martin> So the consensus is...?
[31/08/2005 07:53] <Martin> Continue to write down idea on http://www.geotools.org/J2SE+ImageIO+in+2D (since we don't have to take a decision immediately)?
[31/08/2005 07:53] <bnordgren> I think we should chew on it more.  
[31/08/2005 07:53] <Martin> I think too.
[31/08/2005 07:53] <bnordgren> +1 for tabling it and letting Simone frolic more.
[31/08/2005 07:54] <simone> sorry guys but I am a bit lost
[31/08/2005 07:54] <Martin> ?
[31/08/2005 07:54] <simone> +1 about keep digging this
[31/08/2005 07:54] <simone> but what direction
[31/08/2005 07:54] <Martin> +1
[31/08/2005 07:54] <simone> returning objects for crs
[31/08/2005 07:54] <simone> returning xml
[31/08/2005 07:54] <simone> both?
[31/08/2005 07:55] <bnordgren> Both.  See what works, how much of a pain it is.  Abandon at first sign of too much pain.
[31/08/2005 07:55] <Martin> 1) what is the most appropriate choice between storing a CRS as a reference to a CoordinateReferenceSystem object, or as XML nodes (plain text).
[31/08/2005 07:55] <bnordgren> :)
[31/08/2005 07:56] <simone> (I already sent an email to Brian BurkHalter, the JAI's father) about strings and metadata let's see what he tells me)
[31/08/2005 07:56] <simone> ok
[31/08/2005 07:56] <simone> now everytning is clear!
[31/08/2005 07:56] <simone> :-)
[31/08/2005 07:56] <Martin> (I don't know if JAI and Image I/O have the same father, but lets see)
[31/08/2005 07:56] <bnordgren> Excellent.  Now.  Image CRS in GML3.1.1.
[31/08/2005 07:57] <bnordgren> Simone, you been digging into this too?  Alex has been 
[31/08/2005 07:57] <Martin> 2) Determine which subset of "GML in JPEG 2000" we should use, if we should use it.
[31/08/2005 07:57] <normanbarker> Sorry, I am going to have to log off, Simone please assign me some work
[31/08/2005 07:57] <normanbarker> thanks
[31/08/2005 07:57] <bnordgren> coming up to speed on it and may be able to have a 
[31/08/2005 07:57] <simone> (in italy we say the mother is always  known the father is not!)
[31/08/2005 07:57] <bnordgren> Woo hoo!!  A Stuckee!
[31/08/2005 07:57] <simone> (ok norman!)
[31/08/2005 07:58] <Martin> Thanks for comming Norman.
[31/08/2005 07:58] <simone> (night)
[31/08/2005 07:58] <simone> I have been digging quite a ot of specifications
[31/08/2005 07:58] <simone> trying to figure out what we need/want
[31/08/2005 07:58] <bnordgren> (...may be able to help out.)
[31/08/2005 07:58] |<-- normanbarker has left irc.eu.freenode.net ("Chatzilla 0.9.68.5 [Firefox 1.0/20041111]")
[31/08/2005 07:59] <simone> the first thing that comes into my head about this topic is
[31/08/2005 07:59] <simone> that image crs in gml 3.1.1
[31/08/2005 08:00] <simone> does not take into account time and third dimension
[31/08/2005 08:00] <simone> but since it talks about images
[31/08/2005 08:00] <simone> it completely ignores 3d, 4d, and 5d
[31/08/2005 08:00] <Martin> I admit that I haven't looked at this one yet, and I should do it soon... Is this specification available on the public OGC portal?
[31/08/2005 08:00] <simone> I do not think it wast we need
[31/08/2005 08:00] <simone> at least we need more 
[31/08/2005 08:01] <Martin> So we are reaching the "axis" agenda item?
[31/08/2005 08:02] <bnordgren> I think the main problem is ISO19111.  It's only spatiotemporal.  No Category axis.
[31/08/2005 08:02] <Martin> It is true that ISO 19111 is mainly about spatio-temporal domain.
[31/08/2005 08:03] <Martin> However, the category axis may live in a different space.
[31/08/2005 08:03] <Martin> I mean, in the legacy OGC GridCoverage specification, there is a distinction between "spatio-temporal" dimension and "sample" dimension.
[31/08/2005 08:04] <Martin> The CRS object is only about axis in the spatio-temporal dimension.
[31/08/2005 08:04] <Martin> The sample dimensions (org.opengis.coverage.SampleDimension) is an other kind of axis.
[31/08/2005 08:04] <Martin> The sample dimensions are represented by a different set of interfaces than the spatio-temporal domains.
[31/08/2005 08:04] <bnordgren> You can CompundCRS it all you want, but you're limited to 4D + bands.
[31/08/2005 08:04] <simone> that is true, but if have taken a look at ISO19123
[31/08/2005 08:04] <simone> bands are called range
[31/08/2005 08:04] <simone> and are not part of crs info
[31/08/2005 08:04] <simone> (I kind of agree with that view)
[31/08/2005 08:04] <bnordgren> "Bands" are indeed a value.  You can't index with them.
[31/08/2005 08:04] <bnordgren> The definition of DirectPosition is deceptive.  It looks like it's 
[31/08/2005 08:04] <bnordgren> n-D, but there's no CRS which can describe nD, and DirectPosition 
[31/08/2005 08:04] <bnordgren> is an index into a CRS space.
[31/08/2005 08:05] <bnordgren> Martin, are the sample dimensions part of the new OGC framework?  
[31/08/2005 08:07] <Martin> I'm not yet completly sure to understand ISO 19123 correctly. It is possible that what OGC was used to call "SampleDimension" is a "DomainObject" (or "Domain", I'm not sure) in ISO 19123.
[31/08/2005 08:07] <Martin> But I may be wrong. I need to clarify my understanding of ISO 19123.
[31/08/2005 08:08] <Martin> Whatever DirectPosition and CoordinateReferenceSystem is up to the task or not depends on whatever we want to merge "spatio-temporal" and "sample" dimensions or not.
[31/08/2005 08:08] <bnordgren> My understanding, which also may be wrong, is that the DomainObject is 
[31/08/2005 08:08] <bnordgren> some geometry defined by ISO191??.  These in turn have a CRS in which they are 
[31/08/2005 08:09] <bnordgren> expressed.
[31/08/2005 08:09] <bnordgren> The coverage of 19123 seems to be a unified method of data access 
[31/08/2005 08:10] <bnordgren> for features and coverages.
[31/08/2005 08:10] <simone> Shouldn't be Range the equivalent of the old SampleDimension?
[31/08/2005 08:10] <bnordgren> (features and raster data.,.. oops)
[31/08/2005 08:11] <Martin> Yes. I'm taking my word back (reading again, I believe that Bryce and Simore are right).
[31/08/2005 08:11] <simone> which basically is a record of AttributeValues
[31/08/2005 08:11] <simone> domain object is for spatiotemporal
[31/08/2005 08:11] <Martin> It may be that SampleDimension in ISO 19123 are actually AttributeType.
[31/08/2005 08:11] <simone> I think...
[31/08/2005 08:11] <simone> (I propose a third item about adopting ISO123)
[31/08/2005 08:11] <Martin> Yes Simone, I think that you are right (thank for correcting me).
[31/08/2005 08:12] <Jody_> We are looking at fixing up the "AttributeType" system right now
[31/08/2005 08:12] <Jody_> (that is why bowens is here)
[31/08/2005 08:12] <bnordgren> However, this still leaves us with the fact that you index with up to 
[31/08/2005 08:12] <Martin> (Typo: "It may be that SampleDimension in ISO 19123 are actually FeatureType". Well, I'm not sure if I'm not mixing attribute and feature as well...)
[31/08/2005 08:12] <bnordgren> 4D, and retrieve a set of values based on that index.
[31/08/2005 08:12] <bnordgren> Fragmented.
[31/08/2005 08:12] <bnordgren> Bad.
[31/08/2005 08:13] <simone> what you mean exactly with this, can you provide an example? (I am slow, sorry...)
[31/08/2005 08:14] <bnordgren> You index a coverage with a DirectPosition (which has an associated CRS.)
[31/08/2005 08:14] <bnordgren> The CRS has up to 3D + time.
[31/08/2005 08:14] <bnordgren> The coverage returns a RangeValue (FeatureType).
[31/08/2005 08:14] <bnordgren> If one puts the 5th dimension in as a Range.
[31/08/2005 08:15] <bnordgren> you can't select by range with the Coverage interface,
[31/08/2005 08:15] <bnordgren> even if you have a 5D array in memory.
[31/08/2005 08:15] <simone> well, taking as an example the old fashion
[31/08/2005 08:16] <simone> the final step would have been a band select
[31/08/2005 08:16] <simone> we could convert that to select attributes in a range
[31/08/2005 08:16] <simone> there should not be any substantial changes
[31/08/2005 08:16] <simone> what do you think?
[31/08/2005 08:17] <bnordgren> I think that's the difference between nD and 5D. :) 
[31/08/2005 08:17] <simone> (it is contemplated in the deferred execution model)
[31/08/2005 08:17] <bnordgren> But yes, that's an option if we only need 5D right now.
[31/08/2005 08:17] <simone> for the moment (for me.. ) 5D is more than enough!
[31/08/2005 08:17] <simone> :-)
[31/08/2005 08:18] <bnordgren> :)
[31/08/2005 08:18] <Martin> Note: axis is exactly one of ISO 19123 issue that Stephane Fellah raised.
[31/08/2005 08:18] <bnordgren> I also observe that if we want to do this "generically", for nD, 
[31/08/2005 08:19] <Martin> For information, Stephane Fellah is the PCI engineer who edited the legacy OGC specification, before ISO 19123 came out.
[31/08/2005 08:19] <bnordgren> we got a lot more work cut out for us than 5D, and I only need 5D too. :) 
[31/08/2005 08:19] <Martin> At the following page:
[31/08/2005 08:19] <Martin> http://geoapi.sourceforge.net/pending/javadoc/overview-summary.html
[31/08/2005 08:19] <bnordgren> Did Stephanie offer a suggestion to extend the Axes descriptions?
[31/08/2005 08:19] <Martin> there is actually two set of Coverage interfaces.
[31/08/2005 08:19] <bnordgren> (sorry, impatient)
[31/08/2005 08:19] <Jody_> To back up for me that is working through these ideas a bit slower, the CRS has the metadata you need about the different raster layers
[31/08/2005 08:19] <Jody_> so you can do later processing (like a band select for display?)
[31/08/2005 08:20] <Martin> org.opengis.coverage.* contains the straight translation of ISO 19123 we are doing right now.
[31/08/2005 08:20] <Jody_> Range info is needed so you can make your RasterSymbolizer style correctly?
[31/08/2005 08:20] <bnordgren> CRS does not have band information, but j2SE ImageIO will contain the number of 
[31/08/2005 08:20] <bnordgren> bands.
[31/08/2005 08:21] <bnordgren> One thing that the "band" model in IIO lacks is 
[31/08/2005 08:21] <Martin> (continuing). Stephane Fellah proposal are com.owsx.* interfaces.
[31/08/2005 08:21] <bnordgren> heterogeneous data types.
[31/08/2005 08:24] <simone> going a step back here but has anybdy taken a look at this paper https://portal.opengeospatial.org/files/?artifact_id=8826
[31/08/2005 08:24] <simone> Imagery Metadata
[31/08/2005 08:24] <bnordgren> Sorry. Typing notes.   Please continue.
[31/08/2005 08:24] <simone> it contains some attempt to define metadata for Coverages
[31/08/2005 08:24] <simone> and it is quite interesting
[31/08/2005 08:25] <simone> it also makes use of ISO 19115 (metadata spec)
[31/08/2005 08:25] <simone> providing a very complete set of metadata for a coverage
[31/08/2005 08:25] <simone> since at the beginning we talked about 
[31/08/2005 08:25] <simone> stream metadata nd image metadata
[31/08/2005 08:26] <simone> that spec would be good to indicate a way to go with stream metadata
[31/08/2005 08:26] <simone> which shold include much more than only crs
[31/08/2005 08:26] <simone> info
[31/08/2005 08:26] <simone> but also
[31/08/2005 08:26] <simone> info about z-level, temporal extent , bands, etc...
[31/08/2005 08:27] <Martin> I was not aware of this one (it seems quite recent). Downloading it right now...
[31/08/2005 08:27] <simone> My concern about Image CRS in GML 3.1.1 is that it focuses only on 2D crs and that is it
[31/08/2005 08:28] <bnordgren> 2D is a bad shortcoming.
[31/08/2005 08:28] <simone> we need a way to transfer much more info than that from file format to coverage through ImageIO plugins
[31/08/2005 08:30] <bnordgren> How easy / hard is it to translate https://portal.opengeospatial.org/files/?artifact_id=8826 to 
[31/08/2005 08:30] <bnordgren> an IIOMetadataFormat?
[31/08/2005 08:30] <simone> I see another item to investigate
[31/08/2005 08:30] <simone> I can handle that too
[31/08/2005 08:30] <bnordgren> What item? 
[31/08/2005 08:31] <simone> How easy / hard is it to translate https://portal.opengeospatial.org/files/?artifact_id=8826 to an IIOMetadataFormat?
[31/08/2005 08:31] <simone> I was laready thinking about doing that
[31/08/2005 08:31] <simone> :-)
[31/08/2005 08:31] <bnordgren> Got it (Og slow.  Og need coffee.)
[31/08/2005 08:31] <Martin> I just had a quick look to this spec. At a first glance, its look like an extension of ISO 19115.
[31/08/2005 08:31] <simone> there is a new ISO spec coming out
[31/08/2005 08:32] <simone> ISO 19115-2 imagery and gridded data
[31/08/2005 08:32] <simone> which I think would what we need to describe a coverage
[31/08/2005 08:32] <simone> with a lot of details
[31/08/2005 08:32] <simone> is anybody aware of it?
[31/08/2005 08:32] <bnordgren> It's news to me.
[31/08/2005 08:32] <CIA-1> 03desruisseaux * r15556 10geotools/gt/ (13 files in 8 dirs): Bug fix in 'createTransformedShape' / Clarification in the way a GridCoverage2D convenience constructor handle axis
[31/08/2005 08:33] <simone> Martin?
[31/08/2005 08:33] <bnordgren> Martin's not paying attention.  He's working again. :) 
[31/08/2005 08:33] <Martin> I was aware that an ISO 19115 revision for image and gridded data is comming, but I have not seen this specification yet...
[31/08/2005 08:33] <simone> neither have I
[31/08/2005 08:34] <simone> I hoped you had though! :-)
[31/08/2005 08:34] <Martin> (sorry for the distraction; just took advantage that the build has been repaired recently for commiting some work pending for one or two week).
[31/08/2005 08:34] <bnordgren> Ok, so do I have the "Stuckees" correct so far? 
[31/08/2005 08:35] <simone> or you could find out a way to have an early version
[31/08/2005 08:36] <Martin> I believe that the guys from Ionic software on the Geotools mailing list have one. He wrote sometime on the mailing list, but I don't know much more at this time.
[31/08/2005 08:36] <simone> good! :-)
[31/08/2005 08:36] <Martin> (Jeff is his name if I remember right).
[31/08/2005 08:36] <bnordgren> Shall we pursue a draft copy of this holy document?>
[31/08/2005 08:37] <simone> that would be absolutely great!!!
[31/08/2005 08:37] <bnordgren> Ok.  Who wants to do it? 
[31/08/2005 08:37] <bnordgren> Alex volunteer.
[31/08/2005 08:37] <bnordgren> (s)
[31/08/2005 08:38] <simone> I would like to have a copy of it if possible :-P
[31/08/2005 08:38] <bnordgren> We'll keep you in mind. ;) 
[31/08/2005 08:39] <simone> what about discussing a bit about ISO 19123?
[31/08/2005 08:39] <Martin> It is possible (just a guess) that current ISO 19115 + "Image metadata" (the spec pointed out by Simone above) give a fair overview of ISO 19115-2.
[31/08/2005 08:39] <simone> Martin? :-)
[31/08/2005 08:39] <simone> Martin you are right
[31/08/2005 08:39] <simone> that is way it would be great to take a look at that spech for Stream metadata at least
[31/08/2005 08:40] <Martin> ISO 19123: translation into Java interface is a work in progress. I got help from Wim Koolhoven recently.
[31/08/2005 08:41] <bnordgren> Ok, so we all review this and Alex is granted a temporary reprieve.
[31/08/2005 08:41] <Martin> I would said that about 2/3 of ISO 19123 interfaces are available as Java interfaces right now. However, they need revision.
[31/08/2005 08:41] <simone> Alessio would like to help you out with ISO 19123
[31/08/2005 08:42] <simone> (I would like to help too but I have no time)
[31/08/2005 08:42] <simone> (I could help a bit with revision though)
[31/08/2005 08:42] <Martin> Sure! The first step is to finish the interface creation. The second step will be to take decisions about some open issues.
[31/08/2005 08:42] <simone> norman could help too
[31/08/2005 08:43] <Martin> I can send a list of interfaces remaining to be translated.
[31/08/2005 08:43] <simone> I feel like the right way to go would be move right away to ISO 19123 instead of spending a lot of energies on packages we will migrate afterwards
[31/08/2005 08:44] <Martin> The IIOMetadata work can probably be done in parallel.
[31/08/2005 08:44] <simone> Absolutley
[31/08/2005 08:44] <simone> we want IMageIO plugins independent
[31/08/2005 08:44] <simone> therefore we should be able to work in parallel
[31/08/2005 08:44] <simone> (otherwise something is wrong!)
[31/08/2005 08:44] <simone> :-)
[31/08/2005 08:45] <bnordgren> Agreed.
[31/08/2005 08:46] <simone> Martin could drop some lines on the wiki about the ISO 19123 interfaces
[31/08/2005 08:46] -->| darkfrog (n=darkfrog@adsl-68-89-12-209.dsl.okcyok.swbell.net) has joined #geotools
[31/08/2005 08:46] <simone> like status, plans, locations
[31/08/2005 08:46] <simone> *could you*
[31/08/2005 08:47] <Martin> There is my proposal: I will post a list of interface remaining to be done on geoapi and geotools mailing list. If there is some volunter for taking some interfaces, they could let me know. Once interfaces creations are finished, we may create a wiki page for open issues, let some time for peoples to review them, and schedule a new IRC for trying to take decision on some open issue (actually for sending proposal on geoapi mailing list; peoples there will need to be involved too).
[31/08/2005 08:47] <Jody_> If you guys give me timelines I can juggle the RnD page around.
[31/08/2005 08:47] <simone> so people can jump in and start helping you out
[31/08/2005 08:47] <darkfrog> Hey guys, our group is currently using Oracle Spatial and I've been looking into GeoTools as a possible solution to help us as an alternative to Oracle's crappy MapViewer.
[31/08/2005 08:48] <Martin> Oh yes, instead of sending a mail I should create a wiki page.
[31/08/2005 08:48] <Jody_> Hi darkfog - we are in a meeting right now.
[31/08/2005 08:48] <darkfrog> oh, my bad
[31/08/2005 08:48] <Jody_> I am an oracle module maintainer - lets chat out of band.
[31/08/2005 08:49] <simone> cool martin
[31/08/2005 08:49] <bnordgren> Ok, so Martin makes a wiki page about the interface 
[31/08/2005 08:49] <simone> I have a a couple of master students who could help out on this 
[31/08/2005 08:49] <Jody_> Umm guys: Simone and I have been talking about OSSIM/JOSSIM out of band.
[31/08/2005 08:49] <simone> they need to do their master thesis
[31/08/2005 08:49] <bnordgren> progress and agrees to maintain it and harness slaves efficiently.
[31/08/2005 08:49] <simone> I can abuse of them!
[31/08/2005 08:49] <Jody_> And I think we coudl do with an update, intentions etc...
[31/08/2005 08:50] <bnordgren> Update, by all means...
[31/08/2005 08:51] <Martin> A note on my schedule: the next 3 weeks will be very busy on my side, because we have a deliverable for mid-september. I will do some GridCoverage / ISO 19123 in parallel, but should be more active in 3 weeks.
[31/08/2005 08:51] <Jody_> I seem to understand it that this API is coming together at the ImageIO level, it also seems to be a level where the OSSIM hackers are comfortable.  
[31/08/2005 08:52] <Jody_> They are wheting their appitate on udig and then hope to drop in behind your new ISO19123 interfaces when they are available.
[31/08/2005 08:52] <Jesse_Eichar> THey are implementing the current CRS and GridCoverage interfaces now.
[31/08/2005 08:53] <Jody_> (Is this of interest, or do you guys know all this already?)
[31/08/2005 08:53] <bnordgren> I don't know it.
[31/08/2005 08:53] <simone> I knes some of it
[31/08/2005 08:54] <Jody_> Jesse_Eichar does JOSSIM completly hide GDAL, some talk was mentioned of grabing SWIG for a GDAL wrapper
[31/08/2005 08:54] <simone> (martin could you then drop the wiki page asap therefore people can start helping right away?)
[31/08/2005 08:54] <Jesse_Eichar> completely hides.  but we don't know how complete it is.
[31/08/2005 08:54] <Martin> Will create the wiki page today.
[31/08/2005 08:54] <simone> My concern about ossim + gdak behind coverage
[31/08/2005 08:55] <simone> is that in the structure we are planning
[31/08/2005 08:55] <simone> would be
[31/08/2005 08:55] <Martin> Do they have a web page monitoring their progress?
[31/08/2005 08:55] <simone> gdal--> ossim-->ImageIO --> Coverage
[31/08/2005 08:55] <simone> (I am not an ossim expert)
[31/08/2005 08:55] <Jesse_Eichar> ouch.  they are directly implementing Coverage.
[31/08/2005 08:55] <Martin> ImageIO --> Coverage is an optional step.
[31/08/2005 08:56] <simone> ah
[31/08/2005 08:56] <simone> ok
[31/08/2005 08:56] <simone> that is godd then
[31/08/2005 08:56] <Jesse_Eichar> ok good.
[31/08/2005 08:56] <simone> good
[31/08/2005 08:56] <Martin> I mean, they can implements Coverage directly if the want.
[31/08/2005 08:56] <simone> I agree 
[31/08/2005 08:56] <simone> that would be right way to go
[31/08/2005 08:56] <Martin> At Geotools, we choose to go through ImageIO Metadata in order to insulate image I/O plugin from GridCoverageExchange, but this is a design choice hiden from user eyes.
[31/08/2005 08:57] <simone> true, but Ossim developers would maybe be more than just users
[31/08/2005 08:58] <bnordgren> Well, they certainly are more than just users if they're making 
[31/08/2005 08:58] <Martin> But they are not necessarly Geotools users.
[31/08/2005 08:58] <bnordgren> plugins.  But if they've got their own chain that they're comfortable
[31/08/2005 08:58] <bnordgren> with, that may make them happy.  
[31/08/2005 08:59] <Jesse_Eichar> Is there an agenda item for discovery of coverages?
[31/08/2005 08:59] <bnordgren> Besides, they're going to incur some native code 
[31/08/2005 08:59] <bnordgren> dependencies whereas we should work on any 1.4+ JDK.
[31/08/2005 08:59] <bnordgren> (Jesse: ) there can be.  Go on.
[31/08/2005 09:02] <Jesse_Eichar> I just want them to be able to add their coverage implementatin to geotools and have it discoverable and usable with the other coverage implementations.
[31/08/2005 09:02] <simone> An another item would be talk to OSSIM guys in order to coordinate
[31/08/2005 09:02] <Martin> Coverage discovery (a.k.a. catalog) topic is a little bit inactive lately I believe. It is an important one, but I feel that it may be more active after we have resolved the metadata issue.
[31/08/2005 09:02] <simone> (item==task)
[31/08/2005 09:02] <Jesse_Eichar> OK
[31/08/2005 09:02] <bnordgren> Umm...Jesse are you talking of discovery of persisted coverages, or 
[31/08/2005 09:03] <bnordgren> of coverage implementations?
[31/08/2005 09:03] <Jesse_Eichar> implementation.  IE ways to load a given coverage.
[31/08/2005 09:03] <bnordgren> Thus far we're using the ImageIO hooks to make us discoverable.
[31/08/2005 09:04] <Jesse_Eichar> This is mostly above my head... but is the current gc and the proposed one going to be close?
[31/08/2005 09:04] <Jesse_Eichar> ok well they know something about it but they are mostly C guys so I can talk to them and see how they feel.  One of us may have to help them with that part.
[31/08/2005 09:05] <Jesse_Eichar> (that's my 2 cents)
[31/08/2005 09:05] <Martin> Discovering ImageIO plugins and discovering Coverage implementation is two different tasks.
[31/08/2005 09:06] <Martin> There is not yet a CoverageFactory in GeoAPI. There is GridCoverageExchange which is doing something close...
[31/08/2005 09:07] <bnordgren> Is CoverageFactory part of 19123?
[31/08/2005 09:07] <Martin> If the OSSIM guy are binding a GridCoverage implementation to their native library, they are probably ignoring totally J2SE Image I/O.
[31/08/2005 09:07] <Jesse_Eichar> Yes they are.
[31/08/2005 09:07] <Martin> I have not see anything like a CoverageFactory in ISO 19123. We will have to come with out own proposal for GeoAPI.
[31/08/2005 09:08] |<-- chippy| has left irc.eu.freenode.net ("Leaving")
[31/08/2005 09:08] <Jesse_Eichar> That shouldn't be too hard but I think we'll need that functionality at some point.  
[31/08/2005 09:08] <simone> ISO 19123 does not state anything about discovery
[31/08/2005 09:09] <Martin> Yes. Some kind CoverageFactory (or a redisign of GridCoverageExchange) will be part of the "open issues" to solve after ISO 19123 interfaces completion.
[31/08/2005 09:11] <bnordgren> Ok.  Updating notes.  What's next...
[31/08/2005 09:11] <Jesse_Eichar> You can mark that down as a future concern I think.
[31/08/2005 09:11] <bnordgren> GCE2.
[31/08/2005 09:12] <bnordgren> Anyone read my blithering idiocy on the wiki?
[31/08/2005 09:12] <Jody_> Yes
[31/08/2005 09:12] <Jody_> Anyone read mine?
[31/08/2005 09:12] <bnordgren> You write too much. :)
[31/08/2005 09:12] <Jody_> lol
[31/08/2005 09:12] <Jody_> In short I would like to "not" do GCE2
[31/08/2005 09:13] <Martin> Where are the wiki on GCE? I saw the one on the second IRC meeting and on axes, but I missed the one on GCE?
[31/08/2005 09:13] <Jody_> But that said your nD spatially aware J2SE ImageIO did not sound like a description of GCE in my mind.
[31/08/2005 09:13] <Jody_> In todays agenda
[31/08/2005 09:14] <Jody_> http://docs.codehaus.org/display/GEOTOOLS/Second+IRC+Meeting
[31/08/2005 09:14] <Jody_> Does Bryce's high-level synopsis meet with approval:
[31/08/2005 09:14] <Jody_>     * GCE2 is conceptually analgous to an n-Dimensional, spatially aware J2SE ImageIO.
[31/08/2005 09:14] <Jody_>     * Spatial metadata (CRS, etc.) should be communicated from plugin to client code via a standardized IIOMetadataFormat.
[31/08/2005 09:14] <Jody_>     * Operations such as spatiotemporal subsetting, band selection, etc should be communicated to plugins using extensions to ImageReadParams or ImageWriteParams.
[31/08/2005 09:14] <Jody_>     * 2D + bands case should reduce to J2SE ImageIO.
[31/08/2005 09:14] <Jody_>     * What about multiple resolutions in same file / over the same extent?
[31/08/2005 09:14] <bnordgren> I know it's here somewhere...
[31/08/2005 09:15] <bnordgren> Aha!! http://docs.codehaus.org/display/GEOTOOLS/Coverage+Support+Plans
[31/08/2005 09:16] <bnordgren> But Jody's synopsis boils it down.
[31/08/2005 09:16] <bnordgren>  (...to the essentials.)
[31/08/2005 09:17] <Jody_> (I think it is your summary, I was just hoping to carve off the top "layer" of the problem as part of the catalog interfaces
[31/08/2005 09:18] <Jody_> top layer = file "handle
[31/08/2005 09:18] <Jody_> and metadata
[31/08/2005 09:19] <Jody_> So to start - bryce? What do you mean by GCE2 ?
[31/08/2005 09:20] <bnordgren> Basically, the persistence framework for coverages.  I don't
[31/08/2005 09:20] <bnordgren> envision including persistence-and-catalog in one thing.
[31/08/2005 09:20] <Jody_> Okay - that was kind of in the origional GCE 
[31/08/2005 09:21] <Jody_> Are you shooting for something similar to a "GridCoverageStore" ?
[31/08/2005 09:21] <bnordgren> Well, if it's a 2D + bands coverage, I'm shooting for a javax.imageio.ImageReader. (or whereve it lives)
[31/08/2005 09:22] <bnordgren> (*wherever*)
[31/08/2005 09:22] <Martin> I suggest to javax.imageio.ImageReader hiden as an implementation details, even for 2D + bands coverage.
[31/08/2005 09:23] <Martin> (I mean use it under the hood, but the user would see only a GridCoverageExchange / GridCoverageStore / GridCoverageFactory...)
[31/08/2005 09:24] <bnordgren> Ok.  I'm prying myself slowly away from 
[31/08/2005 09:24] <Martin> The reason is that ImageReader creates RenderedImage objects.
[31/08/2005 09:24] <Martin> We need an additional layer for creating Coverage objects.
[31/08/2005 09:24] <Jody_> See I am trying to get rid of GridCoverageExchange as a flawed model - all the code I have seen makes use of GridCoverageReader directly.
[31/08/2005 09:24] <bnordgren> the "just use J2SE" concept.
[31/08/2005 09:24] <Jody_> (unless you guys have code you don't tell me about)
[31/08/2005 09:25] <bnordgren> Lookit my test case in Geotiff.  I used it (once).
[31/08/2005 09:26] <bnordgren> Sorry for the mind block.  
[31/08/2005 09:26] <bnordgren> Fixated on the J2SE discussion.
[31/08/2005 09:26] <bnordgren> Yes of course we need the extra layer.  We also
[31/08/2005 09:26] <bnordgren> need something for OSSIM to implement directly.
[31/08/2005 09:27] <simone> extra layer?
[31/08/2005 09:27] <Martin> The layer which returns Coverage objects.
[31/08/2005 09:27] <bnordgren> to make coverages from grid stores.
[31/08/2005 09:27] <simone> ok
[31/08/2005 09:27] <simone> but why are you saying ImaheIO plugins are only 2D+bands
[31/08/2005 09:28] <simone> we can use them to build a 5d coverage
[31/08/2005 09:28] <simone> by using a RenderedImage as a slice of the final coverage
[31/08/2005 09:28] <bnordgren> Well, the interfaces support getwidth and getheight and getBands.
[31/08/2005 09:29] <Martin> We don't use directly Image IO plugin for building a 5D coverage. We use image I/O for building 2D slice, and some external code (external to image I/O) have to assemble them in a 5D coveragE.
[31/08/2005 09:29] <bnordgren> the creation of more than that is imposing an extra layer of abstraction.
[31/08/2005 09:29] <Martin> ImageReader can produces only RenderedImage, which are 2D.
[31/08/2005 09:29] <simone> true
[31/08/2005 09:29] <Jody_> Summary: I would be happier if you guys renamed Format as GridCoverageStore - and it produced GridCoverages for you.
[31/08/2005 09:29] <simone> then the extra layer would be something like a coverage reader
[31/08/2005 09:29] <bnordgren> That would make me happy too.
[31/08/2005 09:30] <simone> which uses the properly ImageReader to read RenderedIages and to stack them somehow accordingly to the domain
[31/08/2005 09:30] <Martin> Will but that (Format --> GridCoverageStore) on the wiki page.
[31/08/2005 09:30] <Martin> (typo: will put that...)
[31/08/2005 09:30] <simone> am I having the right vision?
[31/08/2005 09:30] <Martin> I see the same way.
[31/08/2005 09:30] <simone> ok
[31/08/2005 09:31] <simone> on the same path
[31/08/2005 09:31] <simone> for ISO19123 are you still thinking about JAI as the backend?
[31/08/2005 09:32] <Martin> Yes, but this implementation details should be hidden from the interface perspective.
[31/08/2005 09:32] <Jody_> Thank! I won't trouble you with the rest of my writing then.
[31/08/2005 09:32] <simone> (maybe I am deviating from the main discussion sorry but i am getting sleepy)
[31/08/2005 09:32] <bnordgren> I was thinking that for, say, a 3D scalar coverage, the GCE 
[31/08/2005 09:32] <simone> (and slower than usual as well)
[31/08/2005 09:33] <bnordgren> would directly create a 3D coverage backed by a 3D databuffer (like multiarray2)
[31/08/2005 09:33] <Jody_> (It think we each have a different thing in mind for GridCoverageExchange - to me GCE is a service that lets you access GC information in a varity of formats and lets you convert between them)
[31/08/2005 09:33] <simone> my idea and actual reasearch is heading a different way
[31/08/2005 09:33] <bnordgren> The J2SE IIO stuff would be a special case for the 2D case (which is 
[31/08/2005 09:33] <simone> this is what I am trying to say
[31/08/2005 09:34] <simone> if we keep using jai as backend
[31/08/2005 09:34] <bnordgren> likely to be prolific: GeoTIFF, eGoJp2K)
[31/08/2005 09:34] <simone> we need to leverage its models
[31/08/2005 09:34] <simone> and we can use deferred execution at large
[31/08/2005 09:34] <--| Jesse_Eichar has left #geotools
[31/08/2005 09:34] <simone> especially with netcdf and everything
[31/08/2005 09:34] <simone> it is a matter of writing smart imageio plugins
[31/08/2005 09:35] <simone> and we will have a stack of PlanarImage instead of a multidimensional array
[31/08/2005 09:35] <Martin> For a 3D scalar, a GridCoverage can stores the values in a 3D databuffer, or it can stores the value is a stack of 2D images. Both approach are valable, and both should be allowed. Again, this is an implementation details hiden from user eyes.
[31/08/2005 09:35] <simone> planar image is fairly powerful
[31/08/2005 09:35] <simone> I agree wit that
[31/08/2005 09:36] <simone> but allowing bth seems a bit hard to me
[31/08/2005 09:36] <bnordgren> Yes, I agree that the implementation should be hidden.
[31/08/2005 09:36] <simone> hard to achieve I mean
[31/08/2005 09:36] <simone> in terms of time
[31/08/2005 09:36] <simone> and amount of work
[31/08/2005 09:37] <bnordgren> Yeah.  How does one select a slice in a manner that's independent
[31/08/2005 09:37] <bnordgren> of implementation?
[31/08/2005 09:37] <bnordgren> I guess that goes back to axes and indexing and at what level
[31/08/2005 09:37] <bnordgren> do we put the indexing?
[31/08/2005 09:38] <Martin> To me, "allowing both" means avoiding to put anything in GeoAPI interface which would force a particular implementation. In Geotools, the only implementation currently available is the "stack of 2D images" model (we don't have to implement both approach in Geotools). But a user can implements the "3D databuffer" model on its side if he wants.
[31/08/2005 09:39] <Martin> Yes, selecting in a slice bring us back to the indexing discussion.
[31/08/2005 09:39] <bnordgren> So the added layer which produces coverages performs:
[31/08/2005 09:39] <bnordgren>  * Virtual band selection
[31/08/2005 09:40] <bnordgren>  * nD Envelope translation to native format
[31/08/2005 09:40] <Martin> The model is already implementation-independant at least for space+time dimensions (3D, 4D, etc.).
[31/08/2005 09:40] <bnordgren> I guess it's not as impossible as I was first thinking... :) 
[31/08/2005 09:41] <bnordgren> ...becasue the "added layer" is the only thing in GeoAPI and IIO is totally hidden if we do decide to use it.
[31/08/2005 09:41] <Martin> yes.
[31/08/2005 09:41] <bnordgren> I've got the 2 hour meeting groggies.
[31/08/2005 09:42] <Jody_> I gotta go too.
[31/08/2005 09:42] <simone> I agree with your "allowing both" explanation
[31/08/2005 09:42] <Martin> Maybe we should stop the meeting here. I will try to put some text in the wiki.
[31/08/2005 09:43] <bnordgren> Well, it's a logical stopping point.  Who's for tabling discussion of 
[31/08/2005 09:43] <bnordgren> the deferred execution model for now?  Or do you feel like 
[31/08/2005 09:43] <bnordgren> continuing, Simone?  It's pretty late out there.
[31/08/2005 09:44] <Jody_> I gotta go, but you can put me down as interested in the "GC handle" object.
[31/08/2005 09:44] <Martin> I suggest to write down some stuff on wiki, and continue in a next IRC?
[31/08/2005 09:44] <Martin> Thanks Jody.
[31/08/2005 09:44] <bnordgren> Bye Jody.
[31/08/2005 09:44] <bnordgren> :)
[31/08/2005 09:44] <simone> I can keep writing about my experiments in the wiki
[31/08/2005 09:45] <bnordgren> I've been reading about them.  I like.
[31/08/2005 09:45] <simone> I would like to stop the meeting too
[31/08/2005 09:45] <simone> it is 1:00 am here
[31/08/2005 09:45] <simone> I am kind of tired :-)
[31/08/2005 09:45] <bnordgren> Ok, no more meeting.  I'll finish the notes and 
[31/08/2005 09:45] <bnordgren> move on to other things. :)  Good night Simone!
[31/08/2005 09:46] <simone> just out of curiosity
[31/08/2005 09:46] <simone> what do you want to discuss about deferred execution?
[31/08/2005 09:46] <simone> I can wriite more on the wiki as a basis
[31/08/2005 09:46] <bnordgren> Processing model: Grid Coverage Processor
[31/08/2005 09:46] <bnordgren>    1. Establish basic specifications, tentative starting point (discuss and add to this list):
[31/08/2005 09:46] <bnordgren>           * Should be a deferred execution model.
[31/08/2005 09:46] <bnordgren>           * Should reduce to JAI in the 2D+bands case.
[31/08/2005 09:46] <bnordgren>           * Should leverage JAI whenever possible, especially lessons learned.
[31/08/2005 09:46] <bnordgren>           * ...
[31/08/2005 09:46] <bnordgren>    2. Need to more fully flesh this out. Discuss other potential issues.
[31/08/2005 09:47] <bnordgren>           * What is necessary to specify a region of interest?
[31/08/2005 09:47] <bnordgren>           * Each plugin needs to appropriately operate on image data and georeferencing metadata.
[31/08/2005 09:47] <bnordgren>           * Is it sufficiently advantageous to develop a processing API specifically for the case where the data are gridded? Should this be a special case of a Coverage Processor?
[31/08/2005 09:47] <bnordgren>           * ...
[31/08/2005 09:47] <bnordgren> It's on the agenda no need to write it down. :) 
[31/08/2005 09:47] <Martin> Lets push the deffered execution on a next IRC.
[31/08/2005 09:48] <bnordgren> I think Simopne's going to write about it on the wiki.
[31/08/2005 09:48] <simone> ok
[31/08/2005 09:48] <Martin> Nice. Can we said that we are done for today?
[31/08/2005 09:48] <simone> i am done
[31/08/2005 09:49] <bnordgren> done.
[31/08/2005 09:49] <simone> i cannot think anymore :-)
[31/08/2005 09:49] <Martin> Thanks all for comming. I have to go back to work now (and write some wiki). Does someone have the IRC log? I can post mine but the 10 first minutes are missing.
  • No labels