1) PSC
Have not had time to review Chris's email and web pages in detail, will vote of the course of the next 7 days.
2). 1.4.0
We are held up on a GeoTools release, I have had a hard time making sense out of where we are at. I hope with Richard and Justin on the case for Wednesday things will be sorted out. With uDig making use of this same release it is a great chance to work together
3) trunk
To start with GeoServer+WCS will require GeoTools trunk, and this is stuck behind a GeoAPI is a mess.
I will look into this and report back this afternoon. (Andrea explained the situation nicely on IRC).
4) code format
I would like to see us improve on this for GeoServer+WCS is on trunk, hopefully a nice proposal will be written up
5) axis order
Rob correctly points out that GeoServer + WCS will bring the axis order issue into stark relief for our average GeoServer user. Their is some work we can do to ease the pain ... but there will be pain. I am available to answer questions, can help with QA when the time comes. But frankly hooking up uDig to make the requests would do more good in terms of QA
1) PSC
Have not had time to review Chris's email and web pages in detail, will vote of the course of the next 7 days.
2). 1.4.0
We are held up on a GeoTools release, I have had a hard time making sense out of where we are at. I hope with Richard and Justin on the case for Wednesday things will be sorted out. With uDig making use of this same release it is a great chance to work together
Agreed. Sorry I have been missing IRC and letting email slip, but the jmappane and geoapi javadoc issues are solved on 2.2.x? I will chat with Rirchard tommorow about getting a release out.
3) trunk
To start with GeoServer+WCS will require GeoTools trunk, and this is stuck behind a GeoAPI is a mess.
I will look into this and report back this afternoon. (Andrea explained the situation nicely on IRC).
Sorry I missed the IRC. Creating a straight branch of geoserver trunk as it stands right now ( no WCS ), moving it to geotools trunk seems to be pretty seemless. There are a few changes due to the expression / filter api changes, but pretty minimal. So I am all for a move to trunk for the 1.5.x stream. But yes, the geoapi mess is a bit of a hurdle.
4) code format
I would like to see us improve on this for GeoServer+WCS is on trunk, hopefully a nice proposal will be written up
5) axis order
Rob correctly points out that GeoServer + WCS will bring the axis order issue into stark relief for our average GeoServer user. Their is some work we can do to ease the pain ... but there will be pain. I am available to answer questions, can help with QA when the time comes. But frankly hooking up uDig to make the requests would do more good in terms of QA
2). 1.4.0
We are held up on a GeoTools release, I have had a hard time making sense out of where we are at. I hope with Richard and Justin on the case
Agreed. Sorry I have been missing IRC and letting email slip, but the jmappane and geoapi javadoc issues are solved on 2.2.x? I will chat with Rirchard tommorow about getting a release out.
They seem to be resolved to acusters satisfaction - I was a bit unhappy with the code quality, and have
asked for a code review (and am hoping Andrea will take me up on it). I may apply a few tricks I learned
on uDig so that tool API does scale even a little bit.
Here are my quick thoughts:
- make a simple Map as a blackboard and ask the selection tool (that I removed) to store is state there.
- the FilterModel was a good idea, and solves my problem about how to "ground" the Filter classes to a root
GTComponent for event notification (see StyleLayerDescriptor for an example GTRoot implementation). I make
punt that into the main / filter classes.
(but for now selection is just simply removed)
- changing CRS does not seem to do anything (other then break the display) - acuster does not care right now
- turning on the StreamingRenderer fast hints break spatial query (the in memory spatial index must be wrong?)
But yeah, acuster is happy, and I none of the above are show shoppers - ship it
3) trunk
Sorry I missed the IRC. Creating a straight branch of geoserver trunk as it stands right now ( no WCS ), moving it to geotools trunk seems to be pretty seemless. There are a few changes due to the expression / filter api changes, but pretty minimal. So I am all for a move to trunk for the 1.5.x stream. But yes, the geoapi mess is a bit of a hurdle.
So I got the geoapi thing mostly sorted, I think I may need to back out the changes they made
to coverages (make them the nD branch first). You are a bit better at svn then me so perhaps
you could try? I sent some progress out to the geotools list ...
4) code format
I would like to see us improve on this for GeoServer+WCS is on trunk, hopefully a nice proposal will be written up
5) axis order
Rob correctly points out that GeoServer + WCS will bring the axis order issue into stark relief for our average GeoServer user. Their is some work we can do to ease the pain ... but there will be pain. I am available to answer questions, can help with QA when the time comes. But frankly hooking up uDig to make the requests would do more good in terms of QA
2). 1.4.0
We are held up on a GeoTools release, I have had a hard time making sense out of where we are at. I hope with Richard and Justin on the case
Agreed. Sorry I have been missing IRC and letting email slip, but the jmappane and geoapi javadoc issues are solved on 2.2.x? I will chat with Rirchard tommorow about getting a release out.
They seem to be resolved to acusters satisfaction - I was a bit unhappy with the code quality, and have
asked for a code review (and am hoping Andrea will take me up on it). I may apply a few tricks I learned
on uDig so that tool API does scale even a little bit.
Here are my quick thoughts:
- make a simple Map as a blackboard and ask the selection tool (that I removed) to store is state there.
- the FilterModel was a good idea, and solves my problem about how to "ground" the Filter classes to a root
GTComponent for event notification (see StyleLayerDescriptor for an example GTRoot implementation). I make
punt that into the main / filter classes.
(but for now selection is just simply removed)
- changing CRS does not seem to do anything (other then break the display) - acuster does not care right now
- turning on the StreamingRenderer fast hints break spatial query (the in memory spatial index must be wrong?)
But yeah, acuster is happy, and I none of the above are show shoppers - ship it
Yeah, we can definitely continue to improve it, but I think we really just need the basics to demo at first.
Chris
3) trunk
Sorry I missed the IRC. Creating a straight branch of geoserver trunk as it stands right now ( no WCS ), moving it to geotools trunk seems to be pretty seemless. There are a few changes due to the expression / filter api changes, but pretty minimal. So I am all for a move to trunk for the 1.5.x stream. But yes, the geoapi mess is a bit of a hurdle.
So I got the geoapi thing mostly sorted, I think I may need to back out the changes they made
to coverages (make them the nD branch first). You are a bit better at svn then me so perhaps
you could try? I sent some progress out to the geotools list ...
4) code format
I would like to see us improve on this for GeoServer+WCS is on trunk, hopefully a nice proposal will be written up
5) axis order
Rob correctly points out that GeoServer + WCS will bring the axis order issue into stark relief for our average GeoServer user. Their is some work we can do to ease the pain ... but there will be pain. I am available to answer questions, can help with QA when the time comes. But frankly hooking up uDig to make the requests would do more good in terms of QA
