[postgis-users] postgis+zaurus 5500

strk strk at keybit.net
Sat Jul 3 04:44:36 PDT 2004


See on the matter:
http://postgis.refractions.net/pipermail/postgis-devel/2004-February/000125.html
And please check if postgresql endiannes detection fails.

--strk;

On Sat, Jul 03, 2004 at 01:40:38PM +0200, strk wrote:
> On Fri, Jul 02, 2004 at 05:59:20PM -0300, Jonathan Giorgio Ghellere wrote:
> > Hi,
> > 
> > I set BIG and LITTLE_ENDIAN and in both cases the problem persists.
> 
> Where did you set them ?
> You should try setting under line 111 of postgis.h
> Around there there is an inclusion of sys/param.h which 
> has been found as needed for w32 systems.
> I do not know about availability of the 'endian.h' include,
> but including that would do the trick. As you can see
> sys/param.h is included *only* for w32, if you can provide
> a similar define for your system we can do the same thing.
> 
> --strk;
> 
> > 
> > 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
> > _______________________________________________
> > 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-users mailing list