I've pasted in a discussion from the GeoTools list titled "Supporting non-EPSG "EPSG" codes". It might help you. I'm not an expert in the portion of Geoserver so I will leave it to others to answer your questions more directly.:
Brent Owens
(The Open Planning Project)
------------------------------------------------------------
Martin wrote on 08/16/2006 03:06:02 PM:
> Paul Ramsey a écrit :
> > But, in the long term, what is the correct design way to handle
> > this? we have the "real" EPSG database, which will presumably be
> > updated over time, to include more and more projections as EPSG does
> > their work. And we have some projection numbers like the ESRI and
> > Cubewerx ones, that were pretend standards, but exist in legacy
> > software in lots of places. And we have the global useful ones,
> > which might also exist in legacy places (ESRI has a number for world
> > mercator, for example) which would be hand to have around.
It looks like newer servers will be capable of addressing the issue, as I
just figured out. WMS 1.3.0 can refer to a CRS definition via
URL-to-definition as well as by authority:id. They didn't insist that the
CRS definition be expressed in any particular way, tho. Could be WKT or
GML, or that wierd indented textfile format ISO sometimes uses in examples.
If automatic format detection fails, as long as it's readable by a human,
the human should be capable of associating a CRS with the provided URL.
From then on, uDig has a cached copy of that URL's crs. 
Also, old server standards seem to limit the authorities to EPSG, AUTO, or
CRS. That restriction has been lifted with 1.3.0, so maybe we'll start
seeing an ESRI authority.
So, in the long term, the correct way to handle this is to migrate servers
to newer technology which doesn't require that ESRI or Cubewerks (or me, or
Simone, or Adit for that matter) masquerade as EPSG.
But you want a long-term client-side solution which correctly handles
unbounded error.
my $0.02:
If you have confidence that both you and the server define ESRI-EPSG and
Cubewerks-EPSG CRS in the same way, I suppose that maintaining a client
side copy of the probable definition makes sense. This solution is only as
good as the assumption that you and the server are talking the same
language. In the end, you must provide a way for human judgement to be in
the loop. You should provide tools to remember the verdict of that
judgement if the "sensible defaults" proposed by Martin have been deemed
incorrect (e.g., once human says that authority:id from server
http://dumb.broken.org/wms is actually "WKT or GML for CRS here", uDig
should remember.) This also goes for axes ordering.
Can you automatically have uDig send a canned request for a formal CRS
definition to the stuckee provided in <wms:ContactInformation/> if it
parses as an email address? Heh heh. This might help get the server
migrated. But seriously, there may be no substitute for contacting the
server operators to wrestle projection information out of them. Clients
will need a way to merge in this out-of-band info.
> I already though about this issue and created a JIRA task for that a
> few months ago:
>
> http://jira.codehaus.org/browse/GEOT-774
>
> The proposed fix, already available on trunk, is
> "FallbackAuthorityFactory" (note that I'm not sure
> that this name is really correct). This is a factory which delegates
> all object creation to a main
> factory, and fallback on an other one if the main factory failed. So
> "FallbackAuthorityFactory" can
> delegates object creation to epsg-hsql (for example) and fallback on
> epsg-wkt if the former failed.
I spent my $0.02, here is free advice:
1] Define an ESRI authority factory with all the ESRI CRS definitions in
the ESRI authority namespace.
2] Now define aliases which map ESRI's crs definitions into EPSG authority
namespaces. (still inside ESRI authority factory)
3] Include ability to disable recognition of "aliases".
4] Repeat for Cubewerks, etc.
Therefore, if "alias recognition" is on, the ESRIAuthorityFactory responds
to requests for EPSG:100000. If alias recognition is off, it doesn't
respond to any aliases.
This is obviously a strawman proposal. Apply "design" liberally, as
-------------------------------------------------------------------
required. 
Bryce
Bryce L Nordgren wrote:
While working on a totally unrelated project, the age old problem of
publishing data in a screwy CRS began to tickle my brain. Our weather
model loves to churn out data in a projection which has not been blessed by
EPSG, requiring Alex to add our custom projection into Geoserver with every
upgrade.
Our main problem is that WCS 1.0 requires you to reference a CRS by
authority:id, and you never get an opportunity to transmit the full CRS
definition (ellipsoid params, etc.) End effect: maybe you can describe the
CRS to the server, but the client will never know what projection the data
are in.
Aha, says me, does WMS 1.3.0 improve things? I go look it up.
Aye carumba! We can now refer to a CRS either by "authority:id" _or_ by a
URL to a publicly accessible file which describes a 19111-compatible-CRS.
And there was much rejoicing! I pine for this new ability in the
multidimensional WCS.
So you Geoserver folks:
1] Tell me if you've already handled this and I'm just playing catch up
(like usual).
2] If no one's handled this, does it make sense to have a "custom CRS"
registry managed by Geoserver? CRS in the registry get converted to GML
and hosted in some common spot (http:blah/geoserver/proj/local1.gml).
Bryce
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel