- Meeting time for next IRC
- Graduation to OSGEO
- Image I/O metadata
- Meeting time moved to 9:30 PST
- Martin is going to make a mvn site:site report capturing the review.txt files
- Jody is going to make the Provenance Review page on the geotools wiki
- Jody is going to make a Jira issue category for "provenance" issues
- Andrea was going to verify the state of unsupported
- Breakout IRC on wednesday to fix any remaining issues
- GeoTools 2.5.0-RC1 to be released just in time for the board meeting (Unsupported modules will not be included)
- Simone is looking into ImageIO metadata and will ask on java-collab and possibly use google docs to collect requirements
- unsupported/ogc modules are required for our build
jgarnett hello everyone!
desruisseaux Hello Jody
desruisseaux The meeting didn't started yet
simboss hy guys
SamH Hi all
desruisseaux Hello Simone & Samuel
SamH How's everyone doing?
SamH I'm getting mad at JAI.
simboss don't worry, you are not the first one, and for sure you won't be the last one either
SamH it doesn't seem like a very well supported project...
desruisseaux Its is a very powerfull library, but its development is going slowly since a while.
simboss well from what I know
SamH yeah... good way to put it.
simboss they only take care of the commercial users
simboss but they are having internal problems to go open source for good
simboss hence it is kinf of a dangling project
simboss which sucks honestly
Eclesia (then we must join the jai project)
SamH that would explain a lot.
simboss patches takes forever to get to trunk
simboss eclesia, I did, but It did not changed much
jgarnett well it is like 30mins after? going to be a quick meeting?
simboss I would like to add
simboss imageio metadata
simboss for nd coverage
simboss just for the fun of it
SamH that would be very helpful...
simboss (well daniele is not around, I'll do my best)
SamH and could be very powerful.
aaime Shall we get started?
desruisseaux Fine for me
jgarnett yes ...
jgarnett aaime do you want to run the meeting today?
aaime 0) What's up?
aaime is trying to speed up feature and taking pain in the process
desruisseaux Martin: a bit of cleaning in metadata, referencing and coverage (just scratching the surface actually)
Eclesia playing on puzzle, and seriously working on styles
simboss simone: jpip + python
vheurteaux word excel and powerpoint :-/
jgarnett jgarnett: more udig training; I am really enjoying it - except for the GeoTools 2.2 part - which I am hoping to get over.
simboss move to trunk, move to trunk, move to trunk...
jgarnett (I have to move my developers first)
jgarnett so yeah - what is next?
jgarnett 1) Meeting time for next IRC
desruisseaux I'm fine with whatever hour people come with (would be happy if sooner)
simboss that would work for most europeans
desruisseaux This is 10:00 AM on American West coast. Sound raisonable?
SamH That is reasonable.
desruisseaux Computing again...
desruisseaux Yes, 10 AM (I think)
desruisseaux (checking again with a real tool; I think I'm confused...)
aaime works very nice for me
jgarnett that sounds fine for me; as mentioned on email the only people left out here are in Australia.
jgarnett so +1
aaime so we have 3 +1 right?
aaime or 4? simboss?
desruisseaux Would be 9:00 AM in Vancouver
simboss i proposed it, I am +1
jgarnett okay so simboss you get rewarded by updating the developers guide
jgarnett motion passed.
desruisseaux Is 9:00 AM okay for you Jody?
jgarnett I was hoping for 10:00 AM; but yeah 9:AM is fine ...
desruisseaux I made I mistake when I said 10 AM. This is why I checked with a better tool after.
aaime well, 19.00 italian time is not that bad either for me
aaime both work fine for me
desruisseaux Both work for me as well.
simboss no wait sorry
simboss it is a bit late for me
simboss can we make it 18:30
SamH That sounds like a good compromise.
aaime that would be 9.30am Vancouver time
jgarnett I don't mind moving the meeting early
jgarnett all these options are in refractions work day; so you are not cutting into my personal time.
aaime so, 19.30 CEST, 9.30 Vancover, deal?
jgarnett So I will vote +1 on any of them.
aaime it seems we have an agreement?
jgarnett sounds fine; and a final idea - let us start on time
aaime eh, right
aaime So ok, new meeting time is scheduled at 19.30CEST
desruisseaux 2) Graduation to OSGEO
aaime simboss, update the page, can you also send a mail?
jgarnett and simone updates the developer guide Can you send email too Simone?
jgarnett Simone is popular; it must be his good looks.
simboss being beatiful is a curse
aaime he has big shoulders, we know he can take it
simboss but I bear with it as a man would do
aaime desriusseaux, osgeo?
desruisseaux Adrian as sent an email last week
aaime do we have a wiki page with a status of each module?
jgarnett um the page has to be on the osgeo site
jgarnett let me find the link;
jgarnett last time I emailed each module maintainer; but perhaps this time we should just "get 'er done"
jgarnett - http://wiki.osgeo.org/wiki/GeoTools_Incubation_Progress
desruisseaux Rob is our mentor. The next OSGEO meeting is Friday in about 10 days. If we want him to submit GeoTools graduation to OSGEO vote, we need to make sure that:
jgarnett - http://wiki.osgeo.org/wiki/GeoTools_Provenance_Review
desruisseaux * review.txt file is up to date for every modules
jgarnett Cameron is our mentor
desruisseaux * We have determined to provenance of our data
jgarnett up martin
jgarnett review.txt is just our way of being organized
desruisseaux Ah? Oups, sorry to have confused who is our mentor
jgarnett for the actual issues we can fix them; or
jgarnett punt them into the bug tracker.
jgarnett We will link to the review text files; but that is really us just getting organized...
desruisseaux So do we have a parent JIRA task when we can create sub-task for open issues?
desruisseaux (typo: where we can create...)
jgarnett compare with http://wiki.osgeo.org/wiki/FDO_Provenance_Review
jgarnett or this one: http://wiki.osgeo.org/wiki/GDAL_Provenance_Review
jgarnett the second one is much more inline with what we need.
jgarnett notice each actual issue links to an entry in the issue tracker?
aaime well, ours is not that bad, we'd need to expand all the review files into the wiki page, right?
jgarnett gdal/data has the most issues; not it graduated with known issues.
jgarnett well we can link to the review.txt files in svn ... sound okay?
jgarnett really the committee will check the review files; and try and catch us out.
jgarnett make sure every issue is in Jira etc...
aaime sort of, I mean, we'd have to make it evident which review.txt contains issues
jgarnett How about we have a link to each review.txt in the wiki
aaime also that page hasn't been upgraded since 1.5 years it seems?
jgarnett and then a link to each issue covered by that review.txt
jgarnett I think we are down to only a few issues now right?
jgarnett correct aaime
jgarnett now a couple ideas to make this easier.
desruisseaux Adrian told me that Java code is okay, but we need to determine the provenance of our test data.
jgarnett can we move the contents of this page into our own wikit?
jgarnett I think we can ...
aaime desriusseaux, I fear that many shapefiles are very old
aaime no one knows where they come from
jgarnett would making it in our own wiki - make it easier for module maintainers to update?
desruisseaux I guess that Ian Turton would know.
aaime like the old old states.shp, anybody knows about its origins?
jgarnett I assume ESRI test data honestly.
desruisseaux We should ask to Ian Turton. He is the most likely guy to know about those data.
desruisseaux I will send an email to him.
desruisseaux Do we have someone up for the wiki page?
jgarnett that poor osgeo wiki page links to our module matrix; which is very incomplete...
jgarnett martin is there any chance our mvn site:site thing could have a report link for each review.txt file?
desruisseaux Yes we can do that.
jgarnett martin I can do the wiki page ... I will move it to our wiki and expect help filling in the details.
jgarnett if you can do a mvn site:site with the review.txt stuff it will take care a lot of the grunt work on the wiki page...
desruisseaux Thanks Jody. I take the email to Ian and the link in "mvn site:site".
jgarnett the other thing is to make a sample download of the code that is "Ready"
jgarnett I assume we do not want anything in unsupported;
jgarnett the downside is a lot of Justin's generated code is there ...
jgarnett we may have to set up a formal profile or something?
jgarnett what do people feel about that?
desruisseaux I think it would be safe to ommit the unsupported modules.
jgarnett well problem is martin we use some of them;
jgarnett andrea are you up for some pom.xml hacking?
aaime that does not mean we have to include them into the releases...
aaime jgarnett, what exactly?
jgarnett I am thinking we have several profiles in "unsupported"
aaime creating profiles so that unsupported is not included by default in the builds?
jgarnett (we do already)
jgarnett and we isolate all the stuff that is "ready" from an osgeo standpoint; oracle-spatial; ows; etc...
aaime that would speak trouble thought....
jgarnett and we turn that profile on by default.
jgarnett okay what trouble?
aaime modules getting broken because of chages in the core ones
aaime and nobody noticing
jgarnett we can include them in the nightly build if you want
aaime like what happened in epsg-oracle
jgarnett but they are not something we can ship right now?
jgarnett agreed; but this is a deadline; and we need to cut our losses (for the geotools project here)
jgarnett I understand that uDig and GeoServer make use of oracle-spatial plugin...
desruisseaux Do we need to provides downloadable files for the graduation?
jgarnett I think oracle-spatial is not the best example; it has a review.txt
jgarnett See email:
jgarnett I want to be able to point Cameron at the following:
jgarnett - sample download with the headers all fixed up; a release candidate?
jgarnett - a list of Jira tasks for each problem we found in the review.txt files
jgarnett - update the incubation status page to reflect we are ready
jgarnett ie we would like to say to the committee; here it is - the geotools library as we would like you to approve.
jgarnett does that make sense?
aaime it does
desruisseaux I think it make sense. But could the downloable file be just a milestone?
jgarnett the only problem here is unsupported\ogc ... we have no review.txt and this includes the work of the OGC (in the form of schemas)
jgarnett Do we have jdeolive around?
aaime jgarnett, actually I believe acuster did review most of the unsupported modules
aaime jgarnett, away, vacation
jgarnett ah ...
desruisseaux How does unsupported/ogc relate to the OGC project on dev.java.net?
aaime not at all afaik
jgarnett I am not sure if there is any relation martin
aaime there are EMF models
aaime of many OGC specs
jgarnett I think everything else in unsupported we can safely drop and still have the library work.
jgarnett okay we need a volunteer to look at unsupported; or pester acuster and see how far he got, or even check for email from acuster on the topic.
jgarnett can we follow this one up on emal?
aaime I so far counted 2 modules without review.txt made/updated by acuster
jgarnett and since this is a deadline and the PMC are responsible for seeing this happen; tag the subject "PMC:" to start out with; or use the admin list.
aaime ok, so the plan is?
desruisseaux Jody move the wiki; I ask Ian Turton for shapefile data provenance and I make review.txt content to appears in mvn site:site.
aaime (sorry guys, played tennis two hours, had a shower, no dinner, I'm about to fall flat on the floor)
jgarnett yeah and the meeting is running late; almost done andrea.
desruisseaux We can point Cameron to the new wiki and to the maven site
desruisseaux What else?
jgarnett we should check back in; say a breakout IRC later this week; and if ready we can make a release candidate.
jgarnett how does wednesday sound? too soon or too early?
desruisseaux fine for me
jgarnett or too late for us to fix stuff after.
jgarnett okay cool.
jgarnett 3) Image I/O metadata
jgarnett sounds like good progress on this one on the email list
simboss I just wanted to tell people what we are up to
simboss since we would like to do a tentative for early collaboration
simboss at the lowest possible level
simboss for coverage, which means imageio
simboss daniele and alessio have been working on imageio readers for grib1, netcdf-cf and hdf4/5
simboss some work hs already been done
simboss some needs to be done
simboss and especially on defining
simboss possible structure for metadata
simboss I was thinking about asking daniele
simboss to capture the work on the wiki
simboss but I am fraid it might be dispersive
simboss right now we are using an OO document
simboss I was thinking about
simboss a google document
simboss a public one
jgarnett quick suggestion
aaime I guess it's up to cbriancon, he's the one working on that for Geomatys, right?
jgarnett jump on that silly java-collab list - and let them know what is up
jgarnett at the very least frank will want a look see?
simboss yeah, good point
desruisseaux I'm fine with java-collab list
desruisseaux (fine with wiki page too, at your choice)
simboss what would you think about a google doc
simboss we could import the one we have
simboss and edit online
simboss in a cooperative fashion
desruisseaux Actually I don't know how google doc work (never tried before). But if you have experience with that, it is really worth a try I think
jgarnett (aside: I am going to make a new Issue Category for this "license" stuff; that way the wiki can report back the issues and always be correct)
desruisseaux Nice idea Jody!
jgarnett yeah I have my moments.
jgarnett simboss I am also doing okay with just open office documents in version control
simboss is it obvious that I am google docs fun?
simboss well, go for the document in subversion then
jgarnett but yeah google docs works fine.
jgarnett depends on how much collaboration you expect from java-collab I figure.
desruisseaux I have no objection against google doc; this is really as you wish
aaime if you're shooting for java-collabo maybe google stuff is better
jgarnett your party simboss
simboss let' try google docs, if it does not wkr we can export as open office again
simboss we can control who write on it
simboss who can read it
simboss we can have ffeds for the updates
simboss etc., etc.
jgarnett okay so with that non decision we better end the meeting.
jgarnett before andrea falls asleep on the keyboard.
jgarnett (and can I ask someone to post the logs; I got wiki page of doom going on here and I am scared to lose my train of thought)
desruisseaux On the metadata document, I would have a suggestion... If "calibration" is a requirement from your client, then I understand that we try to put it in the metadata. But if it is not a requirement, I would suggest to leave "calibration" out for now. This is really a much wider topic than just "scale" and "offset" coefficient (even if the have an "error" attributed). Actually it is venturing in...
desruisseaux ...the land of SensorML...
simboss martin, we might need it to capture
simboss packed remote sensing data
simboss for the moment thigs are simple
simboss but we might soon start working
simboss with the cosmo skymed data
jgarnett oh martin don't go to SensorML; we like you more than that.
simboss and that is going to be painful
jgarnett oh no they are both lost ...
aaime goes have some dinner
jgarnett we will hold a wake; SensorML is the start of specifications that never end ... Observations and Measurements.
desruisseaux I means, if you don't need calibration now, lets wait a bit before to try to handle them. "scale" and "offset" are related to data encoding, which is not the same. Calibration is really an other topic.
simboss yeah, I see what you mean
simboss let's put it this way
simboss from the moment scale and offset
simboss *shouldé be fine
simboss let's leave a question mark though
simboss I got some data to play with and calibration might really be involved
simboss but as I said for the moment
simboss scale and offset
simboss should be fine
desruisseaux Yes, but they would be deserve a "Calibration" node independant of the data encoding.
simboss yeah I see your point
desruisseaux Calibration scale and offset are not necessarly the same than data encoding scale and offset.
desruisseaux Calibration varies with each instruments
desruisseaux Data encoding is usually frozen for a whole data series
simboss (I remember that was part of the email right? )
desruisseaux Even if the data series come from of many instruments.
desruisseaux Yes, that was part of my email.
desruisseaux Calibration are almost never linear.
simboss (cool then, I'll talk to daniele about this tomorrow)
desruisseaux They are usually at least cubic, often yet higher degree.
simboss we might want to come back to that
desruisseaux So this is not the same than the scale and offset using for data encoding.
simboss quite soon
desruisseaux All right.
simboss if we get to model the sensor platform used for the acquisition of the scene we have to manage
simboss but for the moment
simboss you are right
simboss we might want to find a better name for data encoding params
desruisseaux I suggest to just move "scale" and "offset" either in Category, or in SampleDimension close to "nodataValues".
desruisseaux And reserve "Calibration" name for much more sophesticated calibration metadata later.
desruisseaux In OGC 01-004, "scale" and "offset" are in SampleDimension with "nodataValues".
simboss fine with that
jgarnett updated: http://wiki.osgeo.org/wiki/GeoTools_Provenance_Review
jgarnett created: http://docs.codehaus.org/display/GEOTOOLS/GeoTools+Provenance+Review
simboss since you are there
simboss did you ever manage to get around
simboss hdf crashes?
desruisseaux No, but last time I tried was two years ago.
desruisseaux I got crash on Linux only; it was working fine on Windows.
jgarnett that is a first
simboss well under big load crashed on windows as well
simboss I tried to rebuild the source from scratch putting guard expressions in the c/c++ code
simboss but it still fails
simboss it is failry unusable inside a web server
simboss too bad
desruisseaux I would suspect the problem to be more likely to be on JNI side than HDF C/C++ side
desruisseaux Given that the HDF C/C++ library is widely used at Nasa, it would be surprising if it was unreliable.
desruisseaux The JNI part is likely to be less widely tested.
desruisseaux I have done a little bit of JNI a while ago and I found that tricky.
simboss that's what I meant, i tried to reinforce the JNI part
desruisseaux Most be very careful about releasing JVM resources, especially pointer to arrays (and HDF library probably use a lot of them)
simboss woring in c/c++
simboss but it is too wide
desruisseaux Enforcing the JNI part with classical C/C++ guard expression code probably don't manage JVM resources.
simboss yeah, I guess we would need to spend quit some time on it to make it robust
desruisseaux So if a JVM resource was not properly released, I'm not sure that gard expression would have detected that (just an hypothesis; I just expect those expression to work on classical C/C++ stuff)
simboss I was thinking about rewriting them from scratch with SWIG
jgarnett guys can I capture the logs now? And it is Canada day tomorrow.
jgarnett oh simboss that is a lot of work ...
simboss not too much actually
simboss if you know how to use swig
jgarnett jgarnett not leet enough; repressed all JNI stuff ages ago.
simboss well, my python is calling me
simboss ciao a tutti!