- what is up
- Raster Symbolizer Proposal
- Commit rights
- military grid reference system
<simboss> 1>rastersymbolizer proposal
<aaime> Hi
<simboss> 2>commit right for adit and/or jon blower (DEWS project)
<avc_wet> hey you both
Eclesia would like to propose http://docs.codehaus.org/display/GEOTOOLS/Process+proposal but jody is not here
<avc_wet> sorry we didn't get to chat some
<Eclesia> so not this week
<avc_wet> a bit dry, that conversation
<simboss> for playing with coverage I/O interface
<avc_wet> Eclesia, lives! (Someone told me a johann had killed him)
avc_wet has changed the topic to: 1) simboss: Raster Symbolizer proposal 2) Commit rights for new blood
avc_wet has changed the topic to: 1) simboss: Raster Symbolizer proposal 2) simboss:Commit rights for new blood
avc_wet has changed the topic to: 01) simboss: Raster Symbolizer proposal 2) simboss:Commit rights for new blood
avc_wet has changed the topic to: 0) what is up? 1) simboss: Raster Symbolizer proposal 2) simboss:Commit rights for new blood
<avc_wet> simone, you can probably start whenever you want...
<simboss> (hold on sorry, telephone call, can we start with two)
<simboss> (I mean point 2 
)
<avc_wet> hey arneke, any topics you wish to discuss?
<simboss> (hello?)
<desruisseaux> yes
<desruisseaux> (I mean we still there)
<avc_wet> hey
<arneke> not really, I'll mention geoserver 1.6.1 release this week, so keep that in mind for 2.4.x
<acuster> cool
<simboss> ok back
<simboss> so 1>?
<acuster> arneke, you are going to cut a new 2.4.x?
<aaime> yep, we have to
<arneke> I was going to talk to aaime about that
<aaime> release policies
<aaime> every geoserver stable release needs a gt2 release
<acuster> you might quickly spam the list to tell us all to tread lightly on the branch
<acuster> simboss, go ahead, yeah?
<acuster> we are killing time waiting on you
<simboss> well basically
<arneke> will do
<simboss> I would like to understand martin's suggestions on the rastersymbolizer work
<simboss> in order to arrive to a common ground
<simboss> (btw I have a third topic which is 3> MGRS coordinate system)
<desruisseaux> Remove from public visibility the Category/CategoryList tha appears in the proposal.
<desruisseaux> Thats all.
<simboss> what about changing names?
<desruisseaux> No
<desruisseaux> Their purpose is too close to Category / CategoryList
<simboss> I am trying to be quite flexible here
<desruisseaux> There is a high risk of confusion, even if the name are different.
<simboss> I cannot really say the same as far as it concerns with you
<simboss> so ither you propose some alternative
<simboss> or your comment is close to useless
<simboss> I hope you can understand that
<acuster> why?
<simboss> why?
<simboss> is that a joke ?
<acuster> no, I really don't understand
<acuster> I saw a lot of code that came over from category
<acuster> I don't understand the code much since I've been elsewhere
<simboss> this might be a surprise for you
<aaime> desriusseaux, I guess the problem really boils down to wheter Simone is free to bend the Category to match teh raster symbolizer needs (current and future)
<simboss> but it is something that martin knewe at least
<simboss> from foss4g
<aaime> if not, there is not much point in dicusssing, a separte set of classes is needed
<desruisseaux> the CategoryList in the proposal contains a transform without definition of what source and target are.
<desruisseaux> It implements MathTransform1d and contains a getTransform() method without explaining what their relationship are
<aaime> because he wants transform to be free and extensible afaik
<simboss> I removed the getMathtransform
<desruisseaux> All relationship between with scale, offset, nodata and unit of measurement are wiped out.
<simboss> martin please stop
<simboss> and try to understand
<simboss> this
<desruisseaux> Ah, I didnt noticed that you removed the MathTransform...
<simboss> THIS WORK IS NOT RELATED TO THE SAMPLE_TO_GEOPHYSIC DISCUSSION
<desruisseaux> Then, what it appears to the proposal?
<desruisseaux> (typo: why?)
<simboss>
<simboss> it appears?
<simboss> let me check
<simboss> if it appears
<simboss> we have to remove that
<desruisseaux> TransformCategory
<simboss> martinm there exists a lot of transformations in the world
<simboss> and today job blower
<simboss> talked about a imple one
<desruisseaux> Yes, but you have to define them
<simboss> he wants to be able to do a logarithmic contrast stretch on float data as part of the rendering
<desruisseaux> At the very least, you must define what are the source and the target of a transform.
<simboss> the sourcec
<simboss> in this case is the definition range of the category
<simboss> and the output range is defined by the transformation itself
<aaime> Martin, I think Simone is trying to keep the transforms open ended. Saul already wants some transformations that are not included in the standard raster symbolizer?
<simboss> It is not clear to me what your objections really are
<acuster> what's the name of the branch?
<simboss> if you can formulate the objections as you have done before I can incorporate them with no problems
<simboss> if you think the names can confuse people
<simboss> I can change them
<acuster> gt-2.4.x-RS' doesn't exist
<desruisseaux> I think that at the very least the hierarchy need to be revisited. From what you just said a few line above, you are not trying to define category. You are trying to defines some kind of ColorTransformer or CategoryTransformer.
<desruisseaux> The hierarchy in your proposal is a new Category framework
<simboss> yeah category transformer could be an idea
<desruisseaux> While from what you just said above, you are looking for some kind of ColorTransform or CategoryTransformer
<simboss> even though the goal is a band transformer
<desruisseaux> Something expecting a set of category in input and giving a new set of categories in output
<desruisseaux> Not a definition of categories themselves...
<simboss> not really
<simboss> or better not only
<simboss> something that in general can help people to transform a range of values
<simboss> to other values
<simboss> via a transform
<desruisseaux> Yes I remember that you mentioned that point in email. Then you are talking about a MathTransformBuilder.
<desruisseaux> CategoryList are not MathTransformBuilder
<desruisseaux> Even if their implementation build a MathTransform, this is implementation details that could be moved elsewhere
<simboss> I am seeing your point...
<desruisseaux> if such MathTransformBuilder were defined elsewhere.
<simboss> hold on a sec, I cannot find anywhere in the proposal a mention to the sample-to-geophysics, can you tell me where you find it so that i can remove it?
<desruisseaux> I noticed that TransformCategory was a refactoring of org.geotools.coverage.Category and I remembered the talk that we had last fall where you expressed the wish to put sampleToGeophysics in an other interface, so I assumed that it was this TransformCategory class. Given that CategoryList are not supposed to be MathTransformBuilder neither ColorConverter, what else could it have been?
<desruisseaux> Now, if we want a MathTransformBuilder, this is an other story. But the API would need to be revisited.
<desruisseaux> Category contains Color and MathTransform because they piecewise a SampleDimension, which contains Color and MathTransform.
<desruisseaux> If we want a MathTransform builder, Color make no sense. It needs to be clearly separated.
<simboss> I guess that a good name for a buildere here would
<simboss> or better
<simboss> a good nome for this classes
<simboss> would
<simboss> be BandTransformer
<simboss> I see your point
<desruisseaux> I'm fine with BandTransform. But my point is also that if we have a BandTransformer and a MathTransformBuilder, they are two independant tasks and having a common parent (Category) for TransformCategory (to be used by MathTransformBuilder) and VisualizableCategory (to be used by BandTransform) seems a mix of concepts. Do we really needs to ties those two (apparently) unrelated concepts...
<desruisseaux> ...through a common super-class?
<desruisseaux> I have not looked at the remainder of the symbolizer architecture, so I can't said if it is required to tie them.
<vheurteaux> hello Sam
<samhiatt> Hey there...
<simboss> so what are you proposing exactly?
<samhiatt> Just thought I'd drop in to say hi and listen in a bit.
<desruisseaux> A MathTransformBuilder and a BandTransformer as two separated classes or interfaces (at your choice).
<desruisseaux> MathTransformBuilder API could be like that:
<desruisseaux> public void addNodataValue(double);
<desruisseaux> public MathTransform1D createLinearTransform(double scale, double offset);
<desruisseaux> The later would returns a linear transform that take in account the nodata values previously defined in a given builder instance.
<desruisseaux> If we want the ability to specify more than one linear transform for different range, the later method would need to be replaced by:
<simboss> (this would be for the sampleToGeophysics thing I assume)
<desruisseaux> Could be is we decide to refactor org.geotools.coverage.Category to use that builder.
<desruisseaux> May or may not be for the symbolizer depending of your needs.
<desruisseaux> other methods could be createLogarithmicMethod(double base)
<simboss> I need the ability to specify transformation on ranged
<simboss> ranges
<desruisseaux> (typo: createLogarithmidTransform)
<simboss> and to retain nodata vavlues
<desruisseaux> Yes, the nodata values were in the previous "addNodataValue(...)"
<acuster> in what part of the branch, is the code?
<desruisseaux> For the range, could be
<desruisseaux> public void addLinearTransform(NumberRange range, double scale, double offset);
<desruisseaux> This is basically the same than invoking category constructor and giving them to a CategoryList
<desruisseaux> except that this MathTransformBuilder is interrested only in ranges, scale, offset and nodata values.
<simboss> acuster:http://svn.geotools.org/geotools/branches/2.4.x_rs/modules/library/render/src/main/java/org/geotools/renderer/coverage/category/
<acuster> thank you
<desruisseaux> The other attributes of Category are of no interrest there.
<simboss> desruisseaux: I need some more general tough
<simboss> to do more complex transformations
<simboss> on difference pieces of a band
<simboss> some of them
<simboss> are not even well defined transformation
<simboss> like a gaussian strectch requires
<simboss> or a local histogram enhancement
<simboss> that is why the output range is left unspecified fo transform category
<acuster> a gaussian has a well defined range
<simboss> I am not saying that it does not have it in general
<simboss> I am saying that there is no need to specify it all the time
<simboss> since if you define the domain
<simboss> and the function
<desruisseaux> Well, in any case, my issue is that in order to support this need, the current proposal basically copy-and-paste org.geotools.coverage.CategoryList, thus creating an important amount of duplication. If you need the ability to create a piecewise MathTransform like org.geotools.coverage do, we need to either 1) Refactor existing org.geotools.coverage so that you can reuse its code in other...
<desruisseaux> ...situations than "sample to geophysics" transform (this would would need to be done in the referencing module, not in coverage or renderer), or 2) if we don't have the time to do so, at least keep the "copy-and-paste" privated so we can replace it later.
<simboss> I have not problems in hiding a bit this code and refactor/merge later
<desruisseaux> Then I'm fine.
<simboss> but this discussion is indeed interested
<acuster> what's the "Gray channel"?
<simboss> check sld 1.0
<simboss>
<desruisseaux> That all I wanted: if we don't have the time to refactor existing org.geotools.coverage in order to meet your needs, keep the duplication hiden from user eyes so we can refactor later.
<acuster> you don't know?
<desruisseaux> thats the reason of my earlier "no" (sorry for having looking so rude).
<simboss> are you ok with removing the interface for now
<simboss> and start a wiki page
<desruisseaux> Yes
<desruisseaux> Yes
<simboss> to capture this discussion
<desruisseaux> sure
<simboss> it would be great to be able to
<simboss> (acuster:sorry let me close this )
<simboss> specify complex transformations on single bands
<simboss> in an easy way
<simboss> we could on a way address to sample to unit once for all
<simboss> and also extend JAI a bit
<simboss> (you know well that piecewise sucks )
<simboss> acuster: rastersymbolizer allow you to pick up 1 channel from source image as gray or 3 as RGB
<desruisseaux> I agree. But then you are asking for a generic MathTransformBuilder capable to handle nodata values. The MathTransformBuilder part of this work need to be done in the referencing module.
<samhiatt> I wish I had been able to make it to this meeting on time... looks like you
<simboss> np about that
<samhiatt> 've been discussing some interesting stuff.
<simboss> actually I think it is a pretty good idea
<simboss> since at that point
<simboss> it can be reused
<simboss> anywhere
<desruisseaux> Exactly.
<simboss> even on features
<desruisseaux> Fine Are we done we topic 1?
<simboss> k, I'll work on removing the intefaces and I'llopen upa wki page for that
<simboss> sure
<desruisseaux> thanks
<acuster> what's the schedule for the work? Does it have a deadline?
<simboss> (acuster: ok?)
<simboss> the schedule is ASAP
<desruisseaux> In the main time, Simone can keep (if he wish) the duplicate Category, but we will try to keep it hiden.
<simboss> I can work something out like a builder
<simboss> and I will hide the classes at a package level
<desruisseaux> Well, I suggest to write about the timeline in the wiki page if you agree.
<simboss> k
<simboss> should we move quickly
<simboss> ?
<simboss> we are already out of time
<acuster> the next topic is yours also
<simboss> ah right
<simboss> 2>
<simboss> Jon blower
<simboss> from the DEWS and SHAVER project
<simboss> asked me about the possibility
<simboss> have commit access
<simboss> (I'd suggest under the spike dir)
<simboss> to play a bit with interfaces for coverage i/o
<acuster> why do they need to commit?
<simboss> in order to work out some interfaces
<simboss> in parallel to the proposasl
<simboss> so that we can all play with them
<simboss> and intervene as early as possible
<simboss> there are a lo of use cases to capture
<simboss> hence early collaboration
<simboss> is really important I believe
<simboss> so that everybody is happy
<acuster> seems like they should be playing on some other svn
<acuster> until such time as they know the code a bit
<simboss> no wait
<acuster> and have some code to inspect
<simboss> they would not play with the geotools code
<acuster> I'm reading JTS and I'm sick of un-documented code
<simboss> they would try and abstract
<desruisseaux> If the play only in "spike", this is not dangerous...
<simboss> from their codebase
<aaime> right acuster, let's stop open source right away
<simboss> some interfaces
<acuster> well (1) we can't give out commit rights until we work out LEGAL
<simboss> desruisseaux: you got the point
<acuster> and that's waiting on jody, who is in korea
<simboss> spike is pain free
<acuster> and we have rules for commit rights
<acuster> which we are ignoring to our peril
<simboss> but still everybody can view the work
<simboss> acuster: that's why I am asking
<simboss> is it feasible to give commit rights limited to a spike directory
<simboss> to capture an experiment?
<aaime> we can use the same rules as the community modules
<desruisseaux> Adrian has a point: if moving to OSGEO still planed, we need to have some procedure. For example would they accept to sign the copyright assignment?
<acuster> actually, make them set up an svn
<simboss> that is tied to a proposal
<acuster> that way they can learn how to do it
<simboss> ?
<acuster> and be better when they come contribute for real
<simboss> they have an svn
<simboss> but they cannot open it easiliy
<acuster> great, let's play there
<simboss> and besides
<acuster> well, start a gtexp on sf
<acuster> or some such
<simboss> they are willing to contribute
<desruisseaux> Well, just for clarification I believe that Adrian's issue is that "spike" directory is a pain when trying to bind SVN to a distributed repository like Mercurial .
<acuster> great, but willing and ready are two different things
<desruisseaux> (was just an note, maybe irrelevant)
<simboss> to summarise
<simboss> do we have a procedure for this?
<aaime> no, we don't
<acuster> for commit rights?
<aaime> I already suggested to use the one for unsupported modules
<aaime> it's the closest one to what we need
<simboss> for experimenting on spike I mean...
<acuster> spike anyone can do what they want in
<acuster> ideally under their username
<aaime> acuster, about commit rights, nobody of us signed anything either... why do you think we should stop contributions?
<acuster> aaime, contributions?
<aaime> new committers
<acuster> 1) we have well define rules for commit rights
<acuster> you are now asking to waive those rules
<acuster> I see no reason to do so
<aaime> acuster, I'm not
<simboss> me neither
<acuster> 2) we are very close to working out legal work
<aaime> for the third time, I've suggested to use the procedure to
<aaime> create a new unsupported module
<acuster> you can commit anything to spike
<acuster> anytime
<simboss> I am just trying to understand what we cacn do to ease this guys work
<acuster> no proposal required
<simboss> so acuster
<aaime> acuster, not everybody can commit to spike
<acuster> simboss is asking for commit rights, absent any code
<simboss> it is ok to give them commit rights limited to a spike directory or not? I am getting lost
<acuster> no
<aaime> so you say for spike everybody can get access? That's not among the procedures either
<desruisseaux> Adrian: could we said "we change the procedure for spike. The new procedure is now: do as for unsupported modules"?
<acuster> no
<simboss> desruisseaux: I wass about to ask that
<aaime> acuster, since when you're the PMC?
<acuster> I'm not
<acuster> I'm telling you the rules, as they exist
<acuster> you can ignore them as you wish
<simboss> guys, I do not want to ignore them I am just trying to understand
<simboss>
<aaime> there is no rule about kicking away people because we're "close" to finishing the legal stuff
<acuster> simboss, it's all in the developer's guide
<acuster> which they are required to read
<aaime> and an unsupported module for experimentation is contemplated among the rules
<simboss> I will suggest to set up a google code project for this and link it to the proposal work
<aaime> you describe what you want to do, get a +1 from a pmc member
<acuster> commit rights are not granular
<acuster> it's all or nothing
<aaime> so what
<aaime> we trust people
<acuster> that's why there were rules set up
<simboss> talk for yourself
<desruisseaux> Well... commit right could be granular. We have not setup the infrastructure for that because we are lazy, but this is something that could be done if we feel the need for it.
<aaime> whatever
<aaime> we have rules stating that one should not commit in a module without the consent
<acuster> desruisseaux, this would not be an issue if we were on hg/bzr/git
<aaime> of the maintainer
<aaime> we follow them good enough without granular rules
<aaime> on svn
<aaime> (granual premissions, sorry)
<acuster> aaime, the proposal is currently not let's revisit all our commit rules
<acuster> if you want to do that, great
<aaime> distributed versioning is not the topic of this discussion, nobody wants it besides you right now
<simboss> I think I will tell them to set up a separate project
<simboss> on google code
<desruisseaux> Yes... I see more and more the advantage of Mercurial and his friend. Soon or later I guess that this topic will come back, but it have deep implication on the way the community work.
<simboss> so that we stop fighgting
<simboss>
<acuster> seems like a great solution
<aaime> seems like the solution you wanted
<aaime> so much for a democratic appraoch
<simboss> but I guess that soon we'll have to find a way to let people play within our svn in a controlled manner
<acuster> aaime, in order to change the rules, propose that you change the rules
<aaime> I did not ask to change the rules
<acuster> aaime, don't call me names when I argue against waiving the rules
<simboss> 3>this is q quick question for you martin
<aaime> you don't understand them in the first place and it shows
<simboss> desruisseaux: I am trying to push a company to use the referencing code and drop what they have (which sucks )
<samhiatt> If I may chime in...
<simboss> but they need a MGRS projection
<samhiatt> and I recognize I am a very new uesr...
<simboss> have you ever heard of ?
<desruisseaux> heu... there is two discussion in parallel. Shall we let samhiatt express himself?
<desruisseaux> We will come back on MGRS after.
<samhiatt> but I really like the idea of granular commit access, whether enforced by permissions, or just by project rules...
<simboss> may ask to samhiatt to introduce himself?
<samhiatt> GeoTools really should push to be open to the support of any who which to help.
<samhiatt> I am working with Martin on PostGrid and will be using it to implement web services for our raster timeseries archive.
<acuster> samhiatt, we love new users. There's a long document that introduces them to the code and the community.
<acuster> samhiatt, and which explains how to do things, like get commit rights.
<samhiatt> Yes, and I love the project, which is why I decided to jump on the whole JavaGIS ship for it.
<acuster> it's really easy to do, too
<desruisseaux> Welcome
<aaime> http://docs.codehaus.org/display/GEOT/Creating+your+own+Module
<samhiatt> So, concerning "granular permissions" my opinion is that we should allow people with "sub-specialties" to commit to sub-projects, or certain areas in a sandbox.
<simboss> I agree
<acuster> samhiatt, that's one of the things that the next generation tools solve
<samhiatt> Especially if their project is of interest to the whole GT community.
<aaime> samhiatt, that really reminds somewhat of the reserved checkout model
<acuster> and, as aaime says, it's something we can do on trust fairly well
<aaime> if a person is not grow up enough to stay in the module he's been assigned until he gets
<aaime> the trust of others
<samhiatt> If our technology doesn't support it at the moment we should just trust that people will follow the rules you give them after giving them cimmit access.
<aaime> he should not get committ access at all
<aaime> and get kicked out if he does not learn
<samhiatt> yeah.
<acuster> we all agree broadly.
<samhiatt> and I doubt that would happen.
<aaime> what, getting kicked out?
<aaime> well, I don't remember of anyone randomly committing stuff without getting permissing either
<samhiatt> If there are legal issues with having their code on the same server (can we get around that by having it in a sandbox?) then we should be careful about which projects like this are granted commit access.
<acuster> simboss, why can't those two produce some code so they can simply get full rights?
<samhiatt> Aaime, yeah... I doubt the situation would arise.
<simboss> that's a matter of personal tastes I guess
<simboss> and btw
<simboss> it is something I suggested
<aaime> acuster, where is the part that says you have to commit code in order to get an unsupported module here: http://docs.codehaus.org/display/GEOT/Creating+your+own+Module?
<samhiatt> acuster: I agree with that, too...
<acuster> aaime, in the developer's guide
<acuster> how do I get commit rights
<aaime> you can start empty, work on it, and remove it?
<acuster> haven't we done this ten thousand times?
<samhiatt> I wouldn't expect commit access before showing anything.
<simboss> so that it would be easier for other contributors to actually contribute
<acuster> the bar is (1) read the guide (2) write some code (3) get someone to sponsor you
<acuster> it's about as low as it can get
<acuster> can we move on and close this meething out?
<desruisseaux> Fine for me
<simboss> +1 about move
<simboss> -1 about close
<simboss>
<simboss> 3> MGRS
<simboss>
<simboss> (this should be a quick one)
<desruisseaux> Is it an acronym for something?
<simboss> military grid reference system
<acuster> is it a modified GRS? Modified, GRS 1980
<simboss> (if I remember correctly)
<CIA-23> groldan * r29447 geotools/gt/modules/plugin/arcsde/datastore/src/main/java/org/geotools/arcsde/ArcSDEDataStoreFactory.java: improved readability in ArcSDEDataStoreFactory
<simboss> it should be a modified version
<simboss> of UTM
<simboss> or better customized
<desruisseaux> I have heard about it, but know nothing about it.
<acuster> grid or geodedic?
<simboss> that's bad news
<acuster> if it's military, they are probably geodedic for terrain following
<desruisseaux> If it is UTM with different parameter, maybe there is no need for new code. For example UTM and MTM are based on the same code (TransverseMercator), they are actually the same thing with different parameters.
<acuster> http://en.wikipedia.org/wiki/GRS80
<simboss> Ihttp://en.wikipedia.org/wiki/MGRS
<desruisseaux> So if MGRS is derived from UTM, there is a slight possibility that there is few code to write.
<desruisseaux> Looking at the URL...
<CIA-23> groldan * r29448 geotools/gt/modules/plugin/arcsde/datastore/pom.xml: removed edu.oswego for arcsde datastore, already removed from main pom as trunk is on Java 5
<desruisseaux> Wikipedia said that it is identical to UTM (except close to pole) with different labeling conventions.
<simboss> exact
<simboss> I am going to dig it a bit more
<acuster> seems interesting
<simboss> and then I will try to come back with an idea
<simboss> on how we can actually do that in geotools
<simboss> it looks feasible though, right?
<desruisseaux> Since labeling convention are not really MathTransform's job (if we want to handle that, we would need to think for some class dedicaced to labeling), sound like that we can map directly to UTM for latitudes between 80°S and 84°N. However if we want the general case (including poles), then we need some mechanism for swithing automatically the projection depending of the latitude.
<desruisseaux> This is a topic that Adrian already raised months ago
<simboss> are there any ideas on that topic?
<simboss> I mean, any thoughts for a possible solution
<acuster> we were waiting to have a real talk about it until martin
<acuster> had time to think about his redone renderer
<desruisseaux> Both projections mentioned on the wiki page (UTM and PolarStereographic) are supported in GeoTools, but as separated projection. We need some subclass of MapProjection, said "CompoundProjection", which is a compound of two other MapProjection and delegates automatically to one or the other depending on the latitude value.
<simboss> I see
<acuster> depending on "some rule"
<desruisseaux> Yes
<simboss> well, having MGRS is crucial for these people
<desruisseaux> I said "latitude" for simplication, but you are right.
<acuster> and that allows for overlapping areas
<simboss> if I convince them that we can do that
<samhiatt> * I'm gonna split... I'll try to make it on time next time and introduce myself. I hope my unsolicited opinion was helpful. 
<desruisseaux> Sure !)
<simboss> I might get some time to play with this
<acuster> ciao sam hiatt
<simboss> ciao sam
<samhiatt> cuanti sono italiani qua?
<vheurteaux> ciao Sam
<simboss> aaime and me I guess
<simboss> I think we are done guys
Weekly IRC for Monday 18 Feb 2007
-1) Free for all
0) What's going on
1) annotations on metadata
2) shapefile attribute indexing :
3) World+Image extension
acuster has changed the topic to: topics? none? meeting's over
<acuster> jody's on the way to corea
<acuster> korea?
<acuster> k maybe in the us
– aaime (n=aaime@host246-8-dynamic.60-82-r.retail.telecomitalia.it) has joined #geotools
<aaime> Hey
<acuster> hey andrea
<acuster> nothing much is going on but I wanted to ask you about the date stuff I saw you committed
<aaime> sure
<acuster> can you give us some info? why didn't you use the new stuff in the JSR?
<aaime> sorry?
<aaime> those are just filter functions
<acuster> dates are terribly hard to do right
<aaime> what jsr?
– acuster goes hunting
<aaime> acuster, you seem to be quite off the mark?
<acuster> no idea
<aaime> they are just DateFormat integrations into ogc filter
<aaime> you can use them as expressions in an SLD
<acuster> so you parse different date formats?
<aaime> you specify the format
<acuster> can I specify the system? eg the amharic calandar (just now 2000, 13 months) ?
<aaime> <ogc:Function name="dateParse"><ogc:Literal>yyyy-mm-dd</ogc:Literal><... expressions with the actual string to parse></ogc:Function>
<aaime> ah no, that is not supported
<acuster> cool
<aaime> feel free to add a new filter function that has 3 params and allows for that
<acuster> someday in the far, far future
<aaime> sure, np
<acuster> in the meantime I wanted merely to have an inkling of what was in the library
<aaime> whoever really needs that first will add it
<acuster> calandars make me nervous
<desruisseaux> DateFormat wrapped in filter sound nice - should support different calendar like Adrian mentionned. From the JIRA topic, I was unsure if it was about a new parser independant of java.text.DateFormat.
<aaime> no no, it's a pure DateFormat wrapper
<desruisseaux> Thanks
<Eclesia> funStuff : first snapshot Puzzle-GIS : http://img132.imageshack.us/img132/9784/snap1td2.jpg
<acuster> aaime, http://jcp.org/en/jsr/detail?id=310 (for reference)
<aaime> ah, the finally wake up and decided dates in java are a mess?
<simboss> ciao Eclesia
<simboss> what's that?
– acuster has changed the topic to: Geotools free for all...
<Eclesia> Puzzle-GIS = AlterSIG
<desruisseaux> Meeting topic? I guess we have 0) what is going on.
<aaime> are they going to kill joda time too this time?
<acuster> aaime, yes, calandars are hard. First there was date, then there was calandar, now we get something new
<desruisseaux> JSR-310 is derived from JODA in my understanding.
<simboss> I have a few question on algorithm to pick up overviews
<desruisseaux> (I means, use JODA as a starting point)
<desruisseaux> (but I guess they will trim it down a bit)
<aaime> wow, they seem to be getting a grip with open source, I'm surprised
<simboss> since daniele is playing around with that (ok just a bit)
<desruisseaux> Meeting topics? 0) what is going on
<aaime> "This JSR will draw heavily on experience gained from the Joda-Time project" very nice
<desruisseaux> I would like to add 1) jaxb annotations on metadata
– aaime has changed the topic to: 0) What's going on 1) annotations on metadata
– acuster gives Eclesia the eye candy prize of the day
<aaime> Jesse_Eichar, did you have a topic
<Eclesia> 
<simboss> Eclesia: how do you load the raster data?
<aaime> he has critters grabbing pixels out of the hard disk
<Eclesia> It's geotools
<acuster> Eclesia, Jasper is a printout system?
<Eclesia> jasperreport for map print : http://img132.imageshack.us/img132/3694/snap2ks5.jpg
<aaime> wow that is cool
<aaime> it's something I've been willing to add geoserver for ages
<Eclesia> jasper handle multiple output formats, pdf, html, odt ...etc..
<aaime> and eventually feed it with the actual feature collections
<aaime> so that the report can include tables as well
<Eclesia> possible yes
<Eclesia> or you can make a serie of maps
<aaime> right, map atlas, another very common need
<Jesse_Eichar> Thanks Andrea.
<acuster> desruisseaux, if you want your topic you have to call us to order
<Jesse_Eichar> 2) shapefile attribute indexing
<acuster> Eclesia, how do you deal with dpi?
<acuster> dots per inch
– aaime has changed the topic to: 0) What's going on 1) annotations on metadata 2) shapefile attribute indexing
<simboss> algorithm to pick up overviews?
<desruisseaux> So 0: whats going on
<Eclesia> I haven't look for dpi yet
<Jesse_Eichar> Jesse -> Was donated an attribute index implementation for Shapefile
<desruisseaux> Martin: about completed MosaicImageWriter and MosaicImageReader (a little tuning remaining on the later)
<aaime> interesting
<Jesse_Eichar> Jesse -> will be trying to deal with some other locking issues in shapefile
– aaime dumping on gt2 changes that have been sitting on the disk for too long
<simboss> simboss: some work on raster symbolizer
<Jesse_Eichar> Jesse -> busy moving to switzerland
<acuster> acuster, looking for centroids on the ellipsoid
<simboss> simboss: finishing aiime's work for overviews selection
<acuster> Jesse_Eichar, you a skier?
<Jesse_Eichar> a bad one
<Jesse_Eichar> but I know one side from the other
<acuster> are you going to be with refractions still?
<aaime> that's a good start
<Jesse_Eichar> no camp2camp
<acuster> seems like a changing of the guard in victoria
<simboss> you leaving refractions, or going there for work?
<simboss> like integration of the etl with udig?
<Jesse_Eichar> I don't know what I'll do but that seems likely. I just decide to move to switzerland in November
<Jesse_Eichar> and camp2camp grabbed me as soon as I told them
<acuster> lol, have great fun
<acuster> it sure was pretty up there
<acuster> desruisseaux, we should move on eh?
<desruisseaux> yes
<desruisseaux> 1) metadata annotations
– groldan (n=groldan@217.130.79.209) has joined #geotools
<desruisseaux> We have been able to annotate all org.geotools.metadata implementations without API change.
<aaime> nice
<desruisseaux> Its look like that we can read and write ISO 19139 compliant metadata XML
<acuster> congrats
<desruisseaux> Was not obvious since ISO 19139 is a little bit convolved - not the usual XML structure.
<desruisseaux> Would peoples agree to commit the annotations to geotools trunk?
<Jesse_Eichar> I just spent a year on 19139. and I agree with you.
<aaime> Martin, did we have a formal vote?
<aaime> If not, you should start one
<groldan> martin, first, congrats, thats awesome
<groldan> and a question:
<acuster> desruisseaux, didn't you already go through this vote?
<groldan> is there any way to validate conditional attributes?
<desruisseaux> No we didn't voted yet. We can do that toonigt if peoples agree.
<aaime> not enough PMC I fear
<desruisseaux> What do you means by validate conditional attributes?
<aaime> we're 3 provided that jdeolive is awake?
<desruisseaux> Actually the guys we did the annotation work is Cédric
<groldan> you know, where the existence of an attribute depends on the existence or not of another one
<aaime> Martin, maybe it's better if you move the voting to the ml
<aaime> reiterating why and how this won't introduce a jaxb dependency
<desruisseaux> Andrea, all right I will move the topic to mailing list
<aaime> good, I'll vote on it right away
<groldan> conditional as in mandatory/conditional I mean, not sure the 19139 schemas has a way to define those conditions (schematron?)
<desruisseaux> About validation: I didn't tried this kind of check, but I seems quite doable to me
<desruisseaux> Oh I see
<desruisseaux> I didn't implemented what you said, but I see clearly how we could do that.
<jdeolive> hi all
<groldan> ok, cool, just wondering
<desruisseaux> Need to looks if there is a "jaxb way" to do that first however. If not there is other ways.
<groldan> "I know how it can be done" is a perfect answer to me
<desruisseaux> I'm done for this topic - will ask for a vote on mailing list. Thanks for listening
<aaime> cool
<aaime> Jesse_Eichar, your turn?
<Jesse_Eichar> k
<Jesse_Eichar> 2) shapefile attribute indexing
<groldan> Jesse_Eichar: seems a couple of us spent a year on 19139 separately, what a pity
<Jesse_Eichar> haha lost years
<acuster> groldan, you too?
<groldan> (damn private projects)
<acuster> that would make 3 groups
<Jesse_Eichar> as I mentioned I was donated some code that performs indexing and lookups via that index
<Jesse_Eichar> indexing on the attributes.
<Jesse_Eichar> I'm looking at ways of integrating it into the datastore
<acuster> does it write out an indexing file as well?
<Jesse_Eichar> yes
<Jesse_Eichar> There are a few ways that come to mind.
<Jesse_Eichar> I'd love other suggestions as well:
<Jesse_Eichar> 1. Add a class/utility for creating indexes and the DS can use them if they are around
<Jesse_Eichar> (and not out of date)
<Jesse_Eichar> 2. Provide a way to configure the DS so that it will generate certain indices automatically. Parameter or method maybe?
<aaime> so that utility would be independent of the datastore?
<Jesse_Eichar> At least that
<aaime> like, for example the spatial indexing in shapefile seems pretty shapefile specific?
<groldan> 1. and a ui in udig for the user to specify what makes sense
<Jesse_Eichar> WEll the other tool have utilities which are called by the datastore when needed
<Jesse_Eichar> so I could do that.
<aaime> well, if you start using a certain attribute for filtering it would make sense to have an index on it
<groldan> euristics?
<aaime> yet that might slow down a lot the first acces (like it happens now with the spatial index in shapefiles anyways)
<Jesse_Eichar> It does but when do you know that it is not a fluke.
<Jesse_Eichar> spatial index is a good bet
<acuster> can you summarize what files gt generates by default then when it hits a shapefile? just the qix/your new index?
<Jesse_Eichar> acuster that was what I was thinking for idea 2.
<aaime> the .fix file when you do fid filters, .fix + .qix if you do spatial filtering?
<acuster> you could generate the index prior to second pass
<Jesse_Eichar> I don't think I'm going to do heuristics. At least at first. Sounds too hard to get right.
<Jesse_Eichar> But I think 1 and 2 are good ideas. I'll start with 1. Then as time permits move to idea 2.
<groldan> imho too much automation leads to too much grief, what happens if you add a layer for a given shapefile twice?
<Jesse_Eichar> That will only be for the IndexedShapefile datastore.
<Jesse_Eichar> groldan. That's my thinking as well
<Jesse_Eichar> to scary for me. At best it could be an option to enable. But that is a ways in the future
<Jesse_Eichar> since this is my spare time project.
<Jesse_Eichar>
<Jesse_Eichar> k that's good for me. Unless there are other comments
<groldan> understood. I'd say keep it as simple as possible, let the user create the index he thinks make sense and that's it
<groldan> if I can give a recommendation
<Jesse_Eichar> +1
<Jesse_Eichar>
<acuster> aaime, .fix is a feature index? is that different from the attribute index?
<Jesse_Eichar> yes it is.
<Jesse_Eichar> it is often used the same. But when you come to editing it has a very critical role
<Jesse_Eichar> that attributes don't have to worry about.
<acuster> so we generate 3 files?
<Jesse_Eichar> at least
<Jesse_Eichar> so does ESRI though. So its not as if we're the odd balls
<acuster> could you give a list?
– acuster is trying to learn enough to help a confused user
<Jesse_Eichar> I am maintaining the list in ShpFileTypes class
<Jesse_Eichar> sorry its not plural ShpFileType
<acuster> and all those you might generate under different circumstances?
<Jesse_Eichar> If I'm creating a Shapefile they could all be created.
<Jesse_Eichar> If I'm taking an existing one only some need to be generated
<Jesse_Eichar> for example QIX is also a mapserver format
<acuster> thank you
<Jesse_Eichar> np
<Jesse_Eichar> Oh
<Jesse_Eichar> 3) World+Image extension
<Jesse_Eichar> can we move on to that?
– aaime has changed the topic to: 0) What's going on 1) annotations on metadata 2) shapefile attribute indexing : 3) World+Image extension
<aaime> go go go!
<Jesse_Eichar> ok
<Jesse_Eichar> I just got a long email on the uDig list about the possible extensions for World+image
<Jesse_Eichar> we currently accept .wld for the world file
<Jesse_Eichar> and .jgw if the file is a jpg
<simboss> we==?
<Jesse_Eichar> or tfw if it is a tif
<Jesse_Eichar> (uDig and I think GT)
<simboss> gt no
<aaime> maybe gt 2.2.x
<simboss> maybe
<Jesse_Eichar> no?
<Jesse_Eichar> what do we take then?
<aaime> we accepts those and others as well in 2.4.x and trunk afaik
<aaime> like 4 extensions for jpeg world file
<aaime> 2 for png
<aaime> and 2 for all other image types as well
<simboss> http://rafb.net/p/wzvGy460.html
<Jesse_Eichar> ok so pngw and jpgw etc... are ok?
<aaime> yeppers
<aaime> provided you don't use a prehistoric version of gt2, that is
<simboss> in main
<simboss> there is a class
<Jesse_Eichar> ok so I can make that change on 2.2 and don't have to worry then. Well On uDig trunk I worry because we also do the filtering there
<simboss> which is called world file reader
<simboss> we could move extension lookup there
<aaime> hmmm... doesn't that increase the likeliness of having a mismatch between the actual image reader and the world file reader?
<aaime> (like adding an image format in the image reader and forgetting to update the world image reader extensions?)
<acuster> simboss, the mail on the udig list had good info on the rules
<desruisseaux> Well... I have an issue with that. If I'm understanding right, worlfiles are IIOMetadata. Simone started to write a nice document about a standard IIOMetadataFormat we could agree on at least for the geotools code base. I missed time for providing feedback, but I feel that some kind of GeographicIIOMetadata is required before extensions like worldfile... (or do I miss what a worlfile is?)
<acuster> and the differences that esri follows
– utlo (n=lotu@151.200.90.2) has joined #geotools
<acuster> we should grab that info for the javadocs
<simboss> world file
<simboss> is just a plain grid to world martin
<simboss> it is a de facto standard from esri arcinfo
<simboss> yeah you are right acuster
<simboss> I saw the email
<desruisseaux> Yes, but isn't the plain grid to work information a metadata?
<desruisseaux> (typo: to world)
<simboss> but did not get time to read it carefully
– acuster neither
<aaime> Martin, it is, and if we had a full set of metadata classes it would end up there
<desruisseaux> That what we need to do in my opinion.
<aaime> but it seems illogical to me to ask for a full fledged metadata set of classes just to handle the grid to world?
<aaime> (that we already handle btw)
<desruisseaux> I'm talking about javax.imageio.metadata
<desruisseaux> not ISO metadata
<desruisseaux> J2SE Image I/O has a framework for image metadata that we would benefit from leveraging more.
<aaime> I don't know about that. I'm having a hard time to follow, maybe you're thinking beyond the needs of the world image format?
<acuster> Jesse_Eichar, sounds like you can do what you want on 2.2
<simboss> desruisseaux: I agree with that
<aaime> including releasing a new version of it?
<desruisseaux> Can I take a few minutes for explaining this javax.imageio.metadata stuff?
<acuster> desruisseaux, better on email
<aaime> I have to run, but please, I'll read the logs
<aaime> whatever you feel is better
<acuster> so we can have a record and read it slowly
<desruisseaux> I will write an email tomorrow then.
<aaime> nice
<acuster> rocking
<acuster> Jesse_Eichar, anything else?
<Jesse_Eichar> nope. I'm happy. I just wanted to make sure GT was doing this correctly so I can update uDig
<acuster> we done?
<aaime> I guess so
<aaime> who's posting the logs?
Agenda:
- what is up
- JP WFS Patches
- DataAccess proposal lasts too long
- OSGeo 2007 Report
jgarnett: cool; welcome to geotools and please stay for the IRC meeting.
jgarnett: which should be now ...
jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches
jgarnett: (change the topic to add agenda items; meeting last an hour)
groldan has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2) DataAccess proposal lasts too long
aaime: Hi
***aaime did not have time to look at it today.... sigh
jgarnett: Hi aaime; anything for the meeting? And thanks for the 2.4.0 release (ahayes is here to talk about some of the WFS patches that were too slow to make it)
jgarnett: lol - hi gabriel; we will get it out of the way today.
groldan:
jgarnett: that is the pain for working on the fun stuff; everyone wants a say.
groldan: aaime: no worries, may be you can take a look at the spikes while the meeting goes on?
aaime: I'll try
jgarnett: we got a new website (http://udig.refractions.net) - not worth an agenda item but still fun.
groldan: yeah, it'd be a pain not having your opinions
jdeolive: who here has decided on which option they prefer?
groldan: jgarnett: was lurking on it, nice stuff
jgarnett: well if that is it for agenda items we can start ... oh wait I got another one
jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2) DataAccess proposal lasts too long 4) OSGeo 2007 Report
groldan: (seems like you're foreseeing dataaccess to span for 2) and 3)
)jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2-3) DataAccess proposal lasts too long 4) OSGeo 2007 Report
groldan: lol
groldan: l, lets move?
jgarnett has changed the topic to: IRC Meeting 0) what is up 1) JP WFS Patches 2) DataAccess proposal lasts too long 3) OSGeo 2007 Report
jgarnett: 0) what is up
desruisseaux: Martin: again on org.geotools.image.io.mosaic...
jgarnett: jgarnett - having fun with Eclisia; testing geoserver / udig; training materials; stressing out
Eclesia: johann sorel : new proposal : http://docs.codehaus.org/display/GEOTOOLS/Process+proposal
**sfarber is changing strategies about doing raster processing *inside the wms/wcs. Instead will do raster processing in-between the WCS/WMS and the client and not worry about having to create a specialized language in SLD/WCS for specifying raster-processing operations
***aaime is running like a crazy cat trying to do four things at a time
groldan left the room (quit: Nick collision from services.).
groldan n=groldan@217.130.79.209 entered the room.
groldan: hi
Eclesia is now known as JSorel
jgarnett: okay well that is what is up seems everyone is crazy
jgarnett: 1) JP WFS Patches
jgarnett: ahayes want to introduce yourself; and I will see if I can find that issue tracker number again
ahayes: Hi. I'm Amos Hayes. I manage the technical issues for a small research lab at Carleton University (http://gcrc.carleton.ca)
ahayes: We're developing an interactive atlas framework (http://nunaliit.org) that is designed to make it easier for people to add context and tell stories that include cartography.
groldan: cool, and you're needing the WFS plugin to get rock solid?
ahayes: Our main developer is Jean-Pierre Fiset who, due to a few boundaries we're pushing, seems to run across odd (or surprising) issues with GeoTools/GeoServer. We use GeoTools in our own server backend code as well as GeoServer as our WMS/WFS/WCS of choice.
aaime: Nice
jgarnett: Jean-Pierre showed up on IRC a couple days before 2.4.0 with a couple of bug fixes; looks like one of them missed the cut (http://jira.codehaus.org/browse/GEOT-1703). This is a case where lack of a WFS module maintainer hurt us; thanks to Gabriel for applying as much as he could before the release.
aaime: unfortunately wfs client issues are not... suprising... that module is dead in the water
ahayes: We're working on user contributed content features for Nunaliit at themoment, so WFS-T is getting some excersise.
aaime: ahayes, the issue here is that
jgarnett: I would like to review a few more patches and see if we can get JP svn access; but it would really help ahayes if he was hear to talk to us. We want to have confidence that he has read the developers guide and so on ...
aaime: to commit patches we need someone that understands the code (a mantainer)
aaime: we don't have a mantainer, so someone that does not understand the code but has commit access has to do the review
aaime: that is much more likely if JP is willing to become the new mantainer (that is, we have to make an effort to see if the patches make sense, but there is reward)
ahayes: Yep. So from what I can tell, he's been on and off IRC for at least a month trying to track down a few issues.
Jesse_Eichar n=jesse@mail.refractions.net entered the room.
ahayes: Well I can certainly talk to him about that. I'm paying for his time so I'd have to have some idea of what that's going to cost me.
groldan: if they were to work with trunk it would be easier to get things going. As for the WFS module, the hard part is the old xml tech its using
groldan: that's what I guess is the most unmaintained part of it, and harder to maintain
simboss n=chatzill@host50-221-dynamic.117-80-r.retail.telecomitalia.it entered the room.
jgarnett: Jesse and I are able to review; but we only care about 2.2.x and trunk
aaime: ahayes, how do you evaluate your cost? It's not like we ask any fee for assisting JP
aaime: (at least if we get a mantainer in exchange
)jgarnett: aaime++
aaime: alternatively you can come up with a list of things you want to get fixed and pay someone of the official developers to fix them
ahayes: Hmm.. So that has been a big issue for him. He has been pointed to a few different branches in his attempts and in some cases, he's had to patch 2.2, 2.4 and trunk depending on that features we needed and what was broken where.
aaime: but that would not be nearly as good as getting someone new on the module
simboss: (hi guys, sorry I am late but gotta go back in shape, summer is approaching
)aaime: why so?
aaime: I mean, why that many branches?
avc_afk is now known as avc_nice
jgarnett: filter visitor aaime; your fav bit of undone work.
aaime: jgarnet, I'm not following you
ahayes: Because each seems to have stuff that works, and other stuff that doesn't. Every time he switched branches, something started working and something else broke.
ahayes: I wish he were here today and could comment, but I will get him in here soon to explain himself.
jgarnett: sending requests to WFSDataStore depends on the pre/post filter visitor code; that was never really QAed after the change to geoapi filters. JP is coming along and finding these problems; I helped him through a patch last week - but there is more pain before this is going to get better.
cholmes: ahayes, the best from our perspective would be to work on trunk. Gabriel's got some funded time to work on WFS, and any fixes made to trunk we only have to apply once...
cholmes: Fixes made to older branches will get lost or else need extra time to move forward.
groldan: cholmes++
cholmes: That said, trunk can be scarier...
aaime: trunk is the place for new developments
aaime: so it's not nearly as stable as other branches
cholmes: but GeoServer trunk is now living on geotools trunk, which we've not always done, and it's been helping to make it more stable.
ahayes: I think if he were going to jump in and help maintain, then he'd be on trunk. But as product developers ourselves, we wanted to be able to point at a versioned GeoTools for patches, etc. We need some stability.
jgarnett: udig trunk is also there; running full tilt into the same problems JP is finding.
aaime: ahayes, you can develop patches on trunk and then backport them
aaime: that's what we do for GeoServer
groldan: actually, if JP were working on trunk he could start moving WFS 1.0 DataStore to share more code with the 1.1 flavor I'm working on and thus get rid of a ton of pending issues with the old parsers, at the cost of dealing with the new ones, but in the end having a stady approach for both
groldan: (steady)
ahayes: Unfortunately, we have our own app to build and that's where his focus needs to be.
jgarnett: as you can see you have found a "hot topic" for development. We would love to work with JP on this stuff; if you would like to figure out the extent of your involvement that would be great. At the very least it would be good to move towards svn access so we are not a bottle neck.
avc_nice is now known as avc_mean
jgarnett: I am sure that is a lot to think about; did you have any additional questions.
ahayes: I think I could afford some time for him to help and get patches on trunk as things move along, but we can't afford to have him take on whole new things. We're running from grant to grant here.
aaime: which is exactly the reason why wfs client is unmantained
groldan: though getting svn access for a two-week patches is equally scaring, that's why we require patches first, and patches with unit tests to have more options to be taken rapidly
aaime: there was money to create it
aaime: but not for long term mantaininace
ahayes: No. That helps a lot. I will make sure he's read the process docs (I'm pretty sure he has) and I'll get him to keep submitting patches (against trunk? 2.4? both?) for the problems he hits.
aaime: ahayes, both
jgarnett: cool
jgarnett: moving on.
jgarnett: 2. Data Access proposal
jgarnett: groldan go!
groldan: here we go
***jdeolive fastens his seatbelt
groldan: imho we have only two options: generics and nogenerics
***aaime desperately tries to read the code
groldan: the middle ground solutions sucks
groldan: and since I hope the requirements are clear
groldan: it'd be time to know who already has a strong inclination towards one of them
groldan: aaime hint: face to the Example.java class in org.geotools.data.sample package
jgarnett: middle ground is the same as generics (with a few subclasses so that new users do not get scared) - it does not completly suck.
jgarnett: generics +1
jgarnett: middle ground +0
jgarnett: nogenerics +0
aaime: wow you replicated the whole api module
aaime: there is no way I'll be able to do a 5 minutes review
jgarnett: in all three cases.
groldan: jgarnett: right, I meant the parametrize only the arguments one, that one sucks, though not even in spike
aaime: jgarnett, I need half a day to have a look at all this stuff...
jgarnett: aaime; focus on DataStore getFeatureReader method to see the approaches in a nutshell.
groldan: getFeatureSource
avc_mean: groldan, why not just do the one you prefer?
groldan: because that's not how I've been told this works
avc_mean: since we don't have any really good analysis for you
groldan: (though I was hoping nobody replies in three days so I was free to go
)avc_mean: jgarnett: groldan go!
jgarnett: I like the generics approach because there is less stuff at the end of the day to document and understand; but I recognize that I like generics and am pretty good at reading them now. The middle ground approach where the generics is hidden for the common case may actually represent the best solutions. Question for me comes down to how much to cater to new java developers.
jgarnett: Answer: Generics is part of Java 5; lets update our API and take the benifit of not needing extra classes since the compiler will sort out the details.
aaime: sorry, am I looking at the wrong samples? I don't see the org.geotools.data.sample in jdeolive one?
jdeolive: aaime: i created a seperate module called example
jgarnett: gabriel - do the one you prefer; you are the guy doing the work. What do you think!
aaime: or they are not meant to be 1-1 comparable?
jdeolive: to my defense i was the firs tone who did it so it was others who did not follow suit
aaime: I wasn't trying to blame anyone
avc_mean: go generics go!
aaime: just trying to figure out how to compare the code
groldan: the generics one also does not put us on naming hell
groldan: and it seems all name schemes we tried sucked
avc_mean: FeatureSource was the piece I found most comparable if i remember right
jgarnett: or limits naming hell to once class; the super class
groldan: yup
jgarnett: avc_mean - you are correct; except that it was not completly done (the visitor and add features methods were sometimes out of wack). getFeatureReader was the better test.
avc_mean is now known as acuster
desruisseaux: (my point may not be relevant since I'm not very familiar with the two proposal, but I'm of course all for generic)
Jesse_Eichar: I'd probably go for generics. But I'm also not a good candidate since I've been using generics for years
jgarnett: your input helps martin. don't worry.
aaime: it's a pity that we need to parametrize like this: FeatureWriter<SimpleFeatureType,SimpleFeature>
aaime: since one parameter logically implies the other (logically, but not in practice....)
groldan: thing is easy: generics sort of means yeah, we're moving to java5. The others has great value too, but its time to compromise (ie, sure with every choice you'll be losing something)
Jesse_Eichar: Do you think it is a good API for beginners to generics as well?
groldan: beginners are programmers
jgarnett: going with generics is not a clear loss for beginnersthere is less classes to understand with generics and that means a lot when starting out.
acuster: it's not terribly complex
desruisseaux: For beginner (as well as for anyone actually), it help to prevent bugs.
jgarnett: even with the generic approach there is a clear subclasss (ie DataStore) for the most common case.
desruisseaux: If beginner are more likely to do bug, it has yet more value for beginners.
***jdeolive thinks we should leave the generic debate until later
jdeolive: and just state ones preference
simboss: a simple naive questions
jdeolive: and not why
simboss: isn't this implementation of store a little bit feature centric with respect to what we said last time?
simboss: and source as well
groldan: simboss: yes it is, we're running out of time and including coverage is a scope bomb for this run, though I'd be glad to get involved if you want to bring it later
simboss: source to me should data type agnostic
aaime: didn't we agree that coverage "stores" would have better been isolated in their own hiearchy?
jgarnett: simboss the idea was to set a common approach; you will find your proposal page is similar.
jdeolive: aaime: i know i did
simboss: that's what you suggested aaime
jgarnett: but I needed help defining the Query before throwing it into the ring.
aaime: Ah, I see
jdeolive: as groldan says... this is someone off topic at the moment
jdeolive: if we start talkign about coverages this proposal will never reach resolution
simboss: I am not asking to stop anything jdeolive
simboss: but from a user perspective
simboss: because I am just a user of the feature part of geotools
jdeolive: simboss: sorry, i mis understood, i thought you are were asking about coverages
simboss: this split generates some confusion for me
simboss: because I see source
simboss: or store
simboss: as something not feature bound
jdeolive: simboss: right... but keep in mind that is only one of the alternatives
acuster: a coverage is a feature but a gridcoverage is not, so when we get real coverages things will work the same way
simboss: lets say I would expect
simboss: so I was just exposing a thought
simboss: this naming looks ambiguos to me
simboss: to make a long story short
jdeolive: same to me... which is why that is not my choice
acuster: groldan, do you need a vote?
groldan: we could even be more rude and rename the current FeatureSource as SimpleFeatureSource and so on so we have a consistent naming scheme
aaime: in theory the generics approach looks cleaner... but I'm finding very hard to accept the double parametrization spreading in the client code
groldan: but goes quite against the as backwards compatible as possible idea
jdeolive: aaime: keep on thing in mind
jdeolive: that if you write code against Feature you dont have to parameterize
groldan: aaime: I don't see how to solve that without a layer of indirection
groldan: (like the crazy idea of parametrizing just Query)
aaime: jdeolive, yes, but feature interface is designed to be slow
aaime: there is no way you can make fast code if you're forced to go thru an hashmap like lookup
jdeolive: ok... so far jody has voted +1 for generics
jdeolive: am i correct jgarnett ?
jdeolive: and so has martin
jgarnett: you are totally correct; I think the other approaches are capable - but the generics has less code - and I think that is a win all around. For begginers as well.
jgarnett: For details (like the name of the superclass we can leave that to gabriel).
jdeolive: aaime: another thing to keep in mind is that you can simply cast and put up witha compiler warning if you dont lie the look of declaring parametrized variables
jdeolive: ok... groldan have you made up your mind?
jgarnett: guys we are over our timeslot; I don't really want to waste meeting time while andrea reviews the proposals for the first time.
jgarnett: can we hit our last topic; or vote and move on.
groldan: I'm for generics, so if no pmc has a -1 I guess we got it
jdeolive: ok... so its simboss and aaime remaining
jdeolive: letrs give them more time to review
aaime: I equally satisfied/dissatisfied by both approaches
JSorel: (vote generic, for the beginner i am)
jdeolive: aaime: so 0 ?
simboss: guys I don't want to block anyone's work here
aaime: If there was a way to have a single parameter I would vote for generics me too
aaime: like this, 0, yes
simboss: ( I prefer generics anyway
)jgarnett: simboss; did you look at the http://docs.codehaus.org/display/GEOTOOLS/GridAccess+based+on+WCS+Specification - I lined it up with these proposals pending your feedback.
groldan: aaime: 0 for all three approaches, right?
jdeolive: ok... so it seems we are more or less decided
jgarnett: yep
aaime: nope, -1 for the hybrid
simboss: jgarnet: I started to convert them on classes and I am playing with it
acuster is now known as avc_mean
groldan: that's not even an option, I'll update the proposal page
simboss: jgarnet: but it's not the first one in the queue
jgarnett: wow - that is sweet simone
jgarnett: next
jgarnett: 3) OSGeo Report
jgarnett: Sent out an email a while back
jgarnett: the deadline is now on us.
jgarnett: http://wiki.osgeo.org/index.php/GeoTools_Report_2007
simboss: groldan: all I suggested was, can we use a name that may allow us to derive a separate hierarchy for coverage I/O?
jgarnett: is there anything we want to add?
jgarnett: Like looking for a WFS module maintainer ...
simboss: groldan: store and source should not imply feature IMHO
groldan: simboss: seems fine, as we took the one with least new classes seems like we don't use Source
groldan: and the line
groldan: they won't exist as per the approach taken
avc_mean: Geotools is ready!? cough
markusin_ left the room (quit: Connection timed out).
groldan: so they can be worked out in the future, sounds good?
simboss: groldan: k
jgarnett: lol; you try and write something motivational!
avc_mean: you won't be bored on geotools trunk!
jgarnett: avc_mean
jgarnett: that sounds good.
CIA-1: desruisseaux * r29189 geotools/gt/modules/ (3 files in 2 dirs): More opportunist tiles creation in MosaicImageWriter (i.e. leverage already loaded images). Consolidation in TileBuilder.
avc_mean: oh, talk about JSorel more!
JSorel is now known as Eclesia
avc_mean: he's been doing fun stuff last year
sfarber left the room.
jgarnett: how about: GeoTools is looking forward to making 2008 the best year yet. There is lots of exciting development now underway - from embracing Java 5, to rolling our WFS 1.1 support. 2008 will see the long expected return of swing widgets to the GeoTools library.
avc_mean is now known as acuster
jgarnett: seriously I have no interst in this page; I only wrote something so we did not look like idiots; please hack away - it goes out this week.
acuster: cool
***acuster has no interest in the page either. it looks like english
acuster: do we have to do one every year?
jgarnett: apparently
acuster: well thanks for doing it then
jgarnett: okay meeting is done? Sorry for letting it go over time.
jgarnett: I will post the logs
The GeoTools 2.4.0 release is available for download:
New for GeoTools 2.4:
- significant speedups in shapefile and postgis data rendering (and to a lesser measure to other vector data sources as well)
- many expressions improvements using converters to correctly handle a range of queries
- style interfaces now use geoapi filter (no more casting!)
- redirect to an alternate logging api
- datastore dispose
- make use of java connection pools (DBCP and the like)
- use a registered java DataSource for epsg database in a Java EE environment
- user guide; with a small section for 2.4.0
- iso geometry implementation available as a supported module
- community change proposal process has been adopted
For more information on these improvemets visit our web site:
Release Notes:
The GeoTools project has seen a lot of growth over the development of GeoTools 2.4. We have made several important changes to how the project is managed:
- we have introduced "unsupported" modules; allowing early access to community experiments (for a list of supported modules see http://sourceforge.net/project/shownotes.php?release_id=574856)
- we have adopted a formal change proposal system
For more information please visit:
- http://docs.codehaus.org/display/GEOTOOLS/Upgrade+to+2.4
- http://docs.codehaus.org/display/GEOTOOLS
- http://docs.codehaus.org/display/GEOTDOC
Enjoy,
The GeoTools Community
05 <gabriel> ping
05 <gabriel> it seems we don't have a lot of attention for the breakout
05 <gabriel> hopefully much was discussed at the ml
06 <gabriel> so I had a run over the hierarchy+generics approach
06 <gabriel> http://docs.codehaus.org/display/GEOTOOLS/Dry+Run+at+DataAccess+Story
06 <gabriel> it seems the cleaner so far, as it does not imposes extra grief to the current interfaces
07 <gabriel> made some void implementations of those interfaces and all seems right
07 <aaime> looking
07 <gabriel> it'd be nice if you could take a look at it while I hunt for a couple more attendees?
07 <aaime> ugh, long page
07 <gabriel> that's why its a child of the proposal one
09 <aaime> looking at this:
09 <aaime> SimpleFeatureType getSchema(String typeName) throws IOException;
10 <gabriel> right, mistake
10 <aaime> does not seem to narrow down, but to overload instead?
10 <gabriel> fixed
11 <gabriel> no, type narrows cause the argument is Name
11 <gabriel> it was a copy&paste mistake
11 <gabriel> refresh
11 --> dwinslow has joined this channel (n=david@cpe-66-108-80-238.nyc.res.rr.com).
11 <aaime> Name -> String is not type narrowing?
11 <aaime> they are not in the same hiearchy?
11 <aaime> (what I am missing?)
12 <aaime> Ah, got it
12 <gabriel> k
12 <aaime> but then we need the overload as well to keep
12 <aaime> the api compatible right?
12 <gabriel> for that case yes
12 <gabriel> we need Name for complex to work propoerly
12 <aaime> but we need String to be backwards compatible
13 <aaime> so we need both
13 <gabriel> yup
14 <aaime> I really wish there was a way to have classes have just one parameter (the type of feature)
14 <aaime> instead of the collection and reader type
14 <aaime> that seems .... odd
14 <gabriel> agreed
14 <gabriel> yet I don't know how
14 <aaime> we would need to make reader and feature collection parametric as well I guess?
15 <aaime> Reader<T extends Feature>
15 <aaime> FeatureCollection<T extends Feature>
15 <aaime> or something like that?
15 <gabriel> I don't think so
15 <gabriel> reader can just type narrow the return type
15 <aaime> so?
16 <gabriel> otherwise we can rather parametrize FeatureReader and get rid of its super type
16 <gabriel> it'd work for me too
16 <aaime> btw, you did not define ComplexFeatureReader anywhere?
17 <gabriel> right, gonna add it
17 --> jgarnett has joined this channel (n=Jody@mail.refractions.net).
17 <aaime> tsk tsk, you're late
18 <gabriel> aaime: done
18 <gabriel> oops, lacks extends
19 <gabriel> k, now for good
19 <gabriel> hi jgarnett
19 <jgarnett> hello
19 <gabriel> we're taking a look at the parametrized approach
19 <gabriel> http://docs.codehaus.org/display/GEOTOOLS/Dry+Run+at+DataAccess+Story
19 <gabriel> wanna join?
19 <jgarnett> sorry I am slow; Paul is setting up an improved uDig confluence :-D yeah!
20 <gabriel> cool!
20 <jgarnett> (actually confluence has improved a lot; maybe we should host one on osgeo hardware rather than codehaus)
20 <aaime> So, would it be possible to have FeatureReader<F extends Feature, T extends FeatureType>?
20 <gabriel> andrea would like to have to parametrize by <F extends Feature, T extends FeatureType>
20 <gabriel> me too
20 <gabriel> just not sure how?
20 <gabriel> I guess you know more generics than me
20 <aaime> not me
21 <jgarnett> beso which one of the alternatives is represented on this page? Minimal generics for parameter objects?
21 <aaime> And we could have Feature collection based on the same parameters
21 <aaime> jgarnett, I was saying that
21 <gabriel> aaime: sounds good to me, if we agree to insert parametrized at the current api
21 <aaime> parametrizing over feature collection and feature reader
21 <aaime> seems odd, clunky
22 <jgarnett> nope it looks like you guys are using generics for return values as well; not sure that is needed...
22 <aaime> I'd prefer to see parameters like the feature and feature type you're using
22 <jgarnett> opps I will shut up and listen for a bit.
22 <aaime> jgarnett has a point here
22 <gabriel> so yeah, this one is minimal parametizing to narrow parameters
22 <gabriel> jgarnett: for the sake it was the same, we can change return parameters to type narrow
23 <gabriel> soooo
23 <jgarnett> how so? ComplexFeatureSource<F, R> is more complex then needed; all you need is ComplexFeatureSource<Q>
23 <aaime> right, I'm not seeing params being used in the method params, but only in the return types?
23 <gabriel> if we're ok in inserting parameters on the current API (DataStore, FeatureSource, FeatureStore)
23 <gabriel> I can give a try to it
23 <gabriel> it'd be still cleaner
23 <aaime> jdeolive wanted an approach that only used one class instead of a hiearchy, or I'm missing something?
24 <gabriel> and don't think it'd be too much a grief for users upgrading from 2.4 to 2.5?
24 <jgarnett> I think we better call this 3.0 honestly; changing data model (done) and now data access ...
24 <jgarnett> it is a 3.x change....
24 <gabriel> aaime: you're right, but that does not buys us goal number 2
25 --> pramsey has joined this channel (n=pramsey@mail.refractions.net).
25 <gabriel> "We want current code to keep backwards compatible. This means the library won't break all the code written with the SimpleFeature assumptions. And we want all the format drivers written in simple terms to be used as the more general Feature/Type out of the box."
25 <gabriel> I asked for agreement on that before going forward
25 <aaime> ah right
26 <jgarnett> yep; so at a minimum we need one super class each for DataStore, FeatureSource, FeatureStore, FeatureLocking
26 <gabriel> so, minimal type hierarchy + parametrized collection and reader would buy us enough simplicity and flexibility?
26 <jgarnett> I was wondering if we could use FeatureReader<F,FT> and save some pain?
26 <gabriel> yeah, that's what I'm asking
26 <gabriel> putting the burden on upgrading code
27 <gabriel> I'm fine with it
27 <jdeolive> hi guys, sorry i am late
27 <aaime> Hey
27 * jdeolive is catching up
27 <jgarnett> even so that is a small question: FeatureReader<F,FT> vs (Reader and FeatureReader)
27 <gabriel> not that a burden though, they may just need a couple supresswarnings
27 <jgarnett> I am way more interested in Query ...
28 <aaime> so you see no way to simplify that ugly set of params?
28 <aaime> if so, how would the interfaces change?
28 <jgarnett> I do ... we only use generics for the Param objects
28 <jgarnett> I will make a page and modify the code example ...
28 <gabriel> like in Query.getPropertyNames():String[]?
28 <aaime> thanks, that would help
29 <jgarnett> based on email yesterday I was hoping someone else would give it a try ... I did one example on email.
29 <jdeolive> i would up for taking a shot at it
30 <jdeolive> i am not convinced we need a subclass for each of those
30 <jdeolive> but i admit... until i look at it i dont really know
30 <jdeolive> so is this a formal meeting? is someone driving?
30 <-- pramsey has left this server.
31 <gabriel> jdeolive:
31 --> pramsey has joined this channel (n=pramsey@mail.refractions.net).
31 <aaime> jgarnett, I've been fighting to get 2.4.0 in a releasable state, I did have no time
31 <aaime> jdeolive, not so far, everybody just popped up now
31 <gabriel> there are assumptions over simplefeature we need to get rid of for the general case
31 <jdeolive> right
32 <jdeolive> so to keep things clear here
32 <jdeolive> can we come up with an agenda
32 <gabriel> there are compelling forces all over the way
32 <jdeolive> and work through the issues
32 <jdeolive> does that make sense?
32 <gabriel> in order to get the whole picture we need to keep in mind the main goals
32 <aaime> jdeolive++
32 <jdeolive> cool, i am happy to drive
32 <-- pramsey has left this server (Read error: 104 (Connection reset by peer)).
33 <gabriel> we first agreed on the goals then the proposal comes through, changing scope may lead to a different situation
33 *** aaime sets the channel topic to "1) main goals".
33 <jdeolive> so as per gabriel's suggestion, why dont we nail down what the main goals are
33 --> pramsey has joined this channel (n=pramsey@mail.refractions.net).
33 <gabriel> ie, it may be possible to not introduce a type hierarchy if we want to break the api and remove a lot of stuff
33 <gabriel> they're on the page
33 <jdeolive> link?
33 <gabriel> http://docs.codehaus.org/display/GEOTOOLS/Dry+Run+at+DataAccess+Story
34 <gabriel> basically 2, the first is easy, the second is the one forcing us to take a compromise
34 <aaime> So to sum up
34 <aaime> 1) Use Name to keep namespaces around 2) Make the change backwards compatible
35 <aaime> anything else?
35 <gabriel> yep
35 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
35 <gabriel> and allow to ask the factory system to return DataStores as they're now (simplefeature) or anything that works with Feature
35 <aaime> jdeolive, jgarnett, do we have an agreement on the principles at least?
35 <gabriel> that falls on backwards compatible
36 <gabriel> but the use case is worth to be mentioned
36 <jdeolive> aaime: yes
36 <jgarnett> sorry writing right now; will be back in a moment.
36 <gabriel> a smooth upgrade path for the code that cares to upgrade to Feature, backwards compatibility for the code the doesnt, and out of the box functionality for new code
37 <jgarnett> the above two principles seem fine; (2) == no casting for Simple case
37 <jdeolive> well put jody
37 <jgarnett> 3) don't screw over the Feature / FeatureType case as well
37 <gabriel> if it were just a matter of casting
37 <gabriel> think of udig and geoserver as they're right now
37 <aaime> jgarnett, what does that mean?
38 <jgarnett> even if it is just a matter of casting gabriel; you would do well to introduce a specifc subclass so end users don't have to.
38 <jgarnett> the difference betwee: Reader<SimpleFeature> and FeatureReader extends Reader<SimpleFeature>
39 <jgarnett> (it is not worth our time to watch users be confused)
39 <jgarnett> aaime - does that explain what I mean ?
39 <jdeolive> jgarnett: lets not make assumptions about users until we have a better idea of what the api will look like
39 <jgarnett> okay; I can handle that ...
39 <jdeolive> we made that mistake with featurecollection and look what happened
39 <jgarnett> proceed!
39 <gabriel> jdeolive: users == working code
39 <gabriel> we're a library
40 <jdeolive> i am not sure what that means but ok
40 <jdeolive> so it sounds like we have a good idea of what we want
40 <jdeolive> not we need to nail down how we get it
40 <gabriel> that means that if I want to upgrade my app to use geotools 2.5 is should just work
40 <jdeolive> so it seems gabriel has come up with a first cut on that page he just sent out?
40 <gabriel> as we do with other libraries (junit4 the most recent case)
41 * jdeolive thought that backwards compatability went without saying
41 <jdeolive> but yeah, i agree
42 <aaime> Ok, so, we agree on the general principles, what now?
42 <jdeolive> i would say
42 <gabriel> so, as I see it. parametrizing collection and reader would still get client code working
42 <jdeolive> gabriel: i agree
42 <jdeolive> they may get warnings but not errors
42 <jdeolive> afaikl
42 <aaime> jdeolive, gabriel
42 <gabriel> and we should only need the superinterfaces for datastore, source, store, locking
43 <aaime> am I the only one finding collection and reader as the type parametres
43 <aaime> odd?
43 <jdeolive> gabriel: that part i am not 100% convined on
43 <gabriel> aaime: agreed very odd
43 <jdeolive> aaime: yeah i agree i dont quite get that
43 <gabriel> just at the time of writing we still didn't agreed on parametrizing existing interfaces
43 <jdeolive> i woudl think that just Feature and FeatureTYpe would be he parameters
43 <jdeolive> and everything else works by just parameterting them
43 <jdeolive> gabriel: ok.. so that code example is out of date?
44 <gabriel> cool, I like that much better too
44 <gabriel> indeed
44 <jdeolive> cool
44 <gabriel> I can remake it for the new agreement
44 <gabriel> and call for voting?
44 <jdeolive> sounds good to me, so lets make sure that everyone understands the srategy first
44 <gabriel> yet, though not an immediate need of mine
44 <jdeolive> shall i take a shot at summing it up?
45 <gabriel> we'll have to keep an eye on the need for:
45 <gabriel> namespace aware filters
45 <gabriel> sure
45 <jdeolive> ok so the way i see it is this
46 <jdeolive> we add Feature and FeatureType parameters to basically all of our data access classes
46 <jdeolive> DataStore, FeatureSource/Store, FeatureReader/FeatureWriter
46 <jdeolive> we can do that without subclassing correct?
46 <gabriel> yup
46 <jdeolive> sorry
46 <jdeolive> ok
46 <jdeolive> and now there is the problem of backward compat
46 <gabriel> still can't get only simple feature capable datastores out of the factory system
46 <gabriel> right
46 <jdeolive> so
47 <jdeolive> we coudl creeate a super class for DataStore
47 <jdeolive> and have DataStore narrow all the paramaters for hte other classes
47 <jdeolive> to SimpleFeature and SimpleFeatureType
47 <jdeolive> in theory that should keep things backwards compatable
48 <jdeolive> although i guess not
48 <jdeolive> users who did this:
48 <jdeolive> FeatureSource = dataStore.getFeatureSource( ... );
48 <jdeolive> SimpleFeatureType type = source.getSchema()
48 <jdeolive> now break
48 <jdeolive> unless they declare FeatureSource<SimpleFeatureType>
48 <jdeolive> am i correct?
49 <jdeolive> or unless they cast
49 <gabriel> hmmm no, you already got a simplefeature only capable datastore
49 <gabriel> so you should be good?
49 <jdeolive> but
49 <jgarnett> (sorry guys customer call, will be back)
50 <jdeolive> FeatureSource now looks like FeatureSource<T extends FeatureType>
50 <jdeolive> and declares T getSchema()
50 <aaime> yet with type narrowing on return values we can avoid that parametrization no?
51 <gabriel> no
51 <jdeolive> aaime: right but then that means we need a super class
51 <gabriel> cause we're looking for a single FeatureSource
51 <jdeolive> right
51 <gabriel> right
51 <aaime> ah sorry
52 <aaime> but if we introduce params we break client code no?
52 <gabriel> no, they just get warnings
52 <gabriel> about their variables not being parametrized
52 <gabriel> ?
52 <aaime> hum
53 <jdeolive> in some cases they can break, and i think this is one of them
53 <aaime> not so sure
53 <jdeolive> since FeatureSource is genericized to featureType
53 <jdeolive> and anything that extends it
53 <-- cholmes has left this server.
53 <jdeolive> so if a cdeclaration does not declare that it narrors the parameter ot SimpleFeatureTYpe
53 <aaime> but users expect SimpleFeatureType
53 <jdeolive> the compiler will assume the generic, which is just FeatureTYpe
53 <jdeolive> does that make sense?
53 <jdeolive> this is hard to do without code in front of me
54 <aaime> so for backwards compatibility we need the class hiearchy
54 <jdeolive> aaime: well that would fix it
54 <jdeolive> but i really dont like that
54 <gabriel> I'm still not sure
54 <aaime> breaking backwards compatibility would be worse?
54 <jdeolive> i would almost be willing to give up some of our backwards compatability to keep our api cleamn
54 <gabriel> existing client code got a datastore which narrows to Simple
55 <aaime> Gabriel, you mean
55 <aaime> FeatureSource<SimpleFEatureType> datastore.getFeatureSource(...)?
55 <aaime> but in lot of places feature source is used stand alone
55 <jdeolive> right
55 <aaime> received from somewhere else
55 <jdeolive> this will work ok
56 <aaime> and you don't have params around
56 <jdeolive> SFT t = dataStore.getFeatureSource(..).getFeatureTYpe()
56 <jdeolive> but this will fail
56 <jdeolive> FS s = dataStore.getFeatureSOurce(...); SFT t = s.getFeatureType()
56 <aaime> right
56 <jdeolive> ibut as andrea says... there is probably a lot of code which stores the FS in a variable
57 <gabriel> now I see
57 <jdeolive> there is one important thing to keep in mind here
57 <jdeolive> the way things are now
58 <jdeolive> there are already breakages with code that is trying to upgrade to 2.5
58 <jdeolive> the way we did the SimpleFeature change is not back compat
58 <aaime> ok, but we should try to keep the incompatible changes down to a minimum
58 <gabriel> so if we already broke, call it 3.0 and do things right
58 <jdeolive> aaime: agreed
59 <aaime> do things right == generify?
59 <jdeolive> gabriel: agreed...but that comes with more political consequences than just backward compat
59 <gabriel> have only one new class, a superinterface for DataStore
59 <jdeolive> and lets be honest guys
59 <gabriel> I understand, its just an impulse
59 <jdeolive> we have already pissed enough people off with api changing
00 <gabriel> true
00 <jdeolive> i mean... the only peopel that really use geotools are the people like us who work on it
00 <jdeolive> dont get me wrong
00 <jdeolive> i agree with you aaime
00 <jdeolive> but we should also be realistic about the situation
01 <aaime> jdeolive, I would not count on "only us are really using geotools"
01 <aaime> I know quite some users here in Italy that only use gt2
01 <gabriel> yet I see no way of being realistic and not introducing superclasses for datastore/source/store/locking
01 <aaime> and don't use udig or geoserver
01 <gabriel> which seems to be what you want
01 <jdeolive> ack... it seems we are at an impasse
02 <jdeolive> so for the people here
02 <aaime> just look at the amount of poeple hitting gt2-usrs
02 <jdeolive> lets do an informal vote
02 <gabriel> really, we can introduce the type hierarchy and go throuh a deprecation cycle?
02 <gabriel> I even would prefer not to deprecate
02 <gabriel> but keep it working
02 <jdeolive> would you rather a) introduce an extra layer of interfaces or b) break some api and parameterize our api
03 <aaime> I'd say, if we play it so that the changes are pretty mechanical, like the ones for SimpleFeature
03 <aaime> then ok
03 <aaime> otherwise better have the two layers
03 <gabriel> I need it working asap in udig, so I'm for a) or I would need to redo udig
03 <jdeolive> aaime: i think the changes would be mechanical
03 <jdeolive> i mean... all you ahve to do is s/FeatureSource/FeatureSource<SimpleFeatureTYpe>/g
03 <jdeolive> and everything works
04 <aaime> gabriel, for the simple feature change jgarnett and jesse worked... a couple of days?
04 <jgarnett> back; written up enough of the hybrid approach so you can see how it would work
04 <jgarnett> http://docs.codehaus.org/display/GEOTOOLS/Alternative+4+Hyrbrid
04 <gabriel> hrmmm
04 <jdeolive> gabriel: if you are talking about getting somet4hing for fgdc i think there is some leeway there
04 <aaime> jgarnett, how much did you take to migrate udig trunk to SimpleFeature & co?
05 <jgarnett> in a word ... @#$%
05 <jgarnett> actually it was not too bad; we just did not have enough people.
05 <jdeolive> jgarnett: we are talking just getting code to compile
05 <jgarnett> took about 3 days for the first cut
05 <jgarnett> and 15 days for it to work
05 <jgarnett> create feature type dialog still does not work.
05 <jdeolive> keep in mind udig jumped from 2.3 to 2.5 did it not?
05 <aaime> wow, a lot more... with Geoserver we were up in a few days?
05 <jgarnett> 2.2 to 2.5
05 <gabriel> from 2.2
05 <aaime> ah right
05 <jdeolive> aaime: right... because gs kept up with gt releases
05 <-- dany_r has left this server ("ChatZilla 0.9.79 Firefox 2.0.0.11/2007112718").
06 <jgarnett> udig hits things hard; and a lot of the geotools cade base had suffered bit rot.
06 <jgarnett> (ie shapefile editing)
06 <jdeolive> i do think the changes are completely mechanical
06 <jdeolive> that people weould have to make...
06 <jgarnett> so I am lost on this meeting; can anyone look at that Hybrid page and give me feedback?
06 <jgarnett> I had one technical question
06 <jdeolive> jgarnett: it is plan a)
07 <jdeolive> introducting an entire new layer of data access api
07 <jdeolive> which i dont like
07 <jdeolive> personally
07 <jgarnett> (you mean a super class?)
07 <gabriel> so, if we go for a single parametrized FeaureStore, how this apply to Feature: void modifyFeatures(AttributeDescriptor[] type, Object[] value, Filter filter)
07 <aaime> it would be exactly the same?
07 <jgarnett> wait hold on gabriel; want to make sure I understand ...
07 <jgarnett> do we have 1, or 2, or 3 datastore abstractions...
08 <jdeolive> 1
08 <jgarnett> 1. using generics all the time (gak!)
08 <jdeolive> for datastore
08 <jdeolive> and everything else is prameterized
08 <jgarnett> 2. an abstraact one, and then a specific subclass for SimpleFeature/SimpleFeatureType (minimum I would accept)
08 <jgarnett> 3. or three a common super class for both the SimpleFeature and the Feature case.
09 <jgarnett> nope 1 datastore and generics will not cut it, you can do two at a mimum.
09 <jgarnett> and limit generics to the Query object.
09 <gabriel> jdeolive wanted to mean your 2.
09 <gabriel> no?
09 <gabriel> no, sorry
09 <jdeolive> wait lets back up for a sec
09 <jdeolive> we have two alternatives right?
09 <jgarnett> let me hunt down the names we used in email; or I will go insane...
09 <jdeolive> jgarnett: we are summing up here for you
09 <jgarnett> we have 4 alternatives
09 <jdeolive> that will just confuse more
09 <aaime> jgarnett put on the table
10 <aaime> the fact we should parametrize Query too
10 <jdeolive> can we levae that out please
10 <aaime> to make it use Name instead of String
10 <jdeolive> or at least move it to a new agenda item
11 <jdeolive> agreed?
11 <gabriel> jgarnett: in your alternative 4 page, I can't use current DataStores as Data instances
11 <jgarnett> sorry; I went away to write up the hybrid approach in order to talk about it with everyone. I know that made me miss a lot of the conversation here but I though it was worth it.
12 <jdeolive> jgarnett: i am trying to sum it up for you!!
12 <jgarnett> okay ...
12 <jdeolive> so shall i continue?
12 <jdeolive> i want to make sure we are all on the same page here
12 <jgarnett> please; I am only listening to you for now
12 <jdeolive> gabriel + aaime?
12 <gabriel> go ahead please
12 * jdeolive wishes there was a puppet to pass around to know who the speaker was
13 <jgarnett> re /nick yourself as puppet
13 <jdeolive> haha
13 <jdeolive> anywho
13 <jdeolive> ok
13 <jdeolive> so we seem to have boilked it down to two approaches
13 <jdeolive> the first
13 <jdeolive> is a new layer layer of super interfaces for DataStore, FeatureSource, and everything else
13 <jdeolive> the reason being
14 <jdeolive> that we cannot be backwards compat about everything without them
14 <jdeolive> the second al;ternative
14 <jdeolive> is to just have a superinterface for DataStore
14 <jdeolive> with parameters for Feature and FeatureType
14 <jdeolive> the subclass (DataStore)
14 <jdeolive> narrows all teh parameters to SimpleFeatureType and SimpleFeature
14 <jdeolive> the problem with this
14 <jdeolive> is that this code will no longer compile
15 <jdeolive> FeatureSource s = datraStore.getSchem(...)
15 <jdeolive> SimpleFeatureType sft = s.getSchema()
15 <jdeolive> sorry, that should have been dataStore.getSource(..)
15 <jgarnett> yes, got it.
15 <jdeolive> but this is nice
15 <jdeolive> because we only have one FeatureSource class
15 <CIA-23> simboss 2.4.x_rs * r29131 geotools/modules/library/render/src/main/java/org/geotools/renderer/lite/gridcoverage2d/ (12 files in 2 dirs): -committing latest bunch of work on RasterSymbolizer
15 <jdeolive> but its not 100% backwards comat
15 <jdeolive> however
15 <jdeolive> the changes are purely machanical
16 <jdeolive> s/FeatureSource/FeatureSource<SimpleFeatureTYpe>/g
16 <jdeolive> done
16 <-- simboss has left this server ("ChatZilla 0.9.80 Firefox 2.0.0.11/2007112718").
16 <jdeolive> jgarnett: does that make sense?
17 <jdeolive> gabriel: did i sum it up propperly?
17 <gabriel> yes
17 <jgarnett> thinking
19 <gabriel> time to choose your poison
19 <jgarnett> okay I understand.
19 <jdeolive> cool... so an informal vote
19 <jdeolive> a or b
19 <aaime> the changes are a little more
19 <jgarnett> discussion
19 <aaime> you have to change FeatureStore and FeatureLocking as well
20 <jdeolive> aaime: elaborate
20 <jdeolive> right
20 <aaime> in all places where they are used as variables
20 <aaime> and as implements
20 <jdeolive> FeatureREader as well
20 <jgarnett> okay; can I run through something now justin.
20 <jdeolive> but all of them are simple a regex
20 <aaime> FeatureREader would need 2 params
20 <aaime> ugly
20 <jgarnett> I can respond to what you outlined first if you want.
20 <jdeolive> jgarnett: go ahead
20 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
21 <jgarnett> I will respond first; then I really want to go over the hybrid thing with you.
21 <jgarnett> (just focus on the Query when you read that page)
21 <jgarnett> response.
21 <jdeolive> i am not even thinkng about that yet
21 <jdeolive> completely seperate issue in my mind
21 <jdeolive> i cant do this meeting if we go on tangents
21 <jdeolive> its hard enough keeping things straight as it is
21 * jdeolive is done
21 <jgarnett> okay so we have a couple of things on the table that people want to think about; you are focused on the number of classes
21 <jgarnett> and I am focused on the number of generics
22 <jdeolive> it is more than the number of classes but continue
22 <jgarnett> I like you reducing the number of classes to 2
23 <jgarnett> It is going to be really tempting to make SimpleFeatureReader extends FeatureReader<SimpleFeature>; even though it does not add anything.
23 <jdeolive> i could go for that since as andrea says... it will need two parameters
23 <jdeolive> which is ugly
23 <jgarnett> is there anything else you wanted me to get out of your proposal?
24 <jdeolive> just one
24 <jgarnett> It is a nice breakdown; I like "two" classes rather than "three" (an abstract interface is not fun)
24 <aaime> jdeolive, try to make that a subclass and see if the single layer of interfaces still works
24 <jdeolive> that hte reason i am against it is that another layer of abstraction i think really makes things messy
24 <jdeolive> aaime: you dont think it will work?
24 <aaime> I'm not sure
24 <jdeolive> i guess it wont...
25 <jgarnett> what is? the abstract super class? yes I just used it for the hybrid page because that is what gabriel had.
25 <aaime> I think having one subclass will force you to make the others as well
25 <jdeolive> i have an idea for FeatureReader though
25 <aaime> jgarnett, having a reader subclass to avoid the two params that the generic version would need
26 <jdeolive> we could forget about paramaterizing FeeatureType...
26 <jdeolive> but again that would be a breakage... a mechnical one.. but
26 <gabriel> ok, now the conv seems to be going trhou decreasing the use of generics, before it was towards increasing it
26 <jgarnett> gabriel there are different motivations afoot.
27 <gabriel> still I agree with jdeolive on choosing between alternatives a or b
27 <jgarnett> so far I think going with a two class approach seems fine.
27 <jdeolive> yeah we should first determine if some mechanical breakage is acceptable to people
27 <jgarnett> justin I would prefer mechanical breakage over more moving parts.
27 <jdeolive> as would i
27 <jdeolive> so that is two votes for b
27 <jgarnett> let me know when we can talk about generics
28 <jdeolive> aaime and gabriel
28 <jgarnett> it is odd for me justin; I feel like I am voting on something that does not matter to me
28 <jgarnett> ie
28 <jdeolive> this is note a vote
28 <jdeolive> call it a "preerence" if it makes you feel better
28 <jgarnett> okay my preference is two fold:
28 <jdeolive> jgarnett: can you wait for gabriel and aaime
29 <aaime> jdeolive, I'm pretty much twisted
29 <jgarnett> - a single super class using the minimal amount of generics
29 <jgarnett> - use generics only for parameters like Query
29 <aaime> I don't want to see a one km long param list in the code
29 <jdeolive> aaime: nor do i
29 <jgarnett> aaime++; I don't think we need to. only forced into parameters for things like Query
29 <jgarnett> (codehaus is down)
30 <gabriel> I feel better with superinterfaces only for datastore/source/store/locking and being backwards compatible
30 <jdeolive> its hard to make that judgement until we actually look at some code though...
30 <aaime> but the generics proposal seems to to ask for a long param list?
30 <jgarnett> but the hybrid proposal does not
30 <jgarnett> generics proposal is over kill
30 <jdeolive> two params at hte most
30 <jgarnett> I only have one justin; what are the two for you?
30 <jdeolive> jgarnett: not sure what you mean
30 <aaime> All in all I prefer the class hierarchy
30 <jgarnett> yes; I don't think you know what I mean.
30 <aaime> it makes the simple case real simple
31 <gabriel> the hybrid proposal as it is does not buys me out of the box usage of current datastores as generic ones
31 <aaime> and the complex case equally simple for the client
31 <aaime> with minimum amount of extra work for implementors
31 <jdeolive> ok.. it seems we moved to 3 alternatives now...
31 <jgarnett> gabriel let me update the page; and remove the code examples
31 <jgarnett> I am doing a bad job of them and they are loosing the point.
31 <gabriel> take your time, np
31 <jdeolive> jody, that page with Query in it is useless to this discussion imho
32 <aaime> jgarnett, even to me, it seem Query could be discusse after we have chosen a path on the general architecture (or not?)
33 <aaime> yet, Query parametrization would bring the number of params to two for DataStore and co
33 <gabriel> it seems to me jody is using query as to reduce the ammount of parametrization
34 <jdeolive> i fail to see the point of parameterizing query...
34 <jgarnett> justin we are coming at this from different angles
34 <jgarnett> okay let me try again ...
34 <aaime> jgarnett has added a param over a non parametrized version so it's adding one, not removing
35 <jgarnett> - generics for Feature and FeatureType are not needed; that can be covered with type narrowing
35 <aaime> (as far as I can see)
35 <jgarnett> - we only need generics for the method parameters: Query
35 <jgarnett> that is the trade off I am trying to see discussed.
35 <jgarnett> I have updated the page to reflect a single super class now.
35 <jdeolive> you want to param Query for coverage stuff?
35 <jgarnett> (but codehaus is not happy_
35 <aaime> jgarnett, what is the query param used for, to start
36 <jgarnett> getFeature( Q query )
36 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
36 <jgarnett> sorry getFeatures
36 <jgarnett> or getFeatureReader
36 <jgarnett> I don't really mind what is returned; because we can type narrow the return value
36 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
36 <gabriel> the problem is not getFeatures but, say, addFeatures(FeatureCollection) and the like as far as I can tell?
36 *** zzorn_away is now known as zzor.
36 *** zzor is now known as zzorn.
37 <jdeolive> ok... seems this conversation has gone a stray
37 <jdeolive> sigh...
37 <jdeolive> i thought we were making headway
37 <aaime> jgarnett
37 <jgarnett> justin this is the only conversation I have been trying to have.
37 <aaime> that is not telling me why you need params in Query
37 <jgarnett> do we have an agenda if so I can put it on the agenda.
37 <jdeolive> I ASKED YOU TO DO THTA BEFOER!!!!
37 *** jgarnett sets the channel topic to "1) main goals 2) super class 3) generics".
37 <jgarnett> done
38 <jgarnett> I assume we are on 2) and I should be quiet for a bit.
38 <jdeolive> we were trying to figure out what people valued more
38 <aaime> jdeolive, it seems to me Query parametrization is relevant to generics, because it could be implemented in your generic only approach
38 <aaime> but it would add a new type param
38 <jdeolive> backwar compat, or cleaner api
38 <jdeolive> cleaner being a relative term i admit
39 <aaime> too many params == not clean (imho)
39 <jdeolive> i know that
39 <jdeolive> sorry
39 <jdeolive> can you make me understand why we need to parameterize query?
39 <jgarnett> justin I would prefer a clearer api; a mecanical upgrade process (as clients move to Java 5) is an acceptable thing.
39 <jdeolive> i mean... why do we want a subclass superclass of it?
39 <jgarnett> indeed clients would prefer we use Java 5 to clean up the API.
39 <aaime> jgarnett, you're dodging the question
39 <jgarnett> that is my preference. is that what you wanted to know?
40 <jdeolive> jgarnett: yes, thank you
40 <aaime> what are the params in Query for
40 <jgarnett> andrea; I am in trouble for talking about Query; I am going to try and stick to the agenda.
40 <jdeolive> well no, i need to understand this
40 <jdeolive> because there is something fundamental that i am missing
40 <aaime> please Jody
40 <jgarnett> okay
41 <jgarnett> full on generics is a bit of a pain; so I would like to reduce our use to only the places that we are forced it.
41 <jgarnett> the only place I am forced to is on method parameters
41 * jdeolive starts to beat his head against his desk
41 <aaime> right, still does not tell me why do you need to subclass Query?
42 <jgarnett> I need to super class Query
42 <aaime> whatever, why??
42 <jgarnett> so we can gave List<Name> getNames()
42 <jgarnett> because String[] does not cut it for the Feature case.
42 <jdeolive> dude
42 <jgarnett> String[] only works for SimpleFeature right?
42 <jdeolive> deprecate the method that returns straings and add a new one
42 <jdeolive> which returns Name
43 <jdeolive> jgarnett: no
43 <jdeolive> SimnpleFeature works with Name as well
43 <jgarnett> yes I know that justin
43 <jgarnett> but as a way for users to say what they want
43 <jgarnett> providing us with a String[] is only good when working against SimpleFeature
43 <jgarnett> (other than that we need more from them: List<Name> )
43 <jdeolive> yes i realize that
43 <jgarnett> okay.
44 *** You are now known as groldan.
44 <aaime> a convinience constructor that accepts String[] and turn it into
44 <jdeolive> so why do we need a subclass to do that?
44 <aaime> List<Name> would do the trick for the users no
44 <groldan> even more
44 <jgarnett> we don't we need a super class; when working against Feature
44 <groldan> we'll need Query.getNamespaceContext() or such
45 <jdeolive> sure, lets make the mods to Query we need to
45 <jdeolive> not subclass it and parameterize it in the rest of the api
45 <jgarnett> basically I need a palce for gabriel to define what it means to query Feature content (rather than SimpleFeature)
45 <aaime> and keep it one interface
45 <jdeolive> that seems crazy to me
45 <jgarnett> so it sounds like you would like us to mod Query ?
45 <jdeolive> please!!!!
45 <jgarnett> okay
45 <jdeolive> why would you not do that?
45 <aaime> lol
45 <jdeolive> and better question
45 <jgarnett> so justin before you go insane.
45 <jdeolive> why would you think i did not want you do thaty?
46 <jgarnett> because we like to do this generic case, and then add more stuff for the simple case.
46 <aaime> is that really necessary
46 * jdeolive thinks he is speaking in klingon
46 <jdeolive> anyways
46 <aaime> ka-pla!
46 <jgarnett> okay
46 <jgarnett> stop
47 <jgarnett> you are getting distracted by Query
47 <jgarnett> and missing the point
47 <jdeolive> we agree ont hat
47 <jgarnett> that we can limit generics to method parameters only.
47 <jgarnett> that was the only point I was trying to make.
47 <groldan> jody's approach begs for "cleaner api", jdeolives for "pragmatic one"
47 <groldan> where cleaner keeps being a relative term
47 <aaime> the point is that in a pure subclassing approach we don't need generics at all afaik
48 <jgarnett> we still need them; but only when we got parameters.
48 <aaime> grrr
48 <jdeolive> right... but that is for simple feature vs feature... why does query even enter into it
48 <jgarnett> gabriel point out that addFeatures( ... ) would need one.
48 <groldan> jgarnett: limiting generics to method parameters only lead me to the ugly stuff on the page
48 <jdeolive> ok
48 <aaime> but we are saying there is no need for that
48 <jgarnett> query was just an example.
48 <jgarnett> you killed it as an example.
48 <groldan> like the parameters that need to be parametrized are FeatureCollection and FeatureReader
48 <jdeolive> ok, can we stop talking about it then?
48 <groldan> more then query
48 <aaime> jgarnett, we don't need out of the blue examples
48 <aaime> we need a solid proposal on the datastore issue
48 <jdeolive> aaime: well put
49 <jdeolive> ok, we are going in circles
49 <aaime> and as I see it, we don't need params at all in the
49 <jgarnett> well I asked for this to be written up and it wasn't so I am scrambling here andrea.
49 <aaime> we dont' need params at all in the case where we do two layer approach
49 <groldan> yeah, hadn't real time to do so jody, my bad
49 <jgarnett> I am trying to offer an alternative to generics.
49 <aaime> since all the type narrowing we need is on return types
49 <jgarnett> aaime++
50 <jgarnett> (thank you that is all that I was trying to communicate)
50 <jdeolive> wow, you could have done that way easier
50 <jdeolive> moving on
50 <jgarnett> well it was not working for me
50 <jdeolive> so i think we need to code up some examples
50 <jdeolive> i volunteer to code up the generic case
50 <jdeolive> keep in mind
50 <jgarnett> can we make a spike directory?
51 <jdeolive> sure
51 <jgarnett> yeah this conversation would of gone better in code
51 <aaime> can we do the same examples in both cases
51 <jdeolive> aaime: great idea
51 <aaime> so that it's easy to see the differences
51 <aaime> and each camp will try to make up examples
51 <jdeolive> works for me
51 <jdeolive> idea
51 <aaime> that show the shortcomings of the other
51 <jgarnett> andrea can we do the minimal generic case together?
51 <jdeolive> can we just spike the api module and do the work?
51 <aaime> in the end we should end up with a nice comparison
51 <jgarnett> I got lots of work to do...
52 <jdeolive> jgarnett: that is fine, can handle this one
52 <jgarnett> and I don't want to put ideas into danger just because I have no time.
52 <jdeolive> with some help from gabriel coming up with the superclass case
52 <jgarnett> both of them?
52 <aaime> jdeolive does generics
52 <jgarnett> okay...
52 <groldan> since I already have some code
52 <aaime> gabrie does subclass?
52 <groldan> why don't I move it to spike
52 <jgarnett> good thinking
52 <groldan> I do subclass
53 <aaime> jdeolive, groldan
53 <jdeolive> agreed
53 <aaime> it would be nice to have a page listing code exemplars
53 <aaime> both cases side by side
53 <jdeolive> aaime: i will do better and actly write code that compiles against api
53 <groldan> I had sample implementations of them, that may count as code examples, or implementation examples
53 <groldan> had = have
54 <aaime> Well, in that case, two java files side by side doing the same things with both approaches?
54 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
54 <jdeolive> aaime: sure
54 <jgarnett> so the next IRC breakout will really be a bake off.
55 <groldan> sooo, I do DataStore/source/store/locking superclasses with FeatureType/Feature parametrization on the general case and no parametrization on the simplefeature case
55 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
55 <aaime> groldan, you don't need to parametrize at all
55 <aaime> afaik
55 <aaime> all your params are hitting return values
55 <aaime> you can just type narrow them
56 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
56 <groldan> that was the original idea!
56 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
56 <groldan> then it came out we needed to parametrize some arguments
56 <jdeolive> i think we are getting confused
56 <groldan> like for modifyFeatures(FeatureCollection)
56 <aaime> groldan, keep it simple
56 <jdeolive> there are actually 4 things here
56 <jdeolive> pure subclass
56 <jgarnett> you can always have the subclass accept more parameters
56 <jdeolive> subclass all interfaces with some paraming
57 <jdeolive> paraming with one subclass
57 <jdeolive> and all paraming
57 <jdeolive> actually... all paraming wont work
57 <jdeolive> so i guess there are 3
57 --> pramsey_ has joined this channel (n=pramsey@mail.refractions.net).
57 <aaime> groldan, so the need for params comes from FeatureStore?
58 <groldan> hmm yes
58 <groldan> afaik
58 <aaime> then can we just param that one?
58 <aaime> and leave the rest param free?
58 <groldan> hmmmm not sure
58 <groldan> guess not
59 <aaime> why not?
59 <-- pramsey has left this server (Read error: 113 (No route to host)).
59 <CIA-23> jdeolive * r29132 geotools/spike/jdeolive/api/: creating api spike
59 <groldan> at least not with a single getFeatureSource() method
59 <aaime> hum... well, we could overload instead of param in the subclass no?
59 <groldan> overload was the first approach, yes
00 <aaime> why was it rejected?
00 <CIA-23> jdeolive * r29133 geotools/spike/jdeolive/ (3 files): removing unused spike classes
00 <aaime> we have custom methods in SimpleFeature as well
00 <groldan> guess it was jdeolive?
00 <groldan> not really sure though
00 <aaime> I guess he was misunderstood
00 <aaime> in his attempt to present a single layer approach
01 <aaime> with params everywhere
01 <jdeolive> sorry, i am lost here
01 <-- cholmes has left this server (Read error: 104 (Connection reset by peer)).
01 <groldan> there's a way to have superclasses with no parametrization
02 <jgarnett> not sure; the compiler will know
02 <groldan> that means FeatureStore ends up with overloaded methods for addFeatures and modifyFeatures
02 --> cholmes has joined this channel (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com).
02 <aaime> we have two ways to get attribute value in SimpleFeature
02 <jdeolive> akk... that seems ugly to me
02 <groldan> but that also meanse superclass for FeatureReader
03 <groldan> and FeatureCollection
03 <jdeolive> also somethign to keep in mind
03 <aaime> not more, not less than all the extra methods
03 <aaime> that are in simpleFeature?
03 <jdeolive> is that we are stuck with this api forever... backwards compat is only for one release
03 <aaime> same goes for SimpleFeature
03 <aaime> (or not?)
03 <groldan> no
04 <groldan> let people that don't care about complex feature keep things working
04 <aaime> see here: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/feature/simple/SimpleFeature.html
04 <aaime> how many ways we have to get an attribute value in simple feature?
04 <groldan> as junit did for your tests
05 <aaime> lots because we have various getAttribute but also getProperty (coming from Feature)
06 <jgarnett> um question: what is going on? I thought this meeting was done ... are you guys designing the low-generic alternative now?
06 <groldan> we're running in circles
06 <aaime> we just kept on talking about the low generic alternative, yes
07 <groldan> once upon a time there were two alternatives that ensured the goals on my page were met, and the tradeoff was to choose over more generics or more superclasses
07 <groldan> more generics sort of dropped by its own weight as client code breaks
08 <groldan> but then a simple regex replace seemed fine
08 <groldan> and we were to choose one
08 <groldan> now we're getting again to a point where we focus on single spots loosing the big picture
08 <groldan> imho
08 <aaime> a proposal is made of big picture and details
09 <aaime> but the proposal having a big picture ok and details broken is useless imho
09 <aaime> (that is useful for discussion, not for implementation)
09 <jgarnett> okay so we are trying to move this discussion into code
09 <jgarnett> can we do that; and just keep with IRC / Skype windows going.
10 <aaime> well, I'm personally out of time
10 <aaime> dinner and then tennis
11 <aaime> (and then sleep, but I can pop in again for half an hour )
11 <groldan> no, give us time to digest it
11 <groldan> and arrange for tomorrow
11 <groldan> so eouropeans do not need to stay up till 5 am again
11 <groldan>
11 <aaime> ha ha
11 <aaime> I won't for sure
12 <aaime> I worked up to 1am yesterday
12 <jgarnett> thanks guys.
12 <aaime> and I've been sleepy all the day
12 <aaime> I need to sleep a lot
12 <jgarnett> worked? I though you were just hating referencing code?
12 <aaime> like a small child
12 <groldan> lol
12 <jgarnett> (some kind of Itallian excuse for fun)
12 <aaime> hammering it
12 <aaime> I actually fixed it in fact
12 <groldan> so I can compromise to code a spike and put it on svn
12 <jgarnett> yes; aaime++ thanks!
13 <aaime> groldan, sure
13 <groldan> just tell me which one
13 <groldan> or since its my proposal I can do both
13 <aaime> the full generics one is being done by Justin
13 <aaime> you do the others
13 <groldan> k
13 <groldan> full generics with simple superclass for datastore
14 <groldan> justin knows how to choose early
14 <aaime> do what you feel it's good
14 <jdeolive> groldan:
14 <aaime> there no point in coding something you hate
14 <aaime> can a painter paint a subject he does not like?
14 <groldan> so I'll take the fully backwards compatible now
14 <aaime> exactly
14 <groldan> and call it a tennis match (ie. made between gentleman)
15 <aaime> why not
15 <aaime> some sane competition does not hurt
15 <groldan> or I'll need to choose my side of the playing field again
15 <groldan>
15 <groldan> thanks guys, it was an amazing meeting
15 <groldan> two hours long
16 <groldan> same bat-hour same bat-channel?
17 <groldan> aaime, jdeolive, jgarnett?
17 <jdeolive> hi
17 <groldan> I know I'm bad at jokes, yet please confirm
17 <jdeolive> sounds good to me
17 <groldan> cool
17 <jgarnett> hi
18 <jgarnett> gah!
18 <jgarnett> same time tomorrow? okay ...
18 <groldan> cool, with code at hand
The meeting that did not fit into the meeting ... conversations on DataAccess and GridAccess with jgarnett, acuster, simone and grabiel. This conversation will be documented as a proposal for a an IRC breakout later in the week.
simboss: jgarnett
simboss: got 5 minutes?
desruisseaux: Maybe a few minutes while I'm shuffing down my other applications...
desruisseaux: I need to leave. Bye all!
pramsey left the room (quit: Read error: 104 (Connection reset by peer)).
jgarnett: hi
desruisseaux left the room (quit: "ChatZilla 0.9.80 Firefox 2.0.0.11/2007121614").
pramsey n=pramsey@mail.refractions.net entered the room.
jgarnett: I am here simboss; sorry this meeting was such a mess.
jgarnett: I really wish the xml binding stuff was solid.
simboss: np
simboss: quick question
simboss: on coverage data access
simboss: I have been willing to start writing up a proposal for years
simboss: byut anyway
simboss: I have been thinking lately
simboss: about it for toher reasons
simboss: if you factor out dataaccess
simboss: you envision
simboss: the possibility that coveragestore
simboss: will be a child of dataaccess?
jgarnett: nope; I tried that and people did not like it enough to give me feedback.
jgarnett: I think gabriel's idea of
jgarnett: taking what WCS needs may be better.
aaime: simboss, something based on wcs spec could have various benefits
aaime: 1) shared understanding (the spec is one and it's there, no need to write one)
aaime: 2) easy to code wcs on top of it
aaime: 3) wcs extraction is powerful
jgarnett: we can take the same general apporach; a CoverageAccess class that matches what a WCS service can describe; and a class
for accessing a specific coverage; with optional interfaces to reveal additional capabilities (such as overlays)
aaime: 4) we could have complex stuff like PostGrid sit behind it
aaime: (at least, I hope so)
jgarnett: yeah you guys are all on the same page.
simboss: andrea knows more or les what I have in mind
simboss: and I share his ideas
simboss: my intent is to say two things
simboss: 1>do we start pushing that a coverage is a feature subclass
simboss: 2>I would not mind having something similar to gdal/ogr dataset
simboss: I.e. a single entry point for data access
simboss: t1 and 2 can be orthogonal though
simboss: with respect to the dataaccess proposal and what aaime said
aaime: simboss, I think to have some chance of getting work done
aaime: we should try to keep the scope of a "coverageStore" as small as possible
aaime: and be sure to cover the needs of PostGRID, Oracle and SDE rasters
aaime: (and a sample directory based one too)
simboss: nothing else?
simboss:
aaime: Well, if you wanto to design a interface
aaime: you need usually at least 3 different examples no?
simboss: I think we should try and have data access as much unified as possible
aaime: hmmm... and how do you filter over coverages? using ogc filter?
aaime: (band extraction, resampling...)
simboss: that's why I am asking
simboss: the data access proposal
simboss: is too feature centric
simboss: as most part of the geotools proposal
simboss: proposals
jgarnett: thinking ...
aaime: I'd keep the two separate and have a single class implementing both if it has both capabilities
simboss: that's not dataaccess
simboss: that' feature access
aaime: but yeah, maybe some top level methods could be shared
jgarnett: I think it is a bit premature to push for coverate extends feature (but I would like to see us try).
jgarnett: something similar to data set is a good idea; I settled for a common ResourceInfo - as it is what I need today.
simboss: (I do not only think it is premature, it is something tht I do not actually like at all )
jgarnett: good thought about them being orthogonal.
simboss: long story short
jgarnett: no worries.
simboss: I don't care (actually I don't like) coverage as a feature
jgarnett: I think it has only ever been stressed since RobA had visions of using WFS query to screw around with coverages.
simboss: but I would like to have 1 single entry point for data access
simboss: that was just my humble opinion
jgarnett: well tell you what; take a hard look at gabriels data acess super class; and see if a CoverageAccess subclass based on
WCS makes sense.
simboss: I am not saying it is the best one
simboss: as a baseline datacess
jgarnett: (at the very least I don't want to hold up gabriel waiting for coverage if we don't have time to follow through)
simboss: should just tell you how to access your data
simboss: my goal is just to raise the issue
mgrant n=mgrant@norbu.plus.com entered the room.
jgarnett: gak this is too facinating a conversation not to do well. I have considered this issue twice before:
jgarnett: a) for catalog Sevice / GeoResource split (it went really well)
jgarnett: b) for DataAccess (it dies due to lack of interest)
jgarnett: gabriel what do you think?
jgarnett: andrea I like your idea;
jgarnett: there is a bit of a conflict with list of contents.
jgarnett: but you are on to something.
jgarnett: let me rant for a second.
jgarnett: if we had something like getNames(); that listed a bunch of Name
jgarnett: and a getInfo( Name ) that described the contents
jgarnett: we could have subclasses cough up additional methods
jgarnett: like
jgarnett: getFeatureSource( Name )
jgarnett: getFeatureStore( Name )
jgarnett: getCoverageSource( Name )
jgarnett: the FeatureSource / FeatureStore / CoverageSource interfaces would match up with their spec, WFS, WFS-T, WCS.
jgarnett: end rant.
jgarnett: aaime is that what you had in mind?
Eclesia: jgarnett, Idea : could there be a method in the ServiceInfo : public Map<String,Object> getConnexionParameters() ? this
way I could start to save MapContexts in files, and open them again later.
simboss: exact
simboss: that' mny idea
simboss: push down the getFeature and getSchema thing
simboss: and you have something you could use
simboss: for coverage as well
simboss: or at least
simboss: that could give you either a list of coverage names as well as a list of featuretypes
jgarnett: Eclesia; maybe. I would just as soon as see you store your own connection parameters (you need to keep datastores
around for reuse anyways). There is a class around in geotools to do this for you.
simboss: aaime, what do you think?
jgarnett: simboss I like it.
jgarnett: it is more agressive than what gabriel needs; but I like it.
simboss: well
simboss: it is more general
simboss: and it leaves room for imprvements
simboss: if we don't start thinking in a more cross-field manner
simboss: we will always end up
simboss: with having
simboss: people working on coverage which do not know anything about people working on feature
simboss: and viceversa
jgarnett: the hard part is giving enough information out of the getInfo( Name ) method that people can tell what method should
work; ie getCoverage, getFeatureSource, getFetureStore? Or perhaps that is handled via an instance of check on the DataAccess
object.
simboss: this is a small leap forward I think
jgarnett: agreed; yep.
Eclesia: There is a class around in geotools to do this for you. ? there is something to save a MapContext ?
jgarnett: nope there is something to hold onto your datastores.
simboss: I am fine with either approaches
jgarnett: I have code in udig that saves out an industry standard map context somewhere.
simboss: it is something like having getcapabilities for all services
simboss: and specific methods that distinguish them
jgarnett: okay simboss what can we do from here? we should chat with gabriel in his IRC breakout. Or maybe hack on that page
before hand ...
simboss: hack and chat
simboss: is he around now?
sfarber left the room.
acuster: call it gridcoverage unless you want to prevent vector and analytic coverages
jgarnett: groldan ping?
simboss: what do you mean acuster?
groldan: pong
jgarnett: acuster++
acuster: you are talking about access to 'image' like data right?
jgarnett: coverage is a tree data structure; similar to feature. that completely covers an area of the world.
simboss: nope
cbriancon left the room (quit: ).
simboss: whatever is a coverage
jgarnett: grid coverage is the same thing except all the shapes are rectangles.
acuster: 'coverage' in the gis world, is a very general idea
simboss: coverage like in iso 19123
acuster: which is, for example, what udig calls a 'layer'
simboss: yeah
acuster: so your 'access to image data' is not really coverage, but a subset
acuster: the modules in geotools are misnamed
groldan: catching up...
simboss: (hold on a sec, phone call.. )
acuster: jgarnett, coverage doesn't have to have any data structure
jgarnett: got it; silly question acuster; does WCS serve up coverage? or only grid coverage?
acuster: GravtiationalModelObject
acuster: good be a coverage
acuster: jgarnett, not sure about WCS
aaime: jgarnett, grid ones
aaime: georectified or not
aaime: but grid based afai
jgarnett: still; back to the general approach outlined by simboss; what do you think gabriel?
jgarnett: can we write that up before your breakout IRC; and should I post these logs since we are making progress.
groldan: ok
groldan: still catching up, but so far...
groldan: I guess what we need to filter coverages is not Filter
groldan: but rather DataAccess should focus in a Query interfaces
groldan: whichs a superclass of the current, featutre focused, query
jgarnett: still whatever we did need woudl be from the WCS spec; and would be part of a CoverageAccess interface.
groldan: yup, just that abstracting out Query gives you room to specialize as you want for coverages
jgarnett: oh I see your point gabriel; but Query does not show up in DataAccess; only in FeatureSource right ?
groldan: it shows up in Source
jgarnett: what does WCS do; what are the operations andrea?
aaime: fully different
groldan: and keep in mind I'm ignorant about coverages, so just ranting
simboss: ok back
jgarnett: aaime do we have a list of the opreations on WCS ?
aaime: rangeset extraction (covers band and subset of bands when the band is of vector type instead of, say, scalar type)
aaime: spatial subsetting: bbox, temporal
simboss: I don't think we need query or filter fo coverage data access
aaime: resampling and grid to world transformation
aaime: yep, they do not seem to fit
simboss: (or better I never thought about it )
jgarnett: robA did; it was why he wanted Coverage < Feature
aaime: for example, there is nothing like "return the pixel whose value is between x and y"
jgarnett: not sure why he wanted it; so lets ignore it for now.
groldan: ok, those are operations, not predicate based queries
simboss: yeah
groldan: but does a bbox query fit as a query?
aaime: that would be the only one that fits
aaime: but the bbox is n-dimensional
aaime: and there is a separate time dimension
groldan: and asking for just a subset of bands?
aaime: it's a lot more complicated
groldan: ok
jgarnett: catalog had a similar query; using an n dimensional bbox. to account for time.
aaime: jgarnett, in wcs time and space are separate
aaime: space can be n.dimensional
aaime: time sits on the side
aaime: they are not integrated
jgarnett: a specific Query object for this would be good then.
jgarnett: thinking; not sure how well they were intergrate for catalog; but bounds and time range were needed as part of the
query.
aaime: A CoverageQuery that does not have anything to do wtih feature one? yeah
jgarnett: agreed.
groldan: that's what I'm asking, can all that be encapsulated in a CoverageQuery or such?
jgarnett: different "Parameter Object" for a different service.
simboss: actually
simboss: overcaming the current parameter based read
simboss: is a goal for sure
simboss: it would be great having a single object
simboss: probably something like abean
simboss: to describe the actual query
aaime: yep, that would be quite an improvement
simboss: much like ImageRead param for ImageIO
groldan: cool, that sounds good to me, as feature Query and coverage Query don't even need to be in the same hierarchy
simboss: my idea was to build on that
groldan: we can parametrize them at the DataAccess level
simboss: would you write up your idea
simboss: so that I can give it a look
simboss: ?
aaime: guys, it's late for the old man
aaime: I'm gonna go bed
aaime: see you tomorrow
acuster: ciao
simboss: ciao aaime
aaime left the room.
acuster: groldan, not sure that's right. /me is getting confused by coverage vs. grid coverage
acuster: but feature Query and coverage Query are going to be similar when the day comes
simboss: grid coverage should be a coverage back by gridded data
groldan: acuster: ok, I'm on the hands of the ones that know coverage here
acuster: some day, indeed
groldan: I never took the time to understand it
simboss: much of the confusion IMHO comes from the fact that people are using terms mixed from various specs
acuster: but grid coverage today is nothing of the sort
jgarnett: guys silly suggestion
simboss: the okde one has moreor less only gridcoverage
jgarnett: would "raster" work?
simboss: old
simboss: ISO 19123
simboss: uses them all with different meaning
acuster: "grid" would work
groldan: coverage is confusing to me too, as the concept I have of it is the Arc/Info one
acuster: a coverage is a function with a domain and a range
jgarnett: cool; acuster has it; lets write this up as GridAccess ...
acuster: where all values in the domain are guaranteed to have a value in the range
groldan: understood
acuster: so arc/info was in the ball park
acuster: I'll have to think of how we query grids from a general standpoing
groldan: ok, though its not a grid
acuster: standpoint
acuster: coverages are not grids
acuster: grids can be coverages
groldan: thanks!
acuster: if they behave correctly
groldan: so are we actually sticking to grid here?
jgarnett: coverages (real coverages) are a seperate problem for another day; I am sure a DataAccess class can implement
CovreageAccess (when we make it up) and GridAccess which we define today ...
jgarnett: stick to Grid.
simboss: acuster have you seen examples of coverages backed by GML in action?
jgarnett: it is like "Raster" but shorter to type.
simboss: (curious ...)
acuster: simboss, we have the core of one coverage in geotools , the referencing3d model
acuster: a spherical harmonic model of gravitation
acuster: it's something that is in most gps units
acuster: and we have no real coverage infrastructure right now
simboss: I was curious about people experiences with coverage nto backed by matrices but by something else
acuster: but if you have a grid and a pre-defined interpolation method, all nicely bundled behind an interface
acuster: you start having a real coverage
simboss: your use of proper terminology pushed me to ask
simboss: people are trying to used fast way to encode coverage (or better gridcoverage) as GML
acuster: a shapefile can be though of as a coverage
acuster: which is why it works raw as a layer in uDig
simboss: since binary data make BPEL engines choke!
simboss: I have used shapefiles as coverage
simboss: (but it was not geotools work unfortunately )
simboss: (that was )
simboss: but I am curious if someone has started to work out coverage and GML encoding
acuster: sorry, I don't know
acuster: galdos are the folk to ask
simboss: exact
acuster: they just announced their gmlsdk
acuster: a C++ lib to chew gml
simboss: I have seen some results in one of the project s I am working
simboss: and they showed some results about encoding coverage in GML
simboss: which sounded a bit optimistic to me
acuster: we have a long way to go to handle gml
groldan: encoding coverage in gml means a lot of numerical values?
simboss: yeah
acuster: well, at the 'shapefile' like level you could do a gml coverage
simboss: they claim to be quite efficient
simboss: actually
groldan: cool, you should talk to RobA for some insights
acuster: why numeric?
acuster: ah, you are talking about grids again?
simboss: I can tell you that they stram GML files really big as a charm
groldan: and wait till I finish the BXML encoder for eficient gml
groldan:
***acuster missed that
simboss: groldan, tell me about it
simboss: where does it sit?
groldan: I'm on a project implementing the bxml spec
groldan: its a standalone library, and I'm encoding GML3 where posList for example are saved as plain double arrays
simboss: for geoserver?
***acuster curses terminology and all those who don't use exactly the same terms in exactly the right places i.e. everyone else
who doesn't share all the (wrong) ideas as his brain cells
groldan: the sponsors are the gvSig guys, though the lib has no dependency other then the jdk
simboss: that was my second guess
groldan: it's meant to work for/in geoserver in the long term, yes
simboss: that's cool
acuster: groldan, it's valid gml3?
groldan: actually I'm meant to provide a geoserver build serving bxml encoded gml
acuster: that is cool
simboss: yea it is!
groldan: its valid, since posList is of type list<double>
acuster: maybe that's what the gvSIG were trying to show me in Italy
simboss: do you know if there is the possibility to get binaryxml decoded at javascript level?
groldan: may be, as by that time the work were too in an early stage
***acuster needs to look at their work someday
acuster: or at gabriel's
groldan: I don't think at the javascript level
jgarnett: guys I need to go take a break; I will leave this on and post the good bits as "Grid IRC breakout 1"
groldan: at least the browsers makes it transparent
simboss: you mean like gzip?
***acuster needs to sleep
simboss: I did not think that would possible yet
acuster: good night all
groldan: that is, the encoding is such a detail, in the same way you can get the stream gzip encoded. If the browser supports
bxml that's it
simboss: that for sure
murray42 left the room (quit: Client Quit).
simboss: but is it supported right now?
simboss: I am not aware of any browser supporting that
groldan: although for browser support its more possible they'll support a real standard encoding some day, like the one the w3c
is working on
***Eclesia annotations +1, xml -1 
Eclesia: +++ good nigh
Eclesia left the room.
groldan: right now not afaik, like in the ogc bxml spec is just a best practices document
groldan: that cubewerx defined and use
groldan: and I guess Galdos is doing its own thing
simboss: yeah
simboss: I read that
simboss: I am curios since we mov a lot of features for measurements around
simboss: and hacing BXML would be a plus
acuster left the room (quit: "ciao all").
groldan: yup
groldan: as long as the parser leverages the binary encoding (that is, no need to translate to string and back to the primitive
types) parsing times are great
ggesquiere left the room (quit: "Bye").
vheurteaux left the room (quit: ).
groldan: though space consumption is not generally as much as gzip compressed text, it really depends on the data structures
simboss: what about
simboss: gzip(binaryxml))
groldan: the most xml tags you have, the most space you save. Same thing for number of ordinates
simboss: I have heard that=
groldan: yeah the spec allows to gzip the contents
groldan: though the impact in both parsing and encoding is high
groldan: it may be worth when bandwidth is the main concern
groldan: yet, for an OWS, I'd let the web server handle the gzip encoding
groldan: ie apache does a much better job than java
groldan: I looked around for a well performing java zlib alternative but found nothing
groldan: and GZipInput/OutputStream suck
groldan: that not to say I'm using java.nio instead of java.io
simboss: yeah
groldan: and, although still need to implement namespace support, which will impose some processing overhead, with java.nio I'm
getting better performance than the CubeWerx C implementation
simboss: cool =
groldan: jgarnett question:
jgarnett: sure
groldan: I'll be doing some datastore implementation based on a gpl library
CIA-22: robatkinson 2.4.x * r29068 geotools/modules/unsupported/community-schemas/community-schema-ds/src/test/ (34 files in 9
dirs): Updated to match final published OGC versions of schemas
groldan: guess that can't sit on the geotools svn?
jgarnett: which gpl library ?
groldan: a gvsig one
jgarnett: can it be used as a dependency?
jgarnett: gvsig people I think will sue your ass
groldan: it'll be a dependency, yes
jgarnett: but sure try it and see
groldan: no, actually they're asking me to do that
jgarnett: hrm
groldan: but I wasn't sure if possible at all
jgarnett: well it may be an interesting one; the construction of a GPL library is an odd beaste.
groldan: agreed
groldan: though I'm hands tied for the time being
jgarnett: ie what does it mean to use it? classpath exception is nice and clear for java.
groldan: repeat: agreed
jgarnett: FSF would like to see gpl library only used in gpl programs; but that is hard for dynamic libraries (and jars)
jgarnett: one easy thing to do
groldan: yup
jgarnett: is punt the library into a maven repository; be sure to include the licene info
jgarnett: and make a community plug-in that has a gpl license.
jgarnett: bit it is a slippery slope.
jgarnett: maybe make the plugin lgpl; and force it to be gpl if they ask.
jgarnett: as long as the plug-in is not providing any api; the geotools core library does not care.
jgarnett: that is the approach I used for uDig
jgarnett: when I want to create a GPL plugin.
groldan: I don't know if a lgpl plugin can use a gpl lib?
groldan: understood
jgarnett: well even so; a gpl plug-in can use a gpl library.
jgarnett: but yeah you are on a road to hell; enjoy!
jgarnett: what gvsig library?
groldan: the question is, even if the plugin is lgpl, the lib could only be used on gpl clients (ie geoserver)
jgarnett: their port of the xml binding stuff?
jgarnett: not sure about that gabriel
groldan: not a port, but yeah, that one
groldan: k, thanks for the feedback
jgarnett: if it is a problem you can always host the plug-in in the geoserver code base.
groldan: aha, that makes sense too
jgarnett: so gabriel is your "break out IRC" done
jgarnett: there are a lot of ideas there to write up.
groldan: indeed, though not sure if that'll avoid the break out
groldan: though surely will provide a lot more feed
groldan: we still miss Justin
groldan: and I don't know what mad plan he has in mind
jgarnett: well I can tell you that part
groldan: but so far mine is to make ResourceCollection NOT extend java.util.Collection
jgarnett: he wants me to admit that FeatureReader exists
jgarnett: and have FeatureSource.getFeatureReader( Query )
groldan: and make geotools FeatureCollection extend GeoAPI FeatureCollection
jgarnett: yeah we are all going down the same road here
ahughes n=andrew@202.189.75.62 entered the room.
jgarnett: he finally made a FeatureCollection that delegates EVERYTHING to feature source.
jgarnett: and the result can be resued everywhere.
groldan: yet, the very existence of FeatureCollection as the result of a query seems like an unneeded indirection
jgarnett: so hopefully at the end of the day all the ResourceCollection stuff will die.
groldan: since it ends up being a cursor api anyways
groldan: you still have to ask for an iterator
jgarnett: with one difference!
jgarnett: you can reuse it; ask for the iterator twice.
groldan: yup
zzorn left the room (quit: "Leaving").
groldan: already though about that
jgarnett: that is valuable; you can pass that thing around
jgarnett: still two goals:
jgarnett: 1. less to implement (ie just feature store)
jgarnett: 2. not make feature collection impossible (one implementation that delegates to feature source accomplishes this)
jgarnett: that is his plan
jgarnett: he would love to kill FeatureCollection;
groldan: hmmm my last two featurecollection implementations rely completely on featurereader...
jgarnett: I want to make sure that something like feature collection is posisble
groldan: is that what you mean justin is doing?
jgarnett: since that is how you will need to do assocaitions (for joins)
jgarnett: ie a lazy collection.
jgarnett: I think he was depending on FeatureSource
jgarnett: if you just dependend on FeaureReader you would need to cache the results of the first read
jgarnett: like a LazySet
jgarnett: you need to talk to justin more; sounds like you guys are duplicating work.
groldan: yeah, that
a
jgarnett: I think his stuff is in H2
groldan: it wouldn't be the first time, sadly enough
jgarnett: aside: Eclisia did give us a thumbs up on getInfo stuff
jgarnett: so I have jesse's, yours and eclisias review. time to bring over postgis getInfo etc...
groldan: I've a possible modification over ResourceInfo
jgarnett: what is it?
groldan: getName():Name instead of getName():String
jgarnett: before you go much further; look at the other information there.
groldan: there's duplication with Source.getName() afaik
jgarnett: is there not a get Namespace or something?
groldan: I guess not, at least looked for it
jgarnett: I am torn
jgarnett: I would like this one to be simple.
jgarnett: so that serviceURL#name
jgarnett: works as a URI
jgarnett: really feature type, service and resource need seperate identifiers
groldan: but its not that easy
groldan: uri#topp:states works as id
groldan: though still need the Name to hold the qualified name
groldan: so you're not doing dark tricks with the names
jgarnett: question
jgarnett: does not topp
jgarnett: stand for the namespace?
groldan: nope
groldan: just for the prefix
groldan: though
jgarnett: right the prefix; indicating the namespace uri
jgarnett: and that is available already in getInfo()
groldan: doing real namespace work, you can change the prefix
jgarnett: so you have everything you need.
groldan: where's a ns by prefix lookup in getInfo()?
jgarnett: ie name and namespace uri are already available.
jgarnett: there is none; prefix is something that only lasts for the duration of an xml document
jgarnett: it is not part of the formal model.
jgarnett: you can have a global one for geoserver if you want.
jgarnett: (honest answer; may not be useful)
groldan: no I don't want, I want to play fair
groldan: ie, a WFS request changes the prefix, its resolved to the correct namespace from the same WFS query, and my featuresouce
can be asked
jgarnett: still
jgarnett: what?
jgarnett: sorry reading again.
groldan: agreed prefix is out of the equation
jgarnett: yeah I get it; the wfs request can specify any prefix; you need to resolve it to a namespace. got it.
jgarnett: sorry gabriel I don't have the info code in front of me.
jgarnett: but I did try to make the namespace and name available somewhere in there.
groldan: np, I need to go bed anyway
groldan: thanks for the chat, gonna update the proposal tomorrow
groldan: and call Justin to chime in
Weekly meeting:
- what is up
- contact commiters
- bbox
- data access
- jaxb annotations
groldan: ah, it seems codehaus decided to get back to business just for the meeting time, to be sure I can't get the proposal ready for the meeting...
jgarnett: well start typing
jgarnett: go gabriel go
groldan: doing it in a sprint.. yeah
jgarnett: well lets start an agenda
jgarnett has changed the topic to: 0) what is up
jgarnett has changed the topic to: 0) what is up 1) contact commiters
desruisseaux: 2) (minor data) standard argument ordering for envelope / bounding box
desruisseaux: (typo: minor question)
groldan: N) DataAccess proposal to enable complex feaures
groldan: (by N I mean keep the topic being the last one so I update the page on the fly)
jgarnett has changed the topic to: 0) what is up 1) contact commiters 2) bbox
desruisseaux: 3) JAXB Annotations on metadata
jgarnett has changed the topic to: 0) what is up 1) contact commiters 2) bbox 3) data access
aaime [n=aaime@host195-44-dynamic.3-87-r.retail.telecomitalia.it] entered the room.
aaime: Hi
jgarnett has changed the topic to: 0) what is up 1) contact commiters 2) bbox 3) data access 4) jaxb annotations
jgarnett: hi andrea
aaime has changed the topic to: 0) what is up 1) contact commiters 2) bbox 3) data access 4) jaxb annotations 5) coverage evolution
jgarnett: well lets get this game on ...
jgarnett: 0) what is up
jgarnett: jgarnett - patching jts 1.9 with axios code (really!)
desruisseaux: Martin: trying to figure out why JAI's "Piecewise" operation (an optimization in the "sample to geophysics" transform) produces different numbers than what I would expect...
simboss: (can you tell something about afterwards, I had similar problems this summer...)
desruisseaux: (thanks Simone)
***aaime dying to get 1.6.0 out, and working on some paid stuff
sfarber [n=sfarber@88-149-177-23.static.ngi.it] entered the room.
Eclesia: Johann sorel : selectableMap2D and editableMap2D nearly finished
groldan: gabriel: getting FGDC sample WFS 1.1 server rendered in udig and setting up proposal to enable complex features on trunk
jgarnett: wow that sounds busy!
jgarnett: 1) contact committers
jgarnett: I sent an email out; lists the handles of committers who I have been unable to contact.
chorner: looks like some udig committers on there
jgarnett: Some people I know (like IanS) but have been unable to find a recent email address for.
jgarnett: I had Jesse go through the list; if you recognize anyone please let me know and I can move their name.
jgarnett: (just send me a reply to that email)
jgarnett: and thanks!
mgrant left the room (quit: Excess Flood).
chorner: deslinger can be removed
chorner: (summer of code - udig)
chorner: anyhow... assuming this is going to email
jgarnett: cool.
jgarnett: that is all; I need everyones help on this one.
jgarnett: 3) data access
desruisseaux: We skipped 2?
jgarnett: doh!
jgarnett: 2) bbox
jgarnett: (bad jody no cookie)
desruisseaux: Do I'm right in assuming that argument is usually (xmin,ymin,xmax,ymax) except it JTS?
desruisseaux: (or width,height)
jgarnett: not really; x,y, w, h is even more common.
aaime: You're correct but... did that interface get out before 2.4.x?
jgarnett: I would write the constructor off as a lost cause.
desruisseaux: GeographicBondingBoxImpl constructor is there since 2.1
acuster: boxes are 3d; rectangles 2d
desruisseaux: Thats the ISO name and is 2D...
jgarnett: lol; that makes sense - I never got that before.
aaime: if it has been there for so long, I would not change it
aaime: but add an alternate constructor with 2 points instead
desruisseaux: The question is related to what should be ordinates order in toString() output
aaime: make the tostring output a little more verbose and unmistakeable maybe?
desruisseaux: yes all right, but still which order?
aaime: (xl: 0, yl: 0, xm: 10, ym: 20)
aaime: I'd say xmin, ymin, xmax, ymax, I agree that it's more readable
desruisseaux: I'm fine with that, so this means changing the order of current GeographicBoundingBoxImpl.toString()
jgarnett: aaime++
aaime: it's just that breaking the code in a way that does not even break compilation is subtle
jgarnett: ( xmin - xmax, ymin - ymax ) is a good alternative; use '-' to represent a range rather than a comma.
desruisseaux: Well, maybe I will write a wiki and ask what peoples wish. My wish was just to have a consistent approach in Geotools
desruisseaux: I'm done (will write a wiki or something else)
desruisseaux: 3) data access
aaime: what is this?
groldan: mine
jgarnett: gabriel ?
groldan: http://docs.codehaus.org/display/GEOTOOLS/Data+Access+API+for+ISO+Coverage+and+ISO+Feature
groldan: ok, sorry I didn't get it done for the meeting time
groldan: yet it deserves some discussion
jgarnett: should rename it so it does not mention coverage
groldan: indeed
groldan: the proposal goes on the lines of what we discussed last week at the udig meeting
asantiago [n=asantiag@89.131.54.194] entered the room.
groldan: and the idea is to enable the smooth integration of geoapi Feature/Type into geotools trunk
jgarnett: gabriel can we have a breakout on this one; Justin also has some proposal he is writing up on a related complaint.
jgarnett: http://udig.refractions.net/confluence/display/UDIG/2008/01/24
groldan: driving needs being having to start dealing with WFS instances already serving complex featues
groldan: sure, that would be great
mgrant [n=mgrant@norbu.plus.com] entered the room.
jgarnett: it is just that it will be hard to handle this topic in the IRC meeting without that proposal page.
groldan: but at least I'd like to get from this meeting a sense of what people think
jgarnett: one question; what is your timeline on this one?
groldan: the usual, asap
jgarnett: I am still playing catch up on the getInfo proposal (also done for your timeline).
aaime: From where I stand I would prefer to have DataStore and co use Feature and FeatureType instead of simple, and let subclasses restrict the return values instead
groldan: this one includes the getInfo proposal I guess?
aaime: but I admit I haven't tought much about it
jgarnett: Eclsia gave me a good review of the work thus far; so I will finish up the getInfo work
simboss: are you planning on doing some work for coveages?
pramsey left the room (quit: Read error: 104 (Connection reset by peer)).
jgarnett: nope getInfo is already been and gone; the work is happening (but could use your help!)
aaime: jgarnett, did we vote the proposal?
pramsey [n=pramsey@mail.refractions.net] entered the room.
simboss: sorry, this question is related to the proposal page above
jgarnett: I am not planning any work for coverages; there is a proposal page there based on WCS; but until the coverage guys want to play I would like to live it out of this.
jgarnett: simboss the page has not been renamed yet.
jgarnett: gabriel can I rename that page now?
groldan: go ahead
aaime: yes, it was voted, ok
groldan: andrea having the current DataStore work on Feature/Type instead of Simple would just break too much code (all geotools data code) afaik
jgarnett: andrea; making use of FeatureType and Feature would be okay; but would break client code. Making a super class DataAcess and then making DataStore extend DataAccess seems a good compromise?
groldan: what I'm looking for is for a smooth integration
aaime: why, doesn't the counter variance work since we are on java5?
aaime: datastore clients will be broken, not datastores themselves
jgarnett: well I assume there is more client code; and it is more expensive to update.
groldan: that's it. Being a library we should care about clients
groldan: imho
aaime: jgarnett, it means the client code will have to choose which path to work on?
groldan: there's another reason too
jgarnett: confused; andrea are we talking about the same approach?
aaime: yes
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/Data+Access+super+class+for+DataStore
groldan: which is to allow the smooth upgrade of client code that only knows how to deal with simpleFEature
aaime: you will be forcing the client to decide wheter to use the simple interfaces or rewrite to the new ones?
jgarnett: ah
jgarnett: I will not be forcing the client code to do anything
jgarnett: there is no need to change unless you want to work with complex data.
groldan: breaking the current API that way does not ensures clients that if they are set up to work with simple features they get back only simple-feature capable datastores
aaime: moreover, this will mean we'll have both around for... a very long time, right?
groldan: the other way, they can switch to work over the more generic Feature once they're ready, and keep getting only simple-feature capable datastores in the while
mgrant left the room (quit: Excess Flood).
jgarnett: (andrea undestand that I like your idea; less classes at the end of the day is a good thing - the decision comes down to how nice we want to be. We found that SimpleFeature was worthwhile because we could offer additional methods; can DataStore offer additional methods because it is restricted to simple content?)
asantiago left the room.
jgarnett: andrea you are correct; we would have both around forever. An intentional design choice; designed to take advantage of the fact that DataStore is restricted to SimpleFeature.
aaime: I see the DataAccess thing still has the most ominous mistake in our current DataStore api
aaime: no distinction between read only and read write access
jgarnett: keep talking
groldan: isn't that handled at the FeatureSource/Store level?
aaime: but you cannot say you just want a FeatureSource
aaime: you may get a FeatureStore and pay the price for it
groldan: ie. for a given DataStore, some FeatureSoruces may be editable, others not. Think of db user priviledges
jgarnett: ah
groldan: ok, got your point
jgarnett: does not getView( ... ) cover this case ?
aaime: not only the price, but also the risk
jgarnett: I get your point; and am not convinced that getView is explicit enough. But it is an option available now.
aaime: there is nothing using getView, not even sure it works properly
jgarnett: it works; uDig uses it.
aaime: we're talking about the future, not about now
jgarnett: to great effect I may add.
jgarnett: fair enough.
jgarnett: okay sounds good; we should add a getFeatureStore( Name ) method.
aaime: what about getFeatureSource(name, flavour)
groldan: and isEditable(Name) for the sake
aaime: flavour -> source, store, locking
jgarnett: gak.
jgarnett: Remember we have getInfo()
jgarnett: getInfo( Name ) could have information describing what is available.
aaime: (btw, FeatureSource2 is a name asking for vengeance... can we use something else?)
jgarnett: your point is a good one andrea; is source / store / locking an open set?
groldan: sure we could, just don't know what
aaime: It hasn't been for a long time (open)
acuster: delicious
jgarnett: thinking ...
jgarnett: well this is why we should have an IRC breakout; lots of good feedback :-D
simboss: can I ask something feature-unrelated guys?
jgarnett: do you need an agenda topic; or is it related?
aaime: FeatureSource2 -> GeoApiFeatureSource? (longer, not very fond of it...)
simboss: or better coverage-dataaccess related
jgarnett: http://docs.codehaus.org/display/GEOTOOLS/CoverageStore+based+on+WCS+Specification
jgarnett: basically do the same thing based on the WCS specification
desruisseaux: If it is coverage related, could it fit in item 5?
jgarnett: DataStore based on the WFS spec.
jgarnett: (page is a placeholder for when you have time simboss/martin)
aaime: desriusseaux++
simboss: desruisseaux+=1
simboss: 
desruisseaux: Can we move on item 4?
jgarnett: andrea; just one idea then we should arrange an IRC meeting: ComplexDataStore, ComplexFeatureSource, ComplexFeatureStore, ComplexFeatureLocking
jgarnett: geoapi Feature extends Complex attribute after all.
aaime: that sounds about right
jgarnett: okay gabriel is that enough to keep you happy?
aaime: I'd prefer having SimpleFeatureSource instead... but that would break backwards compatibility?
groldan: ok, to make clear what I think is the main concern of this proposal. Having two separate interfaces for simple/complex allows to being completelly backwards compatible and not force clients to switch to complex if not needed. And if needed, switching to the more generic complex interface still gives you all the simple based ones
aaime: I understand that
jgarnett: yeah; I like it gabriel. please write it up and send out an IRC breakout email when ready.
jgarnett: sweet!
jgarnett: 4) jaxb
jgarnett: martin this one is you.
groldan: ok, Wednesday anyone?
desruisseaux: Can we add annotation on metadata package (for now), referencing probably later?
jgarnett: gabriel can you make sure justin is around? it will be silly if he is not around.
desruisseaux: Given that it would not introduce any new dependencies
groldan: jgarnett: will do, thanks all
desruisseaux: On Java 5, annotations would be erased in a way similar to generic type erasure.
desruisseaux: On Java 6, jaxb is bundled in the JDK - so no dependency needed for compiling.
jgarnett: Martin did you understand the email I sent? we can of course add the annotations; my concern is that there is lots of different annotations that would be fun. Why jaxb get any preference?
desruisseaux: Because it is in the JDK
acuster: it's in the jdk
jgarnett: um that is not my point so I should try again.
acuster:
jgarnett: there are lots of different ways to use a java bean; annotations are a smooth way to teach a javabean how to intergrate with any framework.
jgarnett: if we do jaxb (or any framework) it gives preference.
jgarnett: I would rather tell a consistent story: the default implementation that ships with geotools is a plain java bean
jgarnett: implementors can subclass and do what they want etc...
aaime: jgarnett ++
desruisseaux: The goal is to avoid implementation duplication.
jgarnett: we can make additional plug-ins for jaxb; xstream, hiberante etc...
aaime: metadata is a core module, not a pluggable extension
acuster: so how do you go to/from xml?
desruisseaux: xstream and hibernate are not in the JDK.
jgarnett: I am interested in duplication here; making sure the core library is free of specific bindings.
jgarnett: JDK does not enter into it for me
acuster: why?
groldan: acuster: in a number of ways. For the csw I participated on we used gtxml bindings
aaime: I'm sorry to say this, but my approach is exactly the opposite: if it comes from Sun there's a good chance it's bad
jgarnett: the concept of binding the default java beans to a specific technology here is what is at issue.
jgarnett: but I will offer you a olive branch.
aaime: I usually try to stay away
acuster: sorry that's not a technological argument
desruisseaux: But the binding is not restricted to that technology.
acuster: it's on the order of 'if it comes from eclipse it's bad"
aaime: bundled in the jdk is neither
acuster: which is just a waste of time
aaime: ie is bundled in windows, does it make it good?
jgarnett: If you take the lbrary in a different direction; we need to document it as such; and I would like to see that the factory / plug-in system used and tested. So I am confident we are not screwing over other use cases.
desruisseaux: We ensured with prototypes that the annotation works without API changes.
desruisseaux: The beans continue to work with arbitrary GeoAPI interfaces
jgarnett: acuster; I admit my argument is abstract; not based on jaxb / eclipse / JDK.
jgarnett: It is based on the design we chose (factory + plug-in). I want to trust that.
***acuster was talking about aaime's "it it comes from sun"
acuster: if it
desruisseaux: But they are not exclusive
jgarnett: okay; sorry for the confusion.
desruisseaux: The goal is to avoid a very large amount of duplication
acuster: groldan, would annotations block gtxml?
groldan: nope
aaime: wait
desruisseaux: ~100 classes to duplicate if annotation must be applied on separated classes.
jgarnett: so martin if you want to seperate out the metadata beans; document them as supporting jaxb that is cool.
acuster: so annotations would block only 'some other annotation system that is as yet unnamed'?
aaime: they might if the jaxb dependecy propagates outside of metadata
desruisseaux: What do you means by "separate out the metadata beans"?
desruisseaux: Andrea, no!!!
desruisseaux: No jaxb dependency on Java 5!!
acuster: and could others subclass to use their own annotations?
desruisseaux: No new dependency on Java 6 since it is bundled in JDK.
jgarnett: martin I already work with a complete implementation of the metadata classes in a commercial context (EJB 3).
aaime: sorry, can you elaborate?
groldan: I'm totally ignorant of annotation internals, so this might sound idiot, but couldn't they have home-made/tech-agnostic annotations and generate the jaxb ones automatically with some sort of preprocessor or such?
groldan: so you don't have to maintain them class extensions?
jgarnett: the duplication already happens; I am worried that if any of that implementation extends the default implementation I am in trouble. Or at least not a good steward of the geotools codebase.
desruisseaux: I don't think that you will be in trouble because no jaxb annotation declare the @Inherited meta-annotation
acuster: jgarnett, you seem to have the richest arguments against the proposal, is there any chance you could write them up?
desruisseaux: Any subclass you may create will not inherit the annotations.
sfarber: aaime: I believe martin's comment about no jaxb dependency on java5 goes something like this:
sfarber: if (compiling with java5)
else if (compiling with java6)
desruisseaux: Saul, yes if compiling with Java 5 annotations are stripped.
aaime: how?
sfarber: they're just special comments, righT?
aaime: no
desruisseaux: Declared with @Retention(RetentionPolicy.SOURCE)
acuster: and if users want another annotation system, can they subclass and use that?
aaime: they are languange level constructs
jgarnett: not quite saul; they are a new java syntax borrowed from C#.
jgarnett: at the same level as synchornized; volitile.
***sfarber shrugs half-liddedly
jgarnett: they are hints to any code that cares to use them.
acuster: so rather than Martin duplicating 100 classes, the person who really wants to do differently could do that work themselves
jgarnett: you can find the values using reflection.
sfarber: yeah, I like that description jgarnett
aaime: jgarnett could have used the same approach and stick ejb3 annotations there
jgarnett: now you got the hang of it acuster.
aaime: they are j2ee standard no?
jgarnett: I would like martin to seperate out his implementation as a jaxb implementation; and document it as such.
jgarnett: but make no assumptions in the geotools codebase.
acuster: why?
acuster: how does the assumption restrict other uses?
jgarnett: geotools would no longer ship a default naked java beans implementation. but that is fine martin is the guy doing the work and he has to follow his needs.
jgarnett: question guys
acuster: if we don't restrict others, our time is more valuable than that of some future user
desruisseaux: Geotools would be shipped with an implementation suited with what JDK is shipped it
jgarnett: is the difficulty here the work; or the duplication of code ...
aaime: anyways, I don't like the idea, but if no jaxb dependency ever comes out of the module (as a maven dependency) I'll be -0 on the vote
desruisseaux: No dependency will come out as a maven dependency
desruisseaux: I would like to elaborate more:
desruisseaux: My problem is the duplication of code, and also the intelligence in the class.
groldan: on the other hand, what's wrong with metadata coming with a default way of marshalling/unmarshalling xml? compare that with no-op
desruisseaux: Metadata are just container, they can easily be replaced by other classes generated by some jaxb-processor
desruisseaux: But the next logical step after metadata is referencing
jgarnett: gabriel unless the default way is exactly the ISO flavour of metadata then it is a waste of time.
desruisseaux: Those classes are much more complex and there is no way a processor could generate "intelligent enough" classes.
jgarnett: (ie this stuff comes from a spec with a known xml binding)
groldan: jgarnett++, desruisseaux is it 19139?
desruisseaux: Our goal is to generate exactly the ISO flabor of metadata, yes
desruisseaux: Yes it is ISO 19139
jgarnett: at best it woudl be a way to use xml blobs to serialize data into a database.
jgarnett: ah; so now we are talking!
desruisseaux: We are tying to provides a way to read and formats ISO 19139 out of the box
desruisseaux: in a way that user can ignore if they want.
groldan: don't know you, but I would have paid what you asked to have that a couple years ago...
jgarnett: out of a java6 box but still :-P
desruisseaux: Yes, out of java 6 box
jgarnett: okay so since we are on the same xml page here; can we go back to my "abstract" concern about he library as a whole?
desruisseaux: You means the neutrality aspect? (why jaxb rather than hibernate?)
jgarnett: A lot of the SLD work we do would be a perfect fit for EMF and justin's mad parser; it is a bit beyond what jaxb can handle (every).
jgarnett: That system depends on annotations
jgarnett: should I use those annotations in the "rendering" module?
jgarnett: or should I keep it as an implementation available via a plug-in.
desruisseaux: I'm in favor with annotations if 1) they are bundle in JDK and 2) as closely compliant to ISO as we can.
jgarnett: neutrality aspect = yes. Want to make sure that we respect the library / plug-in boundary.
acuster: that's a new, non standard dependency right? so not exactly the same situation. However, if it saves you time and makes you more productive...great.
jgarnett: So as a library; can we split out the library from the plug-in ?
jgarnett: move the implementation to plugin/metadata
groldan: I guess its too core?
jgarnett: and fold the factory finder / utiltiy methods into library/api or library/util or library/geotools
jgarnett: well only the factory finder stuff is core.
jgarnett: bundling the factory finder stuff and the default implementation is the issue.
groldan: doesn't referencing use metadata?
desruisseaux: Yes factory stuff should move to a library/util or something like that, but isn't it a different topic than annotations?
jgarnett: yep; but only depends on the factory finder; everything else should be interfaces.
jgarnett: it is a related topic for me; because it changes how I view the library fitting together.
jgarnett: (ie is the library factory finder + plain java bean default as a low priority). Or do we make our bed an lay down in it...
groldan: ok, since metadata impl is just about implementing geoapi interfaces, it makes sense to be plugin to me
desruisseaux: In its current state, referencing depends on hard-coded constants in metadata module.
jgarnett: treat ourselves with the same factory seperation as we do others.
jgarnett: martin do you mean things like Citations ?
desruisseaux: Yes
jgarnett: Is there a lot of that going on?
desruisseaux: Maybe 10. There is also a few classes that have some intelligence in it (more than just a container). For example GeographicBoundingBoxImpl.
groldan: and due to the lack of a factory for metadata that's a hard to break junction...
acuster: metadata has never stood as a full fledge module on its own
jgarnett: is there no factory for metadata at all? I thought there was something ...
desruisseaux: Being able to leverage those "more than just container" implementation is one of my rational behind annotations in metadata.
groldan: there's not afaik
jgarnett: okay; so martin - is now the time to do a factory?
desruisseaux: (I means leverage them from a XML unmarshaling)
groldan: factory + builder would feet better
groldan: I tried to make a factory but gave up on the amount of work
jgarnett: I am still have trouble with the last sentence about "more than just container" - what did you mean?
desruisseaux: They have method doing operations.
desruisseaux: Example. GeographicBoundingBox.contains(...).
jgarnett: is this the "freeze" stuff?
jgarnett: ah.
groldan: though "special purpose" factories could fit better (i.e. just for the stuff you care for a specific need)
desruisseaux: Metadata has few of thems, but this issue become much more bigger when we reach referencing.
desruisseaux: My itend was to annotate referencing after metadata.
jgarnett: one solution is a static final method for contains( GeomgraphicBoundingBox box, ... ) and then use that method as common implementation.
desruisseaux: My wish is to be able to marshal and unmarchal OGC compliant CRS objects.
desruisseaux: and being able to use them for real transformations.
jgarnett: acuster and I had a similar discussion about geometry factory last week.
desruisseaux: (coordinate transformations)
desruisseaux: There is no way we will recreate a new referencing module with jaxb-generated annotated classes.
jgarnett: okay your goals are good to understand; and I missed them earlier. We should be sure to write them down on a proposal page.
aaime: doesn't jaxb support any external means of configuration?
aaime: Hibernate for example supports both annotations and xml files
simboss: (xml files are a apin though )
desruisseaux: If jaxb is bundled in JDK, if we annotate them in a way to generate ISO-compliant XML, if it doesn't impact the API (still possible to use arbitrary interface) and if it doesn't exclude other usage of the beans, why object?
simboss: (pain)
jgarnett: pin can be pain if used right.
jgarnett: martin my difficulty was about library direction; wanting to make sure factory system was in place and used.
jgarnett: ie we need to allow people the freedom to use xstream and other implementations; apparently a metadatafactory should be defined. I was hoping it was there for you to use ...
groldan: no factory system could save you from the lack of factories 
jgarnett: I also want to have a good answer for the EMF case.
desruisseaux: The EMF case?
acuster: jgarnett, this would block the emf case?
groldan: martin, does the idea of moving metadataimpl as plugin seem too unrealistic?
aaime: groldan, it's not about realistic, it's that is more work for them
aaime: (a very understandable and shareable point of view if you ask me)
jgarnett: EMF as the worst case example of a dependency that requires annotation intergration; that is so useful I cannot avoid it; but so scary that andrea will kill me if it creaps out of the plug-in system.
groldan: yup, all concerns raised here seem like more work for them though. I'm all up to make it easy for them though
jgarnett: martin can you do your jaxb thing and we start to slowly work on a metadata factory? With the goal of getting our story straight for GeoTools 3.
desruisseaux: It would be some work because of the hard-coded constants and additional methods. But given that referencing needs some kind of metadata implementation, if there is no other implementation around we would still have a dependency to this metadata module.
jgarnett: I don't mind sharing the work around; if it has a benifit to the library.
jgarnett: woudl that be a <test> dependency ?
desruisseaux: No, a runtime dependency
jgarnett: a runtime dependency to get at the common Citations I bet?
groldan: I for one the hardest problem I found with metadata is the definition of the equals method, which might be some work if you want to break the coupling for the constants
jgarnett: as long as the default factory was a low priority I think we would be in the clear.
jgarnett: equals implementation stuff is already defined as a static method; and you are correct gabrile that it is hard.
desruisseaux: Implementations needed are: Citation, Identifier, ResponsibleParty, GeographicBoundingBox, PositionalAccuracy (just the first one that popup from my head)
groldan: and in my case they had to be mutable, so equals needs to be defined in terms of what the spec says is mandatory
jgarnett: martin could we hard code those puppies; or would that break your serialization.
jgarnett: also how is jaxb serialization going to work when you have mixed implemntations
jgarnett: referenced envelope for example is geographic bounding box that is used lots of places right?
groldan: or rather make Citations an interface with getters and obtain the current one through the factory system from the plugin so you keep alltogether
jgarnett: (to answer my own question: the factory should have some copy methods; used to punt data into a known format so you can serialize)
desruisseaux: I don't remember for referenced envelope (would need to check). For serialization: wen mixed implementation, if not one of our metadata implementation, an adapter creates a temporary instance just the time needed for serialization.
jgarnett: good good.
desruisseaux: So yes we are doing exactly what you said just the line before.
jgarnett: martin I have a technical debt page for things about our library that suck; or were too expensive in time/communication/money for when deadlines were around.
aaime: Just for the sake of completeness
jgarnett: sounds like metadata factory should be added to the list.
aaime: the xml-xsd module would allow for creating separate serialization/parsing modules for both metadata and referencing
aaime: but I cannot say using it it's painfless
desruisseaux: They are not exclusive
aaime: no, but it would avoid adding the n-th xml tehcnology in the gt2 mix
desruisseaux: They idea is to provides a way for users to use jaxb out of the box if they wish. But everyone can use whatever other technology they wish (xstream, xml-xsd...)
groldan: indeed, I would rather like to be able of mixing serialization stuff from your default implementation for metadata and our gtxml one for Feature
aaime: mix as in using in the same serialization session? unlikely?
jgarnett: how expensive (compared to jaxb annotations) is making xml bindings?
desruisseaux: About adding n-th xml technology: I agree, but this technology is in the jdk... Not like an other project added in the mix
jgarnett: sax is in the jdk too
aaime: so what, all of the others came before?
desruisseaux: But not everyone have the other. Everyone with java 6 have jaxb.
jgarnett: note there are several jdk level java bean binding things around. some available in java 5
aaime: groldan, if we'll ever need to mix xml-xsd and jaxb stuff I guess we'll end up rewriting Martin work solid
desruisseaux: about sax being in jdk too: I would not be surprised in sax is used under the hood by jaxb, this is just a guess.
jgarnett: oh it is
groldan: could be, just when the time comes I would like to not having to reinvent the wheel
aaime: we'll be forced to
jgarnett: martin is there other jaxb tools you are trying to intergrate with?
aaime: unless justin can invent some funny kind of bridge between the jaxb annotations and the xml-xsd bindings (which may be possible)
acuster: but wouldn't you have exactly the same amount of work today?
groldan: aaime: I wouldn't bet against that possibility
aaime: acuster, wasn't working togheter in a library based on the assumption that we could reuse each other's work?
aaime:
jgarnett: (opps I have been so caught up I have forgot to run the meeting - bad jody.)
aaime: Anyways, I understand your position
acuster: sure, you can re-use martin's work, or, if it doesn't work for you, roll your own
jgarnett: I would write up the proposal; expect a lot of +0. And place the metadata factory stuff as technical debt.
desruisseaux: So does the conclusion is to write a wiki page, enumerate the pro and cons and revisit at next IRC?
acuster: right now we have nothing; having something that doesn't block other alternatives doesn't seem worse
jgarnett: nope; write the wiki page; start work (because we don't want to slow you down). and be prepaired to talk to me about a factory before geotools 3 goes out 
aaime: I disagree, but I don't intend to go on with this pointless discussion
aaime: my vote for this is and remains -0
desruisseaux: Okay I will write a wiki page tomorrow then.
groldan: mine is a community +1
jgarnett: I cannot slow you down for not using a factory that does not exist; I may go and bug the geoapi project about the lack of a MetadataFactory (perhaps you know some people there).
jgarnett: and thanks for the discussion.
jgarnett: 5) coverage evolution
acuster: can we punt that?
desruisseaux: I have to leave...
groldan: about the factory, as well as in the setters, I know Martin's intention is to keep things minimal until they're needed, so this might well be the time
jgarnett: I am learning a lot from the discussion; but mostly I am interested in seeing a way forward that does not involve branches/forks/confusion.
jgarnett: yeah we can punt on that; sorry for letting the last topic go long.
desruisseaux: Gabriel yes, if the need for a MetadataFactory arise now it may be time to think about it. But we will need a little bit of time...
jgarnett: groldan++ you are right.
jgarnett: well I can post the logs...
jgarnett: remember to send me contact info for committers if you have anything.