Just a non Boost specific observation with regard to the problem alluded to here regarding calculations on paths crossing the meridian, when using polar co-ordinates. I worked for a while for a company who did marine navigation aids. A lot of the internal processing was done using cartesian co-ordinates and not polar co-ordinates - the results were converted back to polar for display. This makes crossing the meridian a non-issue as there isn't one. We referred to the axes as g, i and n, where n was through the north pole, g was where the Greenwich meridian crosses the equator, and i was 90 degrees from that. I was advised that those were the axes used by GPS, though it may be that the names g,i,n were a usage specific to that company. Great circle routes were represented as "unit vectors" calculated using the cross product of the start and end co-ordinates. The earth was assumed to be spherical, with radius = 1, for that usage. Just thought I'd mention this in case it's of any use. Regards, Richard. Richard Kerry BNCS Engineer T: +44 (0)20 82259063 M: +44 (0)7812 325518 Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ richard.kerry@atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=mailto%3arichard.kerry%40atos.net> uk.atos.net<https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb99344d708709a3177&URL=http%3a%2f%2fuk.atos.net%2fen-uk%2f> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable ________________________________ From: Boost-users [boost-users-bounces@lists.boost.org] on behalf of Barend Gehrels [barend@xs4all.nl] Sent: 28 February 2013 17:29 To: boost-users@lists.boost.org Subject: Re: [Boost-users] [geometry] getting overlay_invalid_input_exception thrown from union operation

I am seeing a overlay_invalid_input_exception thrown from has_self_intersections when calling the union() operation. Does indicate an internal error, or have I not conditioned my input properly? My test is, taking the TIGER 2010 counties file for Alaska, and repeatedly calling union() on the polygons. There may be some issues that I can think of: 1) Island chains are represented as one big multi-ring polygon in the source shape file. When I convert to boost polygon, I set the first ring as the outer, and all others as inners.

You probably mean Boost.Geometry? For the rest, this might be erroneous. All islands should be separate outer rings in a multi polygon, if I understand you well.

2) Aleutians cross the 180-meridian. I am, however, taking steps to force all latitudes into the negative range, but that logic may need to be checked.

OK. If you encounter the problem after checking: 1: recheck your logic 2: get the wkt of the failing input 3: check this wkt 4: if you think the polygon is valid, so Boost.Geometry is incorrect, please report this and include the wkt in your report. besides this, if you are really going to buffer all these Alaska counties, that is a challenge for the not released code. You will find bugs or inexpected behaviour. Reports of these are welcome too. Please also then include the Wkt and buffer properties. Regards, Barend _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users