# Geometry :

Subject: Re: [geometry] Support for geographic coordinate system
Date: 2014-11-13 18:42:58

Hi Barend,

Barend Gehrels wrote:
> Adam Wulkiewicz wrote On 12-11-2014 1:48:
>>
>> 1. The concept
>>
>> I propose to use a part of already existing nsphere concept for this:
>> - tag
>>
>> Eventually there could be optional traits for flattening,
>> eccentricity, etc. falling into default ones calculating them from
>>
>> Btw, for a (n)sphere I think get_radius<>() should be able to return
>> the same radius for all dimension, not only for <0>.
>> This would be in-line with the spheroids and ellipsoids. This way
>> it'd be possible to use spheres in algorithms working for spheroids.
>> And this also means that for spheroid radius for <0> and <1> should
>> be equal and could be different for <2>.
>
> Hmm, while it is always good to reuse concepts/code if possible, I
> think the common code here is quite small... Basically you propose to
> reuse radius (one floating point value). The sphere-center, which has
> nsphere, is not relevant. All algorithms (to be) supported by nsphere
> (distance of n-sphere to other geometries, etc etc) are all not
> relevant...
>
> So I'm not really sure if this is a good idea - it will support things
> not meant to be supported, and will need other things not necessary
> for nspheres...
>
> But basically - something like nsphere would be OK of course. And if
> users want to implement one nsphere type implementing both Concept's,
> that should be possible.
>

What I had in mind is it's more elegant and consistent to use the same
Plus we need some tag for dispatching (different than nsphere_tag).

>
>>
>> 2. The names
>>
>> Since BG is a general-purpose library we should probably be
>> mathematically correct. I know that it's common to call the reference
>> Earth shape an ellipsoid in a GIS world but this is a spheroid since
>> it has two equal radius values. So I propose to have a Sphere and
>> Spheroid or rather ReferenceSphere and ReferenceSpheroid concept
>> because... see 3.
>
> Yes, you are right. It is a spheroid. Let's call it a spheroid then
> indeed.
>
>>
>> 3. The placing/namespace
>>
>> One problem I see is a collision of Geometries models and those
>> Parametric/Reference models. E.g. nsphere Geometry model has a
>> position but sphere/spheroid Parametric/Reference model doesn't have
>
> Yep ;-)
>
>> This might be confusing for the users so I'm thinking about picking
>> some namespace for those models (to not place them in the main
>> namespace bg or bg::model). Something like bg::parameters or
>> bg::reference. Then:
>>
>> bg::reference::sphere<>
>> bg::reference::spheroid<>
>>
>> Or something like that, e.g. shorter.
>> And then the tags could be:
>>
>> reference_spheroid_tag
>> reference_sphere_tag : reference_spheroid_tag
>>
>> And in the future if we e.g. had model::sphere and Sphere concept,
>> sphere_tag could be derived from reference_sphere_tag and used as a
>> ReferenceSphere too.
>
> This looks all OK to me. Explicitly adding reference makes it quite
> clear - we reserve a model::sphere for later then too.
> So this is then the ReferenceSphere Concept.
>
>
>>
>> 4. Alternative 2&3
>>
>> They could also be named e.g. sphere_xxx and spheroid_xxx (xxx is
>> some word, e.g. params) or reference_sphere/reference_spheroid and
>> placed in the main namespace bg.
>
> Sorry it is not completely clear to me what you mean here, params?
>

Quite simple thing actually, sorry for not being too specific. An
alternative to putting the reference sphere and spheroid in the
bg::reference namespace could be naming them sphere_params<> (storing a
radius) and spheroid_params<> (storing a and b) or reference_sphere<>
and reference_spheroid<> and put them in the namesapce bg. It's just

> So you agree that all this reference-spheroid will be common to both
> distance calculations and geographic projections, and support setting
> its parameters in various ways?

Yes, currently in the case of reference::spheroid<> I'm thinking about
storing only A and B radius values. It's because this would be
conceptually simpler if we consider various RadiusTypes, also integral
ones. As I said before, flattening should be of floating-point type or a
fraction<>, etc. Furthermore it's probably not needed to store the
flattening because relatively to various calculations for geographic CS
(many trigonometric function calls) calculating the flattening is very
simple. So in this case, the algorithm/strategy would pick the most
suitable way of calculating things. E.g. flattening could be stored as
fraction<> or during the calculation (A-B) could be multiplied and then
at the end the result divided by A or flattegning could be stored using
a FP-type generated by promotion of RadiusType to the FP type of similar
size, etc. But the decision would depend on algorithm/strategy.

And yes, it should be possible to initialize the sphere/spheroid radius
values in run-time in various ways. E.g. we could support Proj4
parameters syntax. AFAIU it allows to define radiuses, flattening,
eccentricity as doubles so we'd just initialize the radiuses as well as

Or would you prefer to store as many parameters as possible and just
calculate the rest the best we can? In case of e.g. using integral
radiuses this would be more precise since the flattening wouldn't be
calculated from radiuses (which values would be truncated during
initialization) but passed by the user. In this case we should think
about requirements for types of flattening , eccentricity, squared
eccentricity, etc. However FP/precise flattening could be not compatible
with the truncated values of radius. So it's possible that recalculating