[postgis-devel] Re: [postgis-users] pgsql2shp changing case of fieldnames
strk at refractions.net
strk at refractions.net
Mon May 16 10:30:21 PDT 2005
Regina, I confirm the problem, we compared against PQgetvalue.
I've reorganized the code so that now we store names used for
dbf fields in a separate array and check against it.
Renaming of duplicated fields is done using a serial number appended
to first 7 digits of name and padded to 2 digits + a '_' sign.
Example:
``ord'' is the order of pgsql field reading, it influences the
way name is transformed
ord original with -k w/out -k
----------------------------------------------------
0 testing123456 testing123 TESTING123
1 TESTING123456 TESTING_01 TESTING_01
2 testing123456 testing_02 TESTING_02
3 testingABCDE testingABC TESTINGABC
4 id id ID
5 id id_01 ID_01
6 ID ID_02 ID_02
Every name change (from pgsql to dbf) is warned on stderr.
The only non-warned attribute in previous table is the number 4
(upper-casing is not warned, just truncation and modification).
Comments and tests welcome.
--strk;
On Mon, May 16, 2005 at 10:08:47AM -0400, Obe, Regina DNDMIS wrote:
> strk,
>
> I tried the same test without the k option and it produces 2 fields in the
> dbase table called "LABEL".
> So it appears to be an issue in both cases.
>
> Actually in the non-k based situation - at least in windows, it's a more
> serious issue because the
>
> /*
> * make sure the fields all have unique names,
> * 10-digit limit on dbf names...
> */
>
> rarely kicks in because it is always comparing the Pg field name with the
> uppered field name? So you end up
> With situations like
>
> If you have two field names
>
> testing123456, testing12345
>
> They both get output as identical
> "TESTING123"
>
> Because the compare is always comparing the testing123 against "TESTING123"
> In the non-k situation.
>
> I think if we just change this section to a case-insensitive match, then
> that will fix everything.
>
> You want me to take a shot at fixing this? Maybe just double check on your
> system to make sure my above assumption is correct.
>
>
>
>
>
> -----Original Message-----
> From: strk at refractions.net [mailto:strk at refractions.net]
> Sent: Friday, May 13, 2005 10:51 AM
> To: Obe, Regina DNDMIS
> Cc: postgis-devel at postgis.refractions.net
> Subject: Re: [postgis-users] pgsql2shp changing case of fieldnames
>
>
> On Fri, May 13, 2005 at 10:45:05AM -0400, Obe, Regina DNDMIS wrote:
> > Hi strk,
> >
> > It is Regina. I guess we should check or give a warning. I tried a
> > test with outputing a table with one field named label and another
> > "LABEL" and then opened it in Arc Explorer. It opens in Arc Explorer
> > fine, but when you use the information tool it only shows one of the
> > "label" fields and kicks the other one out.
> >
> > I tried a DBF ODBC driver and got similar behavior.
>
> So, are you suggesting pgsql2shp issueing a warning when caseless equality
> of 2 fields is detected with -k ?
>
> (it renames duplicated field names w/out -k)
>
> --strk;
>
> >
> > Thanks,
> > Regina
> >
> > -----Original Message-----
> > From: 'strk at refractions.net' [mailto:strk at refractions.net]
> > Sent: Friday, May 13, 2005 10:09 AM
> > To: Obe, Regina DNDMIS
> > Cc: postgis-devel at postgis.refractions.net
> > Subject: Re: [postgis-users] pgsql2shp changing case of fieldnames
> >
> >
> > Thanks Obe (or Regina?).
> > I've applied your patch, but I'm not sure about something: would a DBF
> > be legal if it contains attributes like 'LABEL' and 'label' in the
> > same file ? This would be a valid postgresql table, but is this true
> > for .dbf ?
> >
> > In case it isn't we should do a case-insensitive match where
> > we check this (around line 2650). I left a TODO there:
> >
> > /*
> > * TODO: check out if should be case-insensitive
> > * here since we might be running in -k mode
> > */
> >
> > --strk;
> >
> >
> > On Fri, May 13, 2005 at 08:41:54AM -0400, Obe, Regina DNDMIS wrote:
> > > I was working off of the cvs hourly build snapshot from the postgis
> > > site. Unfortunately I'm behind a firewall so don't think I can hit a
> cvs.
> > >
> > > I made a diff patch. Attached is the file. I hope I did it right.
> > >
> > > Thanks,
> > > Regina
> > >
> > >
> > > -----Original Message-----
> > > From: 'strk at refractions.net' [mailto:strk at refractions.net]
> > > Sent: Friday, May 13, 2005 3:26 AM
> > > To: Obe, Regina DNDMIS
> > > Subject: Re: [postgis-users] pgsql2shp changing case of fieldnames
> > >
> > >
> > > On Thu, May 12, 2005 at 08:27:57AM -0400, Obe, Regina DNDMIS wrote:
> > > > I've made the change in my copy and it seems to work okay so far.
> > > > I'm
> > > > going to test it a little more. So I guess I just need to know how to
>
> > > > send you the patch.
> > >
> > > Are you working on a CVS snapshot ?
> > > If so use cvs diff and send me the output (should be small). If you
> > > have problems with that just send me the whole pgsql2shp.c file and
> > > I'll check the changes myself. Thanks.
> > >
> > > --strk;
> > >
> > > >
> > > > Thanks,
> > > > Regina
> > > >
> > > > -----Original Message-----
> > > > From: strk at refractions.net [mailto:strk at refractions.net]
> > > > Sent: Tuesday, May 10, 2005 2:42 PM
> > > > To: Obe, Regina DNDMIS
> > > > Cc: 'PostGIS Users Discussion'
> > > > Subject: Re: [postgis-users] pgsql2shp changing case of fieldnames
> > > >
> > > >
> > > > I've added the request in the HEAD branch TODO list.
> > > > If you will do it yourself sooner then us
> > > > we'll accept patches. Let me know if you plan to do it and feel
> > > > free to ask any info you might need for that.
> > > >
> > > > --strk;
> > > >
> > > > On Mon, May 09, 2005 at 04:02:46PM -0400, Obe, Regina DNDMIS
> wrote:
> > > > > The old one I had was dated sometime in 2003 and was compiled
> > > > > under cygwin, but it still seemed to work when I upgraded to 8.0.
> > > > > I think a -k switch would be best.
> > > > >
> > > > > The older version preserved the case that was in postgres so for
> > > > > situations where we needed UPPERCASE (standard shp behavior) we
> > > > > had to create views that had the fields upper cased and dumped
> > > > > those out; so this new version irradicates that need. There are
> > > > > some situations where it is convenient to keep the same case as
> > > > > postgres - e.g. it makes it easier to swap out a postgis layer
> > > > > with a shape layer where postgis is not feasible for a particular
> > > > > environment. I'm assuming mapserver is still case sensitive with
> > > > > field names in templates.
> > > > >
> > > > > -----Original Message-----
> > > > > From: strk at refractions.net [mailto:strk at refractions.net]
> > > > > Sent: Monday, May 09, 2005 11:26 AM
> > > > > To: 'PostGIS Users Discussion'
> > > > > Subject: Re: [postgis-users] pgsql2shp changing case of
> > > > > fieldnames
> > > > >
> > > > >
> > > > > On Mon, May 09, 2005 at 10:18:52AM -0400, Obe, Regina DNDMIS
> > wrote:
> > > > > > I noticed the 3/31/05 build of pgsql2shp I have now
> > > > > > automatically
> > > > > > forces the output field names to upper case which normally would
> > > > > > be a good thing. Unfortunately I've got some old mapserver maps
> > > > > > that rely on the field names in the dbf being in lowercase. Is
> > > > > > there anyway to reverse this behavior e.g. with a switch or
> > > > > > something of that sort so that I don't have to revert back to the
> > > > > > older version of pgsql2shp?
> > > > > >
> > > > > > Thanks,
> > > > > > Regina
> > > > >
> > > > > Which version of pgsql2shp doesn't do that ?
> > > > > I guess we can revert the change back ... or add a -k switch to
> > > > > it as well.
> > > > >
> > > > > Does anyone see a problem with this ?
> > > > >
> > > > > --strk;
> > > > > _______________________________________________
> > > > > postgis-users mailing list postgis-users at postgis.refractions.net
> > > > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> > > > > _______________________________________________
> > > > > postgis-users mailing list postgis-users at postgis.refractions.net
> > > > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> > >
More information about the postgis-devel
mailing list