Geometry Boost List: Re: [geometry] Negative distance?

Subject: Re: [geometry] Negative distance?
From: Volker Schöch (vschoech_at_[hidden])
Date: 2012-03-12 11:18:21

Hi Barend,
Thank you for your thorough reply.

> It will be an already-solved bug, I think. Version 1.48 contained an uninitialized variable in the case of an empty multi-polygon (empty vector) compared to a point. Might that have been the case?

No. I could reproduce the uninitialized variable problem as described. However, we have a convention to return "infinite" distance, e.g., boost::numeric::bounds<distance_result_type>::highest(), for empty shapes. Therefore in our code, the multi-polygon is checked for emptyness (empty vector) first, and if it is empty, boost::geometry::distance doesn't get called.

Unfortunately, the problem only happened once until now and I did not have a chance to collect the data. I added trace code now so that I will probably be able to provide you with a reproduction soon.

While examining the problem, I also tested for a multi-polygon that contains a single polygon which in turn is empty (empty vectors). This case does not seem to have the uninitialized variable issue, and returns a distance of 0, suggesting that the point is inside the polygon. Not tolerable IMO. The treatment should be the same in both cases (multi-polygon with empty vector or polygon empty vector). Again, I tested with boost 1.48.0, my polygon type is oriented counter-clockwise and not closed, my point type is based on int. I apologize for not having updated to 1.49.0 yet, but if the behavior has been fixed there, I will probably update soon.

> This might change in future versions where we will either return a boost-optional, or an error code, or an exception, probably on request.

As mentioned above, I'd prefer to have "highest" returned. It does not have to be a dedicated magic value, just "very big" ("infinite").

> What has been discussed is that there are wishes to measure the "internal distance" too, so for a point inside a polygon the distance to the border. I believe it has been suggested to make that distance negative (makes sense) but it has not been implemented like that. It is probably better to make that a separate function, or it is also possible to implement that as a strategy property. To be decided.

FWIW, I'd vote for a separate function, mostly because the general consensus about a "difference" function is very strong. I haven't tried, but canonically wouldn't inverting the polygon and taking the distance of that do the trick? It may still be nice to have a dedicated function as a shorthand, but the result (and efficiency) had better be the same.

Regards
   Volker

--
Volker Schöch | vschoech_at_[hidden]
Senior Software Engineer
think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany
http://www.think-cell.com | phone [phone] | US phone [phone]
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl