[Geoserver-devel] Alex code in, we know can define custom CRS using an external file :-)

Andrea_Aime3 · February 14, 2007, 2:39pm

Hi,
I've committed Alexander patches (small patch, very high value per line of code :-)) to geoserver, in the org.vfny.geoserver.crs package.

The release configuration has the custom crs file with all the extra
CRS Martin already added to trunk (ones that are missing from EPSG, but
widely used), so there's plenty of samples.

I also added documentation and reorganized the ones contributed by Alex
in the official user guide, since adding a CRS is no more voodoo and
it's something users need relatively often (especially those playing
against Oracle, that has lots of "personal" definitions).
Since I'm not a native english speaker, can someone have a look at them?
http://docs.codehaus.org/display/GEOSDOC/Handling+custom+projections

Cheers
Andrea

Andrea_Aime3 · February 15, 2007, 2:39pm

Andrea Aime ha scritto:

Hi,
I've committed Alexander patches (small patch, very high value per line of code :-)) to geoserver, in the org.vfny.geoserver.crs package.

The release configuration has the custom crs file with all the extra
CRS Martin already added to trunk (ones that are missing from EPSG, but
widely used), so there's plenty of samples.

Oh well, today I noticed Alex solution (to custom projection definitions) had issues in that, extending the WKT authority, made
that one register as well, and it registered before the hsql
one, as a result the more correct EPSG definitions were replaced
by the ones contained in the epsg-wkt factory (no more TOWGS84
parameters in most projections, holy cow!).

So, I took a peek at Martin's code on trunk, and backported it
into Geoserver (directly), merging it with the external file
loading logic Alexander prepared. This removed the dependency
to espg-wkt, still allowing us to have custom CRS in a directly
modifiable file.

Martin, I hope you don't mind I did copy your code in Geoserver,
we badly needed it, and backporting the whole module to 2.3.x
may have triggered more complaints I guess. I'm open to other
solutions, thought.

In Geoserver 1.6.x I'll simply subclass the FactoryUsingWKT
instead, since we do reference geotools trunk.
Btw, I'm wondering, is there any way to prevent the registration
of FactoryUsingWKT and FactoryESRI? The latter is problematic,
since in Geoserver we handle only EPSG authority, the former
would really be around simply to allow subclassing.

Cheers
Andrea

Alexander_Petkov · February 15, 2007, 3:33pm

On 2/15/07, Andrea Aime <aaime@anonymised.com> wrote:

Andrea Aime ha scritto:
> Hi,
> I've committed Alexander patches (small patch, very high value per line
> of code :-)) to geoserver, in the org.vfny.geoserver.crs package.
>
> The release configuration has the custom crs file with all the extra
> CRS Martin already added to trunk (ones that are missing from EPSG, but
> widely used), so there's plenty of samples.

Oh well, today I noticed Alex solution (to custom projection
definitions) had issues in that, extending the WKT authority, made
that one register as well, and it registered before the hsql
one, as a result the more correct EPSG definitions were replaced
by the ones contained in the epsg-wkt factory (no more TOWGS84
parameters in most projections, holy cow!).

Ack--I forgot about that. I had replaced the epsg.properties file with
a sample one.

So, I took a peek at Martin's code on trunk, and backported it
into Geoserver (directly), merging it with the external file
loading logic Alexander prepared. This removed the dependency
to espg-wkt, still allowing us to have custom CRS in a directly
modifiable file.

Sweet!!

Alex

Martin_Desruisseaux · February 16, 2007, 3:46am

Le jeudi 15 février 2007 à 15:39 +0100, Andrea Aime a écrit :

Martin, I hope you don't mind I did copy your code in Geoserver,

Of course you are welcome :). This is opensource code, not really mine
anymore.

Btw, I'm wondering, is there any way to prevent the registration
of FactoryUsingWKT and FactoryESRI? The latter is problematic,
since in Geoserver we handle only EPSG authority, the former
would really be around simply to allow subclassing.

If we want to register the ESRI factory only on demand, the easiest way
would probably be to move it into a separated module.

I though that the content of the ESRI factory was already provided in
the former epsg-wkt (so I though that I wasn't adding anything new), but
its look like I'm wrong. I don't know if those codes are supposed to be
available in the "EPSG" name space or not. Currently, they are
reacheable in both "EPSG" and "ESRI" namespace. Maybe they should be
reacheable in the "ESRI" namespace only? What do you think?

Martin

Andrea_Aime3 · February 16, 2007, 8:28am

Martin Desruisseaux ha scritto:

If we want to register the ESRI factory only on demand, the easiest way
would probably be to move it into a separated module.

I though that the content of the ESRI factory was already provided in
the former epsg-wkt (so I though that I wasn't adding anything new), but
its look like I'm wrong. I don't know if those codes are supposed to be
available in the "EPSG" name space or not. Currently, they are
reacheable in both "EPSG" and "ESRI" namespace. Maybe they should be
reacheable in the "ESRI" namespace only? What do you think?

Oh hum, I don't really know what to say. If the codes are in the EPSG
namespace there should be no trouble with Geoserver. I'm asking because
currently some parts of the code in geoserver treat the SRS code as
an integer, assuming an EPSG namespace, and I don't know how it'll
handle different authorities (either ignore, or break, still haven't tried).

Paul, I think you're the one that collected those ESRI codes. What
namespace should they fit in?

Cheers
Andrea

pramsey · February 16, 2007, 3:36pm

That's a more-or-less impossible question to answer, Andrea. Theoretically, they should be in something like 'ESRI:XXXX'. Practically, people will be making calls to your server using ESRI integers wrapped in EPSG namespace.

P

On 16-Feb-07, at 12:28 AM, aaime wrote:

Martin Desruisseaux ha scritto:

If we want to register the ESRI factory only on demand, the easiest way
would probably be to move it into a separated module.
I though that the content of the ESRI factory was already provided in
the former epsg-wkt (so I though that I wasn't adding anything new), but
its look like I'm wrong. I don't know if those codes are supposed to be
available in the "EPSG" name space or not. Currently, they are
reacheable in both "EPSG" and "ESRI" namespace. Maybe they should be
reacheable in the "ESRI" namespace only? What do you think?

Oh hum, I don't really know what to say. If the codes are in the EPSG
namespace there should be no trouble with Geoserver. I'm asking because
currently some parts of the code in geoserver treat the SRS code as
an integer, assuming an EPSG namespace, and I don't know how it'll
handle different authorities (either ignore, or break, still haven't tried).

Paul, I think you're the one that collected those ESRI codes. What
namespace should they fit in?

Cheers
Andrea

Martin_Desruisseaux · February 20, 2007, 8:38pm

Le vendredi 16 février 2007 à 07:36 -0800, Paul Ramsey a écrit :

That's a more-or-less impossible question to answer, Andrea.
Theoretically, they should be in something like 'ESRI:XXXX'.
Practically, people will be making calls to your server using ESRI
integers wrapped in EPSG namespace.

In the current "epsg-extension" proposal, the ESRI's CRS are available
in both "ESRI:XXXX" and "EPSG:XXXX" namespace. There is no mechanism at
this time for selectively disabling one namespace; currently we have
both of them or none of them. Maybe experience will tell us if we need
such mechanism in the future.

Martin

pramsey · February 20, 2007, 10:35pm

Martin Desruisseaux wrote:

Le vendredi 16 février 2007 à 07:36 -0800, Paul Ramsey a écrit :

That's a more-or-less impossible question to answer, Andrea. Theoretically, they should be in something like 'ESRI:XXXX'. Practically, people will be making calls to your server using ESRI integers wrapped in EPSG namespace.

In the current "epsg-extension" proposal, the ESRI's CRS are available
in both "ESRI:XXXX" and "EPSG:XXXX" namespace. There is no mechanism at
this time for selectively disabling one namespace; currently we have
both of them or none of them. Maybe experience will tell us if we need
such mechanism in the future.

There's nothing wrong with having both, the ESRI numbers have been kept distinct from the EPSG numbers so far, so there are no numeric collisions. Hopefully that continues

P

--

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   pramsey@anonymised.com
   Phone: 250-383-3022
   Cell: 250-885-0632