The proposal is going to provide us quite some goodness
in the long term (once we have xml parsers/readers for
it and we implement the extensions in the renderer) but
may cause some pain in the short term.
I think we should push for a GeoTools 2.5.0 release
before it lands (what's your opinion about this?).
Yet, there are a couple of things that needs doing
before we can cut 2.5.0-rc1:
- the simple feature speedups (Justin, what's the
status on this?)
- uDig people want to review the classification functions
- Martin wants to review the changes to the referencing
modules
Hum... well, we cannot speak for other people, but
we have to say something from the point of view of
our blockers.
From where I stand, once the simple feature speedups
land we're good to go. What is your opinion?
The proposal is going to provide us quite some goodness
in the long term (once we have xml parsers/readers for
it and we implement the extensions in the renderer) but
may cause some pain in the short term.
I think we should push for a GeoTools 2.5.0 release
before it lands (what's your opinion about this?).
Ah, Eclesia posted a deadline on gt2-devel, he needs
that style work to land on gt2-trunk by July 15.
I have not had much time to work on the simple feature speed up. I got an initial implementation turning over but it still needs work. There is also a lot of code that will have to be updated to use it.
But yes, I agree we should definitely try to branch trunk to 2.5.x before the style work lands on trunk. And i agree that the fm speedup is the only remaining blocker. July is going to be tough for me due to vacation so it might be hard to get that done before July 15. Could we perhaps create the 2.5.x branch before and then do the speedup on it and forward port the changes for it to trunk?
The proposal is going to provide us quite some goodness
in the long term (once we have xml parsers/readers for
it and we implement the extensions in the renderer) but
may cause some pain in the short term.
I think we should push for a GeoTools 2.5.0 release
before it lands (what's your opinion about this?).
Yet, there are a couple of things that needs doing
before we can cut 2.5.0-rc1:
- the simple feature speedups (Justin, what's the
status on this?)
- uDig people want to review the classification functions
- Martin wants to review the changes to the referencing
modules
Hum... well, we cannot speak for other people, but
we have to say something from the point of view of
our blockers.
From where I stand, once the simple feature speedups
land we're good to go. What is your opinion?
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,486209bf264721030819293!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
I have not had much time to work on the simple feature speed up. I got an initial implementation turning over but it still needs work. There is also a lot of code that will have to be updated to use it.
But yes, I agree we should definitely try to branch trunk to 2.5.x before the style work lands on trunk. And i agree that the fm speedup is the only remaining blocker. July is going to be tough for me due to vacation so it might be hard to get that done before July 15. Could we perhaps create the 2.5.x branch before and then do the speedup on it and forward port the changes for it to trunk?
I'm ok with that. As an alternative, I'm open to take what you
cooked up so far and try to take it to a completion so that
we can release following the usual rules.
What about the other PMC members. Anyone interested in expressing
his thoughts? Do we have a GeoServer opinion or Justin and Andrea
ones alone?
I'm ok with that. As an alternative, I'm open to take what you
cooked up so far and try to take it to a completion so that
we can release following the usual rules.
What about the other PMC members. Anyone interested in expressing
his thoughts? Do we have a GeoServer opinion or Justin and Andrea
ones alone?
I am interested to hear if Gabriel's work on Connection Parameters and ArcSDE has died down? That is only change I know of that may still be revised over the next while.
Jody
It is almost the same for me, just want to remember that I’m working right now on the WCS 1.0.0 EMF refactoring that would introduce several changes on geotools side also.
I have not had much time to work on the simple feature speed up. I got
an initial implementation turning over but it still needs work. There is
also a lot of code that will have to be updated to use it.
But yes, I agree we should definitely try to branch trunk to 2.5.x
before the style work lands on trunk. And i agree that the fm speedup is
the only remaining blocker. July is going to be tough for me due to
vacation so it might be hard to get that done before July 15. Could we
perhaps create the 2.5.x branch before and then do the speedup on it and
forward port the changes for it to trunk?
I’m ok with that. As an alternative, I’m open to take what you
cooked up so far and try to take it to a completion so that
we can release following the usual rules.
What about the other PMC members. Anyone interested in expressing
his thoughts? Do we have a GeoServer opinion or Justin and Andrea
ones alone?
It is almost the same for me, just want to remember that I'm working right now on the WCS 1.0.0 EMF refactoring that would introduce several changes on geotools side also.
Several changes as in? A new module under the xsd parser? Or
you're talking about changes in the core modules?
Cheers
Andrea
It is almost the same for me, just want to remember that I’m working right now on the WCS 1.0.0 EMF refactoring that would introduce several changes on geotools side also.
Several changes as in? A new module under the xsd parser? Or
you’re talking about changes in the core modules?
Cheers
Andrea
On GeoTools side yes, my intention would be to create a new module under the xsd parser and on GeoServer side to merge WCS 1.0.0 and 1.1.1 models.
Ouch, merge them? Last time I checked the xml schemas of the two specs
where so different that a single module trying to address them seemed
very hard to achieve. Do you have a plan on how to deal with that?
Don't get me wrong, having a single wcs module able to handle
both wcs 1.0 and wcs 1.1 would be very good, I'm just wondering
how this can be achieved in practice.
> Ouch, merge them? Last time I checked the xml schemas of the two specs
where so different that a single module trying to address them seemed
very hard to achieve. Do you have a plan on how to deal with that?
Don't get me wrong, having a single wcs module able to handle
both wcs 1.0 and wcs 1.1 would be very good, I'm just wondering
how this can be achieved in practice.
Does merge here mean merge together... or merge into GeoServer?
If the former I think I agree with Andrea here after looking at the schemas. They are pretty radically different. When we did wfs 1.1 we used the same model for both wfs 1.1 and 1.0 and there were issues... i think doing the same with wcs might be pretty hard.
-Justin
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,48635f72299595219720167!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
My idea is not to use the same model, the WCS 1.0.0 and WCS 1.1.x schemas are too different … my idea is to make the two different models live into different packages but merge the dispatcher/transformer as much as possible in GeoServer.
Btw I have to do now an important question … is it acceptable a so radical refactoring of the WCS module in GS 1.7.x or it should/must be done in GS trunk?
Ouch, merge them? Last time I checked the xml schemas of the two specs
where so different that a single module trying to address them seemed
very hard to achieve. Do you have a plan on how to deal with that?
Don’t get me wrong, having a single wcs module able to handle
both wcs 1.0 and wcs 1.1 would be very good, I’m just wondering
how this can be achieved in practice.
Does merge here mean merge together… or merge into GeoServer?
If the former I think I agree with Andrea here after looking at the schemas. They are pretty radically different. When we did wfs 1.1 we used the same model for both wfs 1.1 and 1.0 and there were issues… i think doing the same with wcs might be pretty hard.
My idea is not to use the same model, the WCS 1.0.0 and WCS 1.1.x schemas are too different ... my idea is to make the two different models live into different packages but merge the dispatcher/transformer as much as possible in GeoServer.
Btw I have to do now an important question ... is it acceptable a so radical refactoring of the WCS module in GS 1.7.x or it should/must be done in GS trunk?
I would be much more confident if you could do it on trunk or in
a branch (so that you can commit stuff as you go),
test it so that it passes the WCS 1.0 and 1.1 tests (maybe with
some ND data, that WCS cite is able to check), and then merge back
to 1.7.x once it's solid.
My idea is not to use the same model, the WCS 1.0.0 and WCS 1.1.x schemas are too different … my idea is to make the two different models live into different packages but merge the dispatcher/transformer as much as possible in GeoServer.
Btw I have to do now an important question … is it acceptable a so radical refactoring of the WCS module in GS 1.7.x or it should/must be done in GS trunk?
I would be much more confident if you could do it on trunk or in
a branch (so that you can commit stuff as you go),
test it so that it passes the WCS 1.0 and 1.1 tests (maybe with
some ND data, that WCS cite is able to check), and then merge back
to 1.7.x once it’s solid.