<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.7600.16535"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial>Nicklas,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial>public.geometry and trunk.geometry are NOT the same type as
far as PostgreSQL is concerned.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial>With that said I suspect your ST_Area... etc. functions in
trunk are bound to public.geometry and not trunk.geometry, but
your ST_SRID in trunk is against trunk.geometry.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial>Scanning your information_schema. Your table geometry is
defined as public.geometry.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=875574008-13052010></SPAN><FONT
face=Arial><FONT color=#0000ff><FONT size=2>H<SPAN class=875574008-13052010>ow
could this happen. I suspect the sequencing in the install script.
That when ST_SRID was created trunk.geometry existed so it grabbed unto that
since it was higher in search path.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010>ST_Area etc. perhaps when they were created
trunk.geometry did not exist so they got tied to public.geometry. (normally if
these don't exist, you see a creating shell for geometry type -- that's what all
that means. In this case it didn't need to create a shell since it was
already present).</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010>Given that. The downside of your approach is if
you are going to install like this, you need to strip out all the
trunk.geometry/operator functions to prevent this data type from being
created.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010>Alternatively keep two sets of data - one against
public.geometry and one against trunk.geometry. Which sounds
messy.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010>Hope that helps,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=875574008-13052010>Regina</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><BR></DIV>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B>
postgis-devel-bounces@postgis.refractions.net
[mailto:postgis-devel-bounces@postgis.refractions.net] <B>On Behalf Of
</B>Nicklas Avén<BR><B>Sent:</B> Wednesday, May 12, 2010 7:00 PM<BR><B>To:</B>
PostGIS Development Discussion<BR><B>Subject:</B> [postgis-devel] searching for
geometry type in wrong schema<BR></FONT><BR></DIV>
<DIV></DIV>Hallo<BR><BR>I have bumped into something very strange I think. <BR>I
am trying to get postgisonline.org work smoothly with multiple versions of
postgis.<BR><BR>The solution I am now trying I guess is somewhere in the outer
parts of what is recommended but I have found that the easiest administration of
the datasets to use in postgisonline is if everything is in the same database.
<BR><BR>Because of that I have installed postgis 1.5.1 in public schema as usual
and Postgis trunk in a schema called trunk. Then I have different users with
different search_path and decide what version to use by changing connection
parameters. <BR>This worked just great until a removed public schema from the
search_path for the trunk version. Then some functions stopped working with the
error, for instance:<BR><BR>function ST_Srid(public.geometry) does not
exist<BR><BR>What is strange is that ST_Area works fine and ST_Distance and
ST_Length, but not ST_Dump<BR><BR>The question I don't understand right now is
what decides where to get the type. From what I understand ST_Srid reads the
type from the public schema and complains that the ST_Srid function in the trunk
schema doesn't like the public.geometry type. I also guess that ST_Area does
what is expected and uses the geometry type specified in the trunk schema and
the ST_Area function get satisfied since it expects
ST_Area(trunk.geometry)<BR><BR>My first thought is that there is some hard coded
path to public schema in some functions. But I really don't know because in my
local install, not postgisonline, I get different result. First all seemed to
work and now nothing seems to work.<BR><BR>This is of course a very small issue
and there is workarounds, but if this is a bug it might give other unexpected
behaviours I guess.<BR><BR>If you want to see the phenomena on postgisonline you
can get the trunk search_path by using this
address:<BR>http://www.postgisonline.org/map.php?version=trunk<BR><BR>then you
can try against a table called roads. All queries producing a geometry column
called the_geom will give an error because there is an srid check which causes
the error above.<BR><BR>but try <BR>Select ST_Length(the_geom) from roads;
<BR>or<BR>Select ST_Area(the_geom) from property;<BR>and it should work. But
:<BR>Select ST_Srid(the_geom) from roads;<BR> will give error<BR><BR>Any
ideas?<BR>Is it a PostgreSQL bug or a PostGIS bug or am I the bug
myself?<BR><BR>Thanks<BR>Nicklas<BR></BODY></HTML>