Skip to end of metadata
Go to start of metadata

Agenda:

  1. what is up
  2. OSGeo Representative
  3. GeoTools 3.3
  4. SoC Status Reports

Action Items:

  1. jgarnett nominated as OSGeo representative

jgarnett: okay time to go (smile)
jgarnett: aaime it is now time right? So we can get you for 15 mins ...
jgarnett: Good morning Martin; anything for the meeting?
aaime: yep
aaime: for 13 minutes actually
desruisseaux: Hello Jody and all
jgarnett: I assume we are going to miss a few people with the new meeting time and all ...
jgarnett: so let us start (smile)
jgarnett: 0) what is up
aaime is working on speeding up the KML superoverlay code in GeoServer
jgarnett - udig now renderers; trying to review what is needed for 2.5.0; and generally happy it is summer
Eclesia1: hi al
jgarnett: Morning all ... topic 0) has already started; you know the drill - single line saying what you are up to. If anyone is up to something interesting you can chat with them on email.
jgarnett: 1) OSGeo Representative
jgarnett: Okay FrankW asked me today about our current osgeo representative form the PSC
Eclesia1 ahs prepared the style upgrade for 2.6.x, but has 4 last test failure in some stremaing renderer tests, but the code has no comment and is ... strange, so i cant fix those
desruisseaux: Martin: various task (cleaning, a bit of coverage work, etc)
jgarnett: (smile)
jgarnett: moving on ...
jgarnett: I started out in this roll but burned out - I think acuster took over. Can you confirm Martin?
jgarnett: (I am searching the email archive)
desruisseaux: You means for the PSC representative?
FrankW: Note, the OSGeo reprsentative is normally the PSC chair.
FrankW: Do you guys have a chair?
jgarnett: looks like cholmes has volunteered.
FrankW: This will be the person named VP, GeoTools and expected to speak on behalf of the project, and answer on it's behalf.
jgarnett: We have a project management committee
aaime: we had one eons ago, but we don't really have a chair anymore in our PSC
jgarnett: we had James as our tie breaker.
jgarnett: Email record shows chomes as our representative after me; Dec 12 2006.
desruisseaux: There is Ian Turton as the historical creator of the project (together with James)
aaime: I hardly believe he has time
jgarnett: - http://www.mail-archive.com/geotools-devel@lists.sourceforge.net/msg05935.html
jgarnett: Indeed he later stepped down from the PMC did he not?
aaime: he did
desruisseaux: I don't know.
jgarnett: okay I will volunteer for this one
aaime: so we're chair-less
aaime: jgarnett++
desruisseaux: +1 for Jody
jgarnett: well this is more a representative to the OSgeo foundation; so not exactly a chair.
FrankW: I believe Chris was the incubation rep.
FrankW: This isn't the same thing - or at least it does not need to be.
FrankW: I would think the VP GeoTools should at least be on the PMC!
FrankW: The rep is traditionally the chair though it is not strictly necessary.
jgarnett: oh I see ...
FrankW: From what I've seen, I think jgarnett is the logical choice if he is willing.
jgarnett: Okay - so I will need to write this down on the inncubation page I guess Frank?
jgarnett: And will put it in our developer guide as well.
FrankW: It doesn't have to be on the incubation page.
FrankW: But I do think you could note it in your PMC docs.
jgarnett: http://docs.codehaus.org/display/GEOT/4+Project+Management+Committee
jgarnett: done
jgarnett: So my role for this will be communication monkey
jgarnett: rather than code monkey.
FrankW: It would be best if jgarnett was put in this role by a vote of the PMC.
aaime: here is my vote
aaime: and now I really have to run away
jgarnett: aaime can you make the motion.
aaime: vote for jgarnett to be osgeo representative
aaime: +1
aaime is now known as aaime|away
jgarnett: +0 (since I am being nominated)
desruisseaux: +1
jgarnett: simone and jdeolive are on holiday
lreed n=lreed@mail.refractions.net entered the room.
desruisseaux: I don't think they would object.
jgarnett: Ian T is MIA (the joys of academic life may be too much for him)
jgarnett: I will send an email out; Frank this can be offical as the votes come back in.
FrankW: OK, thanks folks!
FrankW: jgarnett: I'll assume it will be ok, unless I hear otherwise. Use whatever your process calls for.
desruisseaux: Are we done with topic 1?
Eclesia1: (+1 for jody ^^ )
jgarnett: well I should of probably voted +1 so you could of gotten an answer right now; but we can wait a few days.
jgarnett: :-P
(9:48:32 jgarnett: 2) GeoTools 3
desruisseaux: Thats mine
jgarnett: martin the floor is yours; personally I like the range of ideas expressed thus far - I think we have lots to work with.
desruisseaux: We would like a GeoTools with some cleaning in it. Adrian proposed the "geotidy" name.
desruisseaux: (as a code name; could be GeoTools 3 or something else as people wish)
desruisseaux: We can not really continue very long to work on GeoTools 2.
jgarnett: I would also like the same thing
jgarnett: but I think we need to negotiate a bit on what tidy means (smile)
desruisseaux: Moving on distributed versionning system make easier to express a wider range of opinions.
desruisseaux: It also reduce the pressure to commit unfinished stuff.
jgarnett: martin we need to get some documentation on the distributed version control thing
jgarnett: we have some contributors that really need this.
jgarnett: (I have tried asking for a couple of weeks; can you write down even some quick notes to help them get started)
jgarnett: (I can make that a seperate agenda topic if you like)
desruisseaux: There is on-line tutorial on Mercurial
desruisseaux: How they will applied exactly to GeoTools is to be determined
desruisseaux: since we are still setting up what may be GeoTools 3.
desruisseaux: Peoples can start with that: http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial
jgarnett: So martin one of the things I want to emphaise here is communication; we had a hard time communicating with Simone when he was on a branch for a year. I am hard pressed to see how distributed version control is going to help matters stay on track; it is very attractive for groups of developers to go off on branches in order to make some tight deadlines - and then expensive to merge back in; go through the community process of collaboration and all that.
jgarnett: So I think that setting up a few policies
jgarnett: around the use of mercurial
jgarnett: is a great place to start.
jgarnett: Does that make sense; we have some great ideas on what geotools 3 can be.
jgarnett: And some wonderful opperunities based on the new work your organization; and several other organizations are getting involved in.
jgarnett: I want to make sure we are prepaired
jgarnett: before we open up GeoTools 3 for hacking.
CIA-32: jezekjan * r31012 /trunk/spike/jan/gsoc-transformations/src/main/java/org/geotools/referencing/operation/builder/GridParameters.java: Spike/Jan - Bug with negative array fixed
jgarnett: I have said I was prepaired to scope this out after OSGeo graduation; and thanks to some heroic efforts on acusters part we are now there (smile)
jgarnett has changed the topic to: 0) what is up 1) OSGeo Representative 2) GeoTools 3 3) SoC Stauts Reports
jgarnett: So what would you like to do martin? When can we start this discussion
jgarnett: is it something to handle at the PMC level?
jgarnett: Or should we as a responsible PMC consult the various organizations that fund our work? Refractions, GeoMatys, Open Planning Project etc...
desruisseaux: We could start the work and put a repository on-line on a geomatys server, so peoples can take a look if they wish.
jgarnett: I am not sure that would help Martin
jgarnett: part of the thing here is that we have a credibility crises here for GeoMatys
jgarnett: in terms of communication and control
jgarnett: still open development here would be good;
jgarnett: anything we can do to communicate your priorities; and what is happening with GeoAPI and so on would be excellent.
jgarnett: But perhaps I am thinking from another angle from you?
jgarnett: For me there is no repository yet; there is no GeoToold 3 project yet.
jgarnett: I need to get a "mandate" (something we can all believe in)
jgarnett: and then search for the correct venue; timeline; etc...
jgarnett: I am starting to entertain svn on osgeo hardware; and distributed version control to allow teams to work together (rather than branches)
jgarnett: but I need us to tell a better story then we did for GeoTools 2; both in terms of allowing teams to work together
jgarnett: and in terms of common goals.
desruisseaux: I would like to express the reasons why we are heading in the direction of GeoTools 3
jgarnett: I think we did a lot of that on email; the good news was that we all have similar motivations and similar scope.
desruisseaux: When I joined the GeoTools project 5 years ago, I was dreaming of a library
desruisseaux: I was hopping to build the best open source geographic toolsbox around (at least in the java world)
desruisseaux: As the years goes one, GeoTools became more like a bazar
desruisseaux: Patches submitted under time constraints
desruisseaux: While I come from a world where we try to think in longer terms
desruisseaux: (sciences vs business)
desruisseaux: Adrian and myself had strong disagreement with other member in this community
desruisseaux: But I stands with Adrian on most points. He have a quality that I appreciate a lot, which is sadly very uncommon in this community: rigor
iant_ n=ijturton@96.235.253.34 entered the room.
desruisseaux: The fact that Adrian and myself are the only ones with a scientific background my be part of an explication why we are having a hard time to be in agreement with the business view.
jgarnett: Understood
jgarnett: Martin I also have a long term plan in terms of API; usefulness and community.
desruisseaux: I was hopping a library released on a "when ready" policy; but in practice it is developped on a "when the client want it" or "when geoserver want a release" policy.
jgarnett: Now we each have different capabilities in terms of funding this dream; so far I am only able to get small chunks of time/money and as such have not been able to do all I have wanted on each day.
jgarnett: The stratagy for GeoTools 2
jgarnett: has been to build it because it is needed
jgarnett: once we have a working implementation
jgarnett: back it on to formal geoapi interfaces
jgarnett: as they are made available.
jgarnett: We are always caught in the conflct because GeoTools is a library used to develope
jgarnett: the standards as well as to implement them when they are published.
jgarnett: So I like this cycle.
jgarnett: However GeoAPI side lost some steam; so one of the things I would like to see for GeoTools 3 is a swift kick to get the GeoAPI project moving?
jgarnett: Does that make sense? I think it is compatible with both your goals; your companies goals; and the need to ship a useful library all the time.
desruisseaux: I was wondering if GeoAPI could be the glue between GeoTools 2 and GeoTools 3 (making easier to switch to geotools 3), with the side effect of increasing his credibility?
jgarnett: In short I find I need both sides (sciences and business) to have a library that is both correct (yeah siences) and timely (yeah business).
jgarnett: (smile)
jgarnett: that is a good idea; migration stratagy is to use GeoAPI interfaces.
jgarnett: that has a lot of upside.
desruisseaux: I agree that there is both world (sciences and busincess) to conciliate
jgarnett: Now for GeoTools 2 we had a mandate - implement GeoAPI interfaces as they became available.
jgarnett: We did not quite get buy in for that mandiate all around; as an example (just like for documentation) there was not always budget to formally define a GeoAPI interface
jgarnett: for each deadline.
jgarnett: I think that is actaully really good.
jgarnett: because frankly a correct GeoAPI
jgarnett: that does not have a couple of implementations (and thus represent a compromise)
jgarnett: is pretty silly or not credible to me.
jgarnett: I am not sure how you feel about that?
desruisseaux: I believe that there is 2 things we need to do in order to get more GeoAPI implementations:
Eclesia1 is now known as Eclesia
desruisseaux: 1) make it alive as an OGC working group (a way to do "marketing")
desruisseaux: 2) Creates a test suite for GeoAPI implementation, which would give a clearer benefit for implementors to use this project.
desruisseaux: #2 implies moving some Geotools tests to GeoAPI.
jgarnett: yes to both counts
desruisseaux: Adrian is already preparing that for geometries.
jgarnett: the test case code should be either LGPL or Public Domain
jgarnett: (for obvious reasons)
iant_: couldn't we define GeoTools as the reference implementation of GeoAPI?
jgarnett: I am not sure that would be smart Ian
jgarnett: we make compromises to GeoTools to "get it done"
iant_: I'm not sure how you'd define tests for interfaces
jgarnett: for GeoAPI we often want to "Get it right"
desruisseaux: I would like that, but not from our initiative. It would be nice to get that words from OGC.
jgarnett: even at the expense of usability.
desruisseaux: We could select onyl a subset of geotools
desruisseaux: to be proposed as reference implementation
jgarnett: ianT_ you can inject a factory into the test case; implementors would subclass the test case.
desruisseaux: But the decision would need to be OGC's one (I don't think they would object if our implementation is correct)
jgarnett: Martin let me bounce an idea off you
iant_: OK
jgarnett: (and then we should think about wrapping up this meeting in 10 mins)
jgarnett: One way to get more GeoAPI implementations is to make more GeoAPI implementations.
jgarnett: consider GeoTools as the nice friendly beast we know and love from GeoTools 2
jgarnett: And a GeoTools Kernal or something
jgarnett: that has all the strict implementations.
jgarnett: As an example our Filter implementation today contains a lot of backwards compatibility loving code and hacks.
jgarnett: A second implementation that avoided all that would a) be fun b) be clear c) be intergrated with GeoTools at a Factory / GeoAPI level.
jgarnett: ie; we need more than one implementation to be crediable.
desruisseaux: But could this second implementation be proposed as part of GeoTools 3?
jgarnett: there is nothing stopping us from providing several implementations.
jgarnett: I am talking about the structure of GeoTools 3
desruisseaux: Fine (smile)
jgarnett: ie how to set it up as an interesting project; with room for collaboration etc...
iant_: I'm not sure how much credability it gets us if both implementations come from GeoTools
jgarnett: in a sense this would be very much "Eating our own dog food" on the factory front.
jgarnett: Iant_ ++
jgarnett: Iant_ I agree on the credibility side of things
jgarnett: but there are two levels here;
jgarnett: in terms of the java community GeoAPI was set up to provide a venue for communication
jgarnett: recent Java Collab discussions
desruisseaux: For GeoAPI, I think that we really need to find the time and energy to support a OGC working group. We need a chair and members of at least 3 different organizations.
jgarnett: have left me a bit cold; I don't think other projects are interested in collaborating at this level.
jgarnett: but I know from experience that commercial and research organizations are
jgarnett: (indeed behind the scenes they funded most of my geoapi / geotools / standards work)
jgarnett: so there is a roll here - but it may not always be with other java open source projects.
desruisseaux: As long as GeoAPI provides only interfaces, other projects may see it as just constraints. But if we provides a test suite for this interfaces, they are starting to see benefit in implementing them. If in addition we migrate for example the OpenOffice plugins from GeoTools to GeoAPI, they would have yet more benefit.
jgarnett: IanT - to finish. Even with two implementations from geotools memebers I would feel more comfortable and trusting of a geoapi interface.
desruisseaux: (assuming some are interrested in a OpenOffice plugins)
jgarnett: (I never want to repeate the SYS_TECHNOLOGIES experience)
jgarnett: martin we may need to offer a bit more than test cases; but it is a start.
jgarnett: Let me give an example; if we can start offering geotools modules as reuseable components
jgarnett: the boundaries of which are defined
jgarnett: using formal geoapi interfaces.
jgarnett: we may have something.
jgarnett: (But we got to work on thouse interfaces / boundaries)
jgarnett: there is a blance between correct and simplicity that we don't hit
jgarnett: and we can measure the lack of success (smile)
jgarnett: Still there are good ideas all around here; and good examples.
jgarnett: I find it amazing that the old CoordinateSystem implementation
jgarnett: is winning out the deegree community
jgarnett: over the new CoordianteReferneceSystem?
jgarnett: I don't even undertand how that decision is worked out?
jgarnett: DO you have any insight martin?
desruisseaux: I have theory
jgarnett: Is the old CS implementation that much more simple?
desruisseaux: The old CS implementation is simplier and closer to WKT, but it was to simple.
jgarnett: Or is it just a lack of control issue? So much process behind GeoAPI that developers would feel at risk ?
desruisseaux: On the Degrees using the old CS, the main issue is that they are not seeing the difficulties of referencing.
desruisseaux: They are discovering it as they progress
desruisseaux: And they are redoing what is already done in current geotools implementation.
desruisseaux: For example the post last week about how to get the CRS that are valid over the USA.
desruisseaux: By not trusting ISO 19111, they do not admit that the referencing issue is more complex that they believe
desruisseaux: And they are discovering the complexity progressively
desruisseaux: For example in the old CS implementation, there is no way to known if a CRS use a cartesian, ellipsoidal or spherical coordiante system.
desruisseaux: Soon or later, when they will want to do serious mathematic, they will hit this wall.
jgarnett: hrm
jgarnett: so what we have here is a communication problem
desruisseaux: You can not do all yours mathematic as if the everything is cartesian.
jgarnett: (ie I am sure you communicated correctly; but sometimes communication problems can be with respect to listening)
jgarnett: We also need to publish how amazing geotools is more often (smile)
jgarnett: Unless we write articles and talk about how nice it is to have a good coordinate reference system implementation
jgarnett: nobody will notice when they google the topic.
jgarnett: (right now if they google most of what they find about geotools is bursa wolf transform parameter questions)
jgarnett: but that is more of a PMC / publicity issue
jgarnett: one we should be able to turn to now that OSGeo graduation is winding down.
desruisseaux: Justin pointed out that not having the referencing module downlable as a single JAR is a major reason.
jgarnett: yeah that is a big one.
jgarnett: you know what.
jgarnett: that - and just that
jgarnett: would make an excellent "first" geotools 3 component.
jgarnett: (the idea of bundling geotools components seperate is a good one; you saw my email on version numbers)
desruisseaux: I had this idea in mind, and this is also a reason why I'm pushing for geotools 3.
jgarnett: well starting out with a message everyone likes is a good move
desruisseaux: Yes I saw your email - I was not sure if it would be easy to do or not.
jgarnett: (you know the pressure of science vs buiness means this first component will have to be "referencing for JTS" :-D )
desruisseaux: What would look like referencing for JtS?
jgarnett: it may not be easy; but we should tell some story with the version numbers.
jgarnett: that is a good question - what referencing for JTS would look like.
jgarnett: I have some quick ideas;
jgarnett: CRS facade + JTS facade
jgarnett: store the CoordinateReferenceSystem object in the Geometry.getUserData()
jgarnett: and use that maven plugin to hunt down all other stuff.
jgarnett: ie fold this into a single download = geoapi interfaces, various geotools classes - and epsg-hsql
jgarnett: does that sound about right?
jgarnett: note the normal GeoTools 3 referencing module would be more general;
desruisseaux: Yes it was my plan to provide a single JAR with what peoples need
iant_: have you seen the fatjar project on sourceforge?
jgarnett: this JTS+referencing thing would be a seperate "product" -
desruisseaux: Yes I saw fatjar
jgarnett: no; but martin found a slick plug-in for maven.
desruisseaux: And I'm thinking about using it
desruisseaux: I think that the Maven plugin used fatjar
iant_: I've used it for some of my projects and i works well - plugs in to eclipse
jgarnett: (aside: iant_ if you can vote on a couple recent proposals - we miss you!)
jgarnett: Okay this was a good discussion
iant_: (already voted for you as osgeo rep)
jgarnett: Martin I need to stay cool for a couple more weeks; and have these discussions with you
jgarnett: and then we can get serious and start some formal planning.
jgarnett: does that meet with your timelines at all?
desruisseaux: As of referencing in JTS, getSRID doesn't have to be EPSG number right? So it could be numbers generated by GeoTools and uniquely assigned to a CRS in a running JVM (or does it have to be persistent between different JVM executions)?
jgarnett: oh good thought there...
jgarnett: I suspect that some implementations will store the SRID number
jgarnett: (I know for POSTGIS we make use of this number to reference the Spatail_Ref_SYS table)
jgarnett: but that is a good thought.
jgarnett: 3) SOC Status reports
jgarnett: wolf was collecting them
jgarnett: Simone was on holiday so I tried to answer a few questions
jgarnett: but in general SoC students have not been at IRC
jgarnett: and with out a wiki page or status emails
jgarnett: I feel a bit out of the loop?
jgarnett: Does anyone have a SoC student?
jgarnett: Or is anyone here a SOC student?
desruisseaux: Not on our side
jgarnett: fair enough
jgarnett: We should call the meeting over
Eclesia: the one you asked me to help didn't even send me a mail ...
jgarnett: there is a couple threads about release planning this week.
jgarnett: Eclesia he did respond to both of us; it was not very clear but it sounded like he managed to sort things out.
jgarnett: (and thank you for trying to help; I think most of what he needed was an encouraging word)
jgarnett: Martin for release planning
jgarnett: what does referencing need?
darkblue_B left the room.
jgarnett: And is there any help that can be provided?
desruisseaux: It is basically in the same state than 2.4. It contains a lot of duplicated code; EpsgThreadedFactories are modified copy of other classes, and those classes are quite big.
desruisseaux: So the amount of duplication is quite important
jgarnett: Rigth and we put off the clean up until 2.5 here
jgarnett: well can we try cutting cold turkey?
desruisseaux: I'm not sure which implementation is actually used, which make interpretation of stack trace more hasardeous
jgarnett: we should be able to do that just with changing the FactorySPI file
jgarnett: if we do it now; it sounds like we will get a couple weeks of solid testing out of GeoServer
jgarnett: and I can try and transition to epsg-hsql on uDig trunk
jgarnett: when you say you are not sure what implementation is actually used what do you mean?
desruisseaux: I do not know by memory what is declared in META-INF
jgarnett: okay;
jgarnett: I do
jgarnett: right now "my" implementation
jgarnett: is not hooked up
jgarnett: so cutting over; and talking about any bugs on email
jgarnett: is the first step
jgarnett: We can leave the "old" implementation there for a bit; perhaps someone wants to use it via a factory hint?
desruisseaux: I don't think we should add a factory hints for old implementations
jgarnett: I was thinking the hint where you say exactly what factory to use?
desruisseaux: So lets edit META-INF...
desruisseaux: Ah yes
desruisseaux: I forgot this one
jgarnett: um; I will wrap up the meeting IRC logs then
jgarnett: (thanks everyone; early meeting time is indeed better for starting on time)
desruisseaux: Bye all
desruisseaux: Thanks for running the meeting Jody

  • No labels