0) what is up
1) SoC deadline
2) what is needed for iso feature

jgarnett: Meeting time ?
jgarnett: Agenda topics?
jgarnett: I will start with 0) what is up
jgarnett: and 1) SoC deadline
jgarnett has changed the topic to: 0) what is up 1) SoC deadline
iant_ [n=ijturton@c-71-58-71-181.hsd1.pa.comcast.net] entered the room.
groldan: 2) what's needed for a real move to ISO Feature
jgarnett has changed the topic to: 0) what is up 1) SoC deadline 2) what is needed for iso feature
CIA-5: groldan 2.4.x * r26618 geotools/modules/unsupported/arcsde/datastore/src/main/java/org/geotools/arcsde/pool/ArcSDEConnectionPool.java: removed unused and conflicting import GetThreadPoolAction
groldan: jgarnett: removed the import on GEtThreadPoolAction
groldan: going for 0) so?
***groldan getting community-schema to build on 2.4 due to geoapi changes
jgarnett: 1) releasing geoapi2.1-M7 (so 2.4.x has something stable to track), putting together foss4g presenation and trying not to trip on deprecated code
iant_: trying to find a hotel in victoria with wifi and smoking rooms
jdeolive: feature model work on trunk, releasing geotools 2.4
desruisseaux: NetCDF and PostGrid work.
jgarnett: iant_ good luck with that - not a lot of smoking in North America.
jgarnett: Looks like you are running the meeting groldan
groldan: nice. anyone else?
groldan: go with 1) so, who's the floor?
chrisr: here I am
groldan: hi Chris, go ahead
chrisr: I now have a working implementation of Feature cache
chrisr: using memory or disk backend
chrisr: I am quite satisfied with the design, with should be reusable and extensible
chrisr: so it will be possible to use other king of spatial index in the cache
chrisr: for the example, I used a simple grid index
CIA-5: gdavis * r26619 geotools/gt/modules/unsupported/jts-wrapper/src/main/java/org/geotools/geometry/jts/spatialschema/PositionFactoryImpl.java: fixed errors in JTS-geom related to positionFactory changes in the GeoAPI
chrisr: As time goes short, I will have to reduce my first ambitions
groldan: cool, excuse my ignorance, but what serialization strategy are you using? and would it be too much effort to adapt it to ISO Features
jgarnett: (aside: http://docs.codehaus.org/display/GEOTOOLS/SoC+2007+Caching+data)
groldan: (ie, another feature model)
chrisr: I still have to move for SimpleFeature through my code, which looks horrible with deprecation warnings
chrisr: but I intended to do this at the very end
jdeolive: can i please interrupt
chrisr: ok go on
jdeolive: anyone moving to simple feature now before the first 2.5 release is made is a bad idea
jdeolive: so like you say, leave that until the end
jdeolive: i know workign against deprecatiion is hard
jdeolive: but you are going to add a huge amount of scope to your project if you try to switch over
chrisr: ok, so I had a good intuition
jdeolive: you did
chrisr: My plans before end of soc :
chrisr: try to write a write-thru implementation of my cache
chrisr: it should now be quite simple from what has already been done
chrisr: I considered making my implementation thread safe
chrisr: but it may be a lot of work, and I don't have much experience with concurrency
chrisr: so this might turn to be a hard work
chrisr: I also considered trying using another type of index, such as a quadtree rather than a grid
chrisr: and I have to save some time for code clean up and final documentation
chrisr: I wish I also get time after project's end to carry on work
chrisr: That's it.
chrisr: Any questions ?
groldan: just the previous one, do you foresee it would be too hard to switch feature model?
chrisr: no it should be ok to swith for SimpleFeature
chrisr: working with DiskStorage, my code works only with DefaultFeature
groldan: fair enough
groldan: so it needs to cast to DefaultFeature?
chrisr: SimpleFeature would be more generic
groldan: cool, I'm looking forward to take a look at your job, as it could be critical for community schemas
chrisr: ok, thank you
chrisr: I will appreciate a code review indeed
groldan: granted. Justin, are you Chris' mentor?
iant_: no I am
groldan: cool
groldan: Chris are you done? more questions?
chrisr: I am done
chrisr: I will update my wiki page for the latest news of what I have done so far
jgarnett: zzorn ping?
zzorn: yes
jgarnett: topic is 1) SoC deadline if you want to pitch in
groldan: nice, looking at it right now, looks way interesting
zzorn: Ah
zzorn: Well, I do have two bugs and one feature I'd like to work on more. And get better example data into the demo.
zzorn: But if you want to keep the deadline I'm ok with that too.
jgarnett: At this stage it is more important to wrap things up in a way where people can try it out; so demo is better than additional features.
jgarnett: chrisr has your mentor talked to you about FOSS4G yet?
zzorn: Neither of the bugs are real show-stoppers, but they can be a bit annoying (some ground tiles not getting textured, and preview textures being flipped along y axis). The feature is to subdivide the nearby tiles more, to have a more even resolution around the camera.
***zzorn nods
chrisr: jgarnett we submitted a presentation
zzorn: If I get a few days I could work on the bugs and getting in the better example data.
jgarnett: cool - so you already have travel plans then? I would like it if James had a few students around to do demos ...
jgarnett: be we can take that to email.
jgarnett: rather than hold up the meeting.
jgarnett: any other students around? Or shall we move on ...
JJezek: Hi all
JJezek: just shortly... if someone is interested I have just updated the wiki
groldan: hi
JJezek: http://docs.codehaus.org/display/GEOTOOLS/New+Transformation+Algorithms+for+GeoTools+and+uDig
JJezek: Some screenshots including uDig plugin are there
groldan: could you give us just a quick resume of your progress?
JJezek: The GeoTools part is almost finshed (some work on ducemtation remains)
JJezek: Now I'm fighting more with uDig trunk.
JJezek: That's all.
jgarnett: sounds great
groldan: cool
groldan: should we move to 2)?
jgarnett: (once again I assume Jesse let you know about travel)
Jesse_Eichar77 [n=Jesse_Ei@mail.refractions.net] entered the room.
JJezek: you mean James and demos...?
jgarnett: I mean James Macgill; he is our contact at google ... and he would like some of the SoC students around to show off what they did.
jgarnett: I should say he is our FOSS4G contact at google, FrankW is organizing OSGeo SoC stuff.
JJezek: yes. I droped him reply already/
jgarnett: cool.
jgarnett: Yes gabriel we should move on .. 10 mins left.
groldan: ok, I'll take the floor
groldan: to ask you all what you think the strategy to move to ISO Feature should be
groldan: afaik, we're moving trunk to SimpleFeature
groldan: and that covers everything but data access
groldan: jody asked me to make a proposal
groldan: for data access
groldan: which I might do, but would like to know what the current plan is
CIA-5: desruisseaux 2.4.x * r26620 geotools/modules/library/coverage/src/main/java/org/geotools/coverage/grid/GridCoverage2D.java: Added a dispose() method because it is required for some situations (GEOT-1041), with a javadoc warning saying that this method should be avoided for other usage in its current state.
groldan: Justin, 2.5 is just about moving to SimpleFeature,right?
jdeolive: not sure this a plan as of yet...
groldan: and it should last till...? october?
jdeolive: yes you are correct
jdeolive: hmm... yeah probably
jdeolive: but yes after that we need to think about the change over
jgarnett: I would think that DataStore returns things that work with Feature; and that for specific implementations like Shapefile we type narrow to SimpleFeature
groldan: ok, I'm asking just to make sure what is and what's not clear yet
jdeolive: i disagree jody
groldan: I like that
jdeolive: DataStore will hvae to return SimpleFeature
Jesse_Eichar77 left the room.
groldan: but so far
jdeolive: too much code will break otherwiser
Jesse_Eichar77 [n=Jesse_Ei@mail.refractions.net] entered the room.
CIA-5: jgarnett 2.4.x * r26621 geotools/ (4 files in 4 dirs): change over to geoapi 2.1-M7 milestone jar
groldan: the code base should work over simple feature or feature
jgarnett: okay, not to worry that was my assumption, I am not sure what the plan is myself justin.
jdeolive: it will need to be a base class of DataStore that returns Feature, and DataStore will type narrow to SimpleFeature
jdeolive: imho anyways
groldan: will the situation be that we have the whole codebase assuming we work only with SimpleFeature?
jgarnett: right; makes sense to me - so we drag out DataAccess again ... as an approach that worked.
jdeolive: thats my understanding gabriel
jdeolive: yup, but scaled back this time
groldan: I would better like that everything that works on features uses PropertyAccessors or whatever?
groldan: I mean...
groldan: I'm not seeing the gain of changing feature model if everything is going to assume simple
groldan: and I might being too naive here
jdeolive: fair enough... and i am ok with going through PropertyAccessor
jgarnett: jdeolive you had the idea of a code sprint to handle the "changeover" did you not? What work are you planning on having us do?
jdeolive: but for the simple case its hard to do that
jdeolive: and the gain is that SimpleFeature is related to Feature through inherietance
jdeolive: so the switch over is cleaner
groldan: but how/when will a "Feature provider" be able of being plugged on the library and make sure it'll run?
jgarnett: I would like to see PropertyAccessor as well; keep a strong seperation between data / description and query
jdeolive: to be honest I dont ever see anyone coming along with their own custom feature implementation
CIA-5: chrisr * r26622 geotools/gt/modules/unsupported/caching/src/ (34 files in 13 dirs): DiskStorage now working
groldan: I don't mean that
jdeolive: sorry
groldan: but with their own complex feature capable datastore
groldan: say we already have a feature implementation to use (currently fm module)
groldan: and a feature capable datastore (community-schema-ds)
jgarnett: I see lots of people coming in with their own custom feature implementation... it is the driver for this work on the uDig side.
groldan: so far, we can foresee what's needed for geoserver wfs and wms to work with it
jdeolive: i know you do... all i said is i would like to see someone actually pull that off
jdeolive: groldan: so here is what i see
jdeolive: at some point we will need to nail down this "DataAccess" class
groldan: agreed, for that to happen there has to be a prepared floor
jdeolive: at the point we do... geoserver will have to switch over to it
jdeolive: and a lot of code in geoserver will have to change to work against Feature... or we break out geoserver extension points for dealing with SimpleFeature vs Feature.... not quite sure
groldan: ok, so far, it seems like we're reaching a mid-point concensus over our old discussion on the fm-to-trunk approach
groldan: like if DataStore, as it is, dont move to ISO Feature, we need an alternative
groldan: with the aggregate that the feature model is the same, but most of them are optimized to ISO SimpleFeature
groldan: which sounds good
groldan: am I right?
jdeolive: yeah i would agree
groldan: ok, so state of play would be:
groldan: - for short term (ie, 2.5) the point is get rid of geotools Feature in favour of ISO SimpleFeature
groldan: - for 2.6? we need to work out DataAccess and geoserver
jdeolive: yup
groldan: question:
groldan: how far are your current work of "moving" the fm implementation to trunk?
jdeolive: pretty much done
jdeolive: i think there may be a few things around the edges i havent ported over
jdeolive: but most of it is there
jdeolive: i still need to port the test cases over now that I think of it
groldan: does it include heavy use of FeatureBuilder and SimpleFeatureTypeBuilder (I might be misspelling them)
Rob_Atkinson: does this mean that behind the SimpleFeature API, you haver removed the default feature and replaced it with fm?
jgarnett: I agree; jdeolive's work looks pretty much done. I am writing up some code examples in order to review it.
jdeolive: groldan: no... the old creation methods like schema.create are still there... but they fall back on the new apis
jdeolive: i would liek to utilize the code sprint to port over all the rest of the code to new apis
jdeolive: Rob_Atkinson: DefautlFeature now is a subclass of SimpleFeatureTypeImpl
jdeolive: sorry
jdeolive: SimpleFeatureImpl
jdeolive: its not done
jdeolive: i am still testing
jdeolive: i am using geoserver cite as the test bed
jgarnett: So to sum up; he has put the ground work in while still letting everything compile. Now we need to go through and update the codebase to take advantage of the fact the new interfaces are available.
jgarnett: Once the codebase is updated you will find it easier (actually possible) to start using iso feature.
jdeolive: my first priority is to have things work like they work before
jdeolive: the rationale being that if they dont, there is no future for this work with geoserver
groldan: ok, we're running out of time, could we wrap the meeting up? I have enough info but might ping you later/tomorrow
jdeolive: i realize that iam kind of waving my hands with regard to full iso feature support
jdeolive: jgarnett, thta is the general idea
jdeolive: ok i am done unless you guys have any more quetsions
Rob_Atkinson: still have no idea of how the fm gets accessed in your port
jgarnett: so if I tie your hands down - "iso feature" is out of scope for 2.5
jgarnett: we are only trying to make it possible.
jgarnett:
jdeolive: jody, i guess you did not head my warning about not killing TypaName
Rob_Atkinson: maybe it only compiles...?
jgarnett: Agreed; that was a misunderstanding justin.
jdeolive: christ, i was so close to passing cite... not back to getting things to compile
jgarnett: geoapi-2.1-M7 is now deployed; 2.4.x is depending on it.
jgarnett: (making this a good release candidate)
JJezek left the room.
chrisr left the room (quit: "Leaving").
groldan: ok, so right now, its a complete mess: the fm implementation that was working doesn't do that anymore as I was close to get it, except FeatureList has dissappeared
jgarnett: so change your implemenations to implement FeatureCollection
jgarnett: I could not handle anymore having an interface around that nobody was supporting.
groldan: so far so good, I understood yout response to the ml
jdeolive: jody you need to stop removing things on a wim, just to make docs look good
jdeolive: people have projects that depend on this stuff
jdeolive: and the worst part is that this is not even in teh scope of any of your paid work
jgarnett: justin you are right; I also need people to take usability a bit more seriously.
jgarnett: so I feel torn.
jdeolive: usability is software that works
jdeolive: when you make changes like this software stops working
jdeolive: keep in mind that user community >>>>>>> developer community
jgarnett: usability is also seeing a little bit past your current deadline and not introducing a bazillion deprecations. I have been answering email on the user list and am getting a better and better impression of how much trouble geotools is to learn.
jdeolive: jody, your increasing scope like usual
jdeolive: and i read the messages to
jgarnett: I tried to push FeatureCollection and FeatureList for a year; but developer community said now ... only thing I am trying to do now is communicate that to the user community.
jdeolive: and there is just as much flak for api cahnging then there is for deprecation
jdeolive: both of which have been happening for years
jgarnett: understood justin
jdeolive: anyways
groldan: ok, just for the record, removing geoapi stuff cause pain. You're in all your right to kick our asses to be more proactive
groldan: but getting to office and finding nothing works because of a non "concensuated" remove kills
jgarnett: jdeolive 2.4.x seems all upto date and ready to go; is your experience any different?
jdeolive: i havent checked... i am not going to be working on something while you are its like trying to hit a moving target
jdeolive: i am trying to work on trunk, and geoserver 1.7x
jgarnett: FeatureList should still be there in 2.4.x, it has just been removed from trunk
jdeolive: which is also like hitting a moving target
groldan: mine is, as I was working, under consensus, on a geotools version being used by a geoserver build
groldan: I might agree unsupported/community is abused that way, but it was decided on several meetings
jgarnett: I am a bit lost; what is the difficulty gabriel?
groldan: uh, oh, it seems I didn't tell gtbot to record the meeting
jgarnett: GeoTools 2.4.x is going stable because it the target for a formal GeoServer release.
jgarnett: I admit uDig trunk has dropped back and is just using GeoTools 2.4.x for a couple of weeks; I needed to clean up the Generics before we could try GeoTools trunk again.
groldan: the difficulty is I tried to get fm and community-schema-ds building and it was impossible after 9 hours of hacking to accomodate to the geoapi changes
jgarnett: nope; I can post the IRC log.
groldan: the generics stuff seems just right
groldan: and I'm glad of most of the changes
jgarnett: I think jdeolive took some of the generics stuff into gt2-main
jgarnett: I at least recognized a lot of the classes.
jdeolive: there should not be any generics on main
jdeolive: if there is get rid of them
jgarnett: sorry my bad
jgarnett: fm stuff; SimpleFeatureImpl and so on.
groldan: but since, though building and having a geoserver build out of it, community-schema were out of the build, it got too out of date
groldan: ok, no point in me crying, let wrap up the meeting and get this beast running again
iant_ left the room (quit: ).
jgarnett: I think you shoudl find that your fm module may be much reduced in scope now; most the implementations should be in main.
jgarnett: I will post the logs; thanks for the meeting (and the extra 20 mins "chat")