I got the circles good. first of all, none were appearing because the code deciding when to add them was all inverted. more interestingly, I realized I can't put them on the same layer as the other country shapes because then they'll get obscured by stuff. so I moved the circles to their own group. I also made them much smaller. finally, I made the Supermap.svg file a tiny bit smaller by styling borders more efficiently.
idk if it was a good use of time, but I think I've figured out how to make the supermap look good. mostly, I needed to supply it with data.
but since I can no longer find the other dataset I was using on the internet, I've transitioned it to natural earth's populated places. I remember havig issues with populated places last time, but it's possible that that was only because the labelranks are all rong in that dataset. now I can finally focus on the circles!
I refactord the map generation code. it now updates the SVG files automaticly rather than waiting for the user to copy and paste the output into them. I did this because I can't imagine doing that for all of them and can't beleve I used to think that was an acceptable waste of my own time. naturally this caused some updates to the data and improvements to the code to get pushd to the SVGs. most notably, the natural earth dataset reflects that the aral sea is gone. I didn't update Supermap.svg because it turns out that one required a dataset that I can't find anywhere online. I have that file still so I could update it, but I would really rather my work be reproducible, and am mad at myself for not documenting that file at all when I found it. I'd like to get it working with the natural earth populated places shapefile, but we'll see.
I updated the polygon code to work on the new sometimes-inside-out-but-always-closed boundary polygons. I also updated the parser to expect the word "boundary" rather than "border". I also went ahead and tried to simplify the spline code based on the assumption that the nan gradients will never be used.
it's onestly weird to think that I originally wrote all this in an IDE that didn't check these things. there was a *lot* of unused code, as it turns out.
I set it to use the new projection format, where each section has its own inverse raster. it does make the poles better in I and II, but it makes the ends of the tears much worse. I need to keep tweaking, I gess.
I set it up so if the iteration gets stuck in a local minimum, it will terminate and return that local minimum. this seemd to work more or less perfectly a minute ago, but I broke it either by reducing the inverse raster resolution or by refactoring the cosine calculation slitely.
the simple Gauss–Newton with Armije backstep was insufficiently robust, so I implemented LM. it seems to work better, but it's still not good enuff. the step size doesn't turn as much as I would expect when λ goes up. I think next it's time to implement the geodesic acceleration correction term.
I added a backstepping line search to each iteration of my Newton-Raphson solver. it actually gets rid of most of those rifts in Elastic Earth III where the folding was causing Newton-Raphson to have difficulty. but there are still a few spots that are struggling. also, it turns out a few points are still not getting counted in any polygon.
I fixd the polygon so it stops excluding certain regions from the projection. I almost got it rite the last time I updated the polgon algorithm, but I forgot to remove the nearestSegment bit, which makes no sense with the crossings counting tecneke.
the problem was that I was modifying the initial gess rather than copying it, and that gess was getting passd to multiple sections and then ultimately returnd as the anser. now it clones it when it starts the iteratinos and then copies it agen when returning it, so the problem went away.
I also made the cropAtPi checkbox work, which was onestly the thing I was doing in the first place (I had no idea this was the root of the problem). and I removed the projected border because I realized I didn't actually need it to implement cropAtPi
the edges of the mesh are a little crunchy now, which is weird because I thaut I set the termination condition to prevent that, but overall this looks quite good. I hope it's correct.
I made the projection smooth at the antimeridian, because it was bothering me. it looks great now. well, I did also notice that a bunch of points near the poles are going to NaN in the vector mapdesiner now, but that doesn't seem to be related to this change, so I'll deal with it later.
I made an attempt to fix the error messages you get with Elastic II. it didn't work. I'm leaving this change in because I think it will probably be better in some situations regardless of the current errors.
I implemented the simplest possible inverse projection. I did end up converting the raster to cartesian coordinates so that the dateline doesn't get screwd up, but other than that it's very simple. now it's just a question of adding that Newton Raphson layer on top.
because god forbid I have a function name longer than fifteen caracters; no one would read that!
but yeah, I hate past me, so here's a much better function name.
I implemented the Elastic projections! this is just a first pass, so of course there are issues to be worked out. the oceanic one has a few particular longitudes that it won't project, and the gradient calculation seems to be rong near the section edges. I also haven't synckd up the section gradients at seams. overall, tho, I'm surprised how good I got the gradient calculation, and the interpolation in general, on the first try. I also haven't done any of the inverse projection yet, but I intend to do a better job with these ones than I did with Danseiji's inverse projections.
I also did some light refactoring; Meshed -> Danseiji and setParameters -> initialize, and +docstrings, so that accounts for most of the modified files.
I rote a script to automatically convert a bunch of equirectangular projections to dymaxion projections. I had to refactor the other main apps slitely, because they were structured very poorly.
