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

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