|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r71784 - in trunk/libs/geometry/doc: . html src/examples
From: barend.gehrels_at_[hidden]
Date: 2011-05-07 13:46:03
Author: barendgehrels
Date: 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
New Revision: 71784
URL: http://svn.boost.org/trac/boost/changeset/71784
Log:
Doc update (general pages)
Removed:
trunk/libs/geometry/doc/html/output_main.png
Text files modified:
trunk/libs/geometry/doc/acknowledgments.qbk | 30 ++++++--
trunk/libs/geometry/doc/design_rationale.qbk | 135 +++++++++++----------------------------
trunk/libs/geometry/doc/geometry.qbk | 9 ++
trunk/libs/geometry/doc/introduction.qbk | 32 +++++----
trunk/libs/geometry/doc/quickstart.qbk | 78 ++++++++++++++++++++--
trunk/libs/geometry/doc/src/examples/Jamfile.v2 | 3
trunk/libs/geometry/doc/src/examples/quick_start.cpp | 104 ++++++++++++++----------------
7 files changed, 206 insertions(+), 185 deletions(-)
Modified: trunk/libs/geometry/doc/acknowledgments.qbk
==============================================================================
--- trunk/libs/geometry/doc/acknowledgments.qbk (original)
+++ trunk/libs/geometry/doc/acknowledgments.qbk 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
@@ -12,15 +12,29 @@
[section Acknowledgments]
-We like to thank all the people who helped in a way to develop this library.
+We like to thank all the people who helped to develop this library.
-First of all we are grateful to Hartmut Kaiser for managing the formal review of this library. Hartmut was a very good review manager, who intervented when necessary and produced the review report quickly. He has also supported the library by subscribing to the GGL mailing list and participating actively on it.
-
-We thank the 14 reviewers of our library, reviewed from November 5, 2009 to November 22, 2009. Reviews have been written by: Brandon Kohn, Christophe Henry, Fabio Fracassi, Gordon Woodhull, Joachim Faulhaber, Jonathan Franklin, Jose, Lucanus Simonson, Michael Caisse, Michael Fawcett, Paul Bristow, Phil Endecott, Thomas Klimpel, Tom Brinkman
-
-We also thank all people who discussed on the list about Boost.Geometry, in preview stage or in review stage or after that. We cannot mention all those names, but we like to mention those who, sometimes with a short message, did have a major influence on our design: Dave Abrahams (for the hint on tag dispatching when we were lost in SFINAE), John Fem.... TODO (for the hint on the set of metafunctions for traits), and Mathias Gaunard (for the hint on ranges instead of iterators).
-
-Finally I (Barend) would like to thank my former employer, Geodan, I've worked there for 16 years, started a geographic library in 1995 which after a number of incarnations, redesigns, refactorings, previews, a review and even more refactorings have led to the now released Boost.Geometry. [/And with them I want to thank those who were initially involved in the library, Maarten Hilfering, Valik, Anne Blankert, and later on Sjoerd Schreuder, Steven Fruitier and Paul den Dulk.]
+First of all we are grateful to Hartmut Kaiser for managing the formal review
+of this library. Hartmut is an excellent review manager, who intervented when
+necessary and produced the review report quickly.
+
+We thank the 14 reviewers of our library, reviewed from November 5, 2009 to
+November 22, 2009. Reviews have been written by: Brandon Kohn, Christophe
+Henry, Fabio Fracassi, Gordon Woodhull, Joachim Faulhaber, Jonathan Franklin,
+Jose, Lucanus Simonson, Michael Caisse, Michael Fawcett, Paul Bristow, Phil
+Endecott, Thomas Klimpel, Tom Brinkman.
+
+We also thank all people who discussed on the mailing lists (either at boost,
+or at osgeo) about __boost_geometry__, in preview stage, or in review stage,
+or after that.
+
+Finally I (Barend) would like to thank my former employer, Geodan. They
+allowed me to start a geographic library in 1995, which after a number of
+incarnations, redesigns, refactorings, previews, a review and even more
+refactorings have led to the now released __boost_geometry__. And with them I
+want to thank the team initially involved in developing the library, Valik
+Solorzano Barboza, Maarten Hilferink, Anne Blankert, and later Sjoerd
+Schreuder, Steven Fruijtier, Paul den Dulk, and Joris Sierman.
[endsect]
Modified: trunk/libs/geometry/doc/design_rationale.qbk
==============================================================================
--- trunk/libs/geometry/doc/design_rationale.qbk (original)
+++ trunk/libs/geometry/doc/design_rationale.qbk 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
@@ -8,6 +8,8 @@
http://www.boost.org/LICENSE_1_0.txt)
===============================================================================/]
+[/ note the source code in this QBK is the only not (yet) checked by a compiler]
+
[section:design Design Rationale]
Suppose you need a C++ program to calculate the distance between two points.
@@ -27,9 +29,10 @@
return sqrt(dx * dx + dy * dy);
}
-Quite simple, and it is usable, but not generic. For a library it has to be designed way further.
-The design above can only be used for 2D points, for the struct [*mypoint] (and no other struct),
-in a __wiki_cs_cartesian__. A generic library should be able to calculate the distance:
+Quite simple, and it is usable, but not generic. For a library it has to be
+designed way further. The design above can only be used for 2D points, for the
+struct [*mypoint] (and no other struct), in a Cartesian coordinate system. A
+generic library should be able to calculate the distance:
* for any point class or struct, not on just this [*mypoint] type
* in more than two dimensions
@@ -115,22 +118,6 @@
with methods like `x()`, and they are supported as long as there is a specialization of the access
`struct` with a static `get` function returning `x()` for dimension 0, and similar for 1 and `y()`.
-Alternatively we could implement, in the traits class, the dimension as a template parameter in
-a member template function:
-
- template <>
- struct access<mypoint>
- {
- template <int D>
- static double get(mypoint const& p)
- // either return x/y using an if-clause
- // or call a detail-struct specialized
- // per dimension
- };
-
-This alternative gives in the end the same functionality, either using an `if` statement (wihch
-may be slower), or adding another level of indirection.
-
[heading Dimension Agnosticism]
Now we can calculate the distance between points in 2D, points of any structure or class.
@@ -159,7 +146,7 @@
}
};
-The distance function is calling that [*pythagoras] structure, specifying the number of dimensions:
+The distance function is calling that `pythagoras` structure, specifying the number of dimensions:
template <typename P1, typename P2>
double distance(P1 const& a, P2 const& b)
@@ -181,7 +168,8 @@
which has to be specialized again for the `struct mypoint`.
-Because it only has to publish a value, we conveniently derive it from the __boost_mpl__ `class boost::mpl::int_`:
+Because it only has to publish a value, we conveniently derive it from the
+__boost_mpl__ `class boost::mpl::int_`:
``
namespace traits
@@ -233,7 +221,7 @@
struct coordinate_type : traits::coordinate_type<P> {};
We now can modify our distance algorithm again. Because it still returns double, we only
-modify the [*pythagoras] computation class. It should return the coordinate type of its input.
+modify the `pythagoras` computation class. It should return the coordinate type of its input.
But, it has two input, possibly different, point types. They might also differ in their
coordinate types. Not that that is very likely, but we’re designing a generic library and we
should handle those strange cases. We have to choose one of the coordinate types and of course
@@ -261,28 +249,30 @@
[heading Different Geometries]
-We’ve designed a dimension agnostic system supporting any point type of any coordinate type.
-There are still some tweaks but they will be worked out later. Now we will see how we calculate
-the distance between a point and a polygon, or between a point and a line-segment. These formulae
-are more complex, and the influence on design is even larger. We don’t want to add a function
-with another name:
+We have designed a dimension agnostic system supporting any point type of any
+coordinate type. There are still some tweaks but they will be worked out later.
+Now we will see how we calculate the distance between a point and a polygon, or
+between a point and a line-segment. These formulae are more complex, and the
+influence on design is even larger. We don’t want to add a function with another
+name:
template <typename P, typename S>
double distance_point_segment(P const& p, S const& s)
-We want to be generic, the distance function has to be called from code not knowing the type
-of geometry it handles, so it has to be named distance. We also cannot create an overload because
-that would be ambiguous, having the same template signature. There are two solutions:
+We want to be generic, the distance function has to be called from code not
+knowing the type of geometry it handles, so it has to be named distance. We also
+cannot create an overload because that would be ambiguous, having the same
+template signature. There are two solutions:
* tag dispatching
* SFINAE
-We select tag dispatching because it fits into the traits system. The earlier versions (previews) of
-Boost.Geometry used SFINAE but we found it had several drawbacks for such a big design, so the switch
-to tag dispatching was made.
+We select tag dispatching because it fits into the traits system. The earlier
+versions (previews) of Boost.Geometry used SFINAE but we found it had several
+drawbacks for such a big design, so the switch to tag dispatching was made.
-With tag dispatching the distance algorithm inspects the type of geometry of the input parameters. The distance function will be changed
-into this:
+With tag dispatching the distance algorithm inspects the type of geometry of the
+input parameters. The distance function will be changed into this:
template <typename G1, typename G2>
double distance(G1 const& g1, G2 const& g2)
@@ -489,7 +479,7 @@
typedef pythagoras<P1, P2, D> type;
};
-So, here is our [*pythagoras] again, now defined as a strategy. The distance dispatch function just
+So, here is our `pythagoras` again, now defined as a strategy. The distance dispatch function just
calls its apply method.
So this is an important step: for spherical or geographical coordinate systems, another
@@ -582,7 +572,7 @@
We promised that calling `std::sqrt` was not always necessary. So we define a distance result `struct`
that contains the squared value and is convertible to a double value. This, however, only has to
-be done for [*pythagoras]. The spherical distance functions do not take the square root so for them
+be done for `pythagoras`. The spherical distance functions do not take the square root so for them
it is not necessary to avoid the expensive square root call; they can just return their distance.
So the distance result struct is dependant on strategy, therefore made a member type of
@@ -608,9 +598,9 @@
or:
- typedef double return_type
+ typedef double return_type;
-for [*pythagoras] and spherical, respectively.
+for cartesian (pythagoras) and spherical, respectively.
Again our distance function will be modified, as expected, to reflect the new return type.
For the overload with a strategy it is not complex:
@@ -647,64 +637,15 @@
Of course also the apply functions in the dispatch specializations will return a result like this.
They have a strategy as a template parameter everywhere, making the less verbose version possible.
-[heading Reversibility]
-
-Our `dispatch::distance` class was specialized for <`point_tag`, `segment_tag`>.
-Library users can also call the distance function with a segment and a point, in that order.
-Actually, there are many geometry types (polygon, box, linestring), how to implement all those
-without duplicating all tag dispatching functions? The answer is that we automatically
-reverse the arguments, if appropriate. For distance it is appropriate because distance is a
-commutative function. We add a meta-function `geometry_id`, which has specializations for each
-geometry type, just derived from `boost::mpl::int_`, such that it can be ordered. Point is 1,
-segment is e.g. 2.
-
-Then we add a meta-function reverse_dispatch:
-
- template <typename G1, typename G2>
- struct reverse_dispatch : detail::reverse_dispatch
- <
- geometry_id<G1>::type::value,
- geometry_id<G2>::type::value
- >
- {};
-
-Because of the order in geometry_id, we can arrange (template) parameters in that order,
-in specializations. So the detail structure looks like:
-
- namespace detail
- {
- template <int Id1, int Id2>
- struct reverse_dispatch : boost::mpl::if_c
- <
- (Id1 > Id2),
- boost::true_type,
- boost::false_type
- >
- {};
- }
-
-and our distance function will be modified again with some template meta-programming: We get
-
- return boost::mpl::if_c
- <
- boost::geometry::reverse_dispatch <G1, G2>::type::value,
- dispatch::distance_reversed
- <
- typename tag<G1>::type,
- typename tag<G2>::type,
- G1, G2,
- // strategy
- >,
- dispatch::distance
- <
- typename tag<G1>::type,
- typename tag<G2>::type,
- G1, G2,
- // strategy
- >
- >::type::apply(g1, g2, s);
+[heading Summary]
-Where the `dispatch::distance_reversed` is a specific struct, forwarding its call to
-`dispatch::distance`, reversing all its template arguments and function arguments.
+In this design rationale, __boost_geometry__ is step by step designed using tag dispatching,
+concepts, traits, and metaprogramming. We used the well-known distance function
+to show the design.
+
+__boost_geometry__ is designed like described here, with
+some more techniques as automatically reversing template arguments, tag casting,
+and reusing implementation classes or dispatch classes as policies in other
+dispatch classes.
[endsect] [/ end of section Design Rationale]
Modified: trunk/libs/geometry/doc/geometry.qbk
==============================================================================
--- trunk/libs/geometry/doc/geometry.qbk (original)
+++ trunk/libs/geometry/doc/geometry.qbk 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
@@ -66,8 +66,16 @@
[def __boost_geometry__ Boost.Geometry]
+[def __boost_array__ Boost.Array]
+[def __boost_fusion__ Boost.Fusion]
+[def __boost_mpl__ Boost.MPL]
+[def __boost_range__ Boost.Range]
+[def __boost_tuple__ Boost.Tuple]
[def __boost_gil__ [@http://www.boost.org/libs/gil/ Boost.GIL]]
+[def __ttmath__ [@http://www.ttmath.org/ ttmath]]
+[def __ogc__ [@http://www.opengeospatial.org OGC]]
+
[heading Contributions]
Boost.Geometry contains contributions by:
@@ -86,3 +94,4 @@
[include matrix.qbk]
[include reference.qbk]
[include about_documentation.qbk]
+[include acknowledgments.qbk]
Deleted: trunk/libs/geometry/doc/html/output_main.png
==============================================================================
Binary file. No diff available.
Modified: trunk/libs/geometry/doc/introduction.qbk
==============================================================================
--- trunk/libs/geometry/doc/introduction.qbk (original)
+++ trunk/libs/geometry/doc/introduction.qbk 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
@@ -15,15 +15,14 @@
__boost_geometry__ (aka Generic Geometry Library, GGL), part of collection of
the Boost C++ Libraries, defines concepts, primitives and algorithms for solving
-computational geometry problems.
+geometry problems.
__boost_geometry__ contains a dimension-agnostic, coordinate-system-agnostic
-and scalable kernel, based on concepts, meta-functions and tag- dispatching.
+and scalable kernel, based on concepts, meta-functions and tag dispatching.
On top of that kernel, algorithms are built: area, length, perimeter, centroid,
convex hull, intersection (clipping), within (point in polygon), distance,
-envelope (bounding box), simplify, transform, convert, and more.
-The library is also designed to support high precision arithmetic numbers,
-such as __gmp__.
+envelope (bounding box), simplify, transform, and much more.
+The library supports high precision arithmetic numbers, such as __ttmath__.
__boost_geometry__ contains instantiable geometry classes, but library users can
also use their own. Using registration macros or traits classes their geometries
@@ -32,11 +31,7 @@
__boost_geometry__ might be used in all domains where geometry plays a role:
mapping and GIS, game development, computer graphics and widgets, robotics,
astronomy and more. The core is designed to be as generic as possible and support
-those domains. However, for now the development has been mostly GIS-oriented.
-
-__boost_geometry__ supports the extension model, the same way as __boost_gil__
-also applies it. An extension is (mostly) something more specific to
-like mentioned above.
+those domains. For now, the development has been mostly GIS-oriented.
The library follows existing conventions:
@@ -44,9 +39,18 @@
* conventions from the std library
* conventions and names from one of the __ogc__ standards on geometry
-The library can be downloaded from the Boost Sandbox, go to the download page
-for more information.
-
-__boost_geometry__ bug tracker and Wiki are available at http://trac.osgeo.org/ggl/
+The library can be downloaded from [@http://svn.boost.org/svn/boost/trunk Boost.Trunk],
+from [@http://svn.boost.org/svn/boost/branches/release Boost.Release], or will come
+to you by the normal Boost distribution process. Note that [*extensions] are
+only distributed in Boost.Trunk, and that they are subject to change.
+
+__boost_geometry__ was accepted by Boost at November 28, 2009
+([@http://permalink.gmane.org/gmane.comp.lib.boost.announce/246 review report]).
+
+There are two mailing lists
+where __boost_geometry__ is discussed: the boost developers list, and also the
+[@http://lists.osgeo.org/mailman/listinfo/ggl GGL mailing list] at osgeo, at which, at the moment of writing, more than 70 people
+are subscribed. The mailing list is also accessible from
+[@http://boost-geometry.203548.n3.nabble.com/ Nabble] as Boost Geometry.
[endsect]
Modified: trunk/libs/geometry/doc/quickstart.qbk
==============================================================================
--- trunk/libs/geometry/doc/quickstart.qbk (original)
+++ trunk/libs/geometry/doc/quickstart.qbk 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
@@ -12,26 +12,84 @@
[section:quickstart Quick Start]
-It is not possible to present all features of the whole library at a glance.
-However, a few very small examples are shown below.
+This Quick Start section shows some of the features of __boost_geometry__
+in the form of annotated, relatively simple, code snippets.
-[main1]
+The code below assumes that `boost/geometry.hpp` is included, and that `namespace
+boost::geometry` is used. __boost_geometry__ is header only, so including
+headerfiles is enough. There is no linking with any library necessary.
-The pieces above generate this output:
+[quickstart_include]
-[$output_main.png]
+[h3 Cartesian]
+
+It is possible to use only a small part of the library. For example: the
+distance between two points is a common use case. __boost_geometry__ can calculate
+it from various types. Using one of its own types:
+
+[quickstart_distance]
+
+If the right headers are included and the types are bound to a coordinate
+system, various other types can be used as points: plain C array's, __boost_array__'s,
+__boost_tuple__'s, __boost_fusion__ imported structs, your own classes...
+
+Registering and using a C array:
+[quickstart_register_c_array]
+[quickstart_distance_c_array]
+
+Another often used algorithm is point-in-polygon. It is implemented in __boost_geometry__
+under the name `within`. We show its usage here checking a __boost_tuple__ (as a point)
+located within a polygon, filled with C Array point pairs.
+
+But it is first necessary to register a __boost_tuple__, like the C array:
+[quickstart_register_boost_tuple]
+[quickstart_point_in_polygon]
+
+We can calculate the area of a polygon:
+[quickstart_area]
+
+By the nature of a template library, it is possible to mix point types.
+We calculate distance again, now using a C array point and a __boost_tuple__ point:
+[quickstart_distance_mixed]
+
+The snippets listed above generate the following output:
+
+[pre
+Distance p1-p2 is: 1.41421
+Distance a-b is: 2.23607
+Point p is in polygon? true
+Area: 3.015
+Distance a-p is: 2.87924
+]
+
+
+[h3 Non-Cartesian]
It is also possible to use non-Cartesian points. For example: points on a sphere.
When then an algorithm such as distance is used the library "inspects" that it
is handling spherical points and calculates the distance over the sphere,
instead of applying the Pythagorean theorem.
-Finally an example from a totally different domain: developing window-based applications,
-for example using QtWidgets. We check if two rectangles overlap and if so, move the second
-one to another place:
+[note __boost_geometry__ supports a geographical coordinate system, but that is
+in an extension and not released in the current Boost release.]
+
+We approximate the Earth as a sphere and calculate the distance between Amsterdam
+and Paris:
+[quick_start_spherical]
+
+It writes: [pre Distance in miles: 267.02]
+
+[h3 Adapted structs]
+
+Finally an example from a totally different domain: developing window-based
+applications, for example using QtWidgets. As soon as Qt classes are registered
+in __boost_geometry__ we can use them. We can, for example, check if two
+rectangles overlap and if so, move the second one to another place:
+
+[quickstart_qt]
-[main3]
-More examples are on the page Examples
+[h3 More]
+In the reference many more examples can be found.
[endsect]
Modified: trunk/libs/geometry/doc/src/examples/Jamfile.v2
==============================================================================
--- trunk/libs/geometry/doc/src/examples/Jamfile.v2 (original)
+++ trunk/libs/geometry/doc/src/examples/Jamfile.v2 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
@@ -13,5 +13,8 @@
: # requirements
;
+exe quick_start : quick_start.cpp ;
+
build-project algorithms ;
+build-project core ;
build-project geometries ;
Modified: trunk/libs/geometry/doc/src/examples/quick_start.cpp
==============================================================================
--- trunk/libs/geometry/doc/src/examples/quick_start.cpp (original)
+++ trunk/libs/geometry/doc/src/examples/quick_start.cpp 2011-05-07 13:46:02 EDT (Sat, 07 May 2011)
@@ -13,23 +13,33 @@
// http://www.boost.org/LICENSE_1_0.txt)
//
-#include <boost/tuple/tuple.hpp>
#if defined(_MSC_VER)
// We deliberately mix float/double's here so turn off warning
//#pragma warning( disable : 4244 )
#endif // defined(_MSC_VER)
+//[quickstart_include
+
#include <boost/geometry.hpp>
-#include <boost/geometry/algorithms/overlaps.hpp>
-#include <boost/geometry/geometries/geometries.hpp>
+
+using namespace boost::geometry;
+//]
+
#include <boost/geometry/geometries/register/point.hpp>
-#include <boost/geometry/geometries/adapted/c_array.hpp>
-BOOST_GEOMETRY_REGISTER_BOOST_TUPLE_CS(cs::cartesian)
+//[quickstart_register_c_array
+#include <boost/geometry/geometries/adapted/c_array.hpp>
+
BOOST_GEOMETRY_REGISTER_C_ARRAY_CS(cs::cartesian)
+//]
+
+//[quickstart_register_boost_tuple
+#include <boost/geometry/geometries/adapted/boost_tuple.hpp>
+BOOST_GEOMETRY_REGISTER_BOOST_TUPLE_CS(cs::cartesian)
+//]
// Small QRect simulations following http://doc.trolltech.com/4.4/qrect.html
// Todo: once work the traits out further, would be nice if there is a real example of this.
@@ -89,33 +99,48 @@
}}}
-void example_for_main_page()
+int main(void)
{
+ //[quickstart_distance
+ model::d2::point_xy<int> p1(1, 1), p2(2, 2);
+ std::cout << "Distance p1-p2 is: " << distance(p1, p2) << std::endl;
+ //]
- //[main1
- //` Snippets below assume the namespace boost::geometry is known
- using namespace boost::geometry;
-
- //` It should be possible to use a very small part of the library, for example only the distance between two points.
+ //[quickstart_distance_c_array
int a[2] = {1,1};
int b[2] = {2,3};
double d = distance(a, b);
- std::cout << "Distance a-b is:" << d << std::endl;
-
- //` Other often used algorithms are point-in-polygon:
+ std::cout << "Distance a-b is: " << d << std::endl;
+ //]
+
+ //[quickstart_point_in_polygon
double points[][2] = {{2.0, 1.3}, {4.1, 3.0}, {5.3, 2.6}, {2.9, 0.7}, {2.0, 1.3}};
model::polygon<model::d2::point_xy<double> > poly;
append(poly, points);
boost::tuple<double, double> p = boost::make_tuple(3.7, 2.0);
- std::cout << "Point p is in polygon? " << (within(p, poly) ? "YES" : "NO") << std::endl;
-
- //` or area:
+ std::cout << "Point p is in polygon? " << std::boolalpha << within(p, poly) << std::endl;
+ //]
+
+ //[quickstart_area
std::cout << "Area: " << area(poly) << std::endl;
+ //]
- //` It is possible, by the nature of a template library, to mix the point types declared above:
+ //[quickstart_distance_mixed
double d2 = distance(a, p);
- std::cout << "Distance a-p is:" << d2 << std::endl;
-
+ std::cout << "Distance a-p is: " << d2 << std::endl;
+ //]
+
+ //[quick_start_spherical
+ typedef boost::geometry::model::point
+ <
+ double, 2, boost::geometry::cs::spherical<boost::geometry::degree>
+ > spherical_point;
+
+ spherical_point amsterdam(4.90, 52.37);
+ spherical_point paris(2.35, 48.86);
+
+ double const earth_radius = 3959; // miles
+ std::cout << "Distance in miles: " << distance(amsterdam, paris) * earth_radius << std::endl;
//]
/***
@@ -126,7 +151,7 @@
std::cout << "Distance A'dam-Paris: " << distance(amsterdam, paris) / 1000.0 << " kilometers " << std::endl;
***/
- //[main3
+ //[quickstart_qt
QRect r1(100, 200, 15, 15);
QRect r2(110, 210, 20, 20);
if (overlaps(r1, r2))
@@ -134,40 +159,7 @@
assign_values(r2, 200, 300, 220, 320);
}
//]
-}
-
-
-void example_for_transform()
-{
- using namespace boost::geometry;
-
- typedef model::point<double, 3, cs::cartesian> XYZ;
- typedef model::point<double, 3, cs::spherical<degree> > SPH;
- XYZ p;
-
- SPH sph1, sph2;
- assign_values(sph1, 12.5, 41.90, 1.0);
- // Go from spherical to Cartesian-3D:
- transform(sph1, p);
- // Go back from Cartesian 3D to spherical:
- transform(p, sph2);
-
- std::cout << dsv(p) << " <-> " << dsv(sph2) << std::endl;
-
- typedef model::d2::point_xy<double> XY;
- typedef model::d2::point_xy<int> PIXEL;
- XY xy(50, 50);
- strategy::transform::map_transformer<XY, PIXEL, false> map(0, 0, 100, 100, 1024, 768);
- PIXEL pix;
- transform(xy, pix, map);
- std::cout << pix.x() << "," << pix.y() << std::endl;
-
-}
-
-
-int main(void)
-{
- example_for_main_page();
- example_for_transform();
+
return 0;
}
+
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk