well, there are a couple of nubs I don't understand that appear when you turn the number of loops down. but this is fine, I think. it finally hits the good enuff metric for which I had been aiming. I just had to pull out the poles and handle them totally separately.
it's almost there. man, I keep trying to get a shitty but presentable version of this projection and it keeps being more challenging than I expected. this one looks alrite, tho, and I think with one more modification I can remove those annoying gaps that shouldn't be there.
there was also a bug where the Liquid Earth projection threw an error if you tried to use a map with points on the pole or antimeridian. but that's fixd now. I also fixed a minor issue where it said that the Equal Earth projection had a closed-form inverse when it in fact does not. I also renamed the liquid earth mesh files.
I feel so silly for not catching this before. but in my defense I really don't want to do tests because I don't understand dependency management in java.
I allowed the user to set the longitude scale of the Lagrange projection as low as 0.01 and as high as 1.5. in order for this to work at all I needed to make the shape calculation much more complex. now it will calculate the actual envelope, which can become infinitely large, and crop that to a square that scales to keep Africa at ruffly the same scale. this may now be one of my most complicated projection shape calculations, which I think is a little funny given that I only decided to generalize this projection on a whim, and it really doesn't seem all that complicated.
dude, the math for this took me so long. at the end of the day it's not that complicated, but boy is it tricky to figure out. maybe my issue is that I don't use complex math. 🤷. it works now for multiple longitudinal scales.
actually this atan2 was really bizzare in the first place. I must have seen the arctangent of a fraction in some book somewhere and just assumed it was supposed to be fully signed.
now when you select a map projection in the "More..." menu, you'll see the name of the person who first introduced it in addition to its geometry, special property, and description. I did this because now that I no longer have an "Invented by Justin" category, I want to make it clearer which are invented by others and which are my own, just as a conflict of interest disclosure thing.
this was much more correct than I was expecting. apparently the reason each bin had 10× more triangles than it was supposed to was just that the way I expanded each triangle to account for curvature (using what I described as "pretty conservative estimates") was too conservative. basicly each triangle on the antimeridian ended up being put in every single bin, just in case. not good. I cleaned up the binning and now it works perfectly!
I implemented Robert Sargent's new Liquid Earth projection. it works sort of, but there are some issues I still need to work out. "Extend map area" is effectively always turned on, there are some bizzare artifacts that I don't think are right, and it's really slow because the caching is messed up. but this is an excellent start.
this adds support for the S and T Bezier shortcuts and commands with multiple sets of arguments, and also has better error handling for when the number of arguments is not what we expect. I also refactord it a bit to be much cleaner in general, because wow was this poorly written.
apparently in addition to dropping the delimiter before negative numbers, because you can infer from the hyphen that it's the start of a new number, they also drop it before numbers that start with a decimal point iff the previus number has a decimal point in it. this is awful. why did they do this. it can't possibly have been worth it. whatever, I account for it now.
when I redefined the Waterman projection coordinates (I don't even remember when) to use four-times-larger units, I apparently missed *one* constant, and it was increasing the slope of this line between these two pieces of the Waterman face that was causing the projections at that interface to not line up. goodness, what an asinine bug. good on me for finding it in less than an our of its reporting, tho!
apparently map projections with unicode in their names create invalid SVG when using the executable (even tho it works fine when I run the source code...). something about the encoding I gess? I don't really understand, but it's better to escape the map projection names anyway just to be consistent with the templates that are already escaped. I did that and now it seems fine.
I refactord the ploitical map generation. I broke the plot_political_shapes function into two parts: the loading part (which generates a nested dictionary) and the plotting part. this will enable me to process the data between those two steps. I haven't gotten to that yet, but that's my next step in thinning the lines between geounits within countries.
I still think this bubble plot is a good idea, but this is not the way I want to go about it and it's cluttering up the directory. someday I'll rite a python script outside of github to modify Template provinces.svg with population bubbles.
