[postgis-users] Change default "canonicalform"of spatial objects

[Gustavo Henrique Sberze Ribas]

Hello,

   first thanks a lot for your replies.
   
Strk and Mark,

  We have a legacy application that relies on the fact that all
selects will return EWKT, it was running well on PostGIS 0.9.
  Now I have four options to choose from:
  1) Rewrite all classes, but that is way too time consuming.
  2) Make views for all tables, but then I'd have to alter the
  table names which could create new bugs on insert/delete
  operations, which take me back to 1).
  3) I could make PostGIS output EWKT and everything would
  work like it once did, just like magic... :)
  4) I could convince the world that PostGIS 0.9 is perfect and
  there's no need to install the newest versions, ever. ;)
  
  It makes really no difference what format PostGIS uses to store
data internally, but I truly believe that the ascii output was meant
to be human readable. Of course, like in Matrix where those guys
saw 3d movies from running letters one can argue that it is
straightforward to "see" the points from a string like this one
"0020000001000010E6C036BB295E9E1B09C047A5E69AD42C3D". 
Nevertheless a function like the one proposed by Strk would make
things easier for the ungifted ones :).
    
  I'm aware of the problems introduced by parsing EWKT, but hey,
if you really need precision there's the binary form. As for the
pg_dump/pg_restore I don't understand the problem, perhaps
I'm missing something. Couldn't I make a simple script to change 
the default output to HEXEWKB, dump the database and restore
the default output back to whatever it was? Them pg_restore would 
always deal with a know, non-varying input format. Of course, the
user should be aware that only HEXEWKB will be accepted by
pg_restore, but when he changes the default output behaviour
he's also accepting that risk.

Thanks again,
Gustavo


> > On Tue, Mar 22, 2005 at 07:53:23PM -0300, Gustavo wrote:
> > > Hello,
> > > 
> > >   Is it possible to change the "canonical form" of spatial 
> > objects in 
> > > an uncomplicated way? :)
> > >   The current form is HEXEWKB for ascii and I'd like it to
> > > be EWKT. I mean, I'd like the following statements to
> > > produce the same output: 
> > >   
> > >   - SELECT geom FROM table;
> > >   - SELECT AsEWKT(geom) FROM table;
> > > 
> > >   I'm currently running PG 7.4.6 with PostGIS RC2.
> > 
> > The only way to change canonical output form is modifying
> > the C code. Canonical form is complicated for the sake
> > of precision.
> > 
> > If using asewkt() is a pain for many people we might
> > consider adding a function like: 
> > 	SELECT postgis_set("ascii_canonical_form", "ewkt");
> > 	SELECT postgis_set("ascii_canonical_form", "wkt");
> > 	SELECT postgis_set("ascii_canonical_form", "hexwkb");
> > 
> > --strk;
> 
> 
> Hi Gustavo,
> 
> Is there any particular reason why your application cannot 
> use AsEWKT()
> around a column? If you look back in the archives, there is a lot of
> discussion as to why the internal representation (HEXEWKB) is 
> different from
> the OGC compliant versions - using an explicit AsEWKT() will 
> guarantee that
> the output will be correct regardless of how the internal 
> representation may
> change in future versions of PostGIS.
> 
> It may be possible to add a postgis_set() function, but I can 
> see there
> being subtle issues with using pg_dump/pg_restore - I believe 
> at the moment
> these accept HEXEWKB but also (E)WKT to allow dumps from 
> previous versions
> of PostGIS to be restored, and I think if we start relaxing 
> this check we
> are only going to make things too complicated for ourselves 
> in the long run.
> 
> If your application really can't select the column, have you 
> considered
> using a view instead? For example, something like this:
> 
> 	-- Rename table to real_table
> 	ALTER TABLE table RENAME TO real_table;
> 
> 	-- Create the view
> 	CREAVE VIEW table AS SELECT AsEWKT(geom) FROM real_table;
> 
> Now you can simply do:
> 
> 	SELECT geom FROM table;
> 
> And this will give your EWKT output as required for your application.
> 
> 
> Kind regards,
> 
> Mark.
>