Re: [postgis-users] How To build postGIS on debian with pbuilder?
Does anyone know how to build postGIS using pbuilder on Debian lenny. I have been about to build geos-3.2.0 and proj-4.6.1 It has heartburn with: The following packages have unmet dependencies: pbuilder-satisfydepends-dummy: Depends: postgresql-server-dev-8.4 which is a virtual package. Depends: libproj-dev (= 4.5.0) which is a virtual package. Both of which are available via apt-get. Any thoughts? I can ask on the debian list also, but I thought people here might provide a more specific solution to this build postgis. Hi, if I understand correctly, You are trying to backport PostGIS package from testing or unstable to Lenny. If so, You must change package dependencies in 'debian/control' file to fit in Lenny. Change 'libproj-dev' to 'proj' and 'postgresql-server-dev-8.4' to 'postgresql-server-dev-8.3'. And try. Ivan ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Problem with ST_ExteriorRing and ST_contains
Hi everybody, I'm a postgis new user and I would like to submit here a problem I encounter. Here's what I do : from a polygon layer I merge some of them (with ST_UNION) into bigger ones according to an attribute value, then I make an exterior ring (with ST_Collect(ST_ExteriorRing())) around these and then I fill these rings (with ST_Contains) with all the original polygon that are inside ( I do this to have a coherent area without the holes I would have otherwise because of some data particularities). All this works very fine for 99.9 % of the polygons but fails on filling the rings for a few of them. When I look at these I see that they have a loop which is a probably due to a wrong geometry in the original polygons. Does any of you know how to deal with this ? Thanks for your help Didier ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Problem with probe_geometry_columns()
Thanks Mark and Ben,
I will try to understand better what happens here.
Fred.
On Wed, May 19, 2010 at 4:31 AM, Ben Madin
li...@remoteinformation.com.auwrote:
Fred,
On 18/05/2010, at 22:38 , Fred Lehodey wrote:
I have no success trying the function probe_geometry_columns() with
Postgis 1.5.0
1) Not sure but comparing the SQL with Postgis 1.3.3:
the clause (in the INSERT step and not the count of probed)
sridcheck.consrc LIKE '(srid('||a.attname||') = %)' in postgis 1.3.3
is now:
sridcheck.consrc LIKE '(st_srid('||a.attname||') = %)' in postgis 1.5.0
This looks like a tipo error. (this is not the function here but the
constraint text in pg_constraint)
I think the st_ prefix is now required,
2) I have a second problem with pg_constraint table and the consrc
field.
Most of time I have something like :
(public.srid(the_geom) = 27492)
and not (as expected by the function probe_geometry_columns()) :
(srid(the_geom) = 27492)
This was previously an issue if you installed postgis into other than the
public schema. The public schema reference was in a few locations, so you
need to search it out in the function defs and remove it and recreate the
function if you don't want to upgrade.
I have upgraded a number of databases to 1.5 from 1.4 and it seems to have
fixed it... but I have also mucked it by not changing the search_path prior
to running the upgrade, leaving me with multiple postgis function
definitions!
cheers
Ben
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Split Multistring on the_geom
Hi,
I would like to know if theres a postgis function (or the easist and
effective way), that I can use to split an intersection o 2 multistrings, so
I can have the geometric data of --the start and end nodes of both lines,
and the new node created in the intersection,
I'llbe really greatful,
Hello
Linear referencing functions may be useful in this case:
http://postgis.org/documentation/manual-1.5/reference.html#Linear_Referencing
A combination of the linestrings intersection and
st_line_locate_point, st_line_substring.
You will have to explode your multilinestrings into linestrings,
though, before using LR functions:
select st_astext(st_line_substring(geom1, 0, st_line_locate_point(
geom1, st_intersection(geom1, geom2)
)
))
from
(select geometryN(geomfromtext('MULTILINESTRING((0 0, 6 0))', -1), 1) as geom1,
geometryN(geomfromtext('MULTILINESTRING((3 3, 3 -1))', -1), 1) as
geom2) as foo;
Nicolas
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Problem with ST_ExteriorRing and ST_contains
Hi everybody, I'm a postgis new user and I would like to submit here a problem I encounter. Here's what I do : from a polygon layer I merge some of them (with ST_UNION) into bigger ones according to an attribute value, then I make an exterior ring (with ST_Collect(ST_ExteriorRing())) around these and then I fill these rings (with ST_Contains) with all the original polygon that are inside ( I do this to have a coherent area without the holes I would have otherwise because of some data particularities). All this works very fine for 99.9 % of the polygons but fails on filling the rings for a few of them. When I look at these I see that they have a loop which is a probably due to a wrong geometry in the original polygons. Does any of you know how to deal with this ? Thanks for your help Hi, You should first check the geometry validity (st_isvalid, st_isValidReason) and isolate invalid geometries to correct them Some tricks can correct them automagically (st_buffer(geom, 0.0) for instance) and some programs can help you identifiy invalid geometries (Jump for instance, with its validation plugin). Mailing list contains useful hints on how to correct invalid geometries. HTH Nicolas ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Question on GEOMETRY type
Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] OpenStreetMap + osm2pgsql + pgRouting into Postgis
Hi, how can i be sure about this? If i get wrong results i mean ... María Arias de Reyna wrote: El Tuesday 18 May 2010, Roshni Budhrani escribió: I have been told that this is probably because the OSM data is not properly noded at all intersections. If it is so, then how can i fix my data? Most probably. You can try to use a bigger number on the assign_vertex_id function, but it can lead you to wrong results too. -- María Arias de Reyna Domínguez Área de Operaciones Emergya Consultoría Tfno: +34 954 51 75 77 / +34 607 43 74 27 Fax: +34 954 51 64 73 www.emergya.es ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- View this message in context: http://old.nabble.com/OpenStreetMap-%2B-osm2pgsql-%2B-pgRouting-into-Postgis-tp28594661p28606823.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] OpenStreetMap + osm2pgsql + pgRouting into Postgis
El Wednesday 19 May 2010, roshni.spain escribió: Hi, how can i be sure about this? If i get wrong results i mean ... Well, you can try some samples and check it by hand. If I am not mistaken, that number is used to know the size of the buffer used to calculate which node goes to each vertex. If you use a small number and the lines you are using are not close enough, pgrouting will think they are not touching and will not assign them the same vertex. If you use a big number, pgrouting can think that lines, who should not be touching, are touching. Then it can lead you to stupid routes, like jumping from one road to the paralell. -- María Arias de Reyna Domínguez Área de Operaciones Emergya Consultoría Tfno: +34 954 51 75 77 / +34 607 43 74 27 Fax: +34 954 51 64 73 www.emergya.es ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Number of registered users and developers on the forum
Hi, Is there a way I could know how many active users and developers are registered to this forum. Will appreciate for the response. Cheers Ali -- View this message in context: http://old.nabble.com/Number-of-registered-users-and-developers-on-the-forum-tp28606905p28606905.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on GEOMETRY type
I'm no expert but the third dimension appears to be supported by most types and the docs are pretty good about showing this. Take a point for example: http://postgis.refractions.net/docs/ST_MakePoint.html You can add a third argument to add the z coordinate. Use ST_Y(point) to access the third dimension. Oh, and when you add your geometry column, be sure to specify a dimension of 3. http://postgis.refractions.net/docs/AddGeometryColumn.html hth charles On May 19, 2010, at 6:27 AM, 孙琦 wrote: Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] PostGIS installation error: could not find geos_c.h
Hi, I'm trying to install PostGIS 1.5 on an Amazon EC2 instance running the 64-bit version of Fedora 8. I've installed PostgreSQL 8.4, Proj, GEOS, and libxml. When I try to configure PostGIS, using the following command: ./configure --with-geosconfig=/root/sources/geos/geos-3.2.0/tools/geos-config I get the following error: configure: error: could not find geos_c.h - you may need to specify the directory of a geos-config file using --with-geosconfig Now, I have geos_c.h installed in /root/sources/geos/geos-3.2.0/capi. Can someone please tell me what I'm doing wrong? By the way, I'm following these instructions: http://www.postgresonline.com/journal/index.php?/archives/147-Compiling-PostGIS-1.5-and-installing-after-Yum-PostgreSQL-Install.html Cheers, Petrus ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on GEOMETRY type
Can anyone throw some lights on the question? Thanks, Cheney On Wed, May 19, 2010 at 6:27 PM, 孙琦 qsu...@gmail.com wrote: Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on GEOMETRY type
ST_NDims() returns the number of dimensions, but that doesn't distinguish between XYM and XYZ. The ESRI compatibility functions SE_IsMeasured() and SE_Is3D() (hey, they are useful after all!) return the information you are looking for. P On Wed, May 19, 2010 at 7:23 AM, 孙琦 qsu...@gmail.com wrote: Can anyone throw some lights on the question? Thanks, Cheney On Wed, May 19, 2010 at 6:27 PM, 孙琦 qsu...@gmail.com wrote: Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on GEOMETRY type
If you have an older version of PostGIS, the zmflag() function also returns the information you need. P 2010/5/19 Paul Ramsey pram...@opengeo.org: ST_NDims() returns the number of dimensions, but that doesn't distinguish between XYM and XYZ. The ESRI compatibility functions SE_IsMeasured() and SE_Is3D() (hey, they are useful after all!) return the information you are looking for. P On Wed, May 19, 2010 at 7:23 AM, 孙琦 qsu...@gmail.com wrote: Can anyone throw some lights on the question? Thanks, Cheney On Wed, May 19, 2010 at 6:27 PM, 孙琦 qsu...@gmail.com wrote: Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on GEOMETRY type
On Wed, May 19, 2010 at 07:43:03AM -0700, Paul Ramsey wrote: If you have an older version of PostGIS, the zmflag() function also returns the information you need. Which was even more useful as you could get the whole information with a single function rather than two, and hitting less keystrokes too! :) Was that function deprecated ? --strk; 2010/5/19 Paul Ramsey pram...@opengeo.org: ST_NDims() returns the number of dimensions, but that doesn't distinguish between XYM and XYZ. The ESRI compatibility functions SE_IsMeasured() and SE_Is3D() (hey, they are useful after all!) return the information you are looking for. P On Wed, May 19, 2010 at 7:23 AM, Ëïçù qsu...@gmail.com wrote: Can anyone throw some lights on the question? Thanks, Cheney On Wed, May 19, 2010 at 6:27 PM, Ëïçù qsu...@gmail.com wrote: Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on GEOMETRY type
No, it's still around. On Wed, May 19, 2010 at 8:25 AM, strk s...@keybit.net wrote: On Wed, May 19, 2010 at 07:43:03AM -0700, Paul Ramsey wrote: If you have an older version of PostGIS, the zmflag() function also returns the information you need. Which was even more useful as you could get the whole information with a single function rather than two, and hitting less keystrokes too! :) Was that function deprecated ? --strk; 2010/5/19 Paul Ramsey pram...@opengeo.org: ST_NDims() returns the number of dimensions, but that doesn't distinguish between XYM and XYZ. The ESRI compatibility functions SE_IsMeasured() and SE_Is3D() (hey, they are useful after all!) return the information you are looking for. P On Wed, May 19, 2010 at 7:23 AM, Ëïçù qsu...@gmail.com wrote: Can anyone throw some lights on the question? Thanks, Cheney On Wed, May 19, 2010 at 6:27 PM, Ëïçù qsu...@gmail.com wrote: Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Split Multistring on the_geom
Sorry, I didn't explain myself very well, now I can: I don't need in every vertex a point or a node. I want to rebuild my geometry by adding new nodes where I need. This is the logic that I want in pgsql code: 1. Read over all the multilinestrings that I have, all the_geom in this case,(Is really neccesary to explode them into linestrings?) 2. By default the first point will be the start node, and i will store it in position[1], when I stop in a vertex, ask to postgis If there's an intersection, if there`s one, store it in position[2], if there's an actual node (will be the end node), store it, and close the multilinestring. 3. Repeat that process on the next node. Thank you Nicolas. -- View this message in context: http://old.nabble.com/Split-Multistring-on-the_geom-tp28597888p28610253.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] ST_Line_Locate_Point - what is the distance at which a point is NOT close to a line?
Hello, Newbie question. Please bear with me. I understand ST_Line_Locate_Point that returns the location of the closest point on LineString to the given Point as a fraction of the total distance of the LineString, but what is the distance between the Point and the LineString that it considers as 'close' In other words, when does it return zero? (i.e what is the distance at which a point is not close to a line?) Thanks, Gokul. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Line_Locate_Point - what is the distance at which a point is NOT close to a line?
Gokul, Returns zero when the closest point on the linesting is the from node. Fred. On Wed, May 19, 2010 at 7:13 PM, Gokul gok...@gmail.com wrote: Hello, Newbie question. Please bear with me. I understand ST_Line_Locate_Point that returns the location of the closest point on LineString to the given Point as a fraction of the total distance of the LineString, but what is the distance between the Point and the LineString that it considers as 'close' In other words, when does it return zero? (i.e what is the distance at which a point is not close to a line?) Thanks, Gokul. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_Line_Locate_Point - what is the distance at which a point is NOT close to a line?
It returns zero if the closest point on the line to the given point is the start point of the line. It returns one when the closest point on the line to the given point is the end point of the line. David On Wed, May 19, 2010 at 1:13 PM, Gokul gok...@gmail.com wrote: Hello, Newbie question. Please bear with me. I understand ST_Line_Locate_Point that returns the location of the closest point on LineString to the given Point as a fraction of the total distance of the LineString, but what is the distance between the Point and the LineString that it considers as 'close' In other words, when does it return zero? (i.e what is the distance at which a point is not close to a line?) Thanks, Gokul. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- David William Bitner ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS installation error: could not find geos_c.h
Petrus, It looks to us that your --with-geosconfig may be pointing at the source directory instead of your install directory. It should be pointing at wherever you installed the binaries of geos. Where your --prefix was designated during your geos configure step. So if you configured geos with something of the form ./configure --prefix=/root/geos/rel-3.2.2 make make install Then postgis should be ./configure --with-geosconfig=/root/geos/rel-3.2.2/bin/geos-config Also since we wrote that article, geos 3.2.2 has come out, so you should be installing geos 3.2.2 instead of geos 3.2.0. Geos 3.2.2 has bug fixes for Geos 3.2 branch, so will be stabler than the geos 3.2.0 version. Leo and Regina http://www.postgis.us _ From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Peter Cotroneo Sent: Wednesday, May 19, 2010 10:15 AM To: postgis-users@postgis.refractions.net Subject: [postgis-users] PostGIS installation error: could not find geos_c.h Hi, I'm trying to install PostGIS 1.5 on an Amazon EC2 instance running the 64-bit version of Fedora 8. I've installed PostgreSQL 8.4, Proj, GEOS, and libxml. When I try to configure PostGIS, using the following command: ./configure --with-geosconfig=/root/sources/geos/geos-3.2.0/tools/geos-config I get the following error: configure: error: could not find geos_c.h - you may need to specify the directory of a geos-config file using --with-geosconfig Now, I have geos_c.h installed in /root/sources/geos/geos-3.2.0/capi. Can someone please tell me what I'm doing wrong? By the way, I'm following these instructions: http://www.postgresonline.com/journal/index.php?/archives/147-Compiling-Post GIS-1.5-and-installing-after-Yum-PostgreSQL-Install.html Cheers, Petrus ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on GEOMETRY type
Thank you all for the reply. I found several of answers have been thrown out, but I just see them from the summary of yesterday's topic, not get those replies directly. Actually, I didn't get any mail from the list yet, perhaps, it's due that I just joined the list yesterday. So if you reply in this thread, please copy qsu...@gmail.com. The provided methods (SE_IsMeasured() and SE_Is3D() zmflag()) do work on getting the dimension of a given geometry value. Probably, I didn't express myself well. What I really want to know is if there is some meta data to judge the type of the geometry column, not from sampling the data. For example, the POINTM can be used to know the column has 3dm points. But unfortunately, the corresponding GEOMETRYM type isn't provided for the mixed-type column in Postgis1.5. Can you tell me if there is some method to workaround the issue? -cheney On Wed, May 19, 2010 at 10:23 PM, 孙琦 qsu...@gmail.com wrote: Can anyone throw some lights on the question? Thanks, Cheney On Wed, May 19, 2010 at 6:27 PM, 孙琦 qsu...@gmail.com wrote: Hi experts, Do we have a way to resolve the third dimensionality of GEOMETRY data? As known, those single types(POINT, LINESTRING, POLYGON) all have the corresponding XYM versions with suffix M. Thus, if we have three-dimensionality feature, we can discriminate its third dimensionality as Z or M by the returned geometry type. However, if the mixed-typed (GEOMETRY) is used, it seems that it's hard to resolve the 3rd dimensionality. By the Postgis 1.5.1 manual, no GEOMETRYM type is provided to fix the issue. So can someone tell me if there is another way to do the work? Thanks, Cheney ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
