Subject: Re: [geometry] Support for geographic coordinate system
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-11-17 16:32:25
Hi Adam,
Adam Wulkiewicz wrote On 14-11-2014 0:42:
> 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
>>> - radius_type/radius_access
>>> Then various radiuses could be accessed with get_radius<>() and
>>> set_radius<>().
>>>
>>> Eventually there could be optional traits for flattening,
>>> eccentricity, etc. falling into default ones calculating them from
>>> radius values.
>>>
>>> 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
> method of accessing radius. Hence to use get_radius() free function
> instead of requireing radius(), a() and b() member functions. That's all.
OK - agree with that.
> 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
>>> one, only radius.
>>
>> 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 about the naming and namespace.
>
>> 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.
OK (after also seeing your PR), OK to me to store it as common
functionality in detail:: calculate flattening function, instread of
storing it into the reference spheroid.
>
> 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 possible WRT the choosen RadiusType.
>
> 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 the flattening for truncated radiuses would lead to more
> consistent results of algorithms, but that's just a guess.
Right, I don't have yet more precise ideas about this. Your current
approach looks OK to me.
Regards, Barend