|
|
Geometry : |
Subject: [ggl] Re: Move a point_ll by a distance
From: Richard Ulrich (richi)
Date: 2009-10-21 17:35:56
Hi Barend,
many thanks for the code. I thought it would be more complicated than
that. But it works perfectly well.
Meanwhile I ran into another problem.
In one sourcefile I use the wkt streaming operator without problems, but
in another file, I get a compiler error as soon as I include
<streamwkt.hpp> on the following statement:
void flight_grabber::read_json(const boost::filesystem::path &jsonfile)
{
std::cout << "Reading json file : " << jsonfile << std::endl;
error: ambiguous overload for ?operator<<? in ?std::operator<<
[with_Traits = std::char_traits<char>](((std::basic_ostream<char,
std::char_traits<char> >&)(& std::cout)), ((const char*)"Reading json
file : ")) << jsonfile?
geometry/io/wkt/streamwkt.hpp:29: note: candidates are:
std::basic_ostream<_CharT, _Traits>&
operator<<(std::basic_ostream<_CharT, _Traits>&, const G&) [with CH =
char, TR = std::char_traits<char>, G =
boost::filesystem::basic_path<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
boost::filesystem::path_traits>]
Any idea why that could be and how to resolve it?
Rgds
Richard
On Wed, 2009-10-21 at 12:00 -0400, ggl-request_at_[hidden] wrote:
> Send ggl mailing list submissions to
> ggl_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.osgeo.org/mailman/listinfo/ggl
> or, via email, send a message with subject or body 'help' to
> ggl-request_at_[hidden]
>
> You can reach the person managing the list at
> ggl-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ggl digest..."
>
>
> Today's Topics:
>
> 1. Re: Move a point_ll by a distance (Richard Ulrich)
> 2. Re: Move a point_ll by a distance (Barend Gehrels)
> 3. changes for consistency (Barend Gehrels)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 20 Oct 2009 23:18:32 +0200
> From: Richard Ulrich <richi_at_[hidden]>
> Subject: Re: [ggl] Move a point_ll by a distance
> To: ggl_at_[hidden]
> Message-ID: <1256073513.7406.17.camel_at_sub-ubuntu>
> Content-Type: text/plain
>
> Hi Barend,
>
> thanks for helping.
>
> If I try to view the file, SVN asks me for username / password.
> And updating my working copy from boost sandbox I don't see the file.
> Can you send it to me?
>
> Of course you can mention my projects although I'm using only a small
> fraction of ggl:
>
> http://sourceforge.net/projects/flugbuch2
> For the flight logbook, I use the ggl classes mainly for typesafety
> reasons. geometry::point_ll is more expressive and saver than
> std::pair<double, double>. Additionally I use distance calculation.
> And for the future, I think I read somewhere in the docs about grid
> conversions (Hopefully SwissGrid and UTM are already supported)
>
> http://sourceforge.net/projects/flightpred
> For my new project I started using ggl for the same typesafety concerns.
> At the moment I want to use it to define the bounding box for the
> postgis indexed lookup. More will follow.
>
> At work we develop a commercial CAD system. I told a college about ggl
> and he was interested. But for use there we would wait at least for it
> to be included in the official boost distribution. And the hardest part
> would be to convince our boss who prefers void pointers over templates.
>
> Rgds
> Richard
>
>
>
> On Tue, 2009-10-20 at 12:00 -0400, ggl-request_at_[hidden] wrote:
> > It is not there, but (considering the earth as a sphere) it is not
> > difficult because the necessary formulae are on this (great) website:
> > http://williams.best.vwh.net/avform.htm
> >
> > It is useful, so I added it to an example, which is (now) here:
> > https://svn.geodan.nl/repos/holding/geolib/trunk/src/cpp/library/gl/libs/ggl/example/extensions/gis/latlong/point_ll_example.cpp
> >
> > It contains functions get_course (in case you need it) and
> > point_at_distance (the one you're looking for). For Amsterdam-Paris it
> > works great:
> >
> > // Other way round: have Amsterdam and go 430 km to the south (first calculate direction)
> > double tc = get_course(amsterdam_rad, paris_rad);
> > std::cout << "Course: " << (tc * ggl::math::r2d) << std::endl;
> >
> > point_ll_deg paris_calculated;
> > point_at_distance(amsterdam_rad, 430 * 1000.0, tc, average_earth_radius, paris_calculated);
> > std::cout << "Paris calculated (degree): " << ggl::dsv(paris_calculated) << std::endl;
> >
> > and it outputs:
> > Paris: (2.33306, 48.8667)
> > [...]
> > Course: 154.156037
> > Paris calculated (degree): (2.33150351, 48.8643588)
> >
> > Note that the point is calculated using spherical formulae, so not
> > geodetical. If those formulae exist, I'm interested (didn't search for
> > them this morning). If not, and the spherical is not satisfactory, you
> > could start with the spherical and than make the point more precise in a
> > few steps using the Andoyer or Vincenty distance.
> >
> > By the way, thanks for using GGL. Are we allowed to mention that on the
> > website? If yes, can you describe your use-case in one or two lines?
> >
> > Regards, Barend
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091020/480e0be2/attachment-0001.html
> >
> > ------------------------------
> >
> > _______________________________________________
> > ggl mailing list
> > ggl_at_[hidden]
> > http://lists.osgeo.org/mailman/listinfo/ggl
> >
> >
> > End of ggl Digest, Vol 6, Issue 13
> > **********************************
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 21 Oct 2009 11:57:48 +0200
> From: Barend Gehrels <Barend.Gehrels_at_[hidden]>
> Subject: Re: [ggl] Move a point_ll by a distance
> To: Generic Geometry Library Discussion <ggl_at_[hidden]>
> Message-ID: <4ADEDB1C.3020608_at_[hidden]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Richard,
>
> Thanks for your description.
>
> Sorry, forgot that our SVN needs accounts. I can give you an account if
> you wish. However, we're in preparation for the review, many things are
> changing, so you might wait for a few weeks. We're doing our best to
> have it in Boost :-)
>
> The source code fits in the example 02_point_ll_example, I'll give the
> relevant pieces here:
>
>
> // Formula to get the course (direction) between two points.
> // This might be a GGL-function in the future.
> template <typename P1, typename P2>
> inline double *get_course*(P1 const& p1, P2 const& p2)
> {
> double const& lat1 = ggl::get_as_radian<1>(p1);
> double const& lon1 = ggl::get_as_radian<0>(p1);
> double const& lat2 = ggl::get_as_radian<1>(p2);
> double const& lon2 = ggl::get_as_radian<0>(p2);
> // http://williams.best.vwh.net/avform.htm#Crs
> return atan2(sin(lon1-lon2)*cos(lat2),
> cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon1-lon2));
> }
>
>
> // Formula to calculate the point at a distance/angle from another point
> // This might be a GGL-function in the future.
> template <typename P1, typename P2>
> inline void *point_at_distance*(P1 const& p1,
> double distance, double tc, double radius,
> P2& p2)
> {
> double earth_perimeter = radius * ggl::math::two_pi;
> double d = (distance / earth_perimeter) * ggl::math::two_pi;
> double const& lat1 = ggl::get_as_radian<1>(p1);
> double const& lon1 = ggl::get_as_radian<0>(p1);
>
> // http://williams.best.vwh.net/avform.htm#LL
> double lat = asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc));
> double dlon = atan2(sin(tc)*sin(d)*cos(lat1),cos(d)-sin(lat1)*sin(lat));
> double lon = lon1 - dlon;
>
> ggl::set_from_radian<1>(p2, lat);
> ggl::set_from_radian<0>(p2, lon);
> }
>
> And this can be called like this (the direction is here calculated, but
> you will specified it directly):
>
> // Other way round: have Amsterdam and go 430 km to the south (i.e.
> first calculate direction)
> double tc = get_course(amsterdam, paris);
> std::cout << "Course: " << (tc * ggl::math::r2d) << std::endl;
>
> double const average_earth_radius = 6372795.0;
> point_ll_deg paris_calculated;
> point_at_distance(amsterdam, 430 * 1000.0, tc, average_earth_radius,
> paris_calculated);
> std::cout << "Paris calculated (degree): " <<
> ggl::wkt(paris_calculated) << std::endl;
>
>
> Regards, Barend
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091021/f1a7470c/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 Oct 2009 16:03:43 +0200
> From: Barend Gehrels <Barend.Gehrels_at_[hidden]>
> Subject: [ggl] changes for consistency
> To: Generic Geometry Library Discussion <ggl_at_[hidden]>
> Message-ID: <4ADF14BF.806_at_[hidden]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> 1) The access traits class has been modified to avoid indirection and to
> be consistent with indexed_access. The change is that the Dimension
> template parameter is now the second template parameter of the struct,
> instead of a member template parameter of the set/get functions.
>
> All point structures, registration macro's, tests and examples are
> updated with this respect. Probably your code does not need to change.
>
> However, if you specialized your traits class yourself, you have to change:
>
> from: template <> struct access<mypoint> { template <int Dimension>
> static double get(...) {...} /and also set/ };
>
> to: template<std::size_t Dimension> struct access<mypoint, Dimension> {
> static double get(...) {...} /and also set/ };
>
> The old construct was rather old and could be a bit unhandy in case of
> specializing for e.g. .x and .y. This needed earlier either an
> 'accessor', second specialized struct, or it could be implemented using
> an if(Dimension == 0) etc, which is an inferior solution. The new
> construct can be specialized per dimension, or for one dimension
> forwarding to e.g. boost.tuples.
>
> If there are any questions I'll be helpful.
>
> 2) For consistency, I propose also to modify the strategies to have an
> "apply" method by default, instead of operator(). The operator() was to
> enable functors (C functions) but they cannot be used anyway, in
> (nearly) all cases, because there are type definitions expected by the
> enclosing code. It was decided to have "apply" everywhere, so also here.
> The simplify-strategy did not have an operator() but a method "simplify"
> which is now also renamed to "apply" (besides some other enhancements)
>
> 3) Related to this I also added "concept checking" files for the
> strategies (distance & simplify now).
>
> 4) simplify with an output iterator is now renamed to simplify_inserter
> (like convex_hull_inserter, and like std::back_inserter). This also
> solves the fact that it didn't work for linestring-to-linestring, that
> is working now again.
>
> Besides all these I'm slowly adding tests and updating documentation.
> Test and example folders have a Jamfile now (as expected) and can be
> tested using bjam
>
>
> Regards, Barend
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091021/16ed1320/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
>
>
> End of ggl Digest, Vol 6, Issue 14
> **********************************
>
Geometry list run by mateusz at loskot.net