[postgis-users] postgis+zaurus 5500

[Jonathan Giorgio Ghellere]

Hi,

I set BIG and LITTLE_ENDIAN and in both cases the problem persists.

In the BIG_ENDIAN, postgis return a XDR, and the select was a NDR..... a 
little crazy.

# select oid,asbinary(geom,'NDR') as qgs_feature_geometry from gtest where 
geom && GeometryFromText('BOX3D(        1.529391         2.750000,        7.
470609         8.250000)'::box3d,-1);

  oid  |                                                                
qgs_feature_geometry
-------+----------------------------------------------------------------------
------------------------------------------------------------------------------
 19203 | 
010000000200000004000000004000000000000000400800000000000040100000000000004014
00000000000040180000000000004014000000000000401C00000000000040200000
(1 row)

but is swapped too.

this is the endian.h of zaurus:

--------------------------cut---------------------
#ifndef _ENDIAN_H
#define _ENDIAN_H   1

#include <features.h>
/* Definitions for byte order, according to significance of bytes,
   from low addresses to high addresses.  The value is what you get by
   putting '4' in the most significant byte, '3' in the second most
   significant byte, '2' in the second least significant byte, and '1'
   in the least significant byte, and then writing down one digit for
   each byte, starting with the byte at the lowest address at the left,
   and proceeding to the byte with the highest address at the right.  */

#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN    4321
#define __PDP_ENDIAN    3412

/* This file defines `__BYTE_ORDER' for the particular machine.  */
#include <bits/endian.h>

/* Some machines may need to use a different endianness for floating point
   values.  */
#ifndef __FLOAT_WORD_ORDER
# define __FLOAT_WORD_ORDER __BYTE_ORDER
#endif

#ifdef  __USE_BSD
# define LITTLE_ENDIAN  __LITTLE_ENDIAN
# define BIG_ENDIAN __BIG_ENDIAN
# define PDP_ENDIAN __PDP_ENDIAN
# define BYTE_ORDER __BYTE_ORDER
#endif

#if __BYTE_ORDER == __LITTLE_ENDIAN
# define __LONG_LONG_PAIR(HI, LO) LO, HI
#elif __BYTE_ORDER == __BIG_ENDIAN
# define __LONG_LONG_PAIR(HI, LO) HI, LO
#endif

#endif  /* endian.h */
-------------------------- /cut------------------

any idea ?

tks

On Fri, 2 Jul 2004 17:06:31 +0200, strk wrote
> It seems postgis is not able to correctly detect BYTE_ORDER
> on zaurus. Please check BYTE_ORDER and the like defines
> in postgis_fn.c. Also try to find out where does your system
> define that (if it does) or a architectur specific header defined
> that could be handled for the specific case.
> --strk;
> 
> On Fri, Jul 02, 2004 at 11:44:42AM -0300, Jonathan Giorgio Ghellere wrote:
> > Hello,
> > 
> > I've compiled postgresql+postgis+proj for a zaurus 5500 running openzaurus 
3.
> > 3.5 and used qgis in a x86 machine to connect to the database in the 
zaurus.
> > The database was created using the http://postgis.refractions.
net/docs/c206.
> > html:
> > 
> > CREATE TABLE gtest ( ID int4, NAME varchar(20) );
> > SELECT AddGeometryColumn('dbname','gtest','geom',-1,'LINESTRING',2);
> > INSERT INTO gtest (ID, NAME, GEOM) VALUES (1, 'First Geometry', 
> > GeometryFromText('LINESTRING(2 3,4 5,6 5,7 8)', -1));
> > 
> > Everything goes ok, but, when I use QGIS (http://qgis.org), to retrieve a 
> > feature map it returns a blank screen. So, I debug QGIS in order to see 
how it 
> > was selecting map and got something like this:
> > 
> > select oid,asbinary(geom,'NDR') as qgs_feature_geometry from gtest where 
geom 
> > && GeometryFromText('BOX3D(        1.529391         2.750000,        7.
470609  
> >        8.250000)'::box3d,-1);
> > 
> > In psql that query line returns:
> > 
> >   oid  |                                                                
> > qgs_feature_geometry
> > 
-------+----------------------------------------------------------------------
> > 
------------------------------------------------------------------------------
> >  21265 | 
> > 
010200000004000000000000400000000000000840000000000000104000000000000014400000
> > 00000000184000000000000014400000000000001C40000000000000204000000000
> > (1 row)
> > 
> > Ok, this line did not show much, but take a look in the same query in a 
x86 
> > machine:
> > 
> >   oid  |                                                                
> > qgs_feature_geometry
> > 
-------+----------------------------------------------------------------------
> > 
------------------------------------------------------------------------------
> >  19203 | 
> > 
000200000004000000000000000000004000000000000008400000000000001040000000000000
> > 1440000000000000184000000000000014400000000000001C400000000000002040
> > (1 row)
> > 
> > It looks like the bytes are swapped. Do anybody knows why it's happening ?
> > 
> > tks for the help.
> > 
> > --
> > Jonathan Giorgio Ghellere
> > http://www.ecosconsult.com.br
> > EcosConsult Planejamento Ltda
> > 
> > 
> > _________________________
> > Linux - uvscan antivirus
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users


--
http://www.ecosconsult.com.br
EcosConsult Planejamento Ltda


_________________________
Linux - uvscan antivirus