Agenda: 1) like filter 2) epsg 3) 2.1.M3 4) coverage
polio Does anyone have anything for an agenda?
I would like to look at LikeFilter in main
Martin On the agenda too: EPSG factory and plugin/epsg module please.
polio 2) epsg
anything else?
3) jody: M3
cholmes 4) coverages in geotools 2.1, for A1Fa
polio 1)
Bill propmpted me to look at the current implementation of the LikeFilter
here I noticed that some computation of the filter was being completed when the values were being set, and I was wondering if anyone minded me changing this to do the computation (and cache it for later consumption)
AlFa Chris I've read your e-mail ... I'm waiting for Simone to connect
polio for use in the evaluation of the Feature inclusion/exclusion
My concern is that this may change some of the assumptions within the datastores
polio as the output from a getX is not the same as the input from setX
jgarnett We ran into this issue when specing out the Expr class - basically is simplification allowed during construction.
The answer at the time for Expr was no, do what the user says.
Leave any partial evaulation to the DataStore Expr walker.
So I would say build exactly what the user says. And fix any datastores that get broken.
cholmes - you are the better person to ask on this then me.
You know what the existing JDBC SQL generation from filter expects.
cholmes I don't remember off the top of my head...
Wait, actually JDBC never got a successful Like filter implementation, if I remember correctly.
jgarnett I think it is fairly clear the current Filter construction code is broken.
The question is really who will fix the testcases when Filter suddenly is unbroken.
cholmes Yeah, Filter is one of the packages most in need of refactoring - unfortunately Expr didn't take off...
jgarnett That is because it got Join stuff mixed in.
I am happy to toss the Join stuff out of it, and submit it for approval again.
But really we should hit the GeoAPI filter at the same time.
cholmes Can GeoAPI filter allow us to do delayed evaluation?
jgarnett So I would say fix the current filter, plan to refactor as part of 2.2 when GeoAPI Filter comes down.
It is just an interface.
Evaulation would/should be up to something else.
(That is how Expr does it)
cholmes Yeah, but I think that our current interfaces sort of imply that you need it evaluated first - though I could be wrong...
jgarnett Note the only thing Expr does better is allow for ease of use.
cholmes Though I guess the Expr experiment showed that could be worked around...
Martin (going away for a couple of minutes)
cholmes Didn't it also allow late processing?
jgarnett Yes it did.
(http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/filter/package-summary.html)
To implement the GeoAPI filter I would just prot Expr to support those interfaces.
cholmes That for me was the biggest improvement - I personally found the Expr ease of use to not actually make it much easier for me.
Cool. Then I'm +1 on everything...
jgarnett Q chris - what is everything
1) fix filter
cholmes ' So I would say fix the current filter, plan to refactor as part of 2.2 when GeoAPI Filter comes down.'
jgarnett 2) chris fixes the jdbc datastores
3) david fixes WFS

Ah.
cholmes jdbc datastores don't implement like filter - that's the one that is just about always post-processed - so if the actual java LikeFilter works then theywill work.
jgarnett I see.
Okay + 1 especially since like is broken already everywhere.
polio ok, both plans seem the same then. +1
cholmes +1
polio 2) epsg ... but martin stepped out
3) Jody + M3
jgarnett wanna wait for him then ..
.. oh darn.
Well 2.1.M3 is ready, tested and approved.
polio yah, lets come back to 2) when martin returns
jgarnett We just need a) SF access for rgould, or b) a PMC to upload the files.
I can't volunteer today
polio but ... can't you log ricahrd in?
jgarnett Any other PMC around, hey maybe I can bless rgould into higher SF access.
polio (he's 6ft away)
jgarnett (I am trying to go through offical channels here :-P )
cholmes Yeah, we can easily give him file release access...
jgarnett Do you know how chris?
AlFa Hi Simboss
jgarnett James said he would do this but has not come through yet.
simboss hi everybody, I made it finally
AlFa Chris Simboss is the other one
simboss te One!
jgarnett We should also thank rgould for all his hard work on 2.1.M3 - it is the best 2.1 yet by a long shot.
cholmes yeah, doing it right now...
jgarnett simboss meeting time - did you have an agenda item?
sweet thanks chris.
polio (think he and AlFa was 4) )
cholmes ok rgould is now a 'release tech'.
polio 4) coverages in geotools 2.1, for A1Fa
rgould thanks chris
cholmes So he should be able to go to the admin -> file release stuff. Sf has good instructions for file release, so just follow those.
ping me if you need help at all.
rgould great, thanks
AlFa yes we are foutrh on agenda
cholmes So you're looking to do WCS on GeoServer, right?
jgarnett So now that jesse is here we can chat - what to be done about grid coverage?
cholmes What's the time frame that you're looking at?
jgarnett We have a shinny new api, and a simple implementation for world + image.
It uses the new CRS work.
I would kind of like to throw out Grid Coverage Exchange and just work from the Formats (it is all any client code ever does).
Martin (back)
jgarnett There was some talk of a new interface from GeoAPI land - Martin do you know more?
(whew good timing - over to you Martin)
AlFa yes I alredy build a first version of WCS in GeoServer
cholmes Really?!? wow - using geotools 2.0?
AlFa yes
Martin About GridCoverage:
We would like to revisit the geoAPI interface (with Stephane Fellah among others)
simboss i would like to expose which are iour needs (mine and alfa's ones)
Martin By the way, Stephan Fellah is the one who wrote the GridCoverage implementation specification 1.0
simboss we are aiming at buildng a whole system which follows ogc specifications on WFS, WMS,WCS,WCTS,WCAS
Martin For now, it doesn't move a lot because we need a refactoring of directories organization in CVS
cholmes Cool - have you seen our opensdi ideas?
simboss that is as everybody here nows qute a big job
cholmes http://docs.codehaus.org/display/GEOS/OpenSDI
simboss clearly we do not want to everything by ourselves and from scratch
cholmes The plan is to turn geoserver into a pluggable framework for ogc services - to tackle exactly all those problems.
simboss that is why we started looking at geotools and geoserver
i got that
cholmes We're going to join up with Geonetwork Open Source - which will do catalog stuff...
simboss that is why we want to base our work on it and relase our work as open source
cholmes excellent.
simboss (we are fighting an internal battle to achieve this, not everybody is for it)
let me see if i got right the actual situation
geoserver at the moment perfomr wfs
and wms non raster
what we really need for the end of may is a skeleton of a wcs
without raster support
or wiyh a little raster support
we need to deal with remote sensing netcdf files
cholmes Gotcha.
simboss we need to be able to provide users with a server capable of storing and retrieving these data along with related metadata
in different formats
but mainly
not images
i have been looking around for months
i studied everything deeply
and i started promoting geotools and geoserver
at the moment everybody ahs been convinced especially the bosses
simboss alfais already working on a skeleton wcs
cholmes So you're a commercial company? And you've already got a contract to do wcs with netcdf?
simboss we are working for a international non governative entity
this is all I can say
otherwise they won't let me do this open source
that is the deal
cholmes cool.
simboss the opportunities are enormous
there are lots of maney involved and if the product goes well
cholmes definitely - this sounds great.
Martin We already have in our laboratory some skeleton code for reading HDF and NetCDF (both formats are somewhat related).
simboss (i am using libraries from unidata to do that)
Martin I may look for commiting them in geotools, but this code will need more work.
Yes, me too.
simboss more and morewill come
Martin But we need some bridge from those library for making a GridCoverage from them.
simboss i have some questions that might be too specific for the MLs
Martin Type: But we need some bridge from those library to geotools.
Which kind of questions?
simboss (i am sorry if i tool so much of your time guys)
cholmes No, not at all. Feel free to ask more questions.
We would love to have you very involved with GeoTools, as the coverage stuff has been in need of some solid support for awhile.
simboss 1>we want to extend coverages r/w capabilities to other formats, ew really like the gce interface, but the point is the following
I think we have no time to bring the 2.1.x at a satisfying state to meet our deadline
not enough time
therefore we are considering extending 2.0 while working on 2.1
Martin GridCoverage work on 2.1 start today...
cholmes When's your deadline? 2.1 needs to be in shape by the end of march, for udig and geoserver releases.
Martin (I was stuck with CRS until recently, but move on on GridCoverage now).
simboss the overall deadline is 20th may
cholmes How do you need to extend 2.0? Just add netcdf?
CIA-11 rgould * r11532 udig/plugins/net.refractions.udig.project.ui/src/net/refractions/udig/project/ui/internal/ProjectEditorAreaDropAction.java: Refactored the drag and drop code
jgarnett back
CIA-11 rgould * r11533 udig/plugins/net.refractions.udig.project.ui/ (2 files in 2 dirs): added File->Open... Action
simboss we trying to made a general ER model of coverages reality (well it will be more general at the end) in order to represent theminside a db rahter the inside files
sothe bigh work will be on that topic
and also, which brings me to the second question,
we need to model data we get from model which are in 3 or 4 REAL dimensions
jgarnett I think coverage allows for more then 2 dimensions.
simboss not like the 3rd dimension for remote sensing imaegs like the one we egt from eris or modis acquisitions
the interfaces sure they do
but the actual implementations i doubt it
Martin Right.
simboss its back end is a buffered image
Martin But this is one of the thing that I plan to fix.
It will be fixed.
simboss i know i might use a trick and use some bands as dimensions
but it would be really tricky and dirty
I was thinking avout using java3d api
to treat 3d data
and to manage time separaty
(my experience suggests me that)
there is a class in java3d
called (i am not sure)
imagecomponet3d
composed by an array of buffered images
i was thinking about swuthing to this class as a back-end (just a thought for the moment)
switching
Martin A few words on my plan please:
simboss sure
sorry for being so long
Martin (no problem )
GridCoverage will be ported from 2.0 to 2.1, at least for switching from old CTS to new CRS framework.
This work start today.
In the process, I plan to use GeoAPI interfaces more.
And refactor the current GridCoverage implementation as a "GridCoverage2D" class.
As you point out, while the interfaces allows an arbitrary number of dimensions, current GridCoverage target 2D.
cholmes Martin - what's the status of Stephane's coverage work in GeoAPI? Will be using those, or the older ones?
simboss gotcha
Martin The "GridCoverage2D" class name for the implementation will make that clear.
simboss i completely agree
Martin And it will leave room for a GridCoverage3D class.
AlFa me too
Martin About Stephane Fellah work:
This is a very important piece, but I don't know how long it will take.
The big problem is political, not technical.
We should build new GridCoverage on top of ISO 19123
extended with Stephane Fellah proposal.
cholmes I believe in one of his emails he said he had a deadline of the end of Feb....
Martin Unfortunatly, at the difference of ISO 19111, ISO 19115 or ISO 19107, ISO 19123 is not published on OpenGIS web site right now.
jgarnett Martin I think we will have to stick with what we have for 2.1, and let GeoAPI and politics work out the rest.
AlFa by I think we have some time for GridCoverage3D, right Simone?
jgarnett Stephane Fellah never really got back to us after we expressed interest.
simboss sure
Martin Yes, I'm aware of Stephane Fellah deadline.
cholmes This is right where my issues with geoapi come into effect - could we just put it in a pending geoapi folder or something?
Martin I agree for a pending folder.
cholmes Or if that's too politically radical, just put it in GeoTools - since all seem to agree it is technically better, no?
Martin The problem is that we need to refactor CVS directory first, and I never got feedback about moving to SVN first.
Again, the problem is political.
If we move to SVN, we need to move out of Sourceforge. Would peoples accept that (outside Geotools)?
My plan is to abandon SVN wish, stick to CVS and refactor SourceForge CVS today.
Martin I will send an email when it will be done. Then, we should put the Stephan Fellah work in a pending folder.
cholmes cool.
Martin There is no political issue in putting Stephan Fellah work in a pending folder. I believe that he is well accepted at OGC, and most peoples recognize the quality of his work.
However, I don't think that we can expect GeoAPI to move fast on the GridCoverage issue.
We really need to clarify this ISO 19123 thing. When wiil we be allowed to use it?
Unfortunatly, it is not clear to me to who we should ask to OGC.
cholmes I mean, from a geotools perspective, we can use it now, right? We are not beholden to the ogc and their politics...
Martin The GridCoverage working group has been disolved.
cholmes GeoTools can move faster - if it is technically superior.
Martin They are considering to recreate a new one, but it is not yet done.
jgarnett Note GML3 has grid coverage stuff as well.
Martin Yes, Geotools could use them.
jgarnett Not that I recommend it, but since they move to ISO Geometry defn in GML3 perhaps they also targeted ISO GridCoverage?
Martin Jody, could you point me to the place in GML specification that talk about GridCoverage? It may be of interest for me...
jgarnett Open the pdf, search for grid coverage.
Martin Yes, I believe that GML target ISO grid coverage.
This is the problem.
Everyone at OGC seems to target ISO grid coverage, but the spec is not public!
jgarnett It is an extention of bounded feature in which the content is defined by a grid or something like that.
Well they obviously don't want an implementation then.
cholmes But if GML targets it then it's more or less public - we can interpret through that...
Martin I asked many time for a fix to this strange situation, but nobody seem to take the task since the grid coverage working group has been disolved.
simboss iso not public spec are a big issues for mere mortals like me!
jgarnett and us all.
Well can the Go-1 people help us out here?
Martin It is an issue for GeoAPI. If we build an API on top of ISO, it is like taking the ISO specification and publishing it on our own. We could be trapped in legal issues.
cholmes Can we infer enough from the GML spec? Or no? (wait, I suppose Martin needs time to evaluate it).
Martin My plan is:
cholmes I mean, most of our feature model was based on gml spec, not the abstract specs.
Martin 1) Port the GridCoverage with interfaces as they actually stand, so we have something working in Geotools 2.1 fast.
jgarnett Good point on GML inference of ISO spec - unfortantly this did not work for me with resepect to ISO Metadata for catalog.
simboss we might share the load of that port if you give us directions
Martin 2) Create the "pending" folder and gets Stephane Fellah proposal, se we have some thing to look at.
3) Take some time in geoapi to looks at GML specification, and see what we can do publicly.
1 and 2 should be fast.
I don't know how long 3 may be.
cholmes Sounds good.
AlFa I agree with your plan Martin
simboss but as i said we need directions
i am concerned especially with the isued that might come out from interaction with refrerencing packages
but we have time and will to share the load
(and someone else pays well for us to do it )
AlFa
simboss let me and alfa now something please
the 3d evolution might come right afterwads
Martin Interaction with the CRS package is actually the biggest issue. But since I did both CRS and GridCoverage package, I can take this issue. In the main time, you could do a port oforg.geotools.io. coverage if you want
AlFa I need GridCoverage working on Geotools 2.1 as soon as possible, so i can continue my work
Martin Or wait, yet better! You could start to work on a GridCoverage3D class right now!
simboss if we get into the package
it is all about deadlines
i need gc2d working as soon as possible
then my time will be on gc3d
Martin My plan is to get is working before the end of this week.
simboss alfa is the one in charge of the wcs thing
AlFa and my on WCS and geoserver
simboss he needs something to work on
martin i guess you are the one who can tell us what to do
so illuminate() me taking into account what I said about deadlines (life is a whole big deadline )
Martin I need to dig in the code (I was away from GridCoverage for a few months). But I suspect that one area that need to be ported is all the I/O framework.
GridCoverage is already partially ported
This is the org.geotools.coverage package.
What remains to be ported is:
simboss yeah i saw that
Martin GridCoverage2D (legacy org.getools.gc.GridCoverage).
simboss from what i understood there is some work to carry out on the org.geotools.coverage.grid package
sampledimensions and everything else
Martin Yes exactly. Because the interaction with CRS, I would like to take this part. I would do my best to finish that in the next 24 or 48 hours (once CRS is working, it is almost done).
simboss we can work on that after some directions
we can help and test
Martin In the main time, there is all the work related to I/O.
Sure, test are appreciated.
simboss i have been comparing old and new code for 4 days 12 hours a y
day
jgarnett Helping test is the way to go, Martin has been working nite and day on CRS stuff recently.
simboss i can start working on that
jgarnett And often the most help we can do is run tests.
(see agenda item #2)
Martin Yolu can help a lot on I/O.
jgarnett I will vouch for the I/O code being good fun, lots of nice JAI ImageIO work. Useful knowledge if you are going to do your own raster format at a later time.
Martin Including NetCDF, of course.
AlFa I'm at your completely at your service for tests and all you need
Martin Do you mind if we come back on GridCoverage help in just 24 hours? I'm just back in grid coverage work, and need to refresh my mind on what is done and what remains to be done?
simboss sure
AlFa sure
Martin Thanks
simboss just to avoid overlappings
which part do you wnat me to concentrate on tomorrow
(i am sick and tired i am loosing my concentration sorry)
Martin There is 2 areas I can see right now: GridCoverage I/O and operations.
I'm not happy with the current operation's API. If you have suggestion for a better API, it would be very appreciated.
(in the legacy package, this is org.geotools.gp).
simboss cool
with i/o you mean the old gce interface
?
Martin Yes, and also the org.geotools.io.coverage package that need to be ported as well.
Do you use RAW format? If so, there is work to do in org.geotools.io.image package as well.
(RAW format is a plain matrix in binary format, without any header information).
simboss usually we do not use those kind of files
we have instead plenty of metedata
Martin Okay, so lets forget RAW format.
Are the metadata stored in an external ASCII file?
simboss usually not
but we are trying to standardize them
and to use xml file along with the data file
like netcdf+xml
but it is hard to convince scientists to do this
they usually hate computer people
Martin Could you extends org.geotools.io.coverage for handling XML? (looking at the exact class...)
simboss we are thinking about that to handle very generic netcdf files
and maybe ascii/grid
Martin There is already a class for reading ascii/grid. It may need to be examined if it can fit yours need.
simboss i saw it
but it not complete
Martin (still waiting for Netbeans to start....)
simboss it does not get the crs right
Martin Could you complete it?
simboss always gcswgs84
we are already on that
Martin Thanks
simboss it was the easiest thing to achieve
jgarnett Hey guys before you launch into a debug session, did you want to finish the meeting We are all kinda waiting ...
simboss sorry
i have the last thing if you do not mind
cholmes I think that was the last agenda item...
jgarnett Oh sure - I can't even remember what the agenda is (we may already be near the end)
Please continue simboss
Martin There is plugin/epsg. But actually, I will have to leave in a few minutes...
cholmes I'm heading to lunch - I'll stay logged in and catch additional logs later, but I won't be answering...
simboss as i said beorewe are building a complete ER model of coverages therefore an important part of our work will be map that into a postigs/postgresql db and to provide classese for reading wirting coverages
i will detail this later on
jgarnett Sweet I would love to here more about it.
simboss but i think it might be interesting
jgarnett Well martin the last agenda item was 2) epsg
and I think you called it.
Martin Yes. What do you think about a previous mail (code do not depends on a particular EPSG factory, but a user may have preference)
My proposal was to set a priority order.
jgarnett I had not reached a firm opinion yet.
Martin 1) EPSG database connection if available, because I assumes that if the user installed an EPSG database, this is because he wants to use it.
jgarnett Priority order seems wrong to me - that is something the application should allow the user to take control over.
Or application should dictate.
Martin 2) The embedded database otherwise, because it is the one that provides the most informations.
3) WKT file otherwise.
jgarnett But to be clear I think we are only talking about priority order as a last ditch effort when things have already gone wrong.
ie Postgis did not find a SRS entry for its data.
or shapefile did not have a .prj file.
Martin Guys, I can't stay on IRC any longer. I have to leave. Could we continue this discussion later?
jgarnett So I think warning or even failure may be an option.
Martin (I really, really have to leave right now. Sorry all...)
jgarnett Sure. Sorry I can't agree on this one right away.
Well that is it for the agenda as well.
Martin Bye
jgarnett Seems a bit sudden.
jgarnett In the news as it were we have a bug with Oracle SDO encoding of polygon holes that I am fixing this afternoon.
And we have found the latest postgis driver to be non fatal in a small sample (GeoServer and the test cases).
I suppose I should grab the logs.