From: Martin D. <mar...@ge...> - 2008-01-28 00:10:07
|
After one full day hacking, I realized that the incompatible change proposal ("Make static ReferencingFactoryFinder methods non-static") was a source of confusion. I have meet cases where I was unsure if I should use STRICT or DEFAULT factory finders. I guess that users will not want to bother about this choice. I tried to fix GEOT-1659 in an other, more transparent, way. The API is not modified - static methods remain statics. I though that making them non-static would be good on a conceptual point of view, but given the difficulty to choose the right instance I'm not so sure now. There is one change for FactoryFinder implementors. I created a new class: org.geotools.factory.FactoryFinder which is the base class of ReferencingFactoryFinder, CoverageFactoryFinder, GeometryFactoryFinder, JTSFactoryFinder and CommonFactoryFinder. The GeoTools.addDefaultHints(Hints) method moved to FactoryFinder.mergeSystemHints(Hints) Same semantic, with the addition of a little bit of internal mechanic for handling StrictHints. Commited on trunk as of revision 28974. Waiting for confirmation that it works before to merge with the 2.4 branch. Martin |
From: Andrea A. <aa...@op...> - 2008-01-29 16:50:31
|
Martin Desruisseaux ha scritto: > After one full day hacking, I realized that the incompatible change proposal > ("Make static ReferencingFactoryFinder methods non-static") was a source of > confusion. I have meet cases where I was unsure if I should use STRICT or > DEFAULT factory finders. I guess that users will not want to bother about this > choice. > > I tried to fix GEOT-1659 in an other, more transparent, way. The API is not > modified - static methods remain statics. I though that making them non-static > would be good on a conceptual point of view, but given the difficulty to choose > the right instance I'm not so sure now. > > There is one change for FactoryFinder implementors. I created a new class: > > org.geotools.factory.FactoryFinder > > which is the base class of ReferencingFactoryFinder, CoverageFactoryFinder, > GeometryFactoryFinder, JTSFactoryFinder and CommonFactoryFinder. The > > GeoTools.addDefaultHints(Hints) > > method moved to > > FactoryFinder.mergeSystemHints(Hints) > > Same semantic, with the addition of a little bit of internal mechanic for > handling StrictHints. > > Commited on trunk as of revision 28974. Waiting for confirmation that it works > before to merge with the 2.4 branch. Hi Martin, this morning I run a few tests on Geoserver trunk and it seems everything is working as expected. If no one else has any tests to make I'd say you're good to go for the merge on 2.4.x Cheers Andrea |
From: Martin D. <mar...@ge...> - 2008-01-29 20:33:45
|
Andrea Aime a écrit : > this morning I run a few tests on Geoserver trunk and it seems > everything is working as expected. If no one else has any tests > to make I'd say you're good to go for the merge on 2.4.x Thanks for the feedback. I will try to merge this weekend then. I have yet one philosophical issue and would like to know what people think. When Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER is set to Boolean.TRUE, the current behavior is (reminder: the last boolean argument is for "longitudeFirst"): * CRS.decode(String) or CRS.decode(String, false) Include the "URN" factory in the search. * CRS.decode(String, true) Exclude the "URN" factory in the search on the basis that the user asked for "longitude first". My issue is whatever CRS.decode(..., true) should include the "URN" factory or not. Put in an other way, my question is whatever the "forceLongitude" boolean argument in CRS.decode(...) should be a strong requirement or a preference. Note: When using ReferencingFactoryFinder.getCRSAuthorityFactory(authority, hints), the hints are strong requirements (but in this case the authority is explicitly specified, so the case is not identical to CRS.decode). Opinions? Martin |