Topology: function GetEdgeByPoint($1,$2,$3)

[aperi2007]

I have created a simple function to retrieve the IDEDGE give the Point.

GetEdgeByPoint(topology, geometry::point, tolerance) return integer

tolerance = 0 mean use the Intersection otherwise ST_DWithin().

It return the integer ID if there is an edge on the Point, but if the Point is even a Node it raise an exception.

If there isn't any edge in the Point, GetEdgeByPoint return 0.

If near the point there are two or more edges it throw an exception.

The patch with the code is attach to this ticket.

[aperi2007]

patch for add GetEdgeByPoint

[strk]

Nice to see this coming up. Just a note: ST_Intersects already performs && check, so don't need to do that explicitly.

Do you feel like providing regression test too ? It'd go under topology/test/regress/getEdgeByPoint.sql See wiki for informations about how to do that: http://trac.osgeo.org/postgis/wiki/DevWikiPGRegress

[robe]

Oh and while we are asking for things. A doc patch would be nice too

http://trac.osgeo.org/postgis/wiki/DevWikiDocNewFeature

[aperi2007]

added documentation. I hope is ok. Xml is unknown for me.

[aperi2007]

GetEdgeByPoint documentation

[aperi2007]

Test regress

[aperi2007]

Expected test regress

[aperi2007]

Add the test regress and expected results. The package is complete.

[robe]

Andrea,

This looks good except that you made the mistake of picking up our bad habits and are using antiquated aliasing syntax.

Can you revise:

So instead of:

topology.GetEdgeByPoint(varchar, geometry, float8)

Do topology.GetEdgeByPoint(atopology varchar, apoint geometry, tol1 float8)

and get rid of your alias stuff.

I think Strk started changing some functions, but can't recall which ones now.

Also can you change your "point" in the documentation to "apoint". Ideally the doc arg names should match the functions arg names (just in case people start doing that named parameter calling stuff). Since I've been guilty of breaking this rule, just because i don't like the names of some of the function arguments it feels cruel of me to force it on you.

Strk you have any comments or issues with accepting his patches? — I haven't inspected the function that closely.

[strk]

One issue is I'd always use DWithin rather than switching to use ST_Intersects when tolerance is zero. Is there any reason for the ST_Intersects ?

Other minor issues:

• this should probably not be in a file called 'populate.sql' as it's a query-only function.
• exception messages should all start with Uppercase ("two or more edges found" doesn't).
• "Tollerance" → "Tolerance" (and simpler: "Tolerance must be ≥ 0")

[robe]

I think for the reason that Nicklas had stated that ST_Intersects in theory should be faster, but I haven't done any official tests myself to be sure. We tend to use ST_DWithin for most everything just because for most cases we need a little bit of tolerance (or are working with less than perfect geometries) which we don't get with ST_Intersects.

I would have said before 1.5 that ST_Intersects was most definitely faster, but now that ST_DWithin speed has improved for larger geometries, I'm not so sure.

[strk]

Maybe for long edges it might be faster, but you have to take into account the conversion to geos too (in the ST_Intersects case) and the ST_Intersects computes full intersection matrix too, which means no early exit ever happens.

Would be interesting to hear Nicklas opinion (but even better: profile data) on the matter

[nicklas]

Hallo

I don't know the ST_Intersects algorithm but the problem for ST_Dwithin is that the faster way of doing it in 1.5 will not be used in the cases where the bounding-boxes intersect. In the case of using ST_DWithin as a intersection test the faster algorithm will never get used because the cases with no intersecting bounding boxes will be sorted away already by the index.

So, until Paul implements his indexing of vertexes in distance/intersection presented

here ​http://postgis.refractions.net/pipermail/postgis-devel/2009-December/007710.html

and here ​http://blog.cleverelephant.ca/2009/11/is-good-enough-good-enough.html

until then, I am afraid we will have to live with the brute force way of doing the calculation for ST_DWithin(geoemtry, 0)

But what I enhanced in 1.5 was also that I put in a lot of more "Is the answer already given" tests, which might give quite a lot better performance in those cases. Before 1.5 this was only tested once per interior ring.

strk, do you have insight in ST_Intersects algorithm?

Regards Nicklas

[aperi2007]

hi Robe, if is ok. I will use a new file named <function>_code.sql for declaring each of these two functions instead of apply directly into the populate.sql file ?

for example: GetEdgeByPoint will have these 4 files

GetEdgeByPoint_code.sql (the function definition) GetEdgeByPoint.xml (the doc) GetEdgeByPoint.sql (the regress test) GetEdgeByPoint_expected (the results expected)

[robe]

Yah that would be fine with me.

[aperi2007]

getedgebypoint pack

[aperi2007]

I have add to this ticket the pack for GetEdgeByPoint as asked.

​https://trac.osgeo.org/postgis/attachment/ticket/791/getedgebypoint.zip

[strk]

Code and regress test in r6865 @robe would you take care of the documentation, which comes in a nice external .xml ?

[robe]

sure

[robe]

documentation completed at r6869.

The errors are very cute but grammatically incorrect I think.

ERROR: Two or more edges founded

I guess we should fix them. Same issue with the GetNodeByPoint. I'll put that in as a separate ticket.

Also I redid the examples with the sample data I had. Andrea, in future for the examples, please also include the output of the query.