Gilles Bassière | 1 Nov 2009 17:03
Favicon

Unable to build WKT Raster

Hi list,

I'd like to try WKT Raster but I have some troubles during install.

My first attempt was to build WKT Raster aginst PostGIS 1.3.5 source
code but the configure script fails because the liblwgeom/ directory
does not exist prior to PostGIS 1.4.0. I tried to create a symlink and
even to rename the directory lwgeom/ to liblwgeom/ but in both case, WKT
Raster don't build:

[...]
In file included from rt_pg.c:42:
pgsql_compat.h:15:1: warning: "SET_VARSIZE" redefined
[...]
rt_pg.c: In function ‘RASTER_lib_version’:
rt_pg.c:239: warning: implicit declaration of function ‘VARATT_SIZEP’
rt_pg.c:239: error: lvalue required as left operand of assignment
rt_pg.c: In function ‘RASTER_lib_build_date’:
rt_pg.c:250: error: lvalue required as left operand of assignment
[...]

Full configure output: http://pastebin.org/49983
Full build output: http://pastebin.org/49982
pg_config output: http://pastebin.org/49984

I've been able to track the problem down to rt_pg/pgsql_compat.h where
SET_VARSIZE seems to be redefined even if my PostgreSQL version is >8.3.
I can't find where/how POSTGIS_PGSQL_VERSION is defined though.

Technical details :
(Continue reading)

Rykov Denis | 1 Nov 2009 19:29
Picon
Gravatar

Strange query result

Hi folks!

I have a postgis table with 1 row.
When I try to do simple query: select ST_AsText(the_geom) from table,
i get very strange result (see attachement).

It looks like one very long blank string, and then WKT result.

Thanks.

-DR


Attachment (log): application/octet-stream, 3167 KiB
_______________________________________________
postgis-users mailing list
postgis-users <at> postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Paul Ramsey | 1 Nov 2009 19:32
Picon
Gravatar

Re: Strange query result

That's the table header, as psql valiantly tries to fit your
multi-megabyte output into an ASCII column aligned output.
Fundamentally, a lot of the assumptions database tools have about
column widths don't work so well for geometry.

P.

On Sun, Nov 1, 2009 at 10:29 AM, Rykov Denis <rykovd <at> gmail.com> wrote:
> Hi folks!
>
> I have a postgis table with 1 row.
> When I try to do simple query: select ST_AsText(the_geom) from table,
> i get very strange result (see attachement).
>
> It looks like one very long blank string, and then WKT result.
>
> Thanks.
>
> -DR
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users <at> postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
Mateusz Loskot | 2 Nov 2009 00:17
Gravatar

Re: Unable to build WKT Raster

Gilles Bassière wrote:
> Hi list,
> 
> I'd like to try WKT Raster but I have some troubles during install.
> 
> My first attempt was to build WKT Raster aginst PostGIS 1.3.5 source
> code but the configure script fails because the liblwgeom/ directory
> does not exist prior to PostGIS 1.4.0. I tried to create a symlink and
> even to rename the directory lwgeom/ to liblwgeom/ but in both case, WKT
> Raster don't build:

The WKT Raster README file available from
http://trac.osgeo.org/postgis/browser/spike/wktraster/README
says

"latest 1.3.5 release won't work"

> Full configure output: http://pastebin.org/49983
> Full build output: http://pastebin.org/49982
> pg_config output: http://pastebin.org/49984

It will not work. Please, use PostGIS 1.4.0 or recent source code
from trunk in SVN repository

> I also tried to build and install PostGIS 1.4.0 but I can't find a way
> to do so within my home directory since the --prefix option is now
> ignored (bug #160). Of course, I could compile a full PostgreSQL in my
> home directory but there might be an easier solution, is there?

If you want to build PostGIS, you need to compile and install PostGIS
only, no need to compile PostgreSQL.

Best regards,
--

-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
postgis-users mailing list
postgis-users <at> postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Paragon Corporation | 2 Nov 2009 01:59
Picon

Re: Unable to build WKT Raster

Mateusz,
We should probably update the docs here accordingly

http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01

This user doc way at the bottom says it works with 1.3.5 or higher and even
points at the 1.3 docs for compilation. 

Thanks,
Regina

-----Original Message-----
From: postgis-users-bounces <at> postgis.refractions.net
[mailto:postgis-users-bounces <at> postgis.refractions.net] On Behalf Of Mateusz
Loskot
Sent: Sunday, November 01, 2009 6:17 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Unable to build WKT Raster

Gilles Bassière wrote:
> Hi list,
> 
> I'd like to try WKT Raster but I have some troubles during install.
> 
> My first attempt was to build WKT Raster aginst PostGIS 1.3.5 source 
> code but the configure script fails because the liblwgeom/ directory 
> does not exist prior to PostGIS 1.4.0. I tried to create a symlink and 
> even to rename the directory lwgeom/ to liblwgeom/ but in both case, 
> WKT Raster don't build:

The WKT Raster README file available from
http://trac.osgeo.org/postgis/browser/spike/wktraster/README
says

"latest 1.3.5 release won't work"

> Full configure output: http://pastebin.org/49983 Full build output: 
> http://pastebin.org/49982 pg_config output: http://pastebin.org/49984

It will not work. Please, use PostGIS 1.4.0 or recent source code from trunk
in SVN repository

> I also tried to build and install PostGIS 1.4.0 but I can't find a way 
> to do so within my home directory since the --prefix option is now 
> ignored (bug #160). Of course, I could compile a full PostgreSQL in my 
> home directory but there might be an easier solution, is there?

If you want to build PostGIS, you need to compile and install PostGIS only,
no need to compile PostgreSQL.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo,
http://osgeo.org _______________________________________________
postgis-users mailing list
postgis-users <at> postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Paragon Corporation | 2 Nov 2009 11:25
Picon

Re: [postgis-devel] Geog/Geom Hack

Havard,

Good points. You stated my concerns better than I could.  

I see the benefit of having these functions and even think we should have
them linked in our documentation, but I don't want to "pollute" our
production waters with them.  So I would much prefer just a link to these
functions as a separate thing people can improve on.  As Nicklas and I think
Steve mentioned -- use it almost like a tutorial to demonstrate how you can
expand on the functionality of geography and see how people improve on it.

the problem with putting it in our production code is 
a) People will see it as a black box and won't bother to look behind the
covers and then they'll be disappointed when they run into issues and think
the whole geography datatype is a hack.
b) With our new policy of release, we won't be able to make patches to it or
add new ones until the next minor.  Which to me puts novices at a great
disadvantage.
c) I don't feel we know absolutely the best way of doing these even from a
hack point of view and I would like to see what others come up with as
solutions.

The geography functions we have in place are really spectacular I think.
They do the right thing - they measure around a sphere/spheroid and use a
more advanced spatial index (though just WGS84 for this first release).
Sure they don't do everything, but they satisfy the number one need of many
people -  How do I figure out proximities, areas, lengths and get real
accurate distances with long lat data and still have full power of spatial
indexes?

I would hate for people to think the whole thing is a hack by introducing
these things in what we call "production". 

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces <at> postgis.refractions.net
[mailto:postgis-devel-bounces <at> postgis.refractions.net] On Behalf Of Havard
Tveite
Sent: Monday, November 02, 2009 5:13 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geog/Geom Hack

My opinion is, that if this is to be implemented, it must be properly
documented (for all affected functions and for the geography support in
general).  The support for geography in
1.5 will also have to be called "experimental" with this kind of behaviour.

Since the plan is to implement all the functions properly in the future, I
think it is a good idea to use the function names that are going to be used
in the future (as Paul suggests).  However, I guess it can be a lot of work
to do a proper implementation of some of these functions for geography.

Paul's approach is clearly a hack, and the results will be unreliable.
Examples: Using this approach, a geography line may not be contained in it's
buffer.  An intersection between to geography lines will in the normal case
not be on any of the original lines.
So, we must expect a lot of topological inconsistencies using this approach.

For cases where it is not possible to find an OK "BestSRID", an error should
probably be thrown.

Håvard Tveite

Paul Ramsey wrote:
> I'm interested to know what the general opinion is of the trick I've 
> used on ST_Buffer(geography):
> 
> http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c
> #L541
> 
> I ask because I could apply the same idea to the larger suite of OGC 
> SFSQL predicates before release. Is half-a-loaf better than no loaf in 
> this case? (Note that there will be failure cases for really large 
> geometry, like a polygon of "Asia" or "Russia" that have polygons over 
> the dateline.)
> 
> P.

--
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB Drøbakveien 31,
POBox 5003, N-1432 Ås, NORWAY
Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/
_______________________________________________
postgis-devel mailing list
postgis-devel <at> postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
Mark Cave-Ayland | 2 Nov 2009 14:45
Picon

Re: Unable to build WKT Raster

Gilles Bassière wrote:

> I also tried to build and install PostGIS 1.4.0 but I can't find a way
> to do so within my home directory since the --prefix option is now
> ignored (bug #160). Of course, I could compile a full PostgreSQL in my
> home directory but there might be an easier solution, is there?

PGXS makes use of the DESTDIR variable for installation, so for a 
relocated install all you need to do is:

./configure
make DESTDIR=/path/to/output install

HTH,

Mark.

--

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-users mailing list
postgis-users <at> postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Pierre Racine | 2 Nov 2009 16:12
Picon

Re: Unable to build WKT Raster

There is no technical reason that should prevent WKT Raster of working with any recent version of PostGIS.
The doc should not then be changed. If it does not compile it is another story.

If Kevin's trick does the job we can document it.

Pierre

>-----Original Message-----
>From: postgis-users-bounces <at> postgis.refractions.net [mailto:postgis-users-
>bounces <at> postgis.refractions.net] On Behalf Of Mark Cave-Ayland
>Sent: 2 novembre 2009 08:45
>To: PostGIS Users Discussion
>Subject: Re: [postgis-users] Unable to build WKT Raster
>
>Gilles Bassière wrote:
>
>> I also tried to build and install PostGIS 1.4.0 but I can't find a way
>> to do so within my home directory since the --prefix option is now
>> ignored (bug #160). Of course, I could compile a full PostgreSQL in my
>> home directory but there might be an easier solution, is there?
>
>PGXS makes use of the DESTDIR variable for installation, so for a
>relocated install all you need to do is:
>
>./configure
>make DESTDIR=/path/to/output install
>
>
>HTH,
>
>Mark.
>
>--
>Mark Cave-Ayland - Senior Technical Architect
>PostgreSQL - PostGIS
>Sirius Corporation plc - control through freedom
>http://www.siriusit.co.uk

>t: +44 870 608 0063
>
>Sirius Labs: http://www.siriusit.co.uk/labs

>_______________________________________________
>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
Mateusz Loskot | 2 Nov 2009 16:33
Gravatar

Re: Unable to build WKT Raster

Pierre Racine wrote:
> There is no technical reason that should prevent WKT Raster of
> working with any recent version of PostGIS. The doc should not then
> be changed. If it does not compile it is another story.

Pierre,

I got your point. I've only used WKT Raster with PostGIS from SVN.

Best regards,
--

-- 
Mateusz Loskot, http://mateusz.loskot.net
Sufficool, Stanley | 2 Nov 2009 20:30
Favicon

Re: [postgis-devel] Buck Rogers and the 3rdDimension

My 2 cents.

Why do spheroid projections assume zero altitude is Z miles from core.
What about other planets? What if I want to map Mars?

Isn't the geography projection model is broken? You can't have a sphere
without a diameter and the Z measure is just a plus/minus of the given Z
constant from the core.

> -----Original Message-----
> From: postgis-users-bounces <at> postgis.refractions.net 
> [mailto:postgis-users-bounces <at> postgis.refractions.net] On 
> Behalf Of Paragon Corporation
> Sent: Saturday, October 31, 2009 9:00 AM
> To: 'PostGIS Development Discussion'
> Cc: 'PostGIS Users Discussion'
> Subject: Re: [postgis-users] [postgis-devel] Buck Rogers and 
> the 3rdDimension
> 
> 
> Paul,
> I always wondered that - I guess 2 questions I would ask
> 
> 1) How do other spatial databases handle this, or do they not 
> really do anything with the z coordinate anyway especially 
> with polar coords? Seems to me SQL Server doesn't do anything 
> with it but haven't tested it enough to be absolutely sure. 
> But not sure about Oracle, Informix, IBM (or maybe for their 
> geodetic calcs they ignore it)
> 
> 2) The instruments collecting this stuff, I guess gps and 
> what-not -- how do they collect this extra coordinate or is 
> it always a separate field and what measurement is it in?  I 
> suppose if they always measure altitude in meters, then we 
> would for users have to come up with some mechanism to allow 
> them to convert it to degrees if you assume all axis are the 
> same type (polar).
> 
> I would say the whole spatial ref model falls apart anyway 
> since it seems to me it completely ignores this (questionably 
> non-polar dimension so if you think in polar its not as clear 
> cut as the planar. that Z is an unknown so the best answer is 
> to do nothing with it and take it literally . 
> 
> Thanks,
> Regina
> 
> -----Original Message-----
> From: postgis-devel-bounces <at> postgis.refractions.net
> [mailto:postgis-devel-bounces <at> postgis.refractions.net] On 
> Behalf Of Paul Ramsey
> Sent: Saturday, October 31, 2009 1:14 AM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Buck Rogers and the 3rd Dimension
> 
> While updating the old geometry spheroid functions, I noted 
> the existence of a length3d_spheroid() variant. It is 
> actually the default call for
> st_length_spheroid() as it happens.
> 
> The kinds of things you have to pass into this function to 
> get sensible results are pretty restricted, as it turns out. 
> For example,
> 
> st_length_spheroid('LINESTRING(0 0 1000, 0 0.001 1001)', 
> 'SPHEROID["WGS84",
> 6378137,298.257222101]')
> 
> Note that the units of Z are meters while the units of X and 
> Y are degrees. To get a sensible answer out, in fact, the 
> units of your altitude have to match the units of your spheroid.
> 
> Anyhow, my geography routines right now are strictly 2D so I 
> haven't renovated this particular variant, but it's put my in 
> the mind of wondering what the right thing to do is, in 
> geography. If I get a '3D' geography, do I assume the third 
> dimension is in meters? Do I calculate a "3D" length (or 
> distance?) by default? That's what our geometry routines do 
> right now, and it hasn't caused harm yet.
> 
> It seems like an interesting submerged assumption in the 
> geodetic space, that the units of your extra dimension will 
> match the units of the axes of your spheroid.
> 
> As I recall, we added this function many years back, to 
> calculate as exactly as possible the drive lengths of roads 
> in a road network (BC is a hilly place). Not sure if anyone 
> else is using it. And still not sure if a 
> "length3d_spheroid()" function is a wise proposition in 
> general, given the required assumptions.
> 
> P.
> _______________________________________________
> postgis-devel mailing list postgis-devel <at> postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 
> 
> 
> _______________________________________________
> postgis-users mailing list postgis-users <at> postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 

Gmane