Agenda: 1) build 2) wiki org 3) roadmap 4) changeover process 5) powered by 6) expected featuretype

IanS this type of thing "svn: REPORT of '/!svn/vcc/default': Could not read status line: connection was closed by server. (http://svn.geotools.org)"?
jgarnett Hi pramsey IanS was just asking about "Connection was closed by server. (http://svn.geotools.org)"
IanS we all experienced network troubles last week - inspecting the server did not show us anything as far as I know.
pramsey show me
do it now
IanS okay
did it
the bizarre thing is that I can do ls,propfind,etc. and connect using cadaver and konqueror (webdav) but svn update fails every time
but only to geotools repository
jgarnett (I am going to go grab some food - back in 10 - feel free to start the agenda without me).
jmacgill wakes up
IanS try doing it in small chunks
IanS i tried that once with spike. I'll try again
pramsey funky, it fails w/ an HTTP error code 207
which does not exist
IanS hmmm, i mentioned some paranoid gov filters, seems like more evidence for that
there is/was a IIS webdav exploit so maybe they're blocking that somehow
okay, well thanks paul
pramsey whereas I get code 200, success.
jgarnett back
agenda?
jmacgill fixing non building modules
jgarnett 2) wiki re/organization done
3) roadmap agreement
4) api changeover process / feedback
Okay james - over to you ...
jmacgill 5) projects using GeoTools page
6) expected feature type for subset of properties...
ok, the nightly build is failing a lot of modules and I think we need to resolve that asap.
I've been working on the wfs plugin for another reason and I think that will come back up when I commit
polio it's already building
jmacgill I have high but untested hopes that just adding a dep on legacy will make most of the others work
jgarnett http://sourceforge.net/mailarchive/forum.php?thread_id=6508133&forum_id=3008
jmacgill check last nights build
jgarnett (above link has the list)
polio just needs to pass tests now
(commited this am)
jgarnett oracle-spatial cholmes/jgarnett are module maintainer. Chris can we have a look at the problem and email the list with a plan? I won't have time until near thursday.
mysql?
cholmes Yeah, I've seen that - I have to finish up this paper, and then I can take a look, hopefully wednesday.
polio I think ew should relax the espg encoding requirements (all caps)
jgarnett Spec says one thing, practice say another.
Jmacgill? Relax an issue a warning like usual?
polio for example espg:4269 would not be parsed, but ESPG:4269 would
jgarnett I assume this is related to wfs not passing its tests david?
polio yes
jgarnett The nightly builds is not picking up everything, I don't see validaiton and graph on that above link.
opps
I am blind.
polio what were there dependencies?
ah ok
jgarnett Here is the list of failures:
jmacgill remember the list becomes inacurate as you move though it
jgarnett gt2:oracle-spatial cleaned
gt2*:mysql cleaned
gt2*:gtopo30 cleaned
gt2*:arcgrid cleaned, compiled
gt2*:wfs cleaned
gt2*:mapinfo cleaned, compiled
gt2*:geotiff cleaned
jmacgill i.e. anything which depends on any of those will not even be listed
jgarnett Yes. Lets just plow through this in an orderly fashion.
polio IM me if needed pls
jgarnett oracle - email at end of the week.
CIA-3 dzwiers * r11158 geotools/gt/plugin/wfs/test/org/geotools/data/wfs/WFSDataStoreWriteTest.java: tests require espg fixes ... otherwise ready to pass
jgarnett Can we just work through the list, james can you speak for any module maintainer not present.
Some of these can be "fixed" by making them depend on legacy.
Is this what you would like in the short term james?
Others like geotiff we need to wait until we have a JAI expert to port the coverage.io classes.
CIA-3 dzwiers * r11159 geotools/gt/plugin/epsg/test/org/geotools/referencing/crs/EPSGTest.java: epsg tests
jgarnett I assume james well not be able to answer now
Is anyone else a module maintainer on these modules?
polio ... so epsg will no longer build (with the new test cases)
Martin_ I know i told that I was going to port
jgarnett understood thanks david.
Martin_ I'm the module maintener of grid coverage and its io part.
jmacgill the legacy module should allow all of these modules to at least compile even without porting
Martin_ I'm late to my schedule. Still working on crs...
jgarnett James I don't think we have the module maintainers present for all the modules that don't build.
Did you want to fix the links to legacy and move on - or leave them broken?
polio (translation for some modules) did you want to release all the modules under 2.1
cholmes I should be able to get mysql and oracle by the end of the week...
jmacgill those two would be a big boost
jgarnett Cool - are you the module maintainer for mysql (or just being nice chris?)
jmacgill the project.xml lists him and garry shepard
polio agreed, I'm just concerned that if they are built against legacy, what would happen at the release date
cholmes Yeah - I keep trying to pass of module maintainership to people by making them co-maintainer, but they always just drop off the map.
jmacgill I can kick garry on this one
do we have a 'how to port' page I can point him at?
jgarnett No we don't I will start that page while I wait ...
cholmes The problem is he didn't catch up on andrea's jdbc changes, so he's not so clear on what's going on in the code any more.
jmacgill ah, fair enough
cholmes Looking at the build report it looks like it's not compiling because it's using old jdbc datastore constructor methods...
jgarnett Ah yes they were deprecated in 2.0 and thus removed.
Something for the porting guide.
jmacgill next item?
jgarnett 2) wiki re/organization done
jmacgill I must say it is looking considerably better
jgarnett X*ier and others have been having some duplication issues.
I had a run through the docs, made a stab at reducing duplication.
Reviewd the developers guide, made a printable version.
And locked all pages that are actually depended on by the layout.
Oh and provided a navigation bar, so I never have to look at http://geotools.codehaus.org/ again.
jmacgill The printable version of the guide is a huge busoost
jgarnett James updated the http://geotools.codehaus.org/ site to include our logo again - thanks james.
Most "lists" now have an "Add new page to list" tip.
Martin_ By te way, I realized that a google on some keyword like "Transverse_Mercator" point out massively to legacy Geotools pages. Maybe we should remove them, so that Google point toward latest pages instead?
jgarnett These work from both sites.
Oh right - thanks martin.
Currently we only refer to the docbook section in the old manual.
We can drop doc book or port those last couple pages.
James do we still docbook?
jmacgill nope
so lets kill that
jgarnett +1
cholmes +1
Martin_ +1
jgarnett I would draw peoples attention to: http://docs.codehaus.org/display/GEOTOOLS/Use
jmacgill Is there a redirect I should put in?
jgarnett There is a resources page where I have dumped to multiple attempts by users to gather example data, and example SLD documents.
On a related not udig is moving to drupal later in the week (part of becoming a product), a RnD presense will be maintained on codehaus for some time.
jmacgill - can I bug your for the IRC logs again
+1
Anything else for the docs or can I move on ...
jmacgill it is very hard to get at them - the old site is full of redirects and the content is in a database which I cannot get into
jgarnett I see, can we export the content somehow?
jmacgill will try again though
jgarnett 3) roadmap agreement
Last week saw our users notice the major changes in the 2.1 code base.
After some discussion a roadmap and migration guide were created.
I said I would present to roadmap for approval / input at this meeting.
http://docs.codehaus.org/display/GEOTOOLS/Road+Map
cholmes What does migration guide mean? For us or for our users?
jgarnett Wann do the roadmap first and come back to the migration guide?
(migration guide just writes down in one spot the information that was scattered througout the developers guide)
We also found a few bugs in the process.
http://docs.codehaus.org/display/GEOTOOLS/Making+a+major+API+shift
The above link is the process ...
Does anyone have any feedback on the short term roadmap above?
Perhaps I will let people think about it for a week before asking for a vote.
jmacgill Will M3 be ready to go on the 11th?
what will it look like?
cholmes So we're going with a roadmap based on release dates instead of features?
jgarnett It will include those datastores that have done the CRS shift.
So it is based on features.
jmacgill I think dates will let us work out what features we can resaonably fit into each version
right now we just stack everyting up and say 'next version'
jgarnett I am happy putting out udig based on a release candidate if need be.
jmacgill then bump them all back a version
cholmes I heard a good quote once about open source works if you pin to dates or to features. Putting it on both just sets up things you won't meet.
Since things just move at their own pace.
jgarnett (but I also want to leave the project in a stable state when our time drys up). Refractions staff should be out of the codebase by then, other than volunteer hours.
cholmes So if we want to go with a set number of features we should set the milestone on that, not on some date we won't meet.
jgarnett Unfortantly we have a cut off date chris.
I don't want to leave the community without stability. Making a release is the best way I know to do that.
cholmes But then again, since refractions is more or less running the show these days I suppose doing both is fine.
Cool, sounds good.
jgarnett Well I want to make sure it is cool - their are many other players here.
For instance not everything refractions wanted made the cut.
(we all work with what is possible).
Lets vote next week, I want to be sure people are cool with this.
Similarly the CRS shift document is not much of an issue until Geotools 2.2 starts up.
cholmes Ok, sounds good. Would be nice to have links on the road map in the wiki to the roadmap in the jira, and have that be what we are actually going to get done.
jgarnett 4) api changeover process / feedback
(we kind of covered this)
5) projects using GeoTools page
James?
jmacgill sorry got pulld away
jgarnett If this is about the GEOS / UDIG links in the wiki I can remove them.
jmacgill ok, we need to start a showcase page
no, I like them
but we need a slot for other projects
jgarnett (I just found them easy to bounce around the GEO Codehaus projects)
Ah.
Screensnaps?
Friends
jmacgill more a place for people to advertise what they are dooing with geotools
jgarnett "Cool Stuff"
Could make another column in the websites page,
jmacgill yeah, something in that sidebar
jgarnett http://docs.codehaus.org/display/GEOTOOLS/Websites
Is that the page james?
Or this one http://docs.codehaus.org/display/GEOTOOLS/Project
jmacgill Neither
something new I thinl
jgarnett Note http://docs.codehaus.org/display/GEOTOOLS/History was updated to include Geotools 2.1 success/failure on our goals.
Okay will do.
6) expected feature type for subset of properties...
jmacgill ok this was an interesting behaviour difference I noticed between the shapefile plugin and the wfs plugin
if you generate a query with a subset of the property names
and pass it to shapefile
you get back features with a modified feature type that only lists the included properties
if you pass it to wfs you get back features with the full set of properties but with most of them set to NULL
jgarnett James that may not be our fault.
The WFS being asked the question may not answer correctly?
Ah - that does sound like a mistake.
Jira issue?
jmacgill the WFS is correctly returning the data
and I have fixed it localy
polio or could be my fault too ... I think I may be caching the fts
jmacgill but.... which is right?
the new one has the same featureTypeName
polio I would have expected the limited featureType
jmacgill me too
but I'm now not 100% sure that is the 'correct' answer
I'll go with the limited feature as it is the most useful
polio well, could view the query as a re-define request of the FT in which case it is fine
yah, and it's what the user wanted back in the first place I think
jmacgill keeps memory usage down too
ok, just wanted a sanity check :_
cholmes I actually sorta feel the FeatureType should be a full featureType.
In keeping with a WFS model.
The schema is still the full schema, just some of the properties are empty.
I think our datastores retyping the featureTypes is a bit weird.
And memory intensive.
When it can just return Attribute.EMPTY or something for one that has not been filled in.
jmacgill trouble is, with a FeatureType with 1600 attributes then having 1598 nulls per feature is even more intensive
polio mm, but the query could essentailly retype the original in the process
(the way it is) for example, it would have to allow nulls where it may not currently ... causing it to retype anyhow
jgarnett cholmes does the schema thing make sense?
jgarnett Sometimes the schema could define the attributes as being required
in which case you have to return them - even if the request did not say so.
I remember having to think through this in the GeoServer case.
That is even though the request is does not mention bounding box, the schema will require it and it will show up when you make a query using the WFSDatastore.
(this is a case of our FeatureType model not capturing everything? Or does our attributetype capture this?)
cholmes sorry, my computer crashed.
jgarnett Opps I am just saying the same thing as david anyhow.
cholmes what were you guys saying?
jgarnett james can't get back in.
We were remembering the AttributeType 1:1 relationship from GML schema.
polio basically: you can ask for a sub-set of the feature, which does not include attribute T, but the original does require attribute T
cholmes (just got it from richard, reading it now)
jgarnett That is attribute you did not ask for will be returned.
ah, we could go for 5 times on the repeat.
james appologies and blames XP.
IanS analogously, dbms allow a subset of columns returned in a query, presumably in the interest of bandwith and isn't wfs supposed to be data-transfer protocol to abtract back-end??
jgarnett yes that is why it lets most attributes be non 1:1
but for somethings like FeatureID you are stuck with.
This is up to the data provider IanS.
cholmes Yeah, that makes sense. I have some further thoughts on all of this, but I don't have much time at the moment, I'll try to write them up.
jmacgi back, sorry about that
polio IanS: yes, think I got your point there. Agreed, WFS can change the schema based on backend data provider's events
so short answer: FT is retyped? +1 here
jgarnett Hey chris add GeoServer to this page - http://docs.codehaus.org/display/GEOTOOLS/Powered+By
IanS don't know whats right, just offering POV
cholmes There are some nice things to be gained by an Attribute.EMPTY - like I think it can make caching of attributes easier, which is a direction I think we should head.
jgarnett No IanS I think you have the right of it.
cholmes ReTyping things all around is fine for streaming stuff - but if you're retyped stuff it's hard to figure out what you're actually missing, what you have cached and what you need to retrieve.
jgarnett Ah see that point too -
polio IanS: point is good ... the spec does not guarantee consistency between requests
jgarnett Chris I think we need a different query for FID ie Attribute empty requests for caching.
jmacgi gml allows subtypes to contain LESS variables than parent - perhaps we could make the retype a child of the main feature type
polio we could do that
cholmes I think that might work well.
jgarnett Okay this is the last agenda item.
Any more thoughts on this ....
bwoodward \leave
jmacgill_III I'll read the logs as the last 10mins are ful of holes for me
jmacgill_III but yeah, I'm done
hime time for me
Martin_ Quick question: can I delete org.geotools.util.ClassFinder? (it was refactored as org.geotools.factory.FactoryRegistry)
rgould Yeah
jgarnett That seems to be my que to gather and post the logs.