override an existing EPSG definition in the property file

cc'ing Martin, the gt2 referencing expert.
Martin, do you have an opinion on this one (i.e., allowing an extension authority factory to override the official epsg one). Also, do you know if a later EPSG release has the problem fixed?

The correct definition of the 28992 code is, according to Bart, the following:

28992=PROJCS["Amersfoort / RD New", GEOGCS["Amersfoort", DATUM["Amersfoort",
SPHEROID["Bessel 1841", 6377397.155, 299.1528128, AUTHORITY["EPSG","7004"]],
TOWGS84[565.237, 50.0087, 465.658, -0.406857, 0.350733, -1.87035, 4.0812],
AUTHORITY["EPSG","6289"]], PRIMEM["Greenwich", 0.0,
AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295],
AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH],
AUTHORITY["EPSG","4289"]], PROJECTION["Oblique Stereographic",
AUTHORITY["EPSG","9809"]], PARAMETER["central_meridian", 5.387638888888891],
PARAMETER["latitude_of_origin", 52.15616055555556],
PARAMETER["scale_factor", 0.9999079], PARAMETER["false_easting", 155000.0],
PARAMETER["false_northing", 463000.0], UNIT["m", 1.0], AXIS["Easting",
EAST], AXIS["Northing", NORTH], AUTHORITY["EPSG","28992"]]

whilst the definition we get from the EPSG database is:

PROJCS["Amersfoort / RD New", 
  GEOGCS["Amersfoort", 
    DATUM["Amersfoort", 
      SPHEROID["Bessel 1841", 6377397.155, 299.1528128, AUTHORITY["EPSG","7004"]], 
      TOWGS84[565.04, 49.91, 465.84, -0.40939438743923684, -0.35970519561431136, 1.868491000350572, 0.8409828680306614], 
      AUTHORITY["EPSG","6289"]], 
    PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], 
    UNIT["degree", 0.017453292519943295], 
    AXIS["Geodetic longitude", EAST], 
    AXIS["Geodetic latitude", NORTH], 
    AUTHORITY["EPSG","4289"]], 
  PROJECTION["Oblique Stereographic", AUTHORITY["EPSG","9809"]], 
  PARAMETER["central_meridian", 5.387638888888891], 
  PARAMETER["latitude_of_origin", 52.15616055555556], 
  PARAMETER["scale_factor", 0.9999079], 
  PARAMETER["false_easting", 155000.0], 
  PARAMETER["false_northing", 463000.0], 
  UNIT["m", 1.0], 
  AXIS["Easting", EAST], 
  AXIS["Northing", NORTH], 
  AUTHORITY["EPSG","28992"]]

I'm also wondering if the "correct" one is among the alternate TOWGS84 parameters included in the EPSG database.
Also, I'm curious. Would it make sense to publish somehow the alternate versions of a SRS code under a slightly
modified code, for example, 3003.a 3003.b and 3003.c (using 3003 since I know there are three acceptable variants
for that Italian code). Or maybe provide some hints to the authority factories so that they can choose which variant
to publish?

Ops, pasted the same code twice by mistake, now I've corrected the first one getting Bart's definition from the mail.

Overriding the EPSG database could easily be done by assigning to PropertyAuthorityFactory a priority number higher than the EPSG factory one. Right now it has a rather low priority number (see line 154 on trunk revision 29113). We could increase this priority number, however my original intend was to keep PropertyAuthorityFactory at a lower priority level and create a separated factory for the EPSG code to override. The rational was that if a user defines a CRS because it was not there in some old EPSG database but this CRS is added in some new version of EPSG database, we probably want to get the EPSG definition automatically when it appears (on the assumption that many users will not check for EPSG updates and remove their custom CRS when it become duplicated). So I wanted to create a factory dedicaced especially to EPSG overriding, but never took the time of doing it and I'm really not sure that it is worth the extra-complexity...

However if we want to look at what is probably the deeper root of this issue, this is probably related to GEOT-1179. There is some chance that (as suggested in Andrea's comment above), the EPSG database is not wrong but the GeoTools EPSG factory pickup to wrong Bursa-Wolf parameters in some situation where there is many. GeoTools EPSG factory uses a few criterions for selecting a set of Bursa-Wolf parameters, but those criterions don't include the CRS area of validity, while it is probably an important criterion.

So instead of increasing the PropertyAuthorityFactory (with the risk described above regarding EPSG updates), the "ideal" approach may be to fix GEOT-1179 first and see if it resolve the case reported here.

Hum, using the area of definition would help, at least from a theoretical point of view, but it's likely to fail in the gt2 codebase, because usually we decode epsg codes in places where the area of definition of the dataset is still not known (in some cases it may as well be very expensive to compute too, think a gigabyte sized postgis db, I have tables whose bbox computation takes 2minutes using the indexes to compute it).
Anyways, the idea of a separate authority for overriding could be appealing. I could roll another property file based authority with a different priority (can it be specified by a subclass?) and have it read a different property file, epsg-override.properties, leaving the current epsg.properties file as an extension.

I was thinking about the CRS domain of validity (which is part of CRS metadata) rather than the data area. If the CRS was created from the EPSG database, this information is usually available. When a transform is created from CRS A to CRS B, we could check the intersection of their domain of validity and select the CoordinateOperation which matches this domain best (CoordinateOperation has "domain of validity" metadata too). But this is not a trivial work.

In the main time, if we want to create a new PropertyAuthorityFactory with higher priority, we just need to override the getPriority method. However it would be a temporary patch because I would like to get ride of this priority number in a future version and rely on the mechanism bundled in J2SE, which is based on pair-wise ordering rather than absolute number. In practice, those absolute number are hard too choose (we need to have every factories in mind). Pair-wise ordering would be safer but will be a compatibility break for plugins that used priority numbers.

I've tried to implement this one and found it to be impossible due to a bug in GeoTools referencing subsystem.
In particular, when longitude first hint is provided, the longitude first factory is used, that is set to maximum priority. This in particular means nothing can override it, trying to set a custom factory to MAX_PRIORITY + 1 generates an error since there is a check that ensures the priority value is between MIN_PRIORITY and MAX_PRIORITY.
Actually most factories are set to such a high priority value that overriding any is almost impossible. MAX_PRIORTY is 100, and:

• LongitudeFirstPriority is set to 100 square when the longitude first hint is set
• Access based one is set to 99
• Hsql based on is set to 95
• Generic threaded one is set to 90

So it seems that setting LongitudeFirst to anything above 95 would do the trick, but still it's funny how the priority layout makes most of the range between 0 and 100 unusable... with these numbers a range between 0 and 10 would have been the same...

Yeah, confirmed that changing LongitudeFirstFactory.relativePriority() to use +7,-7 instead of +10,-10 allows an override.
I see that the method is marked as non necessary, unfortunately GeoServer cannot use the system hints due to http://jira.codehaus.org/browse/GEOT-1704, we're stuck using system properties instead.

I linked this issue as dependant of GEOT-1100 based on Andrea's analysis. The usage of a priority number of factories was a bad idea. The mechanism bundled in the standard JDK (pairwise ordering) would probably solve this issue and other ones too.

This is getting fixed in geotidy, together with many other projects (see GEOT-2117 for a list). It will be ported to Java 5 and linked to the remaining of Geotools, if the community accepts it, after the EPSG factory will have been ported.

Martin, as a stop gap measure do you mind if I change the relativePriority to 7? There is no due date for geotidy to be ready to be used and moreover I need the fix on 2.5.x

Sure, please do

Committed on 1.7.x and trunk, will be available tomorrow in the last nightly build.
If you want to try out, just add a epsg_overrides.properties file into your data dir/user_projections and its contents will override the EPSG factory (the usual epsg.properties remains for the normal case in which you want to add a coordinate reference system that is not supposed to replace an official one).

Fixed on 1.7.x and trunk