From: skybuckflying@gmail.com   
      
   ****************************************************************   
   *****************************   
   Day 9, 19 august 2022, Explored the H3Index coordinate system, want the IJK   
   coordinate system.   
   ****************************************************************   
   *****************************   
      
   Video log of my activities of Day 9:   
   https://youtu.be/8mrw1Kzvu_c   
      
   9.1 H3Indexes coordinate system explored/visualized in 3D/Sphere/Globe with   
   TGLFlatText from GLScene.   
      
   9.2 Wanted to explore IJK coordinate system but was not yet possible because   
   of 8.4 and 9.3:   
      
   9.3 Came to the conclusion that the missing UBER H3 API: _h3ToFaceIjk was a   
   serious shortcoming and would prevent the implementation of hexagon routing.   
   Thus a solution should be found to get this API working. Different solutions   
   came to mind and the ammount of time needed for each solution was considered   
   and   
   described.   
      
   9.4 Decided to wait a day to see if I or anybody else could come up with a   
   solution and to give this a bit of a rest for today, instead of beginning   
   a "crazy C to Delphi port" ;) :) to save myself a lot of time on the long run   
   and to benefit from future improvements and versions of the UBER H3 library and   
   saving myself a lot of days/time.   
      
   ****************************************************************   
   ****************************************************************************   
   Day 10, 20 august 2022, Multiple spheres idea tried, UBER H3 DLL fixed, IJK   
   Indexes Explored, 3D hooking described, Server Protocol described   
   ****************************************************************   
   ****************************************************************************   
      
   Video log of my activities of Day 10:   
   https://youtu.be/_Q23Jb3JL2U   
      
   10.1 Showed the zooming ideas I had in folder/document: Plans and   
   Designs/Zooming.txt   
   (To be tried and implemented on a later day)   
      
   10.2 Described the server protocol, still more work to do to flesh it out.   
      
   10.3 Came to the conclusion that it is very important to get IJK coordinate   
   system working. It will most likely affect the design of the algorithms,   
   such as the peer assignment algorithm inside the server for assi   
   ning/allocating peers to the main hexagons.   
      
   10.4 Decided to shift gears and try to fix the UBER H3 DLL/LIBRARY by   
   manipulating the C source codes slightly to try and export the needed   
   _h3ToFaceIjk   
   function implementation. Did so successfully.   
      
   10.5 Later discovered some feedback (from github user: isaacbrodsky) on github   
   how to issue the correct CMake build command to export ALL functions:   
   https://github.com/uber/h3/issues/643   
      
   Step 2: Configure for DLL release:   
   cmake ..\h3 -DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=ON -DCMAKE_W   
   NDOWS_EXPORT_ALL_SYMBOLS=ON   
      
   Step 3:   
   cmake --build . --config Release   
      
   This fixes the H3.DLL and makes sure all function/api implementations are   
   present, at least it should, at least the _h3ToFaceIjk function implementation   
   was   
   present.   
      
   10.6 Examined and explored and visualized the IJK coordinate system in   
   3D/Spheres for the hexagons at different resolutions, such as resolution 0, 1,   
   2 and even 3.   
      
   10.7 Explored and visualized the multiple/scaled up spheres, one sphere for   
   each resolution. This could be used to visualize how peers are connected for   
   the routing   
   protocol (in the future once this routing protocol is implemented). This is   
   what I called "3D Hooking", the peers conceptually hook into this   
   3D-multi-level/multi-resolution multi-hexagon-grid structure.   
      
   10.8 Uploaded Delphi bindings for UBER H3 library to github and issued a pull   
   request to try and link their bindings documentation to (my) Delphi bindings.   
      
   Skybuck Flying's Delphi bindings for UBER H3 Library (plus some extra helpfull   
   TH3CellIndex record/unit) currently at my internal folder/unit version 0.05:   
   https://github.com/SkybuckFlying/h3_delphi   
      
   UBER H3 bindings for other languages document:   
   https://github.com/uber/h3/blob/master/website/docs/community/bindings.md   
      
   Skybuck Flying's modified UBER H3 bindings for other languages document:   
   https://github.com/SkybuckFlying/h3/blob/DelphiBindings/website/   
   ocs/community/bindings.md   
      
   10.9 Signed some UBER H3 CLA agreement to be able to do pull requests/commits   
   on UBER H3 github/master:   
   https://cla-assistant.io/uber/h3?pullRequest=645   
      
   10.10 For now came to the conclusion that the decision taken at 9.4 was a   
   good/correct decision. The UBER H3 DLL/library was fixed, at least for now it   
   seems   
   to be in a good/complete state. However keep in mind it does seem to depend on   
   external DLLs/runtimes, I will sum them up in here just in case, according to   
   TDUMP, so it might still be usefull to port UBER H3 to Delphi to reduce   
   dependency failures/risks on missing DLLs on end-user systems:   
   I am not sure about this, but for now, to me, it seems like this is the case:   
   Dependencies for release version of UBER H3 DLL/Library (for Microsoft Windows   
   operating system):   
   1. VCRUNTIME140.dll   
   2. api-ms-win-crt-heap-l1-1-0.dll   
   3. api-ms-win-crt-math-l1-1-0.dll   
   4. api-ms-win-crt-stdio-l1-1-0.dll   
   5. api-ms-win-crt-runtime-l1-1-0.dll   
   6. KERNEL32.dll   
      
   Maybe there is a way to get rid of some of these DLLs to reduce the   
   chance/risk of a dependency failure.   
      
   For now the gain in days/time (for not having to port it to Delphi) is nice,   
   but it might bite this project and it's users in the ass later, time will   
   tell, if so   
   a port could still be attempted. One benefit would be that by then the UBER H3   
   library has advanced, however it could also mean more code to port. In case   
   many many new features would be added to UBER H3 library an older version 3   
   could also be ported, which is the version this project uses for now. However   
   the ammount of changes to UBER H3 will probably be somewhat limited, probably   
   mostly some API renames, then again time will tell. New powerfull features   
   would be welcomed by me anyway, the library already has many powerfull   
   features it seems.   
      
   10.11 A quick glance/exploration was taken into an alternative geogrid called   
   DGGRID:   
   https://github.com/sahrk/DGGRID   
      
   10.11.1 However there are a couple of issues with it: First of all is it   
   truely an API library ? Or just an application to generate files ?   
      
   10.11.2 Second the library depends/requires GDAL which byself requires many   
   many many many other libraries and this would turn into dependency and make   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)