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

Subject: Re: [geometry] Negative distance?
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-03-12 14:13:42

Hi Volker,

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

OK, in that case it is not fixed and will still be there in 1.49. So 
your report is most welcome...

> 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 has been fixed in 1.49 (now throws on any empty input).

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

That is an interesting option we did not discuss until now. It makes 
sense but I don't know if everybody will agree about this... But if the 
empty-return is configurable, it could of course be one of the 
configurations.

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

In this case, no (did not try but it is not orientation-sensitive so it 
will not 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.

OK, I agree.

Regards, Barend