[Geoserver-devel] Adding projections to Geoserver 1.5.x is really hard

GeoServer GeoServer Developer
1

Hi all,
in 1.4.x series we used the wkt epsg jar, that allowed the user to
add a projection by editing the inner property file.

In 1.5.x, we are using epsg hsql, so the same operation is possible,
but only after editing the sql creation file included in the jar and
then removing the cached hsql database held in a temp directory.
That's a lot harder.

On geotools trunk Martin is working on a module to allow "chained"
providers, that is, have the ability to invoke multiple ones
when looking for a projection code. I haven't seen backport plans
thought....

Thinking about it, this is a serious issue for us.
Any suggestions? Martin, how much work is needed to finish that
module (can I help you?). Plus, how hard is it to back port it
to 2.3.x?

Afaik the reason for upgrading to epsg-hsql was that the wkt
file missed informations. But it's not impossible to simply
dump all the wkt infos from the hsql db and create a new
property file instead. Would we miss significant information
in that case? The only thing that comes to my mind
is the definition area.

Cheers
Andrea

2

Ciao Andrea,
most part of the information needed to built custom CRS for Geotiff
files cannot be found in the epsg-wkt that is why we move towards
epsg-hsql a the default epsg data source.

Ciao,
Simone.
On 1/24/07, Andrea Aime <aaime@anonymised.com> wrote:

Hi all,
in 1.4.x series we used the wkt epsg jar, that allowed the user to
add a projection by editing the inner property file.

In 1.5.x, we are using epsg hsql, so the same operation is possible,
but only after editing the sql creation file included in the jar and
then removing the cached hsql database held in a temp directory.
That's a lot harder.

On geotools trunk Martin is working on a module to allow "chained"
providers, that is, have the ability to invoke multiple ones
when looking for a projection code. I haven't seen backport plans
thought....

Thinking about it, this is a serious issue for us.
Any suggestions? Martin, how much work is needed to finish that
module (can I help you?). Plus, how hard is it to back port it
to 2.3.x?

Afaik the reason for upgrading to epsg-hsql was that the wkt
file missed informations. But it's not impossible to simply
dump all the wkt infos from the hsql db and create a new
property file instead. Would we miss significant information
in that case? The only thing that comes to my mind
is the definition area.

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions

http://www.geo-solutions.it

-------------------------------------------------------

3

Le mercredi 24 janvier 2007 à 16:50 +0100, Andrea Aime a écrit :

On geotools trunk Martin is working on a module to allow "chained"
providers, that is, have the ability to invoke multiple ones
when looking for a projection code. I haven't seen backport plans
thought....

I didn't finished the epsg-ext module yet. I don't remember right now
how much work is still needed for this module. I need to take a new look
to it.

Afaik the reason for upgrading to epsg-hsql was that the wkt
file missed informations. But it's not impossible to simply
dump all the wkt infos from the hsql db and create a new
property file instead. Would we miss significant information
in that case? The only thing that comes to my mind
is the definition area.

We would miss:

- Area of validity.

- Estimation of transformation accuracy.

- Bursa-wolf parameters to anything else than WGS84 datum
  (WKT is restricted to WGS84, while Bursa-wolf parameters
  can theorically be defined between an arbitrary pair of datum).

- Scope.

- Remarks.

- Aliases.

- Every objects other than CoordinateReferenceSystem (the EPSG
  database can also be used for creating CoordinateSystem, Datum,
  etc. And actually I noticed that the GeoTIFF plugins do uses
  epsg-hsql exactly for that purpose: creating datum, not CRS).

- Explicitly defined coordinate transformations (Geotools try to
  figure transformation path by itself. But the EPSG database do
  defines explicitly the transformation path for some pairs of
  source and target CRS. Those sometime specialized paths should
  be used when available (and epsg-hsql uses them). The current
  epsg-wkt plugin can't encode them).

There is really far much more features in the epsg-hsql plugin than
epsg-wkt.

In addition I didn't compared the performances, but my guess is that the
lack of index in epsg.properties file may hurt.

I will be away for the next 48 hours (need to do so administrative tasks
for getting a visa for comming back to France). I will continue the
referencing work when I will be back Friday.

  Martin

4

Martin, if we can help out let us know. It sounds like the epsg-ext is really the best option for GeoServer, so we can put some resources in to finishing it up and backporting it to 2.3.x. We can't force our users to jump through all the hoops to define an extra CRS.

Though I suppose the other option is an easy UI interface that lets one add a new WKT, that we put in to the hsql database. Alex, what's the status with that work?

Chris

Martin Desruisseaux wrote:

Le mercredi 24 janvier 2007 à 16:50 +0100, Andrea Aime a écrit :

On geotools trunk Martin is working on a module to allow "chained"
providers, that is, have the ability to invoke multiple ones
when looking for a projection code. I haven't seen backport plans
thought....

I didn't finished the epsg-ext module yet. I don't remember right now
how much work is still needed for this module. I need to take a new look
to it.

Afaik the reason for upgrading to epsg-hsql was that the wkt
file missed informations. But it's not impossible to simply
dump all the wkt infos from the hsql db and create a new
property file instead. Would we miss significant information
in that case? The only thing that comes to my mind
is the definition area.

We would miss:

- Area of validity.

- Estimation of transformation accuracy.

- Bursa-wolf parameters to anything else than WGS84 datum
  (WKT is restricted to WGS84, while Bursa-wolf parameters
  can theorically be defined between an arbitrary pair of datum).

- Scope.

- Remarks.

- Aliases.

- Every objects other than CoordinateReferenceSystem (the EPSG
  database can also be used for creating CoordinateSystem, Datum,
  etc. And actually I noticed that the GeoTIFF plugins do uses
  epsg-hsql exactly for that purpose: creating datum, not CRS).

- Explicitly defined coordinate transformations (Geotools try to
  figure transformation path by itself. But the EPSG database do
  defines explicitly the transformation path for some pairs of
  source and target CRS. Those sometime specialized paths should
  be used when available (and epsg-hsql uses them). The current
  epsg-wkt plugin can't encode them).

There is really far much more features in the epsg-hsql plugin than
epsg-wkt.

In addition I didn't compared the performances, but my guess is that the
lack of index in epsg.properties file may hurt.

I will be away for the next 48 hours (need to do so administrative tasks
for getting a visa for comming back to France). I will continue the
referencing work when I will be back Friday.

  Martin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,45b79539169362223018498!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

5

Le mercredi 24 janvier 2007 à 12:29 -0500, Chris Holmes a écrit :

Martin, if we can help out let us know. It sounds like the epsg-ext is
really the best option for GeoServer, so we can put some resources in to
finishing it up and backporting it to 2.3.x. We can't force our users
to jump through all the hoops to define an extra CRS.

Thanks for your offer :slight_smile:

I need to go in a few hours and will be back only in 2 days. I will look
at the state of epsg-ext when I will be back (I don't remember right now
what is the remaining work).

  Martin

6

Hello:

A little background--I have had to define custom projections in the
wkt jar, as well as in the HSQL database. Also, I have written some
Wiki documentation, which aims to explain the procedure(s) for adding
user definitions in both cases:

http://docs.codehaus.org/display/GEOSDOC/Custom+projection+definition+in+Geoserver

Currently, I have a simple community plugin (not commited), which
piggy-backs on the epsg-wkt jar and lets users insert WKT in some
arbitrary file. This plugin uses the preferences plugin written by
Jesse Eichar. The user definitions are loaded on startup. It is
missing a user interface, because struts looks so messy, and because
there was talk about moving to something else. Does anyone see use for
this?

I can probably put together an addition the Geoserver's web interface
that lets users insert their own definitions. The immediate problems I
see regarding this approach currently are:

1) The HSQL db doesn't come with write permissions enabled by default.
(i had to either unpack the jar and change it, or allow writing to the
database in the extracted DB location). But I have figured out the
necessary table inserts for new SRS definitions.

2) The web Interface framework--it is supposed to change to something
else, right? I have no problem with studying some other framework so I
can accomplish this.

Alex

On 1/24/07, Chris Holmes <cholmes@anonymised.com> wrote:

Martin, if we can help out let us know. It sounds like the epsg-ext is
really the best option for GeoServer, so we can put some resources in to
finishing it up and backporting it to 2.3.x. We can't force our users
to jump through all the hoops to define an extra CRS.

Though I suppose the other option is an easy UI interface that lets one
add a new WKT, that we put in to the hsql database. Alex, what's the
status with that work?

Chris

7

Alexander Petkov ha scritto:

Hello:

A little background--I have had to define custom projections in the
wkt jar, as well as in the HSQL database. Also, I have written some
Wiki documentation, which aims to explain the procedure(s) for adding
user definitions in both cases:

http://docs.codehaus.org/display/GEOSDOC/Custom+projection+definition+in+Geoserver

Cool, did not know about that. We should definitely link that from
the user guide. Seems to fit well in the "Configuring geoserver"
section, thought due to the long process needed to add a definition
in hsql maybe we should add a "not for the faint of heart" section :-p

Currently, I have a simple community plugin (not commited), which
piggy-backs on the epsg-wkt jar and lets users insert WKT in some
arbitrary file. This plugin uses the preferences plugin written by
Jesse Eichar. The user definitions are loaded on startup. It is
missing a user interface, because struts looks so messy, and because
there was talk about moving to something else. Does anyone see use for
this?

Sorry, these definitions are loaded on startup... where? Added to the
hsql db?

I can probably put together an addition the Geoserver's web interface
that lets users insert their own definitions. The immediate problems I
see regarding this approach currently are:

1) The HSQL db doesn't come with write permissions enabled by default.
(i had to either unpack the jar and change it, or allow writing to the
database in the extracted DB location). But I have figured out the
necessary table inserts for new SRS definitions.

Cool. Would that work for overwriting a table too?

2) The web Interface framework--it is supposed to change to something
else, right? I have no problem with studying some other framework so I
can accomplish this.

Yeah, we're probably going to switch to wicket, but the timeframe is
still uncertain. I'd like to do so as soon as trunk it's ready
and we do have a 1.5.0 stable release out, but that's just my opinion,
not a PSC decision.

Cheers
Andrea

8

Hi Andrea:

On 1/24/07, Andrea Aime <aaime@anonymised.com> wrote:

> Currently, I have a simple community plugin (not commited), which
> piggy-backs on the epsg-wkt jar and lets users insert WKT in some
> arbitrary file. This plugin uses the preferences plugin written by
> Jesse Eichar. The user definitions are loaded on startup. It is
> missing a user interface, because struts looks so messy, and because
> there was talk about moving to something else. Does anyone see use for
> this?

Sorry, these definitions are loaded on startup... where? Added to the
hsql db?

The community plugin I mentioned simply reads a user's text file with
WKT in it. Just like the definitions in the epsg-wkt jar, the users
definitions are loaded upon Geoserver (re)start (i.e. you can see them
in the srsHelp.do list).

> I can probably put together an addition the Geoserver's web interface
> that lets users insert their own definitions. The immediate problems I
> see regarding this approach currently are:
>
> 1) The HSQL db doesn't come with write permissions enabled by default.
> (i had to either unpack the jar and change it, or allow writing to the
> database in the extracted DB location). But I have figured out the
> necessary table inserts for new SRS definitions.

Cool. Would that work for overwriting a table too?

If you mean using UPDATE statements and the like, yes.

> 2) The web Interface framework--it is supposed to change to something
> else, right? I have no problem with studying some other framework so I
> can accomplish this.

Yeah, we're probably going to switch to wicket, but the timeframe is
still uncertain. I'd like to do so as soon as trunk it's ready
and we do have a 1.5.0 stable release out, but that's just my opinion,
not a PSC decision.

Any advise as to what one can do while decision is being made is much
welcome. Do I just write a JSP page that does this? Wait for wicket to
be used?

Thanks,
Alex

9

Alexander Petkov ha scritto:

Hi Andrea:

On 1/24/07, Andrea Aime <aaime@anonymised.com> wrote:

Currently, I have a simple community plugin (not commited), which
piggy-backs on the epsg-wkt jar and lets users insert WKT in some
arbitrary file. This plugin uses the preferences plugin written by
Jesse Eichar. The user definitions are loaded on startup. It is
missing a user interface, because struts looks so messy, and because
there was talk about moving to something else. Does anyone see use for
this?

Sorry, these definitions are loaded on startup... where? Added to the
hsql db?

The community plugin I mentioned simply reads a user's text file with
WKT in it. Just like the definitions in the epsg-wkt jar, the users
definitions are loaded upon Geoserver (re)start (i.e. you can see them
in the srsHelp.do list).

Alexander, is this community plugin committed anywhere? I don't see it
in the geoserver community section?
Cheers
Andrea

10

No. AFAIK, I don't have commit priviledges.

Alex

On 1/25/07, Andrea Aime <aaime@anonymised.com> wrote:

Alexander Petkov ha scritto:
> Hi Andrea:
>
> On 1/24/07, Andrea Aime <aaime@anonymised.com> wrote:
>>> Currently, I have a simple community plugin (not commited), which
>>> piggy-backs on the epsg-wkt jar and lets users insert WKT in some
>>> arbitrary file. This plugin uses the preferences plugin written by
>>> Jesse Eichar. The user definitions are loaded on startup. It is
>>> missing a user interface, because struts looks so messy, and because
>>> there was talk about moving to something else. Does anyone see use for
>>> this?
>> Sorry, these definitions are loaded on startup... where? Added to the
>> hsql db?
>
> The community plugin I mentioned simply reads a user's text file with
> WKT in it. Just like the definitions in the epsg-wkt jar, the users
> definitions are loaded upon Geoserver (re)start (i.e. you can see them
> in the srsHelp.do list).

Alexander, is this community plugin committed anywhere? I don't see it
in the geoserver community section?
Cheers
Andrea

11

Hi Alex,

If you would submit your code to a jira task, we could do a code review which would be the first step in getting you commit access.

-Justin

Alexander Petkov wrote:

No. AFAIK, I don't have commit priviledges.

Alex

On 1/25/07, Andrea Aime <aaime@anonymised.com> wrote:

Alexander Petkov ha scritto:

Hi Andrea:

On 1/24/07, Andrea Aime <aaime@anonymised.com> wrote:

Currently, I have a simple community plugin (not commited), which
piggy-backs on the epsg-wkt jar and lets users insert WKT in some
arbitrary file. This plugin uses the preferences plugin written by
Jesse Eichar. The user definitions are loaded on startup. It is
missing a user interface, because struts looks so messy, and because
there was talk about moving to something else. Does anyone see use for
this?

Sorry, these definitions are loaded on startup... where? Added to the
hsql db?

The community plugin I mentioned simply reads a user's text file with
WKT in it. Just like the definitions in the epsg-wkt jar, the users
definitions are loaded upon Geoserver (re)start (i.e. you can see them
in the srsHelp.do list).

Alexander, is this community plugin committed anywhere? I don't see it
in the geoserver community section?
Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,45b8d01230021527717022!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

12

I will do that, thanks.
Alex

On 1/25/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Alex,

If you would submit your code to a jira task, we could do a code review
which would be the first step in getting you commit access.

-Justin

Alexander Petkov wrote:
> No. AFAIK, I don't have commit priviledges.
>
> Alex
>
> On 1/25/07, Andrea Aime <aaime@anonymised.com> wrote:
>> Alexander Petkov ha scritto:
>>> Hi Andrea:
>>>
>>> On 1/24/07, Andrea Aime <aaime@anonymised.com> wrote:
>>>>> Currently, I have a simple community plugin (not commited), which
>>>>> piggy-backs on the epsg-wkt jar and lets users insert WKT in some
>>>>> arbitrary file. This plugin uses the preferences plugin written by
>>>>> Jesse Eichar. The user definitions are loaded on startup. It is
>>>>> missing a user interface, because struts looks so messy, and because
>>>>> there was talk about moving to something else. Does anyone see use for
>>>>> this?
>>>> Sorry, these definitions are loaded on startup... where? Added to the
>>>> hsql db?
>>> The community plugin I mentioned simply reads a user's text file with
>>> WKT in it. Just like the definitions in the epsg-wkt jar, the users
>>> definitions are loaded upon Geoserver (re)start (i.e. you can see them
>>> in the srsHelp.do list).
>> Alexander, is this community plugin committed anywhere? I don't see it
>> in the geoserver community section?
>> Cheers
>> Andrea
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:1004,45b8d01230021527717022!
>

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org