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.
I enhanced the hierarchical stuff to lalow supranational entities and sub-country geounits. now the provinces map has england, srpska, french guiana, and more. the only issue is the borders between geounits are thick but I want them to be thin like province borders. so that's the next step.
SVGs only accept «0» as the zero character and «.» as the decimal separator. when I started aggressively using String.format(), it started localizing numbers to sometimes use ⋅ and ,, tho, which of course resulted in invalid SVGs. luckily when it *reads* doubles it seems to assume US locale.
after I implemented the sparse graticule thing at th epoles, I realized some people mite like to have the old graticule behavior in some situations. I added an option to graticule.txt to do just that. now you can set it to make the poles look however you want.
apparently compound CSS selectors don't work in the Wikimedia Commons' SVG renderer? also, href isn't supported, so you have to use xlink:href. but xlink:href is deprecated so you actually have to use both...
calling it "crop at antimeridian" is not accurate anymore (and hasn't been for a long time), since many map projections that use this feature do not use the antimeridian as their boundary. also, antimeridian isn't a real word.
I added a feature to generate a population bubble plot. I want to make it do separate bubbles for the different provinces of big countries, but for now those bubbles are all the same size. I need to find some good databases for those numbers.
I realized that "110m" doesn't mean that data are precise to 110km; it means that it's suitable for 1:110M scale. oops. I deleted the corresponding false statements and also added a bunch of references to natural earth.
I was at first operating on the principle of the more resolution the better, but then I realized that South Africa is really not a big country. 23rd in population, 24th in area. I don't know why it has provincial resolution in this dataset and argentina, mexico, algeria, DRC, saudi arabia, kazakhstan, and india don't. but the fact that it does is slitely insulting. I'm removing it from the provinces map because I can't imagine a situation where it would make sense to draw these lines but not the others for which I don't have data.
I realized that the supermap has been incompatible with the mapdesignervector for some time now, ever since I set the width to 150cm, because the SVG parser didn't know how to account for units in the width and heit. I made a simple Quantity class to keep track of the units as well as the value and now it works fine. now, I did realize that more than just the width and heit can have units. in principle I need to check every number I parse from the SVG for units. but I don't want to do that rite now. I think the width and the height are the most likely numbers to have units attached, so I'm calling this fine for now.
this is so good. I must have thaut of this at some point in the past, but it wasn't much of an option until I added backgrounds. the geographic content now clips to the background, so if you have a map with a lot of interruptions and there are lines that didn't get cut properly or shapes enclosing singularities such that there's gunk extending off the map, it will be invisible. the clipping path hides it. it looks incredible instead of always garbage! it doesn't fix all such issues of course – there are often excess lines inside the geographic region that won't get removed by clipping. but it gets like a lot of them. I can't get over how much better these maps look out of the box now than they did a year ago.
it feels like maybe the jar files should either automaticly build so that they're up-to-date in every commit, or I should gitignore them so that I don't need a commit just to update them. shrug. I gess I would have to commit to update the version number in build.xml anyway.
a few commits ago, I decided to remove the power slider from the IMAGO (AuthaGraph) projection, since the original AuthaGraph wasn't technically parametirizable, and I figured I already had "TetraPower", which was the same thing but explicitly parameterized. there were two problems with this. one was that I forgot to remove the parameter, so the "Power" slider was still there it just didn't do anything. the twoth was that the "TetraPower" projection differed from AuthaGraph in arrangement as well as parameterization, so I can easily imagine someone wanting to tune the scaling on the AuthaGraph projection but not being satisfied with the alternate version. plus, "TetraPower" was buried in the "Created by Justin" section of the map projections so I wouldn't blame people for not noticing it.
thus, rather than simply deleting the slider, which would be the more straitforward fix here, I'm erring on the side of not removing functionality and putting the parameterization back on IMAGO, while also rebranding "TetraPower" as an alternate arrangement of IMAGO/AuthaGraph.
I set the political svgs to remove the divide thru russia at the antimeridian. I'm a bit surprised I didn't try this sooner since it's just kind of an ugly erroneus line in most of my map projections. unfortunately, the solution I found doesn't work for the physical maps. that's a bit of a bummer for the tissot ellipse maps specificly. however, it was most notable (and most potentially confusing) in the blank political templates, so I'm very glad that I fixd that.
I dubble-checked the terminology, and actually an indicatrix is a single circle and the plural is indicatrices. I think I had this exact same revelation in the past, but the end result is that I was rite before. thankfully, I did also find out that there's a preexisting non-terrible alternative, which is to simply call them Tissot's ellipses. which is good because now I don't have to come up with my own (I was leaning toward "Tissot's indicators"). I went ahead and changed the terminology to "ellipse" everywhere in the SVGs.
idk how I got "Tissot's indicatrices" in my head, but this thing is called "Tissot's indicatrix". I mean, "indicatrix" isn't a real word either but it's better than "indicatrices".
also remove simplified because I think it's just a lower-resolution version of basic? users can darn well simplify their own maps. besides, if I wanted such a thing I could get it more effectively by just using the 110km dataset.
drop Danseiji projections, add Elastic projections and Bertin projection. the resulting graph looks different now owing to my lower-resolution laptop, so that's fun.
I made varius improvements to the input SVG maps. I changed the provinces map to use 50km borders rather than 10km borders, reducing its filesize by a factor of 10. this does unfortunately mean that I can *only* have province borders for seven or so countries, not even including argentina. that sucks, but to be fair I really didn't need admin1 boundaries for, like, armenia. I just wish I could have them for more like the top twenty biggest countries. I've decided that the decrease in filesize is well worth it, tho. 25MB was just too big for an SVG, and made it rather difficult to use for practical purposes (not to mention, it was about 10% of the total program size).
I also made it so that all countries in the political maps are classed with both their ISO 3166 A3 code and their ISO 3166 A2 code, so that you can use either in the stylesheet. it seems the A2 codes are more common, so I thaut it worth including.
I removed the circles for Cyprus No-mans-land and the Siachen Glacier. even tho they are both decently inhabited, neither of them has any presence in international politics, so I find it very unlikely anyone using these maps will even have data to put on them.
I removed some empty parentheses that were appearing next to Palestine's name. I fleshd out the descriptions to include more information. and I added more comments to the CSS.
turns out the reason it wasn't working was that I was using newer Java! I'm a bit confused because I *thaut* I had used Java 17 or something to build this in the past, but I gess for whatever reason I've always used 8 to make the JAR and EXE files. whatever, what matters is that it *finally* works!
so the installers don't work; or rather you can install the program just fine but when you try to start the program you get "Class apps/MapDesignerVector not found" or whatever. I figured out why EXEs weren't working (the version of Inno Setup) and changed it back to EXE in the hope of fixing it, but it's the same problem still. but since that's one thing figured out I'm committing it here.
I tried to bild the exe files for the next release and found that it didn't work. I got confused for a really long time. then I figured it out. it turns out Java 17 is kind of completely different from Java 8. I kind of wish I had stayd on Java 8, but I don't want to go back now. also for some reason it has to be msi now not exe. I deleted the eclipse files as well because it's outdated and has a bunch of java 8 stuff.
I made some final improvements to the map data files and accordingly to the inverse code. in particular there are nans in the inverse raster now, and an extra check when returning an inverse solution from a local minimum. it turns out there's kind of a concerning number of local minima in Elastic III, which I think means there's a concerning amount of self-intersection in the spline surface. it makes me wonder if linear interpolation isn't just better for this one. but I really don't want to implement two different types of interpolation, so for now this is it.
