From 8612b98fd7a15bcfdc53fa90b9dec18bdb35d630 Mon Sep 17 00:00:00 2001 From: Barend Gehrels Date: Sat, 7 May 2011 17:46:02 +0000 Subject: [PATCH] Doc update (general pages) [SVN r71784] --- doc/acknowledgments.qbk | 24 ++++-- doc/design_rationale.qbk | 133 +++++++++---------------------- doc/geometry.qbk | 9 +++ doc/html/output_main.png | Bin 1289 -> 0 bytes doc/introduction.qbk | 30 ++++--- doc/quickstart.qbk | 78 +++++++++++++++--- doc/src/examples/Jamfile.v2 | 3 + doc/src/examples/quick_start.cpp | 104 +++++++++++------------- 8 files changed, 201 insertions(+), 180 deletions(-) delete mode 100644 doc/html/output_main.png diff --git a/doc/acknowledgments.qbk b/doc/acknowledgments.qbk index 3678f49c5..842f6c520 100644 --- a/doc/acknowledgments.qbk +++ b/doc/acknowledgments.qbk @@ -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. +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 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). +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, 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.] +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] diff --git a/doc/design_rationale.qbk b/doc/design_rationale.qbk index b718e8930..c659bee7e 100644 --- a/doc/design_rationale.qbk +++ b/doc/design_rationale.qbk @@ -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 @@ and a function, containing the algorithm: 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 @@ as shown in the distance algorithm at the start of this paragraph. So we wanted 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 - { - template - 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 @@ more complex but attractive for template fans: } }; -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 double distance(P1 const& a, P2 const& b) @@ -181,7 +168,8 @@ The dimension which is referred to is defined using another traits class: 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 @@ A longer version is presented later on, the short function would look like this: struct coordinate_type : traits::coordinate_type

{}; 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 @@ So our computation class becomes: [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 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 double distance(G1 const& g1, G2 const& g2) @@ -489,7 +479,7 @@ systems. typedef pythagoras 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 @@ concepts. This is handled in the upcoming section Concept Checking. 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 @@ Each strategy should define its return type, within the strategy class, for exam 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 @@ and modify our distance function: 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] +[heading Summary] -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. +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. -Then we add a meta-function reverse_dispatch: - - template - struct reverse_dispatch : detail::reverse_dispatch - < - geometry_id::type::value, - geometry_id::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 - 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 ::type::value, - dispatch::distance_reversed - < - typename tag::type, - typename tag::type, - G1, G2, - // strategy - >, - dispatch::distance - < - typename tag::type, - typename tag::type, - G1, G2, - // strategy - > - >::type::apply(g1, g2, s); - -Where the `dispatch::distance_reversed` is a specific struct, forwarding its call to -`dispatch::distance`, reversing all its template arguments and function arguments. +__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] diff --git a/doc/geometry.qbk b/doc/geometry.qbk index 4e2d304c0..b42891feb 100644 --- a/doc/geometry.qbk +++ b/doc/geometry.qbk @@ -66,8 +66,16 @@ All algorithms in Boost.Geometry will check any geometry arguments against the c [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 @@ Boost.Geometry contains contributions by: [include matrix.qbk] [include reference.qbk] [include about_documentation.qbk] +[include acknowledgments.qbk] diff --git a/doc/html/output_main.png b/doc/html/output_main.png deleted file mode 100644 index 184ba5965ed321a90ed0f86d0ade58989a23b64c..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1289 zcmeAS@N?(olHy`uVBq!ia0y~yU<_nnU~uGMVqjo+zLmj>fq~_Mr;B4q#jUqqmw#VQdsWhVwBRIbQ`g>W!TCLm%^Zps=L#{P1D8*ib!zwD|2cpC_0^gI z)9rf>^WD>)yWRgDtC+2ArKA7nSF>W{Mfz^C^w#*FJe?T-FIe^8myf^eKb_lF{%0R^9ozK-5^=sf=7%@&{5;q9o9&BX{DUZG zF=4;Y0qZX;vOl`Eu{V9?@|G=^t$!Sr7h6@#{`=Eq>k0m>U$+EI;W+ea$|dXaXWLtU z-D#Ss_2ygQOUcR8<#(JdtD9EZWHyiK_oI2wXFqvefBmja*!7-O-rE+ly_wv^Re zsW1ClJ@Gdu8|oPhlkF_k4NLoESKM;S*&Fyx@Z0(8whB6HW20DOj_QXV+Hrp|-*V@) zN%Q7u{MFuYWBCOC|K|>G-S$kaM$tY^*zN1)!sE|hSFez~l9`qL>f~Ry(s+lw{%rpB z&(~i&)V^eC7vt|6Q@^~?JW>62S(&Xr3pj8atP?&xzr3m9Q`Vwe#s5lspYqL(SwBZR z&|t%QM(qoq-(Gj!mbd$C9lPGi9Q$K$QWBkQCX+xnmA=D z)6I)l{9XIco7)+*RM4Uapr%U)oZBa+o{{z3c85s6SWzOsOJu@Ta694*i*Xf^m zK1ldjT2AL@ct3CEod3oDjL;W=^pQoH(WZ>>sV*5~3yG_r*@q@YXrCGKGk?HSmK8(8BzFqRc zJddB>_Li@;ulW2SzU}=g&L)UF5qT%RL;ne)fr6`yeX z@u%wEpZ_=AUwtb2O>%hB#`H~VuZF5NX*~{Q$l<&!Ytv)9FTY;YCmWn$PzZ(3(j2?$ USJ;PtR0fHAy85}Sb4q9e0I7P1DF6Tf diff --git a/doc/introduction.qbk b/doc/introduction.qbk index c1a155240..266997946 100644 --- a/doc/introduction.qbk +++ b/doc/introduction.qbk @@ -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 @@ can be adapted to fulfil __boost_geometry__ concepts. __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 @@ The library follows existing conventions: * 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. +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__ bug tracker and Wiki are available at http://trac.osgeo.org/ggl/ +__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] diff --git a/doc/quickstart.qbk b/doc/quickstart.qbk index 98893fc8c..0b46f810e 100644 --- a/doc/quickstart.qbk +++ b/doc/quickstart.qbk @@ -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.] -[main3] +We approximate the Earth as a sphere and calculate the distance between Amsterdam +and Paris: +[quick_start_spherical] -More examples are on the page Examples +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] + + +[h3 More] +In the reference many more examples can be found. [endsect] diff --git a/doc/src/examples/Jamfile.v2 b/doc/src/examples/Jamfile.v2 index 527b07c19..abf06eb59 100644 --- a/doc/src/examples/Jamfile.v2 +++ b/doc/src/examples/Jamfile.v2 @@ -13,5 +13,8 @@ project boost-geometry-doc-src-example : # requirements ; +exe quick_start : quick_start.cpp ; + build-project algorithms ; +build-project core ; build-project geometries ; diff --git a/doc/src/examples/quick_start.cpp b/doc/src/examples/quick_start.cpp index 8b2beb4d2..b246afad0 100644 --- a/doc/src/examples/quick_start.cpp +++ b/doc/src/examples/quick_start.cpp @@ -13,23 +13,33 @@ // http://www.boost.org/LICENSE_1_0.txt) // -#include #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 -#include -#include + +using namespace boost::geometry; +//] + #include + + +//[quickstart_register_c_array #include +BOOST_GEOMETRY_REGISTER_C_ARRAY_CS(cs::cartesian) +//] + +//[quickstart_register_boost_tuple +#include BOOST_GEOMETRY_REGISTER_BOOST_TUPLE_CS(cs::cartesian) -BOOST_GEOMETRY_REGISTER_C_ARRAY_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 @@ struct indexed_access }}} -void example_for_main_page() +int main(void) { + //[quickstart_distance + model::d2::point_xy 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 > poly; append(poly, points); boost::tuple 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 + > 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 @@ void example_for_main_page() 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 @@ void example_for_main_page() assign_values(r2, 200, 300, 220, 320); } //] -} - - -void example_for_transform() -{ - using namespace boost::geometry; - - typedef model::point XYZ; - typedef model::point > 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 XY; - typedef model::d2::point_xy PIXEL; - XY xy(50, 50); - strategy::transform::map_transformer 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; } +