THIS IS A WORK-IN-PROGRESS SNAPSHOT OF MY DIRECTORY AT HOME.

THE POLYGON PACKAGE BEING CREATED HERE IS STILL IN FLUX - THE
INTERFACE IS CHANGING DAILY (At least it was back in late Jan 2023
as I write this.)

READ THE "Manual.html" PAGE FOR A DESCRIPTION OF THE ACTUAL LIBRARY ITSELF.

------------------------------------------------------------------------------------
SVG library from:

http://www.fgrim.com/libmsvg/

------------------------------------------------------------------------------------

Installation notes:


I installed GEOS from source.  It required first installing a newer cmake which I did.

I later discovered that "sudo apt install libgeos-dev" would probably have been enough
(especially for a port to Raspbian) - but then it turned out that the compiled libGEOS
for Raspbian was version 3.9 as opposed to the x86 linux version of 3.11 - so I had to
create my own versions of GEOSGeom_createRectangle and GEOSGeom_transformXY to replace
the missing ones.

It looks like cmake still returns the older version unless you invoke it as

  export CMAKE_ROOT="/usr/local/share/cmake-3.25" cmake

cmake had some problems with missing modules which seem to have been solved by:

  sudo ln -s /usr/share/cmake-3.10 /usr/local/share/cmake-3.10
  sudo ln -s /usr/local/share/cmake-3.25 /usr/share/cmake-3.25
    

GEOS was built on my x86 linux by using:

  /usr/local/bin/cmake  -DCMAKE_BUILD_TYPE=Release     -DCMAKE_INSTALL_PREFIX=/usr/local  ..
      
User programs needing GEOS are mostly linked with just  -lgeos_c

but to be safe, you should probably put these in the makefile:

for compiling: `geos-config --cflags`

( equivalent to -I/usr/local/include )


and for linking: `geos-config --clibs`

( equivalent to -L/usr/local/lib -lgeos_c )


When running over ssh, try:  export DISPLAY=192.168.2.254:0.0
before running ./newtest


===
Related links:


   Irene Buchanan and Eric Barton's seminal paper on polygon manipulation:
   http://gtoal.com/history.dcs.ed.ac.uk/archive/docs/CSRs/CSR-44-79-the_polygon_package.pdf

   A current view more tailored to geographers:
   https://github.com/esri/arcgis-pro-sdk/wiki/ProConcepts-Geometry
  

See also: /home/gtoal/src/edwin/ ( http://gtoal.com/history.dcs.ed.ac.uk/archive/apps/edwin/edwin4-c/ ) - put together a hybrid drawing/polygon package?

~/src/vecx/vecxgl_1.2_src/*.c shows how to do other openGL/SDL stuff. Maybe mouse/cursor too?

My CNC code that could use the help of a polygon package is in http://www.gtoal.com/src/mkhive/ (and http://www.gtoal.com/src/CNC )
(as well as on the CNC server itself)

The bloating function is for converting standard PCB tracks into isolation-routing tracks so they can
be created using a CNC.  Bloating a track then subtracting the original track gives an area that
should be removed from the metal PCB surface leaving an isolated track.

TO DO: Operations 'self and', 'self or', 'accumulate'.
(the first 2 are normalise/repair options, and accumulate is what I current have named Merge)

If LibGEOS supports it, add a 'Not' operator which turns a polygon into a hole in an infinite sheet.

Undecided as a TO DO: create a general transformation matrix mechanism rather than current special cases
for transformxy, rotate, & shear.  Need to be more consistent with transformation stack, and when transformations
are applied - can't hold everything back to the end because structures like bezier curves have to be flattened
into straight-line segments before you can apply most polygon operations to them.  BUT if we do that should we
also add a new 'normalize' option which unconverts transformed line segments back into parameterized
bezier curves?

(notes: https://pages.mtu.edu/~shene/COURSES/cs3621/NOTES/geometry/geo-tran.html )

We don't really want to do that flattening until the output resolution is known, to avoid excessively small
(or large!) segments being generated. For example currently all rounded corners use 8 segments per quarter
circle regardless of the relative size of the curve compared to other features.  Relevant for things like
bloating a point into a circle for example.

Note re SVG: unfortunately SVG files have a Y axis in the opposite direction, *and* angles are
measured anti-clockwise whereas ours are clockwise.  Also have not checked which axis SVG considers
the 0 angle.

PS I have a file on the home machine, README-motherhood.txt, with some notes that need to be added
to the documentation in Manual.html