- what is up
- code sprint prep
- nogenerics must die
- swing widgets Q&A
jgarnett: jdolive did you get the gtbot code?
groldan n=gabriel@217.130.79.209 entered the room.
jgarnett: or are we on manual...
jdeolive: manual
jdeolive: never got hte bot
jgarnett: so we have ...
jgarnett: 0) what is up
jgarnett: 1) code sprint prep
jgarnett: 2) nogenerics must die
jgarnett: (anyone else ...)
Eclesia: questions about swing widget? if anyone have some
jgarnett: the way we do it is just "Grab an agenda item" .... so ....
jgarnett: 4) swing widgets Q&A
jgarnett: jdeolive the FM work; is that going to be covered by code sprint prep ? Or are you good ...
jdeolive: sure
aaime n=aaime@host227-95-dynamic.50-82-r.retail.telecomitalia.it entered the room.
jgarnett has changed the topic to: 0) what is up 1) code sprint prep 2) nogenerics must die 4) swing widgets Q&A
jgarnett: I need to change the proposal name so we can vote on the GeometryBuilder api addition.
CIA-9: jeichar 1.1.x * r27016 udig/udig/plugins/ (13 files in 6 dirs): merged in refresh fix from branch
CIA-9: jeichar * r27017 udig/plugins/ (12 files in 6 dirs): merged in refresh fix from branch
jgarnett: 0) what is up
jgarnett: jody - foss4g prep
groldan: gabriel - udig fun with edit tool modes
jdeolive: justin - geapi feautre model
simboss n=chatzill@host236-221-dynamic.117-80-r.retail.telecomitalia.it entered the room.
jgarnett: hey simboss - what is up? literally ...
aaim1 n=aaime@host227-95-dynamic.50-82-r.retail.telecomitalia.it entered the room.
jgarnett: 1) code sprint prep
aaim1: aaime - foss4g and beta3 release
jgarnett: So thigns are starting to look up, I talked to cholmes and he is going to buy us pizza on the saturday.
jgarnett: We are taken care of on the friday as part of the conference.
simboss: hi guys
jgarnett: And I am inviting anyone interested to my place for a BBQ saturday evening ...
jgarnett: So food prep is done ....
jgarnett: Justin how about FM prep?
jdeolive: coming along
jdeolive: i have updated geoapi interfaces based on peoples feedback
jdeolive: so i thin kthe model itself is generally ready to go
jdeolive: now i am working on updating geotools trunk to get ready for the sprint
acuster: so the sprint is FM
acuster: ?
acuster: next time it should be something totally frivilous and fun
jgarnett: The sprint is FM, but it is the part where we update the geotools library internally not to use deprecated stuff. And also geoserver and udig at the same time.
jgarnett: http://wiki.osgeo.org/index.php/FOSS4G2007_CodeSprint
jgarnett: So justin we have a checklist of things we need for the sprint: it amounts to a good code example and a class diagram.
jgarnett: So far we only have four developers listed ... are more people expecting to attend?
jdeolive: yup, on my list, 1. update trunk, 2. make sure examples are good, 3. class diagram
jgarnett: sweet
jgarnett: There will be other groups of developers around; but I would like to make sure we have as many hands as possible for this code sprint.
jgarnett: Since we will all be using svn this can be a constant breakout IRC as well.
jgarnett: okay so the prep is mostly you justin; please tag us all in for help as often as needed.
jgarnett: 2) nogenerics must die
jgarnett: Jesse_Eichar77 this one is yours from email.
Jesse_Eichar77: ok
simboss: (quick question when is the gt codesprint going to be held?)
Jesse_Eichar77: basically I've been trying to get feature editing working with geotools 2.4+
Jesse_Eichar77: .. go ahead
simboss: (so that I can give my fundamental
apport!)jgarnett: http://www.foss4g2007.org/code_sprint/
jgarnett: (Friday September 28th ... we are going to keep the love going for Saturday and Sundary as well. Refractions is providing space for the Saturday and TOPP is providing pizza)
ticheler n=ticheler@d83-181-227-95.cust.tele2.it entered the room.
simboss: (great, I am in for friday, not sure about saturdady, checking...)
Jesse_Eichar77: back to me?
aaim1: sure
Jesse_Eichar77: ok so gettting editing working
Jesse_Eichar77: I encountered an error that confused the heck out of me
Jesse_Eichar77: Essentially I had an featureId Object
Jesse_Eichar77: and I called getID() on it.
Jesse_Eichar77: However it threw an exception
Jesse_Eichar77: something like a AbstractMethodException I think
Jesse_Eichar77: I looked at my jars and saw that the jar had the method implemented.
Jesse_Eichar77: There were no compile errors
Jesse_Eichar77: so Jody came up with the idea that because uDig uses the generic version of GeoAPI
Jesse_Eichar77: uDig couldn't identify the correct method in the geotools implementation
Jesse_Eichar77: ....
Jesse_Eichar77: that make sense?
jgarnett: It does; at the bytecode level the method is marked differently if it is implementing an interface.
jgarnett: two levels of indirection rather than just one.
jgarnett: Justin I belive you tried using the normal geoapi jar and found a compile error in referencing - can we have more details?
Jesse_Eichar77: so basically I have to move uDig to nogenerics or geotools moves to the generics jar for me to fix this issue
jgarnett: (some of the library uses the normal geoapi jar right now)
aaim1: 2.4.x cannot move to jdk 1.5.x
aaim1: (imho)
Jesse_Eichar77: I'm ok with that
aaime left the room (quit: Read error: 110 (Connection timed out)).
Jesse_Eichar77: I don't expect 2.4 to move to 1.5 my self
Jesse_Eichar77: not this late in the release cycle.
Jesse_Eichar77: but 2.5 should be ok yes?
aaim1: Yes, trunk is already using jdk 1.5
aaim1: you cannot compile it anymore with 1.4 afaik
Jesse_Eichar77: but not the geoapi generics jar.
Jesse_Eichar77: correct?
aaim1: I think I've seen both of them in the classpath but I'm not sure (which would be even worse)
jgarnett: They are both used by different modules.
Jesse_Eichar77: well I just wanted to let you know that I'm encountering this issue.
Jesse_Eichar77: so we probably want to address it soon
Jesse_Eichar77: because I won't be the only one before long.
jgarnett: jdeolive do we need to address this before the code sprint?
aaim1: I guess there is nothing against moving trunk to geoapi-generic... anyone?
jgarnett: I know of one compile error in referencing - but Justin has the details.
jgarnett: In general the normal geoapi jar is way nicer to work with.
jgarnett: One of the reasons we use it in uDig.
jdeolive: yeah, there are a few other errors besides feature model
jdeolive: but not that manu
jdeolive: many
jdeolive: so i am ok with moving trunk to geoapi with generics...
jgarnett: +1
jdeolive: although i have not looked too deeply into the issues in the other modules
jgarnett: it would make geotools easier to use w/ maven; right now I have to provide a bunch of <exclude> statements so I do not get conflicts on the geoapi jar.
aaim1: Ah, because that may potentially trigger a pile of compile errors, right?
aaim1: (I mean, switching to the geoapi with generics version)
jdeolive: yeah.. thats probably smarter
jdeolive: keep geoapi-generics, but exclude the feature model teh erasure
jdeolive: so its as andrea says, geoapi-withSomeGenerics
jgarnett: that sounds horrible.
jgarnett: however I think we are not going to make a decision here because we do not have enough specifics
***acuster doesn't understand at all.
jgarnett: (so we are all wondering how bad can it be)
aaim1: Is there anybody with enough time to try out a switch and see how big is the river that we must cross?
jdeolive: i just di
jdeolive: d
jdeolive: one sec, i will try to sum up teh rrors
jgarnett: I will try it out; if only so justin can stay focused on the FM
jdeolive: its tough to guage in main, since there is also all teh chagnes from teh feature model
jgarnett: I can try on a 2.4.x checkout and get a better impression.
jdeolive: one thing that pisses me off about generics
acuster: jgarnett, why is the non generic geoapi nicer to work with?
jgarnett: because it is more specific.
jgarnett: so often a geoapi interface will return getTelephones(): List
jdeolive: is that List<B> is not considered a type narrowing of Collection<A>
jgarnett: when it actually means getTelephones():List<Telephone>
jdeolive: when B is a subclass of A
jgarnett: jdeolive++ we fixed most of that for the metadata interfaces; but they do not plan a good fix until Java 7
jdeolive: actually wait a sec... that is what ? extends A is for
jgarnett: indeed.
***jdeolive wonders if they made a mistake adding generics to java
jgarnett: they made several; but mostly by only going halfway and letting the compiler do it
jgarnett: (rather then the VM)
jgarnett: type erasure is compile time safety only; not runtime safety.
jdeolive: anyways, i cant really guage the work to port the rest until i update the feature model
jgarnett: jdeolive I will send an email after trying the 2.4.x experiment.
jgarnett: 4) swing-widgets Q&A
jgarnett: Eclisia welcome to the team.
Eclesia: thx
Eclesia: i juts udpated the wiki page so everyone can test the demo
Eclesia: http://docs.codehaus.org/display/GEOTOOLS/widgets-swing-pending
Eclesia: (if anyone have questions)
jgarnett: First of all nice docs, and thanks for picking up this aspect of GeoTools - we have not had a volunteer on this front for years.
Eclesia: me objective is to have the basic swing component to make application
jgarnett: Although I have been helpful setting you up, Martin is going to be your major point of contact/feedback ...
jgarnett: ... I am sorry he is not here today.
jgarnett: I think someone already mentioned putting the demo code in demos/
jgarnett: are you cool with that?
acuster: Is there any reason to limit these widgets to j2me?
Eclesia: i use it to test my work and i change it often, so for now i would like to keep it in my module
acuster: the thought occurred to me just now
jgarnett: okay; when your module goes supported we would like to move these demos out to where people can use them.
acuster: looks cool
Eclesia: acuster : they won't work on j2me
Eclesia: i already made changes to make it work on 1.5 so on j2me...
aaim1: Eclesia, I'm getting the impression these widgets impose a look and feel, icon set, label alignments and such... is this true?
***acuster is using j2me only to mean the minimal environment of handhelds
Eclesia: yes, but icons can change
aaim1: Look and feel should be managed outside of the code
Eclesia: see here : http://docs.codehaus.org/display/GEOTOOLS/IconBundle
simboss: (impressive work man, congrats!)
aaim1: in a proper laf set of classes
aaim1: I mean, what if I have to integrate those components in an application that uses another laf
aaim1: with different fonts, alignements and so on?
Eclesia: no problems
Eclesia: i don't use any precise laf
aaim1: I see centered labels for titles, and borders around panels
Eclesia: just the header of the tree but that's all
aaim1: This should be part of a laf
Eclesia: ha... i see what you mean
aaim1: if these are set in code
Eclesia: yes they are
aaim1: when you put those components in an application that uses, says, the jgoodies laf
aaim1: they would look totally out of place
Eclesia: i should try and see
Eclesia: but i don't think it will be all messed up
Eclesia: i used netbeans matisse and the grouplayout to place everything
Eclesia: so i should be correct even if you use the jgoodies laf
aaim1: No, I did not mean the layout of the form
aaim1: Consider this one: http://docs.codehaus.org/download/attachments/10747962/ex_SLD1.jpg
aaim1: "Contour" is centered
acuster: aaim1, is there a good example widget to start from?
aaim1: but it should not under kmost laf
aaim1: Not that I know of acuster
simboss: I saw that eclsia
simboss: is using
simboss: swingfx
aaim1: most swing widgets are much more basic
simboss: am I right eclseia?
Eclesia: yes
simboss: than on their website
simboss: or docs
simboss: youo should find guidelines
simboss: but also
simboss: you can check the advanced
simboss: swing tutorials and guides from sun
jgarnett: two mins left for the meeting.
simboss: it is a rether boring task to use laf
simboss: but aaime is right
simboss: it is needed
simboss: to have "nice java" stamp
jgarnett: Eclisa for the data icons I would like to take those off to the rendering module
Eclesia: i will do what i can, with waht i know
jgarnett: (ie for the icon generated by a SLD for example)
aaim1: Another simple question
jgarnett: Please accept all this feedback as us being exicited
Eclesia: icons or glyph?
jgarnett: what do you find easier?
aaim1: is the example app going to become a separate project? I mean, a sort of udig made in swing?
Eclesia: aaim1 : lol, i had them in netbeans plateform to see
Eclesia: http://altersig.developpez.com/pages/snapshots/altersig_root4.jpg
groldan: geowidgets is dead?
Eclesia: not dead
aaim1: I guess, at least comatose
Eclesia: the work i'm doing (i hope) will be added in geowidget when it will be cleaned
groldan: cool
jgarnett: there is a little confusion here groldan
groldan: so are you in contact with the geowidgets developer at all?
jgarnett: the geowidgets developers are missing
jgarnett: the code is the same as it was in our geotools spike with some added translations.
jgarnett: so who knows?
groldan: I see
well, best of luck with this project Eclesia jgarnett: thanks for the Q&A
jgarnett: that is it for the meeting everyone; I will post the logs.
jgarnett: thanks!
1: Thanks to Frank for his mentorship
2: legal update
3: feature model discussion
<gtbot> Agenda Items:
<gtbot> End of agenda items.
<jdeolive> i have one but will add it as the last
<acuster> gtbot add Thanks to Frank for his mentorship
<gtbot> Added agenda item '1: Thanks to Frank for his mentorship' to the list.
<jdeolive> since it will probably take up the majority of the meeting
<acuster> gtbot add legal update
<gtbot> Added agenda item '2: legal update' to the list.
<acuster> well we can start with 0. what is up
– pramsey (n=pramsey@S01060014515fec41.gv.shawcable.net) has joined #geotools
<acuster> acuster – Looking at the renderering systems; legal stuff
<jdeolive> jdeolive – feature model
<acuster> gtbot start
<gtbot> Logging started.
<jdeolive> gtbot add feature model discussion
<gtbot> Added agenda item '3: feature model discussion' to the list.
<groldan> groldan – almost away from geotools, immerse in udig's edit tools
<acuster> jdeolive, what are you doing more precisely?
<acuster> groldan, any conclusion on the 'modality' stuff?
<jdeolive> jdeolive – waiting for feedback between andrea, gabriel, jgarnett, and myself to settle down in order to cimpile to concrete geoapi api changes
<jdeolive> add acuster to that list of people as well
<groldan> so far the experiment is doing well, was able to add modes for ortho, snap to vertex, snap to line, and parallel
<jgarnett> hello; I am having some #foss4g lab drama so I am not sure how attentive I will be to the meeting today
<acuster> jdeolive, so the feature model has to land in geoapi to land in geotools as well?
<groldan> no conclusion though, as I'd love a code review
<jdeolive> yes
<jgarnett> acuster - usual split geoapi interfaces, geotools implementation (or in this case more than one)
<acuster> jdeolive, what's your personal perspective on temporal support? An infrequent issue to be dealt with later?
<jdeolive> acuster, hmmm... yeah i would say it should come later, i think we have bigger fish to fry
<acuster> jgarnett, do you have time to consider the legal stuff in the next 24hours or should I push it through without you?
<jdeolive> like just coming up with a core model which which will work for complex stuff but not too complex that it kills us
<acuster> yeah, I like the direction andrea is pushing
<acuster> okay, 10 after lets start
<acuster> 1) Frank is resigning as mentor
<acuster> We've been having a private discussion over legal matters
<acuster> which has been painful for everyone
<acuster> and Frank finally had enough
<acuster> he wants to enjoy greener pastures, like his emacs or vi screen (not sure which he uses)
<acuster> I wanted to thank him:
<acuster> Thanks for all your hard work Frank
<acuster> and let everyone know
<acuster> Replacements and other issues have not yet been decided
<acuster> questions?
<acuster> 2) Legal update
<acuster> This is 'do or die'
<acuster> I have yet another draft for the copyright assignment agreement
<acuster> http://docs.codehaus.org/display/GEOTOOLS/Geotools+Legal+Review
<acuster> along with some other docs including background
<acuster> if anyone wants to comment they have 24hours
<acuster> after that, I'll send it to a board member asking that it be sent on to the lawyers for a review
<acuster> if this version doesn't yield a document we can sign, then I give up
<acuster> so either FOSS4G will have a document
<acuster> or we will get to start all over again
<acuster> questions?
<acuster> jdeolive, the floor is yours
<jdeolive> ok... we need aaime, groldan, jgarnett, acuster, and myself for this topic
<jdeolive> without all of us i will just skip it
<acuster> andrea is out
<acuster> jgarnett, is distracted (not that that is new)
– aaime (n=aaime@host227-95-dynamic.50-82-r.retail.telecomitalia.it) has joined #geotools
<acuster> oh!
<groldan> and jody is complicated
<jdeolive> speak of the devil
<simboss> here is andrea
<aaime> Hi
<groldan> hi
<acuster> so jdeolive gets to write up his topic after all
<jdeolive> ok
<jdeolive> lets try without jody
<jdeolive> so... the topic is geoapi feature model
<jdeolive> andrea did a great review of it
<aaime> yikes"
<jdeolive> and since then there has been alot of back and forth
<jdeolive> so... my question is for you andrea... are there any major things that have not been unaswered for you?
<acuster> ? what is the work that actually needs to happen? e.g. do all the datastores have to be re-written?
<acuster> ? is the prototype SimpleFeature system written and/or have a javadoc kicking around?
<groldan> before deciding that we need an up to date data access api,
<groldan> guess jdeolive is just talking about the fm
<groldan> sure both things are closely related
<groldan> yet, I guess he's not trying to get that far?
<jdeolive> i would like to focus on the actual model for now
<jdeolive> we can talk about gt datastores later
<aaime> (e.g. when we have resources to tackle them too)
<jdeolive> ping aaime
<acuster> and that model is all on geoapi trunk?
<jdeolive> yes
<aaime> jdeolive
<jdeolive> sorry, i had a question for you
<jdeolive> will repeat it
<aaime> There are no unanswered questions
<aaime> that I can remember of
<jdeolive> so... my question is for you andrea... are there any major things that have not been unaswered for you?
<aaime> Nope
<jgarnett> hi - it seems there a are a lot of questions.
<aaime> I'm not completely comfortable with how multiple instance attributes are managed
<jdeolive> ok... so based on the feaure model review thread i can go trhough and take my first chop at geoapi
<aaime> I guess so
<groldan> Andrea do you think the bad feeling you have could be left to implementation details, or there is some strong api problem?
<jgarnett> justin I have a document I would like you to read; I am sorry I was too busy to take a part in the email thread.
<aaime> (that is, as an OO developer I would feel more comfortable with them being managed in their own collections)
<acuster> jdeolive, that's what I was asking. What's a first chop? Geotools refactoring?
<jdeolive> nope, geoapi interface changes
<jdeolive> they are overly complex, and inconsistent in some places
<jdeolive> i would like to cut that all out
<jdeolive> to make it easier to ingest
<groldan> do you have a feeling of what changes are those going to be?
<jdeolive> my rationale being
<acuster> so what prototype is andrea working from?
<aaime> Andrea is not working, he's just looking at the geoapi trunk
<aaime> I haven't touched anything
<aaime> I was just being asked for an opinion
<aaime>
<jdeolive> right, andrea has just been reviewing
<jdeolive> and my concern is this
<jdeolive> if a java developer as advanced and experienced as andrea has issues with it
<jdeolive> we have serious problems
<aaime> The main problem is that I love OO and hate (hate!!!) XML
<groldan> being the one that perhaps had to deal more with it (the model, not andrea ), I recognize its sometimes hard to work with
<aaime> so if you asked another person the review outcome would have been different
<jgarnett> guys I am going to have to bail on this meeting; too much else going on ... justin I will send you what I have for feedback via email. If you have time for a breakout IRC or coffee on the subject it would be nice. If not I missed the boat.
– jgarnett (n=Jody@mail.refractions.net) has left #geotools
<groldan> but the pain is meant to be softened by the family of builders
<jdeolive> jgarnett, ok, i need to wade through that massive email thread and reorganizse
<jdeolive> he is gone
<acuster> who will the 'model users' be?
<jdeolive> geotools developers
<aaime> Well, whoever plays with geotools
<jdeolive> anyone who writes code having to do with Feature
<jdeolive> which is pretty much all geotools client code
<groldan> except Martin
<jdeolive> haha
<groldan> (lucky guy)
<aaime> ha ha, right
<jdeolive> fair enough
<acuster> and what are we trying to help them do? be quick? understand quickly? do lots?
<aaime> do more
<aaime> handle complex features
– acuster is imagining an ecologist trying to use feature
<aaime> basically being able to represent whatever xml madness you can find in
<aaime> gml schemas
<aaime> 1:1 inside the gt2 features
<groldan> disagree andrea
<acuster> right we have Rob A. at one end, and jane scientist at the other
<groldan> we got rid of most of the xml madness
<groldan> and in the community schema modules
<groldan> xml specifics are being treated separately
<acuster> are there 'test features'?
<aaime> Well, mapping childs like an unsorted bag of stuff smells like xml madness to me
<groldan> aka, concerns tend to be quite separated, and that's why we're carring out the emf model as metadata
<jdeolive> well... fair enough.. the model is not tied to xml directly
<groldan> actually, doing it as lists would be more xml'ized
<jdeolive> but its definitley influenced by it and gml
<jdeolive> and has been made flexible enough to handle model xml schema and gml more exactly
<aaime> Afaik one of the objectives was to map the xml 1:1 into the feature no?
<groldan> two years ago... yes. With this last model I would say no
<groldan> its more biased to map 1:1 with the ogc general feature model
<jdeolive> which is highly influenced by xml / gml no?
<groldan> and that's why an attribute's property bag is represented as a Collection and not a list
<aaime> yep, tell it what you like, if the stuff you're handling cannot be represented by a javabean it's not very OO to me
<groldan> jdeolive: don't know, guess the GFM is an abstract model, gml dont
<groldan> and the former exists prior to gml? (not sure)
<jdeolive> well regardless... the new model is definitley more xml like then the old one
<jdeolive> ie, having descriptors mapping to schema particles, etc...
<groldan> fair enough, the old one is more JDBC like
<aaime> not really, more shapefile like
<aaime> jdbc woud imply natural support for joins
– acuster already has problems with the terminology 'A feature is an attribute?'
<aaime> (and thus complex features made the "sane way", that is, with association managed with collections and the like)
<aaime> Adrian, yes, I don't like the semantic of that hiearchy either, but from a structural point of view it works
<acuster> we do have to content with fourty odd years of GIS here though
<acuster> we can't pick names we like
<aaime> I fear that hiearchy maps the OGC feature description quite verbatim
<acuster> Feature.java is a mess
<acuster> ah, ok. Then we need to state that
<acuster> A Feature, of arbitrary complexity, with at a minimum Geometry and CRS information.
<aaime> Ha ha, my first reaction as well, you have to start with FeatureType to have some understannding
<acuster> does it have to have a geom? does it have to have a CRS?
<aaime> No and no (not necessarily)
<acuster> who are the authors, what's the license?
<aaime> they should be optional
– acuster moves to featureType
<aaime> Start from property type, go down
<aaime> inspect all the hiearcy, then have a look at descriptor
<aaime> or even better, have a look at my review
<aaime> there is a diagram and a summary for both the type model
<aaime> and the attribute/feature part
– jgarnett (n=Jody@mail.refractions.net) has joined #geotools
<acuster> Declaration of attribute type.
<acuster> how does that kind of javadoc help anyone?
<jdeolive> yes, the javadocs are quite poor
<aaime> The javadoc is not helping yeah
<jdeolive> right, so its very poorly documented
<jdeolive> thats a bad thing
<acuster> The javadoc is how we get users to become developers and do work for us
<jdeolive> and maybe decent docs would solve some of our problems with it being over complex
<aaime> Javadoc won't solve the complexity problem
<aaime> only xml example of what you can and cannot do with the various options start to give the model some sense
<aaime> if you tackle it from a pure OO perspective it looks like madness
<aaime> (especially if you've already bean exposed to pure OO metamodels like the MOF)
– jdeolive is not familiar with MOF
<jdeolive> but i agree
<aaime> Meta Object Framework, it's what UML is based on
<jdeolive> some examples of what different classes mean and relating to an xml schema structure woudl probably be helpful
<acuster> so a developer can't start at PropertyType and read the code to figure out what's going on?
<aaime> Imho no, you have to start from xml, if you look at it from code only it does not make sense
<jdeolive> no, this model is 100% not ready for production, we know that
<jdeolive> we are tryign to get it there
<jdeolive> this was painful for andrea
<jdeolive> and i apologize
<aaime> you have to see what there is in xml that you cannot map in a pure oo model to understand
– acuster will stop harping on the javadocs
<jdeolive> ok
<jdeolive> well to be honest, i am quite pessimistic based on peoples feedback
<jdeolive> but i think the next step is for me to go through and try to sum up things so far
<aaime> jdeolive, first contact with that feature model is going to hurt because you cannot recognize the usual mental model of an OO model
<aaime> and you don't get any help understanding why
<aaime> it's made like this
<aaime> So yes, there are simplifications needed
<aaime> the javabean convention has to be respected
<aaime> some interfaces need to be factored out
<aaime> but in the end it would just make it less messy
<jdeolive> right, this is the list i am trying to come up with
<jdeolive> exactly what needs to be done
<aaime> the hard part would stay there, that is, descriptors, attributes as bags of free floating attributes
<aaime> and that needs some good docs to become understandable
<jdeolive> agreed
<groldan> cool, whatever needs to be done, remember we have two real world models, borehole and timeseries, that will help out to know if the model is good enough
<jdeolive> a good run of the javadocs should have been done before you looked at it
<jgarnett> hi guys; I am back ...
<jdeolive> good point gabriel
<aaime> groldan, that is good as long as it's out of your mind and down into a document
<aaime> otherwise only you will keep having good night sleeps
<jgarnett> yeah; I would really like to see those turned into code examples we can all understand.
<aaime> whilst everybody else is left wondering
<groldan> gotcha
– cholmes_ (n=cholmes@cpe-66-108-80-238.nyc.res.rr.com) has joined #geotools
<jgarnett> justin have you given any thoughts to the migration plan?
<jgarnett> ie migration from FetureType.create to SimpleFeatureBuilder ... what happens when and what does it return?
<jdeolive> well i did but that is on the backburner now
<jdeolive> getting this model usable is paramount
<jgarnett> understood.
<jdeolive> using builders and that is a very very small part of the success, and the easy part if you ask me
<jgarnett> I have a good idea about that; but I would like to draw a picture over coffee. Perhaps you will hate it?
<jdeolive> the problems andrea and adrian point out are the important part
<jdeolive> ok... so does anything have anythign else?
<aaime> I agree. If we concentrate on SimpleFeature everything works, but we get Feature and FeatureType in a trojan horses
<aaime> and we may not like the consequences
<jgarnett> nothing you will like ...
<aaime> ?
<jgarnett> I would like to see the javadocs cleaned up .. but I see others have made that point.
<acuster> Where are the data sets?
<jdeolive> yes, i would like to do that jody
<jdeolive> take a run at the entire set of javadocs and make them consistent across the board
<jgarnett> gottcha
<groldan> acuster: you have two on the community-schema config for the community-schema modues in geoserver, and we could certainly ask Rob Atkinson for some more
<acuster> ah, in geoserver
<aaime> (not in the official geoserver)
<jgarnett> so is there anything else this meeting? we have some legal stuff to sort out before foss4g if I understand my inbox.
<groldan> and in the geotool's module test case
<acuster> jgarnett, I'm getting pissed off enough that I may drop the whole thing
<jgarnett> acuster++
<jgarnett> I am sorry we have been less than helpful; I got to the same point last year.
<groldan> any conclusion on the topic? jdeolive do you have what you need? gonna move this to the ml?
<jgarnett> There is an OSGeo meeting on the monday where I hope to explain that the iccubation process is not being supportive for us.
<cholmes_> acuster, does that mean that you wouldn't consider signing any contributor agreement that isn't one that you worked on?
<jgarnett> ie. Sorting this kind of thing out is one of the reasons we were interested in a foundation.
<acuster> well, in 24hours I'll send out what I've done to the OSGeo board and see what they do with it
<jdeolive> groldan: i am more going to take stuff from mail into something more coherent
<jdeolive> and hopefully come up with some recommendations about thigns we can change
<jdeolive> to make thigns more simple
<jdeolive> the other part will be documenting
<jgarnett> let me be blunt; we are all sick of this. If you are happy with what you have we will all stand behind it.
<acuster> cholmes_, yes, although not at all for the reasons you are concoting
<cholmes_> What would you like the board to do with it? I mean, you're not a lawyer so whatever text you come up with will need to be looked at again?
<jgarnett> but we all feel "out of our depth" and pissed off.
<jdeolive> javadocs... and hopefully some code examples
<cholmes_> I'm not concoting any reasons...
<jgarnett> I see; so chris what should we be doing differently?
<acuster> yes you are. and accusing me of being the reason frank got sick of legal shit. Legal shit is shit and we are all sick of it. Frank did very well to get out. Don't blame me for struggling with it longer than others have.
<acuster> I like tOPP's aggreement a lot
<acuster> probably the most out of the lot
<cholmes_> So if we were to just get SFLC to rewrite TOPP's agreement for OSGeo/GeoTools you'd likely be happy with it?
<acuster> $5000 dollars does not strike me as a fuckload of money
<acuster> it's a bunch less than the time I have poured into this
<acuster> partly because of bad lawyers
<cholmes_> Considering the amount of fundraising that osgeo has actually accomplished it is.
<acuster> and partly because of interference between the people working on things (me) and the lawyers
<acuster> I'm even negotiating with other lawyers to help me out because of the logistics of this situation
<cholmes_> Ok, so the best route forward to me seems to be for me to contact SFLC, and get you in touch with them directly with your concerns, and then take their draft and I can advocate that to the board?
<cholmes_> WHich should be a pretty easy sell, since they are very established.
<acuster> no
<cholmes_> why not?
<acuster> I'm done. I have written, to the tinest detail, all the things I could think of.
<acuster> They are in my draft
<acuster> after that, what anyone does with it is up to them
<cholmes_> Ok, so I'll forward your draft to SFLC, and I'll do all that I can to try to make sure that all your concerns are covered by what they come up with?
<acuster> in 24hours you will get a mail, for the OSGeo board, with the results of my past weeks of work
<acuster> hopefully that goes to the OSGeo lawyers whomever they may be
<cholmes_> Well you can't be completely done, since at some point you will have to sign something.
<acuster> and some agreement comes out of it.
<cholmes_> And I would like that to be an agreement that would be acceptable to you.
<acuster> yes, i will have to read the final draft and decide if i want to sign it
<acuster> we also have to modify headers,
<acuster> decide on a policy
<cholmes_> Ok, But you don't want to give any feedback before that final draft?
<acuster> decide on how to handle contributors that don't want to sign
<acuster> what feedback?
<cholmes_> if you'll sign it or not.
<acuster> Have you looked at my doc?
<acuster> I will sign almost anything that is not:
<acuster> 1) wrong
<cholmes_> I looked at it, haven't had a chance to read it in full depth though
<acuster> 2) talk about "intelectual property" as if that were something
<acuster> so you know that my doc is a continuous feedback: this is why this is here, this is what it's trying to do, this is who we need to think about
<acuster> 80% comments and 20% text
<acuster> and yes, I do care about french law because if this company is successful at all it's going to be sued up and down by some big established players in this country
<cholmes_> Ok, I'll do the best I can, I will try to get something before foss4g but it's unlikely, as before this week I was going to be working flat out, and I just learned that I have another full time job worth of other work to also do.
<cholmes_> Which company?
– acuster holds out on that for a few months
<acuster> are we done?
<jgarnett> I guess so
<jgarnett> was that the agenda?
<aaime> Only talking about the feature model afaik
<jgarnett> looks to be; thanks again to FrankW for helping us over the last year and a half.
<acuster> gtbot stop
<gtbot> Logging stopped.
<gtbot> Posting news to GeoTools confluence...
<gtbot> Unable to post news to Confluence. Saving logs to a local location.
<gtbot> Logs saved in /home/rgould/IRC Meeting - 10 September 2007.log
This is our first Java 5 GeoTools release and should be considered alpha.
Features:
- Java 5
- Improved CRSAuthorityFactory implementations available for Java Enterprise Edition users
- ISO 19107 Geometry implementation available as a supported module
- DB2 returns to supported status
- ArcSDE returns to supported status
- GeometryBuilder utility class
- Preview of SimpleFeature interface
- Preview of GPX DataStore (and a warm welcome to Peter Bolla)
For more information please visit 2.5-M0