Activity for Charles Karney
-
Charles Karney posted a comment on discussion Help
Sorry to be so late answering this... The documentation in the C++ library explains how to interpret the azimuth at one of the poles: If either point is at a pole, the azimuth is defined by keeping the longitude fixed, writing latitude = ±(90° − ε), and taking the limit ε → 0+. Let me know of you have further questions.
-
GeographicLib 2.4 (released 2023-07-14)
-
GeographicLib is a fairly standard C++ library and CMake is a fairly standard way of compiling and installing such libraries. So I recommend that you first seek help on a C# forum on how to use C++ libraries with your C# application.
-
Yes, the method is now included in GeographicLib 2.3 (released July 2023). See the Intersect class and the IntersectTool utility.
-
There are three problems with your suggested scheme: The gnomonic projection is a bad starting point because it badly distorts areas. An equal area projection, e.g., Albers conic, is a better choice. But understand that this would only "work" if your polygon had a relatively small extent, say 100 km or less. Your proposed triangulation scheme then has the problem (a) that it will be slow, O(n^2), I think, and (b) that it's wrong since you don't weight the vertices of the succeeding triangles according...
-
GeographicLib 2.3 (released 2023-07-25)
-
Your .pro seems OK. But then I don't know the intricacies of .pro files. How does your application find bin/GeographicLib.dll? Is the bin directory in you PATH? Your problems are, most likely, nothing to do with GeographicLib but instead how you use any external library in your program. In this case, you need to seek help in a Qt-specific forum. Since your sample code is from ArcGis, maybe you can get help there. If you do resolve your problem, please post the solution to this forum so others can...
-
You don't give enough details to diagnose your problem. But it looks like the linker doesn't know the location of the GeographicLib library. That would be the place to look. Can you link any external library to your application? If not, then you need to seek help in a Qt-specific forum. I haven't messed with Qt's .pro files for many years. Instead, I build Qt projects with CMake. (Qt Creator can handle CMake builds.) In this case, you just use find_package(GeographicLib ...) to tell the system where...
-
No... The Python package contains just a subset of the functionality of the C++ library and the Python package will only be updated if there's some update to the core geodesic routines. At present, I have no plans to port the functionality of the Intersect class to Python.
-
For a multithreaded application, you need to read in all the data you need before entering the multithreaded portion of your code using either the Cache or CacheAll methods. See https://geographiclib.sourceforge.io/1.52/NET/classNETGeographicLib_1_1Geoid.html#a30fd83f3947872f9da6db81113895bef https://geographiclib.sourceforge.io/1.52/NET/classNETGeographicLib_1_1Geoid.html#a2bb6942e8979d9dc54f5b9ec32f154bb Be warned that NETGeographicLib is no longer actively supported.
-
Thanks for the update!
-
Equations B1 and B2 apply to the interception problem.
-
You might also try the modifications to the algorithm of Baselga and Matinez-Llario that I give in Appendix B of https://arxiv.org/abs/2308.00495 . This should converge more rapidly (quadratically) and you can check this by printing s_ax for each iteration. Please post any data you get on the relative convergence rates.
-
This paper only deals with the intersection of geodesics. The point to line problem is only briefly mentioned.
-
GeographicLib 2.3 (released 2023-07-25)
-
GeographicLib 2.2 (released 2023-03-07)
-
GeographicLib 2.2 (released 2023-03-07)
-
GeographicLib 2.1.2 (released 2022-12-13)
-
There are a number of things going on with this projection SPHEROID is not WGS84 but Clarke 1880 PRIMEM is not Greenwich but Paris UNIT is not degrees by grad TOWGS84 is non-zero Presumably the central_medidian is relative to Paris? GeographicLib doesn't know how to map a point on WGS84 to this spheroid+datum. I can't help you with this; PROJ would be the tool I would look into using. Once you've mapped you point of interest to a latitude+longitude on this datum, then you can use GeographicLib::LambertConformalConic...
-
Better to say I do the Forward() operation 1+n times. 1 as part of construction and n for the n points to be projected. Because of the simple way lon0 enters into this projection, I elected not to incorporate it as part of the construction. Instead you specify it on each call to Forward and Reverse. Usually k1 = 1 if there are two distinct standard parallels. I hesitate to say "always".
-
Better to say I do the Forward() operation 1+n times. 1 as part of construction and n for the n points to be projected. Because of the simple way lon0 enters into this projection, I elected not to incorporate it as part of the construction. Instead you specify it on each call to Forward and Reverse. Usually k1 = 1 is there are two distinct standard parallels. I hesitate to say "always".
-
The coordinates are shifted so that the projected coordinates at phi0/lam0 are X0/Y0. The example examples/example-LambertConformalConic.cpp shows how to handle this. This example is for the Pennsylvania South coordinate system. However the French projection is similar. Compare https://www.spatialreference.org/ref/epsg/3364/html/ https://www.spatialreference.org/ref/epsg/2154/html/
-
Geodesics on an arbitrary ellipsoid of revolution
-
GeographicLib 2.1.1 (released 2022-07-25)
-
To answer your question about why the same latitude value results in different northings, you need to examine the latitude/longitude lines for TM, e.g., as given in the Wikipedia article on TM.
-
Sorry, I accidentally deleted your recent post requiring moderation...
-
You're right -- up to a point. You still need to make sure that the latitudes of the two point match (apart from a sign). If you're still having problems, set the central longitude to 0 and plot lines of equal latitude and longitude in TM coordinates. Make sure you understand this before worrying about changing the central longitude.
-
You'll only get the behavior you expect if fabs(coord_1.Latitude()) = fabs(coord_2.Latitude()) A degree separation in longitude corresponds to a shorter distance at higher latitudes. The origin for the northing is the equator and so, obviously, the northings will only match if the latitudes match.
-
Bug (+ fix) in the DST class
-
FYI, I did a fresh checkout of vcpkg. Then, in a VS 2022 command shell, I did: .\vcpkg\bootstrap-vcpkg.bat .\vcpkg\vcpkg.exe install geographiclib:x64-windows --debug > build.log This completed successfully. I attach build.log.
-
Sorry, you've run beyond my knowledge of vcpkg on Windows. Perhaps you can confirm that you can download and compile the source manually without vcpkg. Then I suggest you post an issue on vcpkg. It's obviously best if you can pinpoint the problem with the vcpkg port (as I said, you're probably in a better position to do this than me). I still have a sneaking suspicion that there's something broken in your setup ("Please ensure your system has sufficient memory" + "Restarting build without parallelism")....
-
The first error in the log file is: MT: command "C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe /nologo /manifest bin\TransverseMercatorProj.exe.manifest /outputresource:bin\TransverseMercatorProj.exe;#1" failed (exit code 0x1f) with the following output: mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "bin\TransverseMercatorProj.exe". Access is denied. which suggests that it's some problem on your end (bad permissions, some other process had the file...
-
John, I'd appreciate if you could apply this PR and confirm that this resolves your problems. I can then push for the vcpkg maintainers to merge the PR. Thanks.
-
This PR starts with version 2.1 of GeographicLib. That's where the changes were made. (Windows users who don't use vcpkg will then benefit.)
-
I submitted this PR to update GeographicLib to 2.1 in vcpkg. It's waiting for approval.
-
GeographicLib 2.1 (released 2022-06-09)
-
Attached patch file deals with the std::c++latest warnings across the whole code base. This patch supersedes the previous one. The strategy is: In header files: modify the code In source files: use pragma to disable the warning. I also added the std:c++latest flag in the toplevel CMakeLists.txt file to catch these issues going forward. You can apply these patches to the r2.0 release. They have been applied to the main branch of the git repository.
-
I'll need to check all instances of enum op float that VS is now complaining about. No plans to update vcpkg because the next version of GeographicLib will appear within a month. Change of library name (Geographic -> GeographicLib) was noted in change list. Perhaps you could just compile the library yourself with this picky flag and send me the results -- maybe it's just DMS.cpp that needs attention (but surely Math.cpp does too).
-
Please apply the attached patch and try again. (You can list it as a patch for vcpkg.) I'd appreciate hearing back from you whether this works and whether you encounter any other issues.
-
More post release cleanup
-
Post release documentation cleanup
-
Final set up documentation updates for version 2.0
-
Update README.md
-
Get ready for 2.0-rc1
-
Update README.md
-
Merge from devel
-
Several minor doc fixes.
-
Revert URL for random doc; get rid of deadwood in GeodesicExact.cpp.
-
Introduce Math::qd, Math::dm, Math::ms
-
Move geodesic-papers and misc to geographiclib-doc repo.
-
An intermediate commit on the release branch to join histories
-
Version 2.0-rc1
-
Version 2.0 (2022-05-06)
-
Merge from devel
-
Fix round-off bug in Geodesic inverse (exhibited in long double).
-
Add optional comment arg to Utility::ParseLine.
-
Update copyright year. Fix geodtest for arm processor.
-
GeographicLib 2.0 (released 2022-05-06)
-
The "normal" ways people use GeographicLib are: using the utilities in a command shell or in scripts; writing C++ programs (which might possibly offer a GUI interface!) which link with the library. It sounds like the first is likely to be the most useful method for you. Assuming that PATH includes the directory where the utilities are stored (and the error message you got indicates that this might not be the case), you can open a CMD shell and type echo 1 2 3 4 | GeodSolve -i to determine the shortest...
-
The last argument in you call to Position returns the area, which I'm careful to spell with a capital S, S12 (in m^2 so it's usually a big number). The distance is just the first argument s, of course. You can also then make the simpler call l.Position(s, lat2, lon2, azi). Let me know if this clears up your problem.
-
Correct. The methods in C++ library typically only return single values. For most methods, the results are via reference arguments.
-
The last argument in you call to Position returns the area, which I'm careful to spell with a capital S, S12 (in m^2 so it's usually a big number). The distance is just the first argument s, of course. Let me know if this clears up your problem.
-
The source code for an alpha version of the new release is in the distrib-C++ directory under files download tab. This is NOT FOR USE IN PRODUCTION. I might (will!) change the tar/zip files without warning. This is version 2.0 which folds in lots of changes (yet to be documented) in how things are organized.
-
This problem had already been fixed and will be available in the next release (which I'm hoping will before June 1). Your fix is fine but suboptimal. The problem is that identifiers starting with _[A-Z] or __ are "reserved", see https://en.cppreference.com/w/cpp/language/identifiers My fix was to change _E1 to _eE1. That's better than using __E1. I recommend you do the same as me in case Sun decides to use __E1 for something.
-
The problem is indeed resolved. Thanks!
-
Creating a new shell for GeographicLib fails
-
Roll to version 2.0.
-
Remove Java, JavaScript, MATLAB/Octave, Python, C, Fortran versions
-
Fix bug where a geodesic with lat1 = 0 and lat2 = nan was treated as
-
Fix typo
-
_D0 renamed to _D0fix because _D0 is a preprocessor symbol on QNX
-
Rename identifiers that begin with _[A-Z]
-
Put GeodesicExactC4.cpp back into GeodesicExact.cpp.
-
Document use of fractional years in MagneticModel.
-
EllipticFunction: Specify restrictions on args.
-
Remove unneeded _exact in RhumbLine + unneeded Utility::ParseLine.
-
Workaround boost enum bug; use delete idiom for disabling ctrs.
-
Some house cleaning. Fix doi in documentation.
-
Use fabs, fmin, fmax instead of abs, min, max on reals.
-
Remove deprecated function (MajorRadius() and functions in cmath).
-
Miscellaneous house cleaning
-
Allow for more general test programs.
-
Deal with +/-0 deg and +/-180 deg in a more principled way
-
Simplify cmake/autoconf/make configurations
-
Create VERSION file in release tarballs.
-
Update web links to reflect new organization of documenation
-
Cmake changes to support RELEASE build
-
Check GEOGRAPHICLIB_PRECISION with find_package(GeographicLib)
-
Allow make dist in RELEASE mode.
-
Lib name Geographic->GeographicLib; variables for installation dirs.
-
Move random doc files at top level to misc directory.
-
Clean up test-distribution script
-
Introduce version suffix = -alpha.
-
Add more tests for fixed point output. Skip tests on Windows.
-
Reorganize distribution directories.
-
Tweak for sign of err in sum. Minor fix in Geodesic.cpp.
-
Add more tests to signtest.cpp.
-
Introduce sincosde.
-
Add Geodesic::STANDARD, etc., mask
-
Add sanitize cmake target to check whitespace hygiene
1 >