1. Complex Feature Status
2. Shapefile FID Indexing
3. POJO DataStore
<groldan> cool, was worried about the time
<jdeolive> no problem
<groldan> there are agenda items so far?
<jdeolive> nope, lets start some
<jdeolive> 1) Complex Feature status
<Jesse_eichar> 2) FID indexing for shapefile
<jdeolive> anyone else?
<jdeolive> we can throw them on as they come up, i dont think anyone else is going to show
<jdeolive> i will start
<jdeolive> 1) Complex Feature Status
<jdeolive> so as you guys read from my email i have got the complex-features branch in geotools compiling in a 1.4 world
<jdeolive> and against the geoapi feature interfaces
<jdeolive> well a slightly out of date version of them, jody went and broke things on me
<groldan> yeah, just checked out, trying to build
<jdeolive> so i have been working against datestamped geoapi builds
<jdeolive> any luck?
<jdeolive> everything should be all commited up as of about half hour - hour ago
<groldan> maven complains, but it could be me. should I just "maven build"?
<jdeolive> yup
<jdeolive> i am sure i missed something though so i wont be suprised if it doesnt work
<jdeolive> what kind of errors are you getting
<groldan> Error parsing project.xml '/home/gabriel/workspaces/complex_merge/cpx/org.vfny.geoserver.gtlibs-cpx/project.xml'
<jdeolive> are you tring to build geoserver or geotools?
<groldan> geoserver cpx branch
<jdeolive> hmmm, oh, my bad, forgot to commit something
<groldan> np
<jdeolive> commiting now, you should be able to update and try again
<jdeolive> so to as where things are at
<jdeolive> i am unable to merge from geotools complex-features onto trunk
<groldan> its working
<jdeolive> the changes since the initial branching make the two pretty much incompatable
<jdeolive> so there might be some manual work to perform the merge
<groldan> yeah, I figure it out, so did you a manual merge?
<groldan> ah, ok
<jdeolive> so right now i still have geoserver building off the branch
<groldan> so you started branching trunk and manually applied differences from complex-features?
<jdeolive> nope, so far i have just been making changes to complex-features to get it to compile in a 1.4 world
<jdeolive> and against the new geoapi interfaces
<jdeolive> now we have to merge from complex-features onto trunk
<groldan> note: can you upload the following files to the online repository so maven can download them?:
<groldan> epsg-wkt-2.2.x-complex_branch.jar
<groldan> gml-2.2.x-complex_branch.jar
<groldan> property-2.2.x-complex_branch.jar
<groldan> shapefile-2.2.x-complex_branch.jar
<groldan> validation-2.2.x-complex_branch.jar
<groldan> complexds-2.2.x-complex_branch.jar
<jdeolive> yeah i can
<jdeolive> so the way the merge has gone so far is not desirable
<jdeolive> getting this stuff on trunk still represents quite a bit of work
<groldan> how far we are from being complete porting complex-features?/what do you need that I do?
<jdeolive> well i sent you that list of mofified files?
<jdeolive> if we could figure out where the major changes are, i would like to start there
<groldan> yes, is it ok if I apply changes and commit them or do you only need a review of most important changes?
<jdeolive> other things (like the filter api changes) I would like to do seperatley to avoid massive conflicts
<jdeolive> no go ahead, my only request is that you do not commit any java 1.5 code
<groldan> understood
<jdeolive> cool
<groldan> what do you mean by applying filter changes separately? branch the branch?
<jdeolive> well when I tried to do the merge using svn i got a conflict in every single filter file (~100 files)
<jdeolive> and all the changes are mostly just api changes (minus AttributeExpressionImpl, etc...)
<jdeolive> so i can save myself some pain just by using eclipse to refactor
<jdeolive> does that make sense?
<groldan> what's running on cpx is in line with geotools fm branch?
<jdeolive> not yet
<jdeolive> right now fm = trunk
<groldan> its from complex-features so?
<jdeolive> sorry not sure i understand
<groldan> I mean if the jars being used in cpx are built from complex-features or from fm
<jdeolive> complex-features
<jdeolive> i am uploading them to the refractions rackmount as we speak
<jdeolive> however feel free to build your own, they are synced up with svn now
<groldan> I'm getting the updates, nice
<jdeolive> i apologize for this being a bit confusing
<jdeolive> i would have liked to go directly from complex-features onto fm
<jdeolive> but with all the differences, and a deadline from rob to get a geoserver build up, i thought this was the least risky way
<jdeolive> get geoserver build up, then fix geotools
<groldan> no, its ok. so, in my understanding: cpx == trunk + complex-features
<groldan> complex-features backported to 1.4
<groldan> thats all
<jdeolive> yes
<jdeolive> so i just commited my last changes to geoserver, to get it to compile off of complex-features as you noted
<jdeolive> so now its pretty much testing time
<groldan> well, at least the geoserver side of things is easy. Do we'll get rob's release out of this schema and then go for Jody's modified geoapi interfaces in fm?
<jdeolive> yeah the geoserver changes were pretty trivial
<jdeolive> now i would like to test the complex stuff in geoserver
<jdeolive> not exactly too sure how to do that
<jdeolive> i guess i should read your user docs
<jdeolive> can i get to them off the geoserver experimental page?
<groldan> mmm... what about convering the complexds unit tests to http unit?
<jdeolive> definitley
<jdeolive> just not too sure what the requests for complex content and stuff look like, i guess they are mostly just normal requests
<jdeolive> however there is teh config setup
<jdeolive> which i have been figuring out as i go along
<groldan> some configuration info: http://docs.codehaus.org/display/GEOTOOLS/ComplexDataStore+Documentation
<jdeolive> do you think you could whip up a quick http unit tests as an example, then i can help write additional tests
<groldan> and yeah, requests behave as usual, just that you can include xpath expressions for addressing attributes
<jdeolive> cool, the docs look good at first glance, should be simple enough to get tests going
<groldan> though you already noted the xpath stuff still lacks namespace support
<jdeolive> i didn't see any tests from the geoserver branch you created when i did the merge
<jdeolive> correct?
<jdeolive> yeah, there are some assumptions going on, but we dont live in a perfect world yet 
<groldan> we can setup the tests with a simple properties datastore so its easier to get them running
<jdeolive> yeah i noticed that is how the gt tests were setup, quite handy
<groldan> right and right.
<jdeolive> cool
<jdeolive> cool, things are going well
<jdeolive> so shall we continue this over email or offline
<groldan> so any change we divide work without steping on each other?
<jdeolive> yup sounds good
<groldan> (change == chance)
<jdeolive> how about i do the filter changes
<jdeolive> and you focus on the other classes that were changes
<jdeolive> changed
<jdeolive> but i think before that getting the geoserver tests going should be priority
<jdeolive> do you agree?
<groldan> ok.
<groldan> but I guess i'm not understanding something:
<groldan> cpx is already compiling and running against complex-features, so you mean setting up the geoserver tests and then start applying changes to fm?
<jdeolive> yes
<groldan> but run cpx against fm after this deadline
<groldan> cool, now I'm clear
<jdeolive> yes
<jdeolive> excellent
<groldan> do we let the meeting go ahead and continue this offline?
<jdeolive> sounds good, better yet it woul d be nice if we could start chatting on the devel list, let everyone else know what is going on
<groldan> alright
<jdeolive> alrighty, jesse_eichar, you are up
<jdeolive> 2) FID indexing for shapefile
<Jesse_eichar> ok
<Jesse_eichar> Currently making a feature query to a shapefile data data with a FID filter takes N time. where N is the number of features in the shapefile.
<Jesse_eichar> I'm making modification to the indexed-shapefile datastore so that it will perform FID filter queries in very nearly constant time.
<jdeolive> nice !!
<jdeolive> are you creating a new index for the fids?
<Jesse_eichar> yes.
<jdeolive> cool
<Jesse_eichar> It also changes a few things for example. before if you deleted a feature 1/2 of the way through the features all the FIDs of the remaining features would decrement by 1.
<Jesse_eichar> now they will stay the same at least between runs of the JVM.
<Jesse_eichar> The index is all file based so the memory footprint is not increased so don't worry there.
<jdeolive> sorry i dont understand, do you mean they will be same within a single instance of the jvm?
<jdeolive> and could change between instances? just that all the fids dont have to be update when you change one
<jdeolive> ?
<Jesse_eichar> What it means is the fid index may be deleted when the JVM is shut down depending on how many deletes have been made.
<jdeolive> ok i think i understand
<Jesse_eichar> If there have been many... say half of the features. Then the index is basically useless and should be regenerated.
<jdeolive> makes sense
Hi all. Just a reminder: news article up at http://freenode.net/news.shtml .... group registrations, staff channels, 2006-2007 fundraising .... have a great evening, and thank you for using freenode!
<Jesse_eichar> But I didn't want to do that in the middle of a run because it woudl invalidate all the fids the clients have obtained from the datastore.
<Jesse_eichar> hence. FID may be invalidated between JVM runs.
<jdeolive> ok, that makes sense, that is what i meant
<Jesse_eichar> ok
<jdeolive> did the old implementation change fids out from underneath people?
<Jesse_eichar> So I'm just about done now. I should get it on to trunk tomorrow ish.
<Jesse_eichar> Yes.
<jdeolive> cool
<jdeolive> sounds good
<Jesse_eichar> If a feature was deleted, say the first feature, then imediately all further fids are changed.
<Jesse_eichar> really caused us some headaches.
<jdeolive> yeah i can imagine, espceially for doing things like editing
<Jesse_eichar> exactly
<Jesse_eichar> That's all I have to say.
<jdeolive> cool
<Jesse_eichar> unless there are more questions.
<jdeolive> anyone have anything else?
<groldan> I would like to ask you about pojo ds
<Jesse_eichar> me?
<Jesse_eichar> or justin?
<groldan> yeah, Jesse
<Jesse_eichar> ok shoot
<groldan> are you going to make it, right?
<Jesse_eichar> Refractions is probably not me.
<Jesse_eichar> I'm pretty booked.
<Jesse_eichar> I'll most likely be a designer/consultant on it though.
<groldan> ah, sorry, I thought it was already assigned to you
<Jesse_eichar> nope not yet.
<groldan> ok, its just that I was working with hibernate and wondering if you thought on using it
<Jesse_eichar> I hadn't thought that much about it yet.
<Jesse_eichar> I don't know much about hibernate right now.
<jdeolive> that would be slick in our new geoserver world, spring has tonnes of integration utilties for hibernate
<jdeolive> but i really dont know tha tmuch about it either
<Jesse_eichar> we were going to abstract the persistence away from the datastore.
<groldan> ok, no worries, it may be worth a look though
<Jesse_eichar> so I think that should be one option but not necessarily the only one.
<groldan> my initial concerns about it was that it looked too much memory bound
<groldan> but actually it could be used in a streamed fashion, just like datastore api
<groldan> and you get caching and lazy loading out of the box
<Jesse_eichar> I agree. I never considered it a memory datastore at all.
<groldan> at the cost of extending it for spatial queries
<Jesse_eichar> I figured the backend could be a database/network/memory
<groldan> thanks, that's all. I'll try to be watching for it when the time comes, since I'm quite interested in the pojo ds
<groldan> that's all, thank you