Hi Gabriel,
I just saw a number of commits to 1.7.x related to coverage bug fixes. Seems like some major change to core modules this close to official 1.7.0 release... Anyways, i admit i don't understand the issue, it could be severe enough to include but its not marked as a blocker.
Just wanting more info. Thanks.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Hi Justin,
The commits you refer to are the fix for http://jira.codehaus.org/browse/GEOS-2246. On 1.7.x its fixed, I just need to finish commiting the merge to trunk and the nd branch in order to close it.
Though the changes seem quite wide, they're not harmfull in the sense that most of them are just refactoring the name of internal variables and getters for the coverage config family of classes in order to make more explicit their intent.
The issue should be marked as blocker though, you're right, because the bug makes it impossible to work with a coverage if you change its published CRS in the UI. The problem being that with the move to the new config system the adaptors for catalog persistence do loose the coverage native CRS and instead store only the published crs, both through its WKT and epsg id, while the correct behaviour were to store the native CRS WKT and the published EPSG id, for the cases where there's no standard EPSG code fot the native CRS and hence we need to reproject to a well known CRS in order to publish the coverage.
Hope it makes more sense now.
Cheers,
Gabriel
Justin Deoliveira escribió:
Hi Gabriel,
I just saw a number of commits to 1.7.x related to coverage bug fixes. Seems like some major change to core modules this close to official 1.7.0 release... Anyways, i admit i don't understand the issue, it could be severe enough to include but its not marked as a blocker.
Just wanting more info. Thanks.
-Justin
Hi Gabriel,
Cool, thanks for the clarification. I agree that its worth the change, definitely a blocker.
-Justin
Gabriel Roldan wrote:
Hi Justin,
The commits you refer to are the fix for http://jira.codehaus.org/browse/GEOS-2246. On 1.7.x its fixed, I just need to finish commiting the merge to trunk and the nd branch in order to close it.
Though the changes seem quite wide, they're not harmfull in the sense that most of them are just refactoring the name of internal variables and getters for the coverage config family of classes in order to make more explicit their intent.
The issue should be marked as blocker though, you're right, because the bug makes it impossible to work with a coverage if you change its published CRS in the UI. The problem being that with the move to the new config system the adaptors for catalog persistence do loose the coverage native CRS and instead store only the published crs, both through its WKT and epsg id, while the correct behaviour were to store the native CRS WKT and the published EPSG id, for the cases where there's no standard EPSG code fot the native CRS and hence we need to reproject to a well known CRS in order to publish the coverage.Hope it makes more sense now.
Cheers,
Gabriel
Justin Deoliveira escribió:Hi Gabriel,
I just saw a number of commits to 1.7.x related to coverage bug fixes. Seems like some major change to core modules this close to official 1.7.0 release... Anyways, i admit i don't understand the issue, it could be severe enough to include but its not marked as a blocker.
Just wanting more info. Thanks.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.