3d distance functions

[nicklas]

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

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

 http://svn.osgeo.org/postgis/spike/nicklas/dist3d/

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

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:

ST_Distance3d
ST_MaxDistance3d
ST_ClosestPoint3d
ST_Shortestline3d
ST_Longestline3d
ST_Dwithin3d
ST_DFullywithin3d

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

[robe]

Nicklas,

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

[mcayland]

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.

[bitner]

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)'

LANGUAGE 'sql' IMMUTABLE COST 100;

[nicklas]

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.

2. 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.

3. 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.

/Nickla

[robe]

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.

2. again no comment from me 3. 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?

[robe]

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

[colivier]

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).

[robe]

Olivier,

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) ?

[nicklas]

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

[nicklas]

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

Regina

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

/Nicklas

[colivier]

Hi Nicklas,

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

[nicklas]

Great Olivier

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

/Nicklas

[bitner]

Regina,

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.

David

[robe]

+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.

[robe]

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

[nicklas]

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

length3d
ST_length3d
length3d_spheroid
ST_length3d_spheroid
perimeter3d
ST_perimeter3d
MakeBox?3d
ST_MakeBox3d
Extent3d
ST_Extent3d
st_box3d
st_box3d_extent
box3d

length2d
ST_length2d
length2d_spheroid
ST_length2d_spheroid
perimeter2d
ST_perimeter2d
area2d
ST_area2d
MakeBox?2d
ST_MakeBox2d
st_box2d
st_box2d
box2d

-- Those functions I think should keep their names because that tells something that they are forced towards 3D, 2D and 4D, not from.
force_2d
ST_force_2d
force_3dz
ST_force_3dz
force_3d
ST_force_3d
force_3dm
ST_force_3dm
force_4d
ST_force_4d

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

/Nicklas

[nicklas]

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:
ST_3dDistance
ST_3dMaxDistance
ST_3dClosestPoint
ST_3dShortestline
ST_3dLongestline
ST_3dDwithin
ST_3dDFullywithin
ST_3DIntersects

[havatv]

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

[nicklas]

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.

/Nicklas

[nicklas]

renaming is in #817