Boost logo

Geometry :

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::spheroid<> (I really do prefer this compared to



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]

Geometry list run by mateusz at