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

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