Geodetic Development Tool

[kil...@killetsoft.de]

Hi,

who develops programs with geodetic functionality like coordinate transformations, datum shifts or distance calculations, can use geodetic functions from my Geodetic Development Tool GeoDLL. The Dynamic Link Library can easily be used with most of the modern programming languages like C, C++, C#, Basic, Delphi, Pascal, Java, Fortran, xSharp, MS-Office and others to add geodetic functionality to own applications. For many programming languages ​Interfaces and Examples are available.

GeoDLL is a Geodetic Development Tool or a Geodetic Function Library for worldwide 2D and 3D Coordinate Transformations and Datum Shifts with highest accuracy and for calculating Meridian Convergence and many Extra Parameters. Furthermore: Helmert and Molodensky Parameters, NTv2, HARN, INSPIRE, EPSG, Digital Elevation Model (DEM), distance and Time Zone calculations and much more. GeoDLL is available as 32Bit and 64Bit DLL and as C / C++ source code.

The DLL is very fast, save and compact thanks to the consistent development in C / C++ with Microsoft Visual Studio. The geodetic functions are available in 32bit and 64bit architecture. All functions are prepared for multithreading and server operating.

You find a free downloadable test version on https://www.killetsoft.de/p_gdla_e.htm
Notes about the NTv2 support can be found here: https://www.killetsoft.de/p_gdln_e.htm
Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm

Fred
Email: info_at_killetsoft.de

[Alf P. Steinbach]

Sounds nice but I don't understand why a geodetic library needs to be
Windows-specific?


Cheers!,

- Alf

[Öö Tiib]

It was likely just spam and poster does not read replies. Cursory
eyeballing the site finds indications that perhaps they just hope
you buy the codes and do porting yourself:

"GDLLSOURCE GeoDLL complete C++ source code of all groups EUR 4000.00"
by https://www.killetsoft.de/p_prei_e.htm#geodll

"The source is extensively written in ANSI-C++, so that the migration to arbitrary operating systems and hardware platforms is possible with minor modifications."
by https://www.killetsoft.de/p_gdla_e.htm

[Fred Killet]

Yes, 20000 lines of source code with geodetic functions have their
price. However, WINDOWS programmers have the advantage to integrate
geodetic functions as a DLL. That is already possible from 500 euros.
Fred

[Jorgen Grahn]

On Tue, 2019-07-30, Öö Tiib wrote:
> On Tuesday, 30 July 2019 13:45:11 UTC+3, Alf P. Steinbach wrote:

...

>> Sounds nice but I don't understand why a geodetic library needs to be
>> Windows-specific?
>
> It was likely just spam and poster does not read replies. Cursory
> eyeballing the site finds indications that perhaps they just hope
> you buy the codes and do porting yourself:

I have a feeling there's a good ecosystem around libproj, QGis and so
on for Free Software-oriented people ... although my experience is
limited to conversions between coordinate systems, using libproj.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Chris M. Thomasson]

shared object files on Linux should work fine.

[Paavo Helde]

It takes some knowledge and experience to prepare a binary C++ .so which
would work on most Linuxes, especially if it is using a lot of
third-party libraries. The default model in Linux is to use the
system-installed C++ runtimes, but there have been ABI-breaking changes
in those runtimes, so one just cannot compile a .so on a random Linux
box and hope it will work everywhere. Third-party libraries with C++
interfaces will add many complications, one could either use
system-installed ones or package them together with your own .so, both
approaches have serious drawbacks.

In short, the easiest way to install custom software (not included in
package manager repos) in Linux is to build it directly on the target box.

[Öö Tiib]

Who knows. Majority of Windows DLL-s have actually kind of language
agnostic service interface that provides remote process call objects
(COM). COM might simplify linking to C#, Visual basic
or Ms access but is not easily portable to other platforms.

[Bonita Montero]

>> Yes, 20000 lines of source code with geodetic functions have their
>> price. However, WINDOWS programmers have the advantage to integrate
>> geodetic functions as a DLL. That is already possible from 500 euros.
>> Fred

> shared object files on Linux should work fine.

Maybe he estimates that there will be no customers with Linux?

[Chris M. Thomasson]

Humm... It would be wise to create the shared object API using C. The
guts can be C++, exceptions aside for a moment... but the API would be
all in C. A little C++ wrapping up the C shared API would work. Sound a
little better? Plugin interface.

[Chris M. Thomasson]

Perhaps. Afaict, he can do it with OpenGL for rendering, C for
interface, C++ for guts? Humm...

[Paavo Helde]

Yes, this is a good approach for some C++ libraries, but requires extra
work and may hinder performance. Another good approach is to create
header-only libraries, so there is no .so to link to.

[Chris M. Thomasson]

Agreed. Sometimes, its hard to beat a pure header based lib. I am quite
fond of GLM:

https://glm.g-truc.net/0.9.2/api/a00001.html

;^)

[Manfred]

There is always the possibility for the vendor to provide binary
packages for major distros.
For the vendor this is considerably harder than delivering sources,
nonetheless the process can be fairly automated, at the advantage of not
having to disclose the source code - which in this case appears to be
worth an order of magnitude difference in price.

[Soviet_Mario]

On 31/07/2019 09:36, Paavo Helde wrote:
> On 31.07.2019 9:08, Chris M. Thomasson wrote:
>> On 7/30/2019 7:32 AM, Fred Killet wrote:
>>> Yes, 20000 lines of source code with geodetic functions
>>> have their
>>> price. However, WINDOWS programmers have the advantage to
>>> integrate
>>> geodetic functions as a DLL. That is already possible
>>> from 500 euros.
>>> Fred
>>
>> shared object files on Linux should work fine.
>
> It takes some knowledge and experience to prepare a binary
> C++ .so which would work on most Linuxes, especially if it
> is using a lot of third-party libraries. The default model
> in Linux is to use the system-installed C++ runtimes, but
> there have been ABI-breaking changes in those runtimes, so
> one just cannot compile a .so on a random Linux box and hope
> it will work everywhere. Third-party libraries with C++
> interfaces will add many complications, one could either use
> system-installed ones or package them together with your own
> .so, both approaches have serious drawbacks.

in Linux there is an ongoing trend to "seal" some package in
order not to depend on anything external (but the kernel
itself) and to interact as little as possible.
The solutions are various and do not have standards yet
(some are totally open, some seem rather single-firm backed)

the ones I've come across are
* SNAP runtime (Canonical, Ubuntu world and Mint)
* FLATPAKREF packages (who ? dunno => flathub.org)
* APPIMAGE (open : this does not even add a repo or install
anything at all, there is a single huge executable
containing all it will need)
* other I still don't know

If one really wants to target linux world and is a skilled
programmer, maybe today does not have to target each distro
one by one, but to try install-less solution as above.
I find the most handy and practical solutions are AppImage,
expecially if a centralized update service is not required
for safety reasons (AppImages are "STILL" never handled
centrally, but a heavy user could always keep up-to-date by
themselves in need)

>
> In short, the easiest way to install custom software (not
> included in package manager repos) in Linux is to build it
> directly on the target box.
>
>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)