Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#576 closed enhancement (fixed)

3d distance functions

Reported by: nicklas Owned by: nicklas
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: Cc: bitner


We don't have distance functions that can handle third dimmension yet.

I have copied a spike where I have put the first steps.

So far it is only working in the simple cases point-point

The rest is a little bit more tricky.

But it is a start and the line-point and point-point cases should work with all the distance-functions. I have put a suffix on the 3D-versions of the functions as showed below. Is that a good way of naming them?
We have to have special 3D-functions so it is possible to do the 2D-calculation even if the z-value is present.

The new functions are named:


There is no indexes involved and no use of the faster way of calculating distances.

Change History (21)

comment:1 by nicklas, 14 years ago

Owner: changed from pramsey to nicklas
Status: newassigned

comment:2 by robe, 14 years ago


Unless if others have objections I would prefer if you just commit this work to trunk especially since you already have long requested features worth testing.

Kevin, Mark, Paul — any comments or objections?

My thinking is that since this is a major release we shouldn't be as concerned about rocking the trunk boat (as we are with minor and micro) since there is so much in flux anyway. Its better to have more people pouncing on the new features earlier than later and our chances of that are better if it is in trunk.

Thanks, Regina

comment:3 by mcayland, 14 years ago

I haven't taken a look at the code, but I don't have any objection on principal including the changes in 2.0.0. The naming convention seems to match the way that various other functions are going when handling 3D so I can't see it going too far wrong.

comment:4 by bitner, 14 years ago

Cc: bitner added

Further 3D measurements without resorting to using linear referencing to extract closest points etc would be awesome. As to index usage, the 3D distance is always going to be longer than 2D case, so the same BOX2D expansion will still be valid (just less selective). The following should still be valid, no?

CREATE OR REPLACE FUNCTION public.st_dwithin(geometry, geometry, double precision)

RETURNS boolean AS

'SELECT $1 && ST_Expand($2,$3) AND $2 && ST_Expand($1,$3) AND _ST_DWithin3d($1, $2, $3)'


comment:5 by nicklas, 14 years ago

Ok, I will add it to trunk. I think it is quite safe so far. It is almost just a copy of the 2D functions. The iterations through the geometries is the same and for the point-point and point-line it is just about adding the extra dimension in the algoritms.

I have some questions:

  1. Is it ok to keep the 3d-functions in another source-file? If so I would like to also move the length3d functions there. I think it will be a little messy to have it all in measures.c.
  1. As it is now I am not trying to catch when there is no Z-value present but rely on function getPoint3dz_p puts 0.0 for z-value when I retrive the point. Is that secure enough. I see in lwgeom_pointarray_length that there is a check for z-value before getting the point and if no z-value it is sent to 2D-calculation instead. From my understanding the result should be the same as if getPoint3dz_p sets z-value to 0.0 on all points in the geometry.
  1. About the index, I think bitner have to be right that the 2Dindex will do no harm but just be less effective. Should I add that or is there some other ideas.


comment:6 by robe, 13 years ago

1) I'm fine with that - not sure what Paul, Mark and Kevin think of it though. I suppose Paul would be best to make that decision since he has more experience with that section.

  1. again no comment from me
  2. Yes — we can easily swap it out once the 3D index is in place. Speaking of which —

Paul, You've been very quite in this conversation — I recall you saying you started some preliminary work on the 3D index side. Are you actively working on that now — any stumbling blocks etc?

comment:7 by robe, 13 years ago

Getting back to Mark's point about naming — I think the way you have the functions named is fine for now as it follows convention. Though I hate the current convention. I would just like ST_length, ST_Area, ST_DWithin (and upcoming ST_Intersects), to not have 3D and just use the highest dimension of input geometries.

If its necessary to manage a dimension measurement lower than the dimension of the geometry, then we can pass in an optional dimension argument. I just like using the same code for both my 2D and 3 D work, and having to replace with 3D is just annoying and confusing because when I want a length/DWithin and I'm dealing with 3D I want a 3D length/distance.

David Bitner — you work with 3D probably more than the rest of us. What's your opinion on naming?

Nicklas — sorry for this long drawn out diatribe. Can you add in an ST_Intersects(I guess3D for now) and just have it piggy back on your ST_DWithin3D

comment:8 by colivier, 13 years ago

About naming and behaviour in SQL/MM 2009 we have convention like: ST_3DIntersection who care about Z dimension if present (but still work fine in 2D only if no Z) And ST_Intersection who don't care about Z (even if Z is also present).

comment:9 by robe, 13 years ago


Thanks. I guess we should follow the standard as much as we can even though I don't like that aocnvention very much. So does that mean all our functions should be like

ST_3DInterects, ST_3DDistance (instead of ST_Distance3D) ?

comment:10 by nicklas, 13 years ago

If we name them ST_3DDistance and so on, will that cause problem if ST prefix will be removed in the future? Can a function name start with a digit?

Just a thought

comment:11 by nicklas, 13 years ago

I am about to commit this. Should I name them ST_3DDistance style or ST_Distance3D style?


about ST_Intersects3D, is it of any use for just point-linestring and point-point?


comment:12 by colivier, 13 years ago

Hi Nicklas,

+1 for ST_3DDistance as it's SQL/MM fashion.

comment:13 by nicklas, 13 years ago

Great Olivier

Should we rename ST_Length3D too? We have the chance now when it is a new major version, don't we?


comment:14 by bitner, 13 years ago


I prefer explicit 3D naming for functions that use the third dimension. The underlying assumption right now is that all functions are 2D. A lot of people just throw data into their dbs without even knowing that it has a third dimension and they would be thrown quite off guard if all of the sudden they started getting different results. If there is a SQL/MM standard for naming, all the better.


comment:15 by robe, 13 years ago

+1 from me too. Might as well make the others consistent as well like you said Nicklas. It is a new major version after all.

comment:16 by robe, 13 years ago

Yes having st intersect work for linestring point and point point is better than nothing.

comment:17 by nicklas, 13 years ago

The functions I found from a quick scan that could be affected by changing the naming convention is:



— Those functions I think should keep their names because that tells something that they are forced towards 3D, 2D and 4D, not from.

Then their is the internal functions. Since it is a major release maybe the name convention should harmonize with the internal functions?


comment:18 by nicklas, 13 years ago

What I have so far is committed at r5889.

still just supports point-point and point-line

I have not changed name of any old functions

the new functions are:

in reply to:  9 comment:19 by havatv, 13 years ago

Replying to robe:

Thanks. I guess we should follow the standard as much as we can even though I don't like that aocnvention very much. So does that mean all our functions should be like

ST_3DInterects, ST_3DDistance (instead of ST_Distance3D) ?

Since these new functions are not (yet) SQL/MM Spatial functions, I think it would be better to avoid using names that we expect could be used in SQL/MM Spatial in the future. This way we won't have future problems with different parameters or different sequences of parameters in PostGIS and SQL/MM spatial functions with the same name.

I am also still against using the ST_ prefix for functions that are not included in SQL/MM Spatial - it is an unnecessary source of confusion. ST_ should be reserved for SQL/MM Spatial functions, and we should find another prefix for PostGIS functions. But this is probably a lost fight… ;-)

Håvard Tveite

comment:20 by nicklas, 13 years ago

Resolution: fixed
Status: assignedclosed

I think it is time to close this one.

The functions is not properly tested yet but it is better that that problems will cause new tickets. I will also open a new ticket about the renaming of 3D functions.


comment:21 by nicklas, 13 years ago

renaming is in #817

Note: See TracTickets for help on using tickets.