I second Ted's argument. The reason on http://forums.mysql.com/read.php?23,148162,152625#msg-152625 is very weak, since following that logic there will be no 100% lines or rectangles on the surface of the earth. But these shapes are very useful.
I am sure there are use cases for circles, such as the Apple's new headquarters. A related question is: what's the overhead of implementing and maintaining this type? Chen On Fri, Aug 7, 2015 at 2:04 PM, Ted Dunning <[email protected]> wrote: > There you go. > > Another application. > > > > On Fri, Aug 7, 2015 at 1:43 PM, Mike Carey <[email protected]> wrote: > >> AND: What if NASA wants to use us to store its database of crop circles? >> :-) >> >> On 8/7/15 11:47 AM, Ted Dunning wrote: >> >>> On Fri, Aug 7, 2015 at 3:23 AM, Chris Hillery <[email protected]> >>> wrote: >>> >>> I've noticed that several geospatial serialization formats (at least >>>> "well-known text" and GeoJSON) omit "circle" from their list of basic >>>> geometric forms, even when they have numerous more complex types such as >>>> multi-curves. This led me to here: >>>> http://forums.mysql.com/read.php?23,148162,152625#msg-152625 >>>> >>>> which offers a reasonably compelling argument for why "circle" is not a >>>> reasonable shape to discuss in geospatial contexts (loosely, because >>>> there's no consistent way to map that to a spherical coordinate system). >>>> >>>> Actually, that argument is super-weak. It also implies that you >>> shouldn't >>> have lines (they aren't straight after projection) or squares (they aren't >>> square after projection). But lines and squares both before and after >>> projection are very handy. >>> >>> Circles are useful in many contexts. Drawing the visible horizon for a >>> particular observer is a great example. The flight range of an airplane >>> is >>> another case. Positional error bounds with Gaussian errors is another. >>> >>> Yes. You can approximate it using splines or polygons. But you can >>> approximate anything that way. >>> >>> >>
