1. what is up
2. Raster Symbolizer Proposal
3. Commit rights
4. 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