[Gvsig_english] Several patches for PostGIS driver

[Francisco Puga]

Hi Benjamin,

Sorry for the late answer. I was who wrote the case sensitive patch,
and i am on vacation.

2010/8/16 Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>:
> Hi Andres,
>
> many thanks for these patches! They fix a lot of annoying problems.
> I have reviewed them as much as I could, but I don't have a working
> PostGIS setup at the moment, so could not test them myself.

we are glad that the patches are useful to the community

> 1. Regarding the handling of "gid" and "the_geom" fields.
> I have reviewed the PostGIS docs and did not find a statement
> that says these fields must be called "gid" or "the_geom".
> So I guess it's fine to use something like "gid1" for the
> primary key. However, googling around a bit I got the impression
> that some software always assumes that "gid" and "the_geom"
> exist with these names. Clearly, it's not gvSIG's fault that
> some other software assumes something that is not guaranteed.
> But to guard users from potential trouble when interchanging
> data with other applications: should we display a warning message
> if "gid" or "the_geom" are changed to another name?

About PostGIS and the gid field, here is a good thread [1]. Sincerely,
i don't know if use a different name for "gid" or "the_geom" can break
"compatibility" with other gis software. But gvSIG is already using
"gidX" when "gid" exists so if this is the case the compatibility is
already broken. Anyway, if someone can expose a situation where this
approach is wrong we can think how to fix it.

The patch we provide related to this is just a small fix over how
gvSIG does to export a layer to postgis. I think that a more accurate
way will be ask the user if he wants that gvSIG creates a gid field
automatically. In this dialog we can notify the user with which name
the field will be created. This approach have sense for example if you
export a layer from postgis to shp, make some operations over it, and
the export again from shp to postgis, probably you don't that the gid
field be created, you would want to use the existent.

We didn't do this because in the first approach, we try to fix the
bugs without modifying how the things are being doing now.

[1] http://postgis.refractions.net/pipermail/postgis-users/2007-February/014814.html

> 2. Regarding case-sensitivity in gvSIG.
> This is something that has needed fixing for a long time and
> I am glad you addressed this problem. However, did you test
> how your patches interact with the gvSIG GUI? My impression
> was that some dialogs are not case-sensitive for field names.
> E.g., I was not able to rename a PostGIS field from "fielda"
> to "FieldA", because the field manager dialog thought the two
> were the same names. To clarify: I don't think there is anything
> wrong with how your patches work. But I am afraid there may
> be more parts of gvSIG's GUI that need patching.

We tested the case of modify the table structure (adding, deleting,
renaming), and this works. We think that the patches don't introduce
regressions and works in most of the cases, but of course, something
can be wrong. If someone thinks that anything is not working just, say
it or fill a bug :). We will try to fix it.

What you mention, is slightly different. We now that after some
process, for example a join, you can have a table with fields that
have the same name, and if you try to remove/rename one of then it
always works over the first field, not over the field you select. I
can't test it now, but probably gvSIG continues avoiding that you can
rename a field if the target name matches with other ignoring case.
Maybe more work is needed here.

> Again, thanks for your work. It really improves a key component
> of gvSIG.


best regards

-- 
Francisco Puga
Grupo de Desarrollo
Cartolab - Laboratorio de Ingeniería Cartográfica.
http://www.cartolab.es

ETS Ingeniería de Caminos, Canales y Puertos
Universidade da Coruña
Campus de Elviña - 15071 A Coruña (España)
(34)981167000 ext. 5493