Support for geographic coordinate system

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Support for geographic coordinate system

Adam Wulkiewicz
Hi,

I'm planning to begin the implementation of the support for geographical
CS and would like to hear your opinion. Esspecially from people already
using the geographical extensions.
Basically, to support this CS we need a distance strategy and side
strategy. They're already implemented (more or less) though in the
extensions so not officially released yet. To release them we need to
think about the interface first. The geographical strategies should have
an interface similar to the one used in spherical strategies. Or the
other way around, spherical strategies interface could be extended
somehow to match the geographical version. In all cases the strategies
should be backward compatible. Currently we have:

CARTESIAN:

- cartesian side has no ctor

side_by_triangle<> s;

- cartesian distance has no ctor

pythagoras<> s;

SPHERICAL:

- spherical side has no ctor since it doesn't need to know the radius

spherical_side_formula<> s;

- spherical distance (haversine) requires a radius of type passed to the
strategy as template parameter, and by default radius = 1.0 is used
(unit sphere)

haversine<RadiusType> s(radius);
haversine<RadiusType> s; // radius = 1.0 by default

so to calculate the distance on a sphere the user can pass a strategy
with radius or use the default one and multiply the result by the radius:

distance(p1, p2, haversine<RadiusType>(radius));
distance(p1, p2) * radius;

GEOGRAPHICAL:

- a spherical side strategy is just used by default which I guess should
be changed. I think the most precise would be a strategy finding the
side using the geographic courses found using the inverse Vincenty's
formula but this requires some testing
- for distance there are 2 strategies, both taking
detail::ellipsoid<RadiusType>, andoyer also has a ctor taking a
flattening of type RadiusType (like detail::ellipsoid<>). If 1 parameter
is passed (flattening) then the radius is set to 1.0 but if 2 parameters
are passed then A and B radiuses are set. Furthermore by default Earth's
radiuses are used. So the situation looks like this:

vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
6378137.0, B = 6356752.314245
vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(f)); // A = 1.0, B
= [some fraction for oblate spheroid]
vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(a, b)); // A = a, B = b
andoyer<RadiusType> s; // A = 6378137.0, B = 6356752.314245
andoyer<RadiusType> s(f); // A = 1.0, B = [some fraction for oblate
spheroid]

It's confusing (this 1 and 2 paramers difference) and inconsistent with
spherical strategies.
Furthermore flattening should be stored using some Floating Point type
and currently it's just RadiusType. E.g. for integral RadiusType the
default ctor would initialize flattening with 0.

PROPOSAL:

1. I propose to keep it simple for now, don't release detail::ellipsoid
and change the default parameters to make the strategies close to the
spherical ones:

vincenty<RadiusType> s(); // A = 1.0, B = [fraction], F=
[fraction,default] - unit WGS84 spheroid
vincenty<RadiusType> s(a); // A = a, B = [calculated from a using
default flattening], F= [fraction,default]
vincenty<RadiusType> s(a, b); // A = a, B = b, F= [calculated from a and b]

This way the calls:

distance(p1, p2, vincenty<RadiusType>(a));
distance(p1, p2) * a;

would be equivalent (assuming that RadiusType is not integral type?).

By default FlatteningType would be:
- for floating point RadiusType <=> RadiusType
- for integral RadiusType <=> promoted to FP of the same size (int->
float, long long-> double)
- for user defined types <=> UDT
The FlatteningType could be optionally passed as a second template
parameter of a strategy however I'm not sure about it since it wouldn't
play nice with possible future improvement 3 (see below).

ALTERNATIVES (FUTURE ADDITIONS)

2. To decrease the probability of a mistake the strategy could take
wrapped parameters (only?). This way it'd also be possible to create an
ellipsoid from A,B A,F or B,F pair:

// below are functions returning wrapped values
vincenty<RadiusType> s(major_radius(a), minor_radius(b));
vincenty<RadiusType> s(major_radius(a), flattening(f));
vincenty<RadiusType> s(minor_radius(b), inverse_flattening(if));

3. Desing concepts for models parameters. And then always pass a type
adapted to model's parameters concept to the strategy, instead of
RadiusType. Actually a single number could be adapted to e.g. sphere
parameters concept (radius) but why reserve it specifically for sphere?

haversine< parameters::sphere<RadiusType> >
s(parameters::sphere<RadiusType>(radius));
vincenty< parameters::ellipsoid<RadiusType> >
s(parameters::ellipsoid<RadiusType>(a, b));
vincenty< parameters::ellipsoid_af<RadiusType> >
s(parameters::ellipsoid_af<RadiusType>(a, f));
vincenty< parameters::ellipsoid_unit_flattening<RadiusType> >
s(parameters::ellipsoid_unit_flattening<RadiusType>(f));
vincenty< parameters::ellipsoid_wgs84_1996<RadiusType> >
s(parameters::ellipsoid_wgs84_1996<RadiusType>());
vincenty< parameters::ellipsoid_wgs84_2004<RadiusType> >
s(parameters::ellipsoid_wgs84_2004<RadiusType>());
vincenty< parameters::ellipsoid_latest<RadiusType> >
s(parameters::ellipsoid_latest<RadiusType>());

FYI, all names of namespaces, structs and functions are examples.

For sphere we'd already have a small problem with this. However this
could be implemented in a backward compatible way. But then it could be
done this way in the future, for both coordinate systems.

4. 2 and 3 together:

vincenty< parameters::ellipsoid<RadiusType> >
s(parameters::ellipsoid<RadiusType>(major_radius(a), minor_radius(b)));

Do you have any thoughts or requests regarding the above?

Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Krzysztof Czainski
2014-11-06 17:06 GMT+01:00 Adam Wulkiewicz <[hidden email]>:
Hi,

I'm planning to begin the implementation of the support for geographical CS and would like to hear your opinion.

Hi Adam,

I just wanted to say that I'm glad you're working on this. I used the geographical projections from extensions in a project I finished a year ego. The project used a Boost release 1.54.0 (I think) with a snapshot of Boost.Geometry from svn trunk up front in include dirs list. To unit-test our use of the projections, we generated some test data in Matlab, and the tests confirmed accurate results of projections.
 
Esspecially from people already using the geographical extensions.
Basically, to support this CS we need a distance strategy and side strategy. They're already implemented (more or less) though in the extensions so not officially released yet. To release them we need to think about the interface first. The geographical strategies should have an interface similar to the one used in spherical strategies. Or the other way around, spherical strategies interface could be extended somehow to match the geographical version. In all cases the strategies should be backward compatible. Currently we have:

CARTESIAN:

- cartesian side has no ctor

side_by_triangle<> s;

- cartesian distance has no ctor

pythagoras<> s;

SPHERICAL:

- spherical side has no ctor since it doesn't need to know the radius

spherical_side_formula<> s;

- spherical distance (haversine) requires a radius of type passed to the strategy as template parameter, and by default radius = 1.0 is used (unit sphere)

haversine<RadiusType> s(radius);
haversine<RadiusType> s; // radius = 1.0 by default

so to calculate the distance on a sphere the user can pass a strategy with radius or use the default one and multiply the result by the radius:

distance(p1, p2, haversine<RadiusType>(radius));
distance(p1, p2) * radius;

GEOGRAPHICAL:

- a spherical side strategy is just used by default which I guess should be changed. I think the most precise would be a strategy finding the side using the geographic courses found using the inverse Vincenty's formula but this requires some testing
- for distance there are 2 strategies, both taking detail::ellipsoid<RadiusType>, andoyer also has a ctor taking a flattening of type RadiusType (like detail::ellipsoid<>). If 1 parameter is passed (flattening) then the radius is set to 1.0 but if 2 parameters are passed then A and B radiuses are set. Furthermore by default Earth's radiuses are used. So the situation looks like this:

vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A = 6378137.0, B = 6356752.314245
vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(f)); // A = 1.0, B = [some fraction for oblate spheroid]
vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(a, b)); // A = a, B = b
andoyer<RadiusType> s; // A = 6378137.0, B = 6356752.314245
andoyer<RadiusType> s(f); // A = 1.0, B = [some fraction for oblate spheroid]

It's confusing (this 1 and 2 paramers difference) and inconsistent with spherical strategies.
Furthermore flattening should be stored using some Floating Point type and currently it's just RadiusType. E.g. for integral RadiusType the default ctor would initialize flattening with 0.

PROPOSAL:

1. I propose to keep it simple for now, don't release detail::ellipsoid and change the default parameters to make the strategies close to the spherical ones:

vincenty<RadiusType> s(); // A = 1.0, B = [fraction], F= [fraction,default] - unit WGS84 spheroid
vincenty<RadiusType> s(a); // A = a, B = [calculated from a using default flattening], F= [fraction,default]
vincenty<RadiusType> s(a, b); // A = a, B = b, F= [calculated from a and b]

This way the calls:

distance(p1, p2, vincenty<RadiusType>(a));
distance(p1, p2) * a;

would be equivalent (assuming that RadiusType is not integral type?).

If I recall correctly, we didn't use the distance algorithm in the end. But at some prototyping stage we used distance(p1, p2, vincenty<RadiusType>()), expecting the distance on Earth. You're proposed change would break this expectation, but I don't think this is a problem.
 

By default FlatteningType would be:
- for floating point RadiusType <=> RadiusType
- for integral RadiusType <=> promoted to FP of the same size (int-> float, long long-> double)
- for user defined types <=> UDT
The FlatteningType could be optionally passed as a second template parameter of a strategy however I'm not sure about it since it wouldn't play nice with possible future improvement 3 (see below).

ALTERNATIVES (FUTURE ADDITIONS)

2. To decrease the probability of a mistake the strategy could take wrapped parameters (only?). This way it'd also be possible to create an ellipsoid from A,B A,F or B,F pair:

// below are functions returning wrapped values
vincenty<RadiusType> s(major_radius(a), minor_radius(b));
vincenty<RadiusType> s(major_radius(a), flattening(f));
vincenty<RadiusType> s(minor_radius(b), inverse_flattening(if));

3. Desing concepts for models parameters. And then always pass a type adapted to model's parameters concept to the strategy, instead of RadiusType. Actually a single number could be adapted to e.g. sphere parameters concept (radius) but why reserve it specifically for sphere?

haversine< parameters::sphere<RadiusType> > s(parameters::sphere<RadiusType>(radius));
vincenty< parameters::ellipsoid<RadiusType> > s(parameters::ellipsoid<RadiusType>(a, b));
vincenty< parameters::ellipsoid_af<RadiusType> > s(parameters::ellipsoid_af<RadiusType>(a, f));
vincenty< parameters::ellipsoid_unit_flattening<RadiusType> > s(parameters::ellipsoid_unit_flattening<RadiusType>(f));
vincenty< parameters::ellipsoid_wgs84_1996<RadiusType> > s(parameters::ellipsoid_wgs84_1996<RadiusType>());
vincenty< parameters::ellipsoid_wgs84_2004<RadiusType> > s(parameters::ellipsoid_wgs84_2004<RadiusType>());
vincenty< parameters::ellipsoid_latest<RadiusType> > s(parameters::ellipsoid_latest<RadiusType>());

FYI, all names of namespaces, structs and functions are examples.

For sphere we'd already have a small problem with this. However this could be implemented in a backward compatible way. But then it could be done this way in the future, for both coordinate systems.

4. 2 and 3 together:

vincenty< parameters::ellipsoid<RadiusType> > s(parameters::ellipsoid<RadiusType>(major_radius(a), minor_radius(b)));

Do you have any thoughts or requests regarding the above?

Thanks for a wonderful Geometry library and keep improving it!
Kris 

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Millman, Mark
In reply to this post by Adam Wulkiewicz
While it's fair to be concerned about interdependence between projects there is the well supported Geospatial Data Abstraction Library (GDAL) and specifically the OGRSpatialReference class -- http://www.gdal.org/classOGRSpatialReference.html

These are well established projects widely used within the Open Source Geospatial developer community, written in C++ (and some C).

On Thu, Nov 6, 2014 at 8:06 AM, Adam Wulkiewicz <[hidden email]> wrote:
Hi,

I'm planning to begin the implementation of the support for geographical CS and would like to hear your opinion. Esspecially from people already using the geographical extensions.
Basically, to support this CS we need a distance strategy and side strategy. They're already implemented (more or less) though in the extensions so not officially released yet. To release them we need to think about the interface first. The geographical strategies should have an interface similar to the one used in spherical strategies. Or the other way around, spherical strategies interface could be extended somehow to match the geographical version. In all cases the strategies should be backward compatible. Currently we have:

CARTESIAN:

- cartesian side has no ctor

side_by_triangle<> s;

- cartesian distance has no ctor

pythagoras<> s;

SPHERICAL:

- spherical side has no ctor since it doesn't need to know the radius

spherical_side_formula<> s;

- spherical distance (haversine) requires a radius of type passed to the strategy as template parameter, and by default radius = 1.0 is used (unit sphere)

haversine<RadiusType> s(radius);
haversine<RadiusType> s; // radius = 1.0 by default

so to calculate the distance on a sphere the user can pass a strategy with radius or use the default one and multiply the result by the radius:

distance(p1, p2, haversine<RadiusType>(radius));
distance(p1, p2) * radius;

GEOGRAPHICAL:

- a spherical side strategy is just used by default which I guess should be changed. I think the most precise would be a strategy finding the side using the geographic courses found using the inverse Vincenty's formula but this requires some testing
- for distance there are 2 strategies, both taking detail::ellipsoid<RadiusType>, andoyer also has a ctor taking a flattening of type RadiusType (like detail::ellipsoid<>). If 1 parameter is passed (flattening) then the radius is set to 1.0 but if 2 parameters are passed then A and B radiuses are set. Furthermore by default Earth's radiuses are used. So the situation looks like this:

vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A = 6378137.0, B = 6356752.314245
vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(f)); // A = 1.0, B = [some fraction for oblate spheroid]
vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(a, b)); // A = a, B = b
andoyer<RadiusType> s; // A = 6378137.0, B = 6356752.314245
andoyer<RadiusType> s(f); // A = 1.0, B = [some fraction for oblate spheroid]

It's confusing (this 1 and 2 paramers difference) and inconsistent with spherical strategies.
Furthermore flattening should be stored using some Floating Point type and currently it's just RadiusType. E.g. for integral RadiusType the default ctor would initialize flattening with 0.

PROPOSAL:

1. I propose to keep it simple for now, don't release detail::ellipsoid and change the default parameters to make the strategies close to the spherical ones:

vincenty<RadiusType> s(); // A = 1.0, B = [fraction], F= [fraction,default] - unit WGS84 spheroid
vincenty<RadiusType> s(a); // A = a, B = [calculated from a using default flattening], F= [fraction,default]
vincenty<RadiusType> s(a, b); // A = a, B = b, F= [calculated from a and b]

This way the calls:

distance(p1, p2, vincenty<RadiusType>(a));
distance(p1, p2) * a;

would be equivalent (assuming that RadiusType is not integral type?).

By default FlatteningType would be:
- for floating point RadiusType <=> RadiusType
- for integral RadiusType <=> promoted to FP of the same size (int-> float, long long-> double)
- for user defined types <=> UDT
The FlatteningType could be optionally passed as a second template parameter of a strategy however I'm not sure about it since it wouldn't play nice with possible future improvement 3 (see below).

ALTERNATIVES (FUTURE ADDITIONS)

2. To decrease the probability of a mistake the strategy could take wrapped parameters (only?). This way it'd also be possible to create an ellipsoid from A,B A,F or B,F pair:

// below are functions returning wrapped values
vincenty<RadiusType> s(major_radius(a), minor_radius(b));
vincenty<RadiusType> s(major_radius(a), flattening(f));
vincenty<RadiusType> s(minor_radius(b), inverse_flattening(if));

3. Desing concepts for models parameters. And then always pass a type adapted to model's parameters concept to the strategy, instead of RadiusType. Actually a single number could be adapted to e.g. sphere parameters concept (radius) but why reserve it specifically for sphere?

haversine< parameters::sphere<RadiusType> > s(parameters::sphere<RadiusType>(radius));
vincenty< parameters::ellipsoid<RadiusType> > s(parameters::ellipsoid<RadiusType>(a, b));
vincenty< parameters::ellipsoid_af<RadiusType> > s(parameters::ellipsoid_af<RadiusType>(a, f));
vincenty< parameters::ellipsoid_unit_flattening<RadiusType> > s(parameters::ellipsoid_unit_flattening<RadiusType>(f));
vincenty< parameters::ellipsoid_wgs84_1996<RadiusType> > s(parameters::ellipsoid_wgs84_1996<RadiusType>());
vincenty< parameters::ellipsoid_wgs84_2004<RadiusType> > s(parameters::ellipsoid_wgs84_2004<RadiusType>());
vincenty< parameters::ellipsoid_latest<RadiusType> > s(parameters::ellipsoid_latest<RadiusType>());

FYI, all names of namespaces, structs and functions are examples.

For sphere we'd already have a small problem with this. However this could be implemented in a backward compatible way. But then it could be done this way in the future, for both coordinate systems.

4. 2 and 3 together:

vincenty< parameters::ellipsoid<RadiusType> > s(parameters::ellipsoid<RadiusType>(major_radius(a), minor_radius(b)));

Do you have any thoughts or requests regarding the above?

Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry



--

Mark Millman | Mizar, LLC
[hidden email] | www.mizar.com
(360) 220-3504
9908 Alegria Dr | Las Vegas, NV 89144

 The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
Hi Mark,

Millman, Mark wrote On 6-11-2014 20:10:
> While it's fair to be concerned about interdependence between projects
> there is the well supported Geospatial Data Abstraction Library (GDAL)
> and specifically the OGRSpatialReference class --
> http://www.gdal.org/classOGRSpatialReference.html
>
> These are well established projects widely used within the Open Source
> Geospatial developer community, written in C++ (and some C).

I think everybody knows these libraries.

What do you exactly intend by sending this message?

Regards, Barend

p.s. this list discourages top-postings.


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
In reply to this post by Adam Wulkiewicz
Hi Adam,

Thanks for your proposal!

Adam Wulkiewicz wrote On 6-11-2014 17:06:

> Hi,
>
> I'm planning to begin the implementation of the support for
> geographical CS and would like to hear your opinion. Esspecially from
> people already using the geographical extensions.
> Basically, to support this CS we need a distance strategy and side
> strategy. They're already implemented (more or less) though in the
> extensions so not officially released yet. To release them we need to
> think about the interface first. The geographical strategies should
> have an interface similar to the one used in spherical strategies.

I don't know if that is so important. What is important is that we have
one model or concept of the Earth, used in both distance strategies
(andoyer, vincenty) and in the geographic projections.

That the interface is a bit different than Haversine, I don't know if
that is a problem (maybe, but we can examine that). Or maybe they both
can be implemented with a default constructor.


> Or the other way around, spherical strategies interface could be
> extended somehow to match the geographical version. In all cases the
> strategies should be backward compatible. Currently we have:
>
> CARTESIAN:
>
> - cartesian side has no ctor
>
> side_by_triangle<> s;
>
> - cartesian distance has no ctor
>
> pythagoras<> s;
>
> SPHERICAL:
>
> - spherical side has no ctor since it doesn't need to know the radius
>
> spherical_side_formula<> s;
>
> - spherical distance (haversine) requires a radius of type passed to
> the strategy as template parameter, and by default radius = 1.0 is
> used (unit sphere)
>
> haversine<RadiusType> s(radius);
> haversine<RadiusType> s; // radius = 1.0 by default
>
> so to calculate the distance on a sphere the user can pass a strategy
> with radius or use the default one and multiply the result by the radius:
>
> distance(p1, p2, haversine<RadiusType>(radius));
> distance(p1, p2) * radius;
>
> GEOGRAPHICAL:
>
> - a spherical side strategy is just used by default which I guess
> should be changed. I think the most precise would be a strategy
> finding the side using the geographic courses found using the inverse
> Vincenty's formula but this requires some testing

As far as I know, the spherical side strategy works for the geographic
Earth too, please indicate if that is not the case.

See also
http://barendgehrels.blogspot.nl/2011/06/spherical-side-formula.html

But I might be wrong, it is good to research this.

> - for distance there are 2 strategies, both taking
> detail::ellipsoid<RadiusType>, andoyer also has a ctor taking a
> flattening of type RadiusType (like detail::ellipsoid<>). If 1
> parameter is passed (flattening) then the radius is set to 1.0 but if
> 2 parameters are passed then A and B radiuses are set. Furthermore by
> default Earth's radiuses are used. So the situation looks like this:
>
> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
> 6378137.0, B = 6356752.314245
> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(f)); // A = 1.0,
> B = [some fraction for oblate spheroid]
> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(a, b)); // A = a,
> B = b
> andoyer<RadiusType> s; // A = 6378137.0, B = 6356752.314245
> andoyer<RadiusType> s(f); // A = 1.0, B = [some fraction for oblate
> spheroid]
>
> It's confusing (this 1 and 2 paramers difference) and inconsistent
> with spherical strategies.


Yes this should be harmonized with one "libary-universal" concept of the
Earth model.

> Furthermore flattening should be stored using some Floating Point type
> and currently it's just RadiusType. E.g. for integral RadiusType the
> default ctor would initialize flattening with 0.
>
> PROPOSAL:
>
> 1. I propose to keep it simple for now, don't release
> detail::ellipsoid and change the default parameters to make the
> strategies close to the spherical ones:
>
> vincenty<RadiusType> s(); // A = 1.0, B = [fraction], F=
> [fraction,default] - unit WGS84 spheroid
> vincenty<RadiusType> s(a); // A = a, B = [calculated from a using
> default flattening], F= [fraction,default]
> vincenty<RadiusType> s(a, b); // A = a, B = b, F= [calculated from a
> and b]
>
> This way the calls:
>
> distance(p1, p2, vincenty<RadiusType>(a));
> distance(p1, p2) * a;

I don't know - will anybody call Vincenty with the unit sphere?
I would prefer specifying the ellipsoid.


>
> would be equivalent (assuming that RadiusType is not integral type?).
>
> By default FlatteningType would be:
> - for floating point RadiusType <=> RadiusType
> - for integral RadiusType <=> promoted to FP of the same size (int->
> float, long long-> double)
> - for user defined types <=> UDT
> The FlatteningType could be optionally passed as a second template
> parameter of a strategy however I'm not sure about it since it
> wouldn't play nice with possible future improvement 3 (see below).
>
> ALTERNATIVES (FUTURE ADDITIONS)
>
> 2. To decrease the probability of a mistake the strategy could take
> wrapped parameters (only?). This way it'd also be possible to create
> an ellipsoid from A,B A,F or B,F pair:
>
> // below are functions returning wrapped values
> vincenty<RadiusType> s(major_radius(a), minor_radius(b));
> vincenty<RadiusType> s(major_radius(a), flattening(f));
> vincenty<RadiusType> s(minor_radius(b), inverse_flattening(if));
>
> 3. Desing concepts for models parameters. And then always pass a type
> adapted to model's parameters concept to the strategy, instead of
> RadiusType. Actually a single number could be adapted to e.g. sphere
> parameters concept (radius) but why reserve it specifically for sphere?
>
> haversine< parameters::sphere<RadiusType> >
> s(parameters::sphere<RadiusType>(radius));
> vincenty< parameters::ellipsoid<RadiusType> >
> s(parameters::ellipsoid<RadiusType>(a, b));
> vincenty< parameters::ellipsoid_af<RadiusType> >
> s(parameters::ellipsoid_af<RadiusType>(a, f));
> vincenty< parameters::ellipsoid_unit_flattening<RadiusType> >
> s(parameters::ellipsoid_unit_flattening<RadiusType>(f));
> vincenty< parameters::ellipsoid_wgs84_1996<RadiusType> >
> s(parameters::ellipsoid_wgs84_1996<RadiusType>());
> vincenty< parameters::ellipsoid_wgs84_2004<RadiusType> >
> s(parameters::ellipsoid_wgs84_2004<RadiusType>());
> vincenty< parameters::ellipsoid_latest<RadiusType> >
> s(parameters::ellipsoid_latest<RadiusType>());
>
> FYI, all names of namespaces, structs and functions are examples.
>
> For sphere we'd already have a small problem with this. However this
> could be implemented in a backward compatible way. But then it could
> be done this way in the future, for both coordinate systems.
>
> 4. 2 and 3 together:
>
> vincenty< parameters::ellipsoid<RadiusType> >
> s(parameters::ellipsoid<RadiusType>(major_radius(a), minor_radius(b)));
>
> Do you have any thoughts or requests regarding the above?
>

Yes, I opt for a more simple model, one constructor and not many
overloads, with the model of the Earth. As discussed earlier. So
something like this, as you suggest:

vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
6378137.0, B = 6356752.314245
andoyer<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
6378137.0, B = 6356752.314245

(but the ellipsoid should not reside in detail)

This harmonization is the main reason why it is not moved earlier from
extensions to the main library. As soon as this is fixed we can probably
release them together. The main work will probably be in the projection
part.

Regards, Barend




_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Millman, Mark
In reply to this post by Barend
Barend, my only intention was to make sure that people did know about GDAL.  I am often surprised that many people are not aware of it, particularly people working outside of the so-called GIS field.  My assumption is that the Boost.Geometry classes serve a larger community working in spatial data that is not necessarily grounded on gis principals.  

Regards, mark

On Thu, Nov 6, 2014 at 1:15 PM, Barend Gehrels <[hidden email]> wrote:
Hi Mark,

Millman, Mark wrote On 6-11-2014 20:10:
While it's fair to be concerned about interdependence between projects there is the well supported Geospatial Data Abstraction Library (GDAL) and specifically the OGRSpatialReference class -- http://www.gdal.org/classOGRSpatialReference.html

These are well established projects widely used within the Open Source Geospatial developer community, written in C++ (and some C).

I think everybody knows these libraries.

What do you exactly intend by sending this message?

Regards, Barend

p.s. this list discourages top-postings.


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry



--

Mark Millman | Mizar, LLC
[hidden email] | www.mizar.com
(360) 220-3504
9908 Alegria Dr | Las Vegas, NV 89144

 The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Adam Wulkiewicz
In reply to this post by Barend
Hi Barend,

Barend Gehrels wrote:

> Adam Wulkiewicz wrote On 6-11-2014 17:06:
>> I'm planning to begin the implementation of the support for
>> geographical CS and would like to hear your opinion. Esspecially from
>> people already using the geographical extensions.
>> Basically, to support this CS we need a distance strategy and side
>> strategy. They're already implemented (more or less) though in the
>> extensions so not officially released yet. To release them we need to
>> think about the interface first. The geographical strategies should
>> have an interface similar to the one used in spherical strategies.
>
> I don't know if that is so important. What is important is that we
> have one model or concept of the Earth, used in both distance
> strategies (andoyer, vincenty) and in the geographic projections.
>
> That the interface is a bit different than Haversine, I don't know if
> that is a problem (maybe, but we can examine that). Or maybe they both
> can be implemented with a default constructor.
>

Yes, this is what I'd like to know, gather some feedback, etc.
The interface may be different but it should be consistent, i.e.
familiar for someone already knowing the spherical strategies, the
default parameters should be intuitive in both cases, etc.

<snip>

>
>>
>> GEOGRAPHICAL:
>>
>> - a spherical side strategy is just used by default which I guess
>> should be changed. I think the most precise would be a strategy
>> finding the side using the geographic courses found using the inverse
>> Vincenty's formula but this requires some testing
>
> As far as I know, the spherical side strategy works for the geographic
> Earth too, please indicate if that is not the case.
>
> See also
> http://barendgehrels.blogspot.nl/2011/06/spherical-side-formula.html
>
> But I might be wrong, it is good to research this.

I feel that Vincenty's formula should give different results in some
edge cases because the shape of geodesic on ellipsoid is different than
on a sphere but I must perform some tests to be sure.

>
>> - for distance there are 2 strategies, both taking
>> detail::ellipsoid<RadiusType>, andoyer also has a ctor taking a
>> flattening of type RadiusType (like detail::ellipsoid<>). If 1
>> parameter is passed (flattening) then the radius is set to 1.0 but if
>> 2 parameters are passed then A and B radiuses are set. Furthermore by
>> default Earth's radiuses are used. So the situation looks like this:
>>
>> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
>> 6378137.0, B = 6356752.314245
>> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(f)); // A = 1.0,
>> B = [some fraction for oblate spheroid]
>> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(a, b)); // A =
>> a, B = b
>> andoyer<RadiusType> s; // A = 6378137.0, B = 6356752.314245
>> andoyer<RadiusType> s(f); // A = 1.0, B = [some fraction for oblate
>> spheroid]
>>
>> It's confusing (this 1 and 2 paramers difference) and inconsistent
>> with spherical strategies.
>
>
> Yes this should be harmonized with one "libary-universal" concept of
> the Earth model.

I'm not sure if one "universal" model would be sufficient. Or do you
think about the model for geographic CS? E.g. Earth approximated as a
sphere could have some radius "not compatible" with the ellipsoid model.
E.g. mean radius may be calculated in various ways. So I'm guessing that
we shouldn't use ellipsoidal model for spherical CS.

>
>> Furthermore flattening should be stored using some Floating Point
>> type and currently it's just RadiusType. E.g. for integral RadiusType
>> the default ctor would initialize flattening with 0.
>>
>> PROPOSAL:
>>
>> 1. I propose to keep it simple for now, don't release
>> detail::ellipsoid and change the default parameters to make the
>> strategies close to the spherical ones:
>>
>> vincenty<RadiusType> s(); // A = 1.0, B = [fraction], F=
>> [fraction,default] - unit WGS84 spheroid
>> vincenty<RadiusType> s(a); // A = a, B = [calculated from a using
>> default flattening], F= [fraction,default]
>> vincenty<RadiusType> s(a, b); // A = a, B = b, F= [calculated from a
>> and b]
>>
>> This way the calls:
>>
>> distance(p1, p2, vincenty<RadiusType>(a));
>> distance(p1, p2) * a;
>
> I don't know - will anybody call Vincenty with the unit sphere?
> I would prefer specifying the ellipsoid.
>

I suggested it to be consistent with the spherical CS.
We could do other way around. Make the spherical CS consistent with the
geographical CS taking care about the backward compatibility.

However I don't have an idea how to do it in a "good" way. If we just
allowed passing a Sphere model besides a raw radius it could have some
different default value (spherical Earth radius). But then depending on
the type the default would be different so this would be unintuitive and
error-prone:

haversine<double> s; // radius = 1
haversine<sphere<double>> s // radius = ... e.g. 6367446.98883 or one of
the other mean radius values

Though this would be similar in the case of geographical CS, where
defaults are Earth's semi- major and minor axes.

But if those models had a word 'Earth' in the name explicitly then it'd
be obvious what default values there may be:

// it's obvious that by default those'd have some "real" radius values
haversine<spherical_earth<double>>
vincenty<ellipsoidal_earth<double>>

>
>>
>> would be equivalent (assuming that RadiusType is not integral type?).
>>
>> By default FlatteningType would be:
>> - for floating point RadiusType <=> RadiusType
>> - for integral RadiusType <=> promoted to FP of the same size (int->
>> float, long long-> double)
>> - for user defined types <=> UDT
>> The FlatteningType could be optionally passed as a second template
>> parameter of a strategy however I'm not sure about it since it
>> wouldn't play nice with possible future improvement 3 (see below).
>>
>> ALTERNATIVES (FUTURE ADDITIONS)
>>
>> 2. To decrease the probability of a mistake the strategy could take
>> wrapped parameters (only?). This way it'd also be possible to create
>> an ellipsoid from A,B A,F or B,F pair:
>>
>> // below are functions returning wrapped values
>> vincenty<RadiusType> s(major_radius(a), minor_radius(b));
>> vincenty<RadiusType> s(major_radius(a), flattening(f));
>> vincenty<RadiusType> s(minor_radius(b), inverse_flattening(if));
>>
>> 3. Desing concepts for models parameters. And then always pass a type
>> adapted to model's parameters concept to the strategy, instead of
>> RadiusType. Actually a single number could be adapted to e.g. sphere
>> parameters concept (radius) but why reserve it specifically for sphere?
>>
>> haversine< parameters::sphere<RadiusType> >
>> s(parameters::sphere<RadiusType>(radius));
>> vincenty< parameters::ellipsoid<RadiusType> >
>> s(parameters::ellipsoid<RadiusType>(a, b));
>> vincenty< parameters::ellipsoid_af<RadiusType> >
>> s(parameters::ellipsoid_af<RadiusType>(a, f));
>> vincenty< parameters::ellipsoid_unit_flattening<RadiusType> >
>> s(parameters::ellipsoid_unit_flattening<RadiusType>(f));
>> vincenty< parameters::ellipsoid_wgs84_1996<RadiusType> >
>> s(parameters::ellipsoid_wgs84_1996<RadiusType>());
>> vincenty< parameters::ellipsoid_wgs84_2004<RadiusType> >
>> s(parameters::ellipsoid_wgs84_2004<RadiusType>());
>> vincenty< parameters::ellipsoid_latest<RadiusType> >
>> s(parameters::ellipsoid_latest<RadiusType>());
>>
>> FYI, all names of namespaces, structs and functions are examples.
>>
>> For sphere we'd already have a small problem with this. However this
>> could be implemented in a backward compatible way. But then it could
>> be done this way in the future, for both coordinate systems.
>>
>> 4. 2 and 3 together:
>>
>> vincenty< parameters::ellipsoid<RadiusType> >
>> s(parameters::ellipsoid<RadiusType>(major_radius(a), minor_radius(b)));
>>
>> Do you have any thoughts or requests regarding the above?
>>
>
> Yes, I opt for a more simple model, one constructor and not many
> overloads, with the model of the Earth. As discussed earlier. So
> something like this, as you suggest:
>
> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
> 6378137.0, B = 6356752.314245
> andoyer<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
> 6378137.0, B = 6356752.314245
>

Are you saying that if a user wanted to use some different A or B he
should define his own model instead of passing some parameters?


What do you think about passing a model as a Strategy tempalte parameter
instead of a RadiusType?
It'd be less error-prone, since the radius type would be defined in one
place (the model).
It'd also simplify things in the case is we needed more than 1 type in
some future model.

So:

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

vs

typedef strategy::ellipsoid<double> ellipsoid;
strategy::vincenty<double> s(ellipsoid(a, b));

We could then pass a Sphere model to the haversine<> and handle it
differently than raw radius (as mentioned above).


Btw, I think Vincenty's formula could also be used in side calculation
so it could also be a name for a side strategy. But let's leave the
names for later.

> (but the ellipsoid should not reside in detail)
>
> This harmonization is the main reason why it is not moved earlier from
> extensions to the main library. As soon as this is fixed we can
> probably release them together. The main work will probably be in the
> projection part.

Should we also provide similar model for spherical CS with some default
mean Earth radius?
Another possibility would be to somehow extract this radius from an
ellipsoid<>:
- just take semi-major axis
- use one of those mean values:
http://en.wikipedia.org/wiki/Earth_radius#Mean_radii
- or one of those:
http://math.wikia.com/wiki/Ellipsoidal_quadratic_mean_radius
So I'd rather leave it to the user.

Or do you think otherwise?


Btw, some time ago we talked about convenient strategies specification
for Variant geometries and this would be "in line" with it, e.g.:

boost::variant<SphPoint, SphLinestring, SphPolygon> var1, var2;
// ...
distance(var1, var2, strategy::default &
strategy::sphere<RadiusType>(radius))

And this object of type strategy::sphere<> could go directly into the
Strategy. But this is another story...

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Adam Wulkiewicz
In reply to this post by Millman, Mark
Hi Mark,

Mark Millman wrote:
> While it's fair to be concerned about interdependence between projects
> there is the well supported Geospatial Data Abstraction Library (GDAL)
> and specifically the OGRSpatialReference class --
> http://www.gdal.org/classOGRSpatialReference.html
>
> These are well established projects widely used within the Open Source
> Geospatial developer community, written in C++ (and some C).

Thanks for the link! Definietly we should some day support various SRSs
and make them available out of the box for the user. Though I think it's
not necessary to support various SRSs on a strategy level. Strategies
are rather low level functionality. When they're used we already know
the coordinate system and a reference model (cartesian plane/space,
sphere, spheroid/ellipsoid or maybe some other in the future). The only
thing we need is the parameters. AFAIU SRSs, projections, EPSG codes,
etc. should be somewhere on a higher level.

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Millman, Mark
I agree completely: Boost.Geometry is not the place to implement SRS per se,  But, if the design of CS functionality anticipates an interface it may, in the long run, attract more interest among the geo-spatial community in the Boost.Geometry packages; which would be a very good thing.  I use both Boost and GDAL and anything that makes it easier to integrate the two is good news to me.

Mark

On Thu, Nov 6, 2014 at 3:49 PM, Adam Wulkiewicz <[hidden email]> wrote:
Hi Mark,

Mark Millman wrote:
While it's fair to be concerned about interdependence between projects there is the well supported Geospatial Data Abstraction Library (GDAL) and specifically the OGRSpatialReference class -- http://www.gdal.org/classOGRSpatialReference.html

These are well established projects widely used within the Open Source Geospatial developer community, written in C++ (and some C).

Thanks for the link! Definietly we should some day support various SRSs and make them available out of the box for the user. Though I think it's not necessary to support various SRSs on a strategy level. Strategies are rather low level functionality. When they're used we already know the coordinate system and a reference model (cartesian plane/space, sphere, spheroid/ellipsoid or maybe some other in the future). The only thing we need is the parameters. AFAIU SRSs, projections, EPSG codes, etc. should be somewhere on a higher level.


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



--

Mark Millman | Mizar, LLC
[hidden email] | www.mizar.com
(360) 220-3504
9908 Alegria Dr | Las Vegas, NV 89144

 The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
In reply to this post by Adam Wulkiewicz
Hi Adam, Mark,

Adam Wulkiewicz wrote On 7-11-2014 0:49:

> Hi Mark,
>
> Mark Millman wrote:
>> While it's fair to be concerned about interdependence between
>> projects there is the well supported Geospatial Data Abstraction
>> Library (GDAL) and specifically the OGRSpatialReference class --
>> http://www.gdal.org/classOGRSpatialReference.html
>>
>> These are well established projects widely used within the Open
>> Source Geospatial developer community, written in C++ (and some C).
>
> Thanks for the link! Definietly we should some day support various
> SRSs and make them available out of the box for the user. Though I
> think it's not necessary to support various SRSs on a strategy level.
> Strategies are rather low level functionality. When they're used we
> already know the coordinate system and a reference model (cartesian
> plane/space, sphere, spheroid/ellipsoid or maybe some other in the
> future). The only thing we need is the parameters. AFAIU SRSs,
> projections, EPSG codes, etc. should be somewhere on a higher level.


About interdependence: good point. But there is already interdependence.
The whole Boost.Geometry Projection extension is automatically converted
from Proj4 to templated point concept based.

http://trac.osgeo.org/proj/

So here more information about Boost.Geometry projections as it seems to
be not so well known.

With Proj4, it also got the may parameters and their
string-initialization support.

http://trac.osgeo.org/proj/wiki/GenParms

In Boost.Geometry you can therefore initialize projections like this:

     bg::projections::parameters params =
bg::projections::detail::pj_init_plus(parameters);

See for example the examples  extensions/example/gis/projections

or the projections.cpp unit test where this is done extensively. I copy
a few lines here:

     test_forward<P>("aea", 4.897000, 52.371000, 334609.583974, 5218502.503686, "+proj=aea +ellps=WGS84 +units=m +lat_1=55 +lat_2=65");

     test_forward<P>("aeqd", 4.897000, 52.371000, 384923.723428, 5809986.497118, "+proj=aeqd +ellps=WGS84 +units=m");

     test_forward<P>("airy", 4.897000, 52.371000, 328249.003313, 4987937.101447, "+proj=airy +ellps=WGS84 +units=m");


Of course not all of there parameters are relevant to the Earth model,
many are specific for projections. But some are such as tes, des, te,
de, tf, tb, ...

So this is is why I asked to harmonize the Earth model between distance
(vincenty, andoyer) which have a simpler model, and the projections,
where it is done. We don't have to take this over for 100% but we have
to have one Concept.

About EPSG codes, also here is support within Boost.Geometry 's
projections, you can initalize with:
typedef bg::projections::epsg_traits<28992, P1, P2> epsg_traits; (where
P1,P2 are point types).
bg::projections::parameters par =
bg::projections::detail::pj_init_plus(epsg_traits::par());

See the examples or the unit test projection_epg.cpp

Boost.Geometry projections are huge and well tested. With the unit
tests, projecting forward and backward, some errors in projection code
were found and this is reported back to Proj4 and to Gerald Evenden, so
it is fixed in the sources too.

Regards, Barend

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
In reply to this post by Adam Wulkiewicz
Hi Adam,


Adam Wulkiewicz wrote On 7-11-2014 0:00:

> Hi Barend,
>
> Barend Gehrels wrote:
>> Adam Wulkiewicz wrote On 6-11-2014 17:06:
>>> I'm planning to begin the implementation of the support for
>>> geographical CS and would like to hear your opinion. Esspecially
>>> from people already using the geographical extensions.
>>> Basically, to support this CS we need a distance strategy and side
>>> strategy. They're already implemented (more or less) though in the
>>> extensions so not officially released yet. To release them we need
>>> to think about the interface first. The geographical strategies
>>> should have an interface similar to the one used in spherical
>>> strategies.
>>
>> I don't know if that is so important. What is important is that we
>> have one model or concept of the Earth, used in both distance
>> strategies (andoyer, vincenty) and in the geographic projections.
>>
>> That the interface is a bit different than Haversine, I don't know if
>> that is a problem (maybe, but we can examine that). Or maybe they
>> both can be implemented with a default constructor.
>>
>
> Yes, this is what I'd like to know, gather some feedback, etc.
> The interface may be different but it should be consistent, i.e.
> familiar for someone already knowing the spherical strategies, the
> default parameters should be intuitive in both cases, etc.

Ideally yes. But I don't think there are many users who will use both of
them. It's a different world.

>
> <snip>
>
>>
>>>
>>> GEOGRAPHICAL:
>>>
>>> - a spherical side strategy is just used by default which I guess
>>> should be changed. I think the most precise would be a strategy
>>> finding the side using the geographic courses found using the
>>> inverse Vincenty's formula but this requires some testing
>>
>> As far as I know, the spherical side strategy works for the
>> geographic Earth too, please indicate if that is not the case.
>>
>> See also
>> http://barendgehrels.blogspot.nl/2011/06/spherical-side-formula.html
>>
>> But I might be wrong, it is good to research this.
>
> I feel that Vincenty's formula should give different results in some
> edge cases because the shape of geodesic on ellipsoid is different
> than on a sphere but I must perform some tests to be sure.

I'm curious about this.

>
>>
>>> - for distance there are 2 strategies, both taking
>>> detail::ellipsoid<RadiusType>, andoyer also has a ctor taking a
>>> flattening of type RadiusType (like detail::ellipsoid<>). If 1
>>> parameter is passed (flattening) then the radius is set to 1.0 but
>>> if 2 parameters are passed then A and B radiuses are set.
>>> Furthermore by default Earth's radiuses are used. So the situation
>>> looks like this:
>>>
>>> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
>>> 6378137.0, B = 6356752.314245
>>> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(f)); // A =
>>> 1.0, B = [some fraction for oblate spheroid]
>>> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>(a, b)); // A =
>>> a, B = b
>>> andoyer<RadiusType> s; // A = 6378137.0, B = 6356752.314245
>>> andoyer<RadiusType> s(f); // A = 1.0, B = [some fraction for oblate
>>> spheroid]
>>>
>>> It's confusing (this 1 and 2 paramers difference) and inconsistent
>>> with spherical strategies.
>>
>>
>> Yes this should be harmonized with one "libary-universal" concept of
>> the Earth model.
>
> I'm not sure if one "universal" model would be sufficient. Or do you
> think about the model for geographic CS?

Yes.

> E.g. Earth approximated as a sphere could have some radius "not
> compatible" with the ellipsoid model. E.g. mean radius may be
> calculated in various ways. So I'm guessing that we shouldn't use
> ellipsoidal model for spherical CS.

Agreed - besides that it is an overkill. Spherical really only has the
radius... But yeah, if we have an ellips Concept which has an equal
major and minor axis... That might be usable.


>
>>
>>> Furthermore flattening should be stored using some Floating Point
>>> type and currently it's just RadiusType. E.g. for integral
>>> RadiusType the default ctor would initialize flattening with 0.
>>>
>>> PROPOSAL:
>>>
>>> 1. I propose to keep it simple for now, don't release
>>> detail::ellipsoid and change the default parameters to make the
>>> strategies close to the spherical ones:
>>>
>>> vincenty<RadiusType> s(); // A = 1.0, B = [fraction], F=
>>> [fraction,default] - unit WGS84 spheroid
>>> vincenty<RadiusType> s(a); // A = a, B = [calculated from a using
>>> default flattening], F= [fraction,default]
>>> vincenty<RadiusType> s(a, b); // A = a, B = b, F= [calculated from a
>>> and b]
>>>
>>> This way the calls:
>>>
>>> distance(p1, p2, vincenty<RadiusType>(a));
>>> distance(p1, p2) * a;
>>
>> I don't know - will anybody call Vincenty with the unit sphere?
>> I would prefer specifying the ellipsoid.
>>
>
> I suggested it to be consistent with the spherical CS.
> We could do other way around. Make the spherical CS consistent with
> the geographical CS taking care about the backward compatibility.

Yes, I think that is the way to go.

>
> However I don't have an idea how to do it in a "good" way. If we just
> allowed passing a Sphere model besides a raw radius it could have some
> different default value (spherical Earth radius). But then depending
> on the type the default would be different so this would be
> unintuitive and error-prone:
>
> haversine<double> s; // radius = 1
> haversine<sphere<double>> s // radius = ... e.g. 6367446.98883 or one
> of the other mean radius values
>
> Though this would be similar in the case of geographical CS, where
> defaults are Earth's semi- major and minor axes.
>
> But if those models had a word 'Earth' in the name explicitly then
> it'd be obvious what default values there may be:
>
> // it's obvious that by default those'd have some "real" radius values
> haversine<spherical_earth<double>>
> vincenty<ellipsoidal_earth<double>>
>
>>
>>>
>>> would be equivalent (assuming that RadiusType is not integral type?).
>>>
>>> By default FlatteningType would be:
>>> - for floating point RadiusType <=> RadiusType
>>> - for integral RadiusType <=> promoted to FP of the same size (int->
>>> float, long long-> double)
>>> - for user defined types <=> UDT
>>> The FlatteningType could be optionally passed as a second template
>>> parameter of a strategy however I'm not sure about it since it
>>> wouldn't play nice with possible future improvement 3 (see below).
>>>
>>> ALTERNATIVES (FUTURE ADDITIONS)
>>>
>>> 2. To decrease the probability of a mistake the strategy could take
>>> wrapped parameters (only?). This way it'd also be possible to create
>>> an ellipsoid from A,B A,F or B,F pair:
>>>
>>> // below are functions returning wrapped values
>>> vincenty<RadiusType> s(major_radius(a), minor_radius(b));
>>> vincenty<RadiusType> s(major_radius(a), flattening(f));
>>> vincenty<RadiusType> s(minor_radius(b), inverse_flattening(if));
>>>
>>> 3. Desing concepts for models parameters. And then always pass a
>>> type adapted to model's parameters concept to the strategy, instead
>>> of RadiusType. Actually a single number could be adapted to e.g.
>>> sphere parameters concept (radius) but why reserve it specifically
>>> for sphere?
>>>
>>> haversine< parameters::sphere<RadiusType> >
>>> s(parameters::sphere<RadiusType>(radius));
>>> vincenty< parameters::ellipsoid<RadiusType> >
>>> s(parameters::ellipsoid<RadiusType>(a, b));
>>> vincenty< parameters::ellipsoid_af<RadiusType> >
>>> s(parameters::ellipsoid_af<RadiusType>(a, f));
>>> vincenty< parameters::ellipsoid_unit_flattening<RadiusType> >
>>> s(parameters::ellipsoid_unit_flattening<RadiusType>(f));
>>> vincenty< parameters::ellipsoid_wgs84_1996<RadiusType> >
>>> s(parameters::ellipsoid_wgs84_1996<RadiusType>());
>>> vincenty< parameters::ellipsoid_wgs84_2004<RadiusType> >
>>> s(parameters::ellipsoid_wgs84_2004<RadiusType>());
>>> vincenty< parameters::ellipsoid_latest<RadiusType> >
>>> s(parameters::ellipsoid_latest<RadiusType>());
>>>
>>> FYI, all names of namespaces, structs and functions are examples.
>>>
>>> For sphere we'd already have a small problem with this. However this
>>> could be implemented in a backward compatible way. But then it could
>>> be done this way in the future, for both coordinate systems.
>>>
>>> 4. 2 and 3 together:
>>>
>>> vincenty< parameters::ellipsoid<RadiusType> >
>>> s(parameters::ellipsoid<RadiusType>(major_radius(a), minor_radius(b)));
>>>
>>> Do you have any thoughts or requests regarding the above?
>>>
>>
>> Yes, I opt for a more simple model, one constructor and not many
>> overloads, with the model of the Earth. As discussed earlier. So
>> something like this, as you suggest:
>>
>> vincenty<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
>> 6378137.0, B = 6356752.314245
>> andoyer<RadiusType> s(detail::ellipsoid<RadiusType>()); // A =
>> 6378137.0, B = 6356752.314245
>>
>
> Are you saying that if a user wanted to use some different A or B he
> should define his own model instead of passing some parameters?

More specificly, the parameters are for the Earth model, not for the
strategy. That is not really defining an own model (though that would be
possible too), more configuring the existing model.

>
>
> What do you think about passing a model as a Strategy tempalte
> parameter instead of a RadiusType?
> It'd be less error-prone, since the radius type would be defined in
> one place (the model).
> It'd also simplify things in the case is we needed more than 1 type in
> some future model.
>
> So:
>
> 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));
>
> vs
>
> typedef strategy::ellipsoid<double> ellipsoid;
> strategy::vincenty<double> s(ellipsoid(a, b));

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.

>
>
> Btw, I think Vincenty's formula could also be used in side calculation
> so it could also be a name for a side strategy. But let's leave the
> names for later.
>
>> (but the ellipsoid should not reside in detail)
>>
>> This harmonization is the main reason why it is not moved earlier
>> from extensions to the main library. As soon as this is fixed we can
>> probably release them together. The main work will probably be in the
>> projection part.
>
> Should we also provide similar model for spherical CS with some
> default mean Earth radius?
> Another possibility would be to somehow extract this radius from an
> ellipsoid<>:
> - just take semi-major axis
> - use one of those mean values:
> http://en.wikipedia.org/wiki/Earth_radius#Mean_radii
> - or one of those:
> http://math.wikia.com/wiki/Ellipsoidal_quadratic_mean_radius
> So I'd rather leave it to the user.
>
> Or do you think otherwise?


I think a model following our Ellipsoid concept,  implementing a sphere,
would be perfect.

>
> Btw, some time ago we talked about convenient strategies specification
> for Variant geometries and this would be "in line" with it, e.g.:
>
> boost::variant<SphPoint, SphLinestring, SphPolygon> var1, var2;
> // ...
> distance(var1, var2, strategy::default &
> strategy::sphere<RadiusType>(radius))
>
> And this object of type strategy::sphere<> could go directly into the
> Strategy. But this is another story...

I don't know - I skip this for now.

But you will have noticed my other mail about the projections too ;-)

Regards, Barend


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

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

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.

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

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.

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
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



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

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

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Menelaos Karavelas
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
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/geometry

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Adam Wulkiewicz
Hi,

Menelaos Karavelas wrote:

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

Yes, indeed the word "reference" may be confusing, though I think that
we should just choose a name describing well the content. But ok, maybe
we could pick something different. Note that the reference_system also
has the word "reference" in it.

I'd rather avoid the word geography. I know that the main purpose is to
use it on in a GIS field but it should be general-purpose name. What do
you think about:

bg::reference_model::spheroid<>
bg::ref_model::spheroid<>
bg::rmodel::spheroid<>

They also have "reference" in a name and the last "r" might be confused
with "reverse".


Since we already have bg::cs namespace, somehow related to the reference
system. We could reuse this scheme:

boost::geometry::rs::spheroid<>

but should spheroid and sphere be included in reference systems
(namespace)? They're rather models describing the ref systems. Though
it's possible that we'd need a place for more code related to reference
systems, EPSGs, SRIDs, etc. so this code could be put there. But then
I'd put the models in:

boost::geometry::rs::model::sphere<>
boost::geometry::rs::model::spheroid<>

Or just reuse the namespace cs for this:

boost::geometry::cs::model::sphere<>
boost::geometry::cs::model::spheroid<>

which would be probably the most general choice. The question is: could
additional things be put in the bg::cs namespace?

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
Hi,

Adam Wulkiewicz wrote On 14-11-2014 12:33:

> Hi,
>
> Menelaos Karavelas wrote:
>> On 14/11/2014 01:42 πμ, Adam Wulkiewicz wrote:
>>> Barend Gehrels wrote:
>>>> Adam Wulkiewicz wrote On 12-11-2014 1:48:
>>>>> 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.
>>
>
> Yes, indeed the word "reference" may be confusing, though I think that
> we should just choose a name describing well the content. But ok,
> maybe we could pick something different. Note that the
> reference_system also has the word "reference" in it.
>
> I'd rather avoid the word geography. I know that the main purpose is
> to use it on in a GIS field but it should be general-purpose name.
> What do you think about:
>
> bg::reference_model::spheroid<>
> bg::ref_model::spheroid<>
> bg::rmodel::spheroid<>
>
> They also have "reference" in a name and the last "r" might be
> confused with "reverse".
>
>
> Since we already have bg::cs namespace, somehow related to the
> reference system. We could reuse this scheme:
>
> boost::geometry::rs::spheroid<>


The common abbreviation is srs (spatial reference system), so as we get
to that direction, I would certainly use that one. That would actually
look quite good.


>
> but should spheroid and sphere be included in reference systems
> (namespace)? They're rather models describing the ref systems. Though
> it's possible that we'd need a place for more code related to
> reference systems, EPSGs, SRIDs, etc. so this code could be put there.
> But then I'd put the models in:
>
> boost::geometry::rs::model::sphere<>
> boost::geometry::rs::model::spheroid<>
>
> Or just reuse the namespace cs for this:
>
> boost::geometry::cs::model::sphere<>
> boost::geometry::cs::model::spheroid<>
>
> which would be probably the most general choice. The question is:
> could additional things be put in the bg::cs namespace?


I think I would prefer the srs namespace.

Regards, Barend



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
In reply to this post by Adam Wulkiewicz
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


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Adam Wulkiewicz
In reply to this post by Barend
Hi,

Barend Gehrels wrote:

> Adam Wulkiewicz wrote On 14-11-2014 12:33:
>> Since we already have bg::cs namespace, somehow related to the
>> reference system. We could reuse this scheme:
>>
>> boost::geometry::rs::spheroid<>
>
>
> The common abbreviation is srs (spatial reference system), so as we
> get to that direction, I would certainly use that one. That would
> actually look quite good.
>
>
>>
>> but should spheroid and sphere be included in reference systems
>> (namespace)? They're rather models describing the ref systems. Though
>> it's possible that we'd need a place for more code related to
>> reference systems, EPSGs, SRIDs, etc. so this code could be put
>> there. But then I'd put the models in:
>>
>> boost::geometry::rs::model::sphere<>
>> boost::geometry::rs::model::spheroid<>
>>
>> Or just reuse the namespace cs for this:
>>
>> boost::geometry::cs::model::sphere<>
>> boost::geometry::cs::model::spheroid<>
>>
>> which would be probably the most general choice. The question is:
>> could additional things be put in the bg::cs namespace?
>
>
> I think I would prefer the srs namespace.

Indeed srs is a better name than rs. Though I'm not sure that we should
use it. On the wikipedia
(http://en.wikipedia.org/wiki/Spatial_reference_system) there states:

A spatial reference system (SRS) or coordinate reference system (CRS) is
a coordinate-based local, regional or global system used to locate
geographical entities. A spatial reference system defines a specific map
projection, as well as transformations between different spatial
reference systems.
(...)
Spatial reference systems can be referred to using a SRID integer,
including EPSG codes (...)

AFAIU SRS is higher-level concept than sphere and spheroid models
representing a coordinate system. By using those models I'm not defining
any particular SRS since AFAIR SRS should also define other things like
units and the N/S W/E mapping, etc. The concept of SRS is bound closely
with geography/GIS and on this level I'd prefer to be domain-agnostic,
in other words be closer to mathematics. Newly added sphere/spheroid
represent a global system, not necesarily for geographical entities.

Does the above have some sense?

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Support for geographic coordinate system

Barend
Hi Adam,


Adam Wulkiewicz wrote On 18-11-2014 1:53:

> Hi,
>
> Barend Gehrels wrote:
>> Adam Wulkiewicz wrote On 14-11-2014 12:33:
>>> Since we already have bg::cs namespace, somehow related to the
>>> reference system. We could reuse this scheme:
>>>
>>> boost::geometry::rs::spheroid<>
>>
>>
>> The common abbreviation is srs (spatial reference system), so as we
>> get to that direction, I would certainly use that one. That would
>> actually look quite good.
>>
>>
>>>
>>> but should spheroid and sphere be included in reference systems
>>> (namespace)? They're rather models describing the ref systems.
>>> Though it's possible that we'd need a place for more code related to
>>> reference systems, EPSGs, SRIDs, etc. so this code could be put
>>> there. But then I'd put the models in:
>>>
>>> boost::geometry::rs::model::sphere<>
>>> boost::geometry::rs::model::spheroid<>
>>>
>>> Or just reuse the namespace cs for this:
>>>
>>> boost::geometry::cs::model::sphere<>
>>> boost::geometry::cs::model::spheroid<>
>>>
>>> which would be probably the most general choice. The question is:
>>> could additional things be put in the bg::cs namespace?
>>
>>
>> I think I would prefer the srs namespace.
>
> Indeed srs is a better name than rs. Though I'm not sure that we
> should use it. On the wikipedia
> (http://en.wikipedia.org/wiki/Spatial_reference_system) there states:
>
> A spatial reference system (SRS) or coordinate reference system (CRS)
> is a coordinate-based local, regional or global system used to locate
> geographical entities. A spatial reference system defines a specific
> map projection, as well as transformations between different spatial
> reference systems.
> (...)
> Spatial reference systems can be referred to using a SRID integer,
> including EPSG codes (...)
>
> AFAIU SRS is higher-level concept than sphere and spheroid models
> representing a coordinate system. By using those models I'm not
> defining any particular SRS since AFAIR SRS should also define other
> things like units and the N/S W/E mapping, etc. The concept of SRS is
> bound closely with geography/GIS and on this level I'd prefer to be
> domain-agnostic, in other words be closer to mathematics. Newly added
> sphere/spheroid represent a global system, not necesarily for
> geographical entities.
>
> Does the above have some sense?

Sure, it makes sense and I agree (a bit). While srs describes a spatial
reference system, it includes a reference ellipsoid. So the spheroids
can be part of the namespace srs, defining also other things. But yes,
it is GIS-specific. But isn't the whole geographic coordinate system
GIS-specific?

OK, thinking more about this. In general what we try to model here is
called a refererence ellipsoid.
http://en.wikipedia.org/wiki/Reference_ellipsoid

You earlier mentioned that we should call it a spheroid, because the
Earth is in fact spheroid-shaped, so it is mathematically more correct
to call it a spheroid. For the Earth it is. But that makes it
GIS-specific too...

Each spheroid is an ellipsoid, where two axes happen to be the same. But
there are also bodies which are true ellipsoids, e.g. Jupiter's moon Io
(same article). So yes, why not call it in general an ellipsoid, it is
one, and that is the common name...

If we have that, we can use the namespace re (reference ellipsoid).

The model we are currently defining, of course, you can then still call
a spheroid because it defines only two axes.

So it then becomes for example:

boost::geometry::re::spheroid<>

srs is for me still an option too

Another alternative is "datum" which has the advantage that it is not an
abbreviation. Geodesic datum contains a reference ellipsoid and more,
but as a namespace it might be convenient.

boost::geometry::datum::spheroid<>

Regards, Barend


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
12