Geometry Boost List: Re: [geometry] Support for geographic coordinate system

Subject: Re: [geometry] Support for geographic coordinate system
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
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
>> - 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.
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.

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.

Regards,
Adam