(if that is what it is) formed by an irregularly elevated boundary. So
them in generality. For that we need the real stuff, Surfaces,
requirement". We need a 4D index. That will allow us to handle things
> I'm not sure how low hanging the fruit :), but first off would be being able
> to do intersections and indexable ST_DWithin with 3D polygons and
> linestrings and so forth. For example when I place a cable up on a roof I
> need to know if I'm hitting another piece of equipment.
>
> Higher fruit - being able to support volumetric geometries. Right now we
> support 2d-3D polygons and lines and you can form wireframes with those, but
> no true volumetric stuff. But then what do I know, I'm just parroting
> things I've heard in whispers and those whispers are getting louder is all
> :)
>
> There is still the issue of being able to display 3-D geometries without
> spending a fortune on proprietary stuff which is not a PostGIS issue, but
> has to gain in momentum to make PostGIS 3D more powerful (e.g. uDig for 3D
> or OpenJump for 3D or OpenLayers for 3D?)
>
> Thanks,
> Regina
> ________________________________
> From:
postgis-devel-bounces@... on behalf of Paul Ramsey
> Sent: Tue 10/7/2008 12:30 PM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Dropped DM (Time) dimension with intersections
>
> Perhaps elabourate on what better 3D support would be? There's the
> surface object hanging around. There's the issue of maintaining higher
> dimensional coordinates through lower dimensional transforms (which
> you saw the result of a few days ago). There's elabourating the
> complete set of 3D objects and relationships (gulp).
>
> It's not clear to me what is the "low hanging fruit" that will make 3D
> users happiest in the shortest time.
>
> P.
>
> On Tue, Oct 7, 2008 at 8:54 AM, Obe, Regina <
robe.dnd@...>
> wrote:
>> Margie,
>>
>> Unfortunately I think the answer is no. Most of the work going on in 1.4
>> is
>> to improve speed of existing functionality and reorganize the source to
>> make
>> it more maintainable.
>>
>> Someone please correct me if I am wrong.
>>
>> I for one would be very elated if we had better 3D support since CityGML
>> and
>> similar initiatives are becoming more of a hot topic around here.
>>
>> Thanks,
>> Regina
>> ________________________________
>> From:
postgis-devel-bounces@...
>> [mailto:
postgis-devel-bounces@...] On Behalf Of
>> Huntington, Margaret (US SSA)
>> Sent: Tuesday, October 07, 2008 11:47 AM
>> To:
postgis-devel@...
>> Subject: [postgis-devel] Dropped DM (Time) dimension with intersections
>>
>> Hello,
>>
>> Currently I'm using PostGIS 1.3.3. From past discussions and from
>> testing, both the st_intersection st_extend methods return 2D results with
>> 4D input geometries. As a temporary work-around, I had hoped
>> st_intersection might work with 3DM geometries. (Plan was to interpolate
>> the altitude value within the function call if PostGIS could calculate the
>> time dimension). I found time components are also dropped by
>> st_intersection with 3DM geometries. I abandoned usage of 4D bounding
>> boxes
>> since these too effectively degrade 4D geometries down to 2D geometries
>> (altitude and time are zeroed out).
>>
>> polyGeometry geometry;
>>
>> bbGeometry geometry;
>>
>> intersectionGeometry geometry;
>>
>> coorddims smallint;
>>
>> -- both polygon and linestring have an expected zmflag value of
>> 1
>>
>> polyGeometry := 'SRID=4326;POLYGONM((0 0 0, 0 10 4, 10 10 4, 10
>> 0
>> 0, 0 0 0))'::geometry;
>>
>> bbGeometry := 'SRID=4326;LINESTRINGM(0 0 1.5, 10 10
>> 2)'::geometry;
>>
>> intersectionGeometry := st_intersection(polyGeometry,
>> bbGeometry);
>>
>> -- st_intersection method drops the time dimension; zmflag
>> value
>> of 0
>>
>> coorddims := st_zmflag(intersectionGeometry);
>>
>> If I were to download the subversion snapshot, the current 1.4 version,
>> might st_intersection work with either 3DM or 4D geometries? Are bounding
>> boxed or st_extend improved for either 3DM or 4D geometries? I had
>> incorporated polygons only as a possible work-around to the bounding box
>> and
>> st_extend 2D limitations.
>>
>> Margie
>>
>> ________________________________
>>
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure pursuant to
>> Massachusetts law. It is intended solely for the addressee. If you
>> received
>> this in error, please contact the sender and delete the material from any
>> computer.
>>
>> ________________________________
>>
>> Help make the earth a greener place. If at all possible resist printing
>> this
>> email and join us in saving paper.
>>
>> _______________________________________________
>> postgis-devel mailing list
>>
postgis-devel@...
>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel>>
>>
> _______________________________________________
> postgis-devel mailing list
>
postgis-devel@...
>
http://postgis.refractions.net/mailman/listinfo/postgis-devel>
> ________________________________
>
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure pursuant to
> Massachusetts law. It is intended solely for the addressee. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> ________________________________
>
> Help make the earth a greener place. If at all possible resist printing this
> email and join us in saving paper.
>
> _______________________________________________
> postgis-devel mailing list
>
postgis-devel@...
>
http://postgis.refractions.net/mailman/listinfo/postgis-devel>
>