Hello,
I’m from a company that is using Geoserver to serve some GIS services (we are still in a development and testing stage, so we do not have anything to show yet) Well, we’ve decided user MySQL as datastore, mainly because ALL our data and web applications uses MySQL and a migration to postgres/postgis would be too expensive for us. Well. Until now, MySQL GIS extensions fulfills all of our necessities but we’ve detected some issues/errors in the Geoserver side. For example, if we have a MySQL table which primary key is an INTEGER (among a spatial key of course), Geoserver (plain installation) simply refuses this table as a datasource. If we change the primary key type to, let’s say, VARCHAR(40), all works fine for Geoserver. Other examples are that we cannot use type Geometry. We must use the leaf datatype instead.
I really don’t know if this mailing list is the best place to send ‘bugreports’ so please, if I’m wrong point me to the right place. Also, we have the spirit of contribution and we are very interested in making the MySQL extension for Geoserver fully operative, se if we could help in this area, please, tell us.
Best regards,
Jacobo.
Jacobo Rodríguez ha scritto:
Hello,
I'm from a company that is using Geoserver to serve some GIS services (we are still in a development and testing stage, so we do not have anything to show yet) Well, we've decided user MySQL as datastore, mainly because ALL our data and web applications uses MySQL and a migration to postgres/postgis would be too expensive for us. Well. Until now, MySQL GIS extensions fulfills all of our necessities but we've detected some issues/errors in the Geoserver side. For example, if we have a MySQL table which primary key is an INTEGER (among a spatial key of course), Geoserver (plain installation) simply refuses this table as a datasource. If we change the primary key type to, let's say, VARCHAR(40), all works fine for Geoserver. Other examples are that we cannot use type Geometry. We must use the leaf datatype instead.
In general using a Geometry as primary key is something you won't be able to do anyways, since you have to convert it to a (relatively short)
string to make up the Feature FID.
Anyways, if you're interested in contributing, you're very welcomed to.
Geoserver is based on Geotools, and all data stores are there.
For handling extra primary key types, you will have to patch the MySql
data store (gt2-mysql), and create new FIDMapper classes for that datastore.
If you're planning to use Geoserver 1.5.x, it's the geotools 2.3.x branch that you have to use.
To set up a developer environment, have a look at the Geotools and
Geoserver developers guide:
http://docs.codehaus.org/display/GEOT/Home
http://docs.codehaus.org/display/GEOSDOC/Developers+Guide
If you need suggestions and the like, this list is a good starting point, but geotools-devel would serve you better.
Once you have patches ready, attach them to a Jira issue on the Geotools
Jira tracker, the module mantainer will evaluate them and apply them.
Hope this helps
Cheers
Andrea
Jacobo Rodríguez ha scritto:
I really don't know if this mailing list is the best place to send 'bugreports' so please, if I'm wrong point me to the right place. Also, we have the spirit of contribution and we are very interested in making the MySQL extension for Geoserver fully operative, se if we could help in this area, please, tell us.
Oh, forgot one thing. If you do feel like contributing, but you don't have time, skills, or simply prefer one of the official geotools developers to work on it, you can sponsor some custom development.
Various consultants accept support contracts to perform custom developments/bug fixes on both Geoserver and Geotools. See:
http://docs.codehaus.org/display/GEOS/Commercial+Support
Cheers
Andrea