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

Subject: Re: [geometry] Support for geographic coordinate system
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2014-11-14 03:13:48

Hi Adam, hi Barend.

On 14/11/2014 01:42 πμ, Adam Wulkiewicz wrote:
> 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.
>>

I have to admit I do not particularly like the name reference for the 
reference system, as it very much reminds me of references in C++. I 
would prefer something like
bg::reference_system::sphere<>
bg::reference_system::spheroid<> (I really do prefer this compared to 
ellipsoid)

or

bg::geography_model::sphere<>
bg::geography_model::spheroid<>

Similarly for the tags. Among the two options I mention above I prefer 
the second, but can happily live with the first.

- m.

>>
>>>
>>> 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.
>

I would start with the minimal approach: store A and B and compute 
everything else from them (for now).
Then, as we use them, we can see if things need to get changed/updated.

I also think  that within the namespace we are going to choose for 
reference systems we should also have pre-specified geography 
models/reference systems, such as WGS84, GRS80, etc.

- m.

> Regards,
> Adam
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry