Boost logo

Geometry :

Subject: Re: [geometry] Support for geographic coordinate system
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-11-13 16:27:55

Hi Adam,

Thanks for your new proposal!

Adam Wulkiewicz wrote On 12-11-2014 1:48:
> Hi,
> Barend Gehrels wrote:
>> Adam Wulkiewicz wrote On 7-11-2014 0:00:
>>> vincenty<EllipsoidModel> s(EllipsoidModel())
>>> andoyer<EllipsoidModel> s(EllipsoidModel())
>>> haversine<SphereModel> s(SphereModel())
>>> // or rather
>>> haversine<SphereModelOrRadius> s(SphereModel())
>>> // for backward compatibility
>>> , e.g.:
>>> typedef strategy::ellipsoid<double> ellipsoid;
>>> strategy::vincenty<ellipsoid> s(ellipsoid(a, b));
> <snip>
>> Sure, the first version looks much better. And ellipsoid follows the
>> Ellipsoid Concept (or how it will be called)
>>> We could then pass a Sphere model to the haversine<> and handle it
>>> differently than raw radius (as mentioned above).
>> Sure.
> 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

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.

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

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?

Regards, Barend

Geometry list run by mateusz at