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.
this must have come up when I was doing all the Shape stuff and I never noticed because the default projection in MapAnalyzer happens to be square. but it turns out it was making them *all* square. obviusly that's no good. fixd it.
my real goal here was to add the outline of the full map to the gradicule, but I realized that would be hard because the Awt package I'm using only supports line segments; not arcs or anything. so maybe another time, but for now have a slite improvement where the meridians are thinned out rite near the pole.
I cleaned up the output folder to not include outputs from when the code was buggy and to have more straitforward filenames. then I picked out three to include in the readme. I think more GitHub repos should have images in their readme; it help a lot with readers quickly grasping what the code is about. I suppose I could also include screenshots of the software, but I don't think that's necessary and it would be work. these images were already readily available!
the hammer retroazimuthal was rong as it turns out; the back hemisphere was mirrored in x from what it was supposed to be. I set up a more robust implementation where the front and back hemispheres are now separae projections that you can use, in addition to the full one with the rotate back hemisphere. part of this was creating a tility function in Shape to combine th eoutlines of the front and back hemispheres, which incidentally turnd out to be super helpful for Waterman's shape definition as well.
I made it so that when an inverse projection returns nan (which it never should) you get brite magenta instead of ocean color. makes it waaayyy easier to tell where the problem is as compared to just printing out the problematic coordiantes.
I tried to make my SVGs more robust in terms of only using features supported on a wide variety of platforms. in particular, it turns out nested CSS blocks may not be a core CSS thing... they're a Sass thing? but chrome and firefox both seem to interpret it correctly automaticly. in any case, I got rid of that and told the user to do their circle showing manually. I also deleted all these namespaces and metadata tags because it seems like intellij is having trubble resolving their sources and idk what's the point of including them in the first place. all of this information is either already included or is better given in supplementary files. I also added more background rectangles.
I discoverd that the error pane automaticly cuts off the last few words of your error message if it can fit *almost* the whole message on one line. god, javafx is stupid. I hacked at it until it wraps consistently so that *all* – not just *almost all* – of the words I ask it to show the user are actually shown to the user.
I went thru and corrected numerus inspection warnings. I'd say most of it is correcting typos. I also removed a bunch of unused variables and methods (and even a cupple of files), adjusted varius stylings, improved a few docstrings, made local variables where one quantity was getting calculated multiple times, and cetera. the spiciest thing was that I refatord the part where it saves a screenshot of the graphs in the MapAnalyzer; previusly it was bizzy-waiting for the GUI thread to finish taking the screenshot, which was probably fine, but now it uses FutureTask.get(), which is probably faster and definitely cleaner. I also deleted the code for the two-point equalized projection because it was bad and didn't work very well (to be precise it wasn't in use after I removed it from the projection list a few days ago so this is just codifying that renunciation). I also made AuthaGraph fixd instead of parameterized because I think that was just a mistake.
I just went thru and was a bit more intentional about my variable names. "finite" in particular was quite misleading, as the orthographic projection is most definitely finite in extent. i -> section_index just allows me to be more consistent with my indexing, and distance->cost is because calling half the distance squared the distance is just false. the commit summary is a very clever and nuanced reference to the air force being impressed by software engineer employees who can rename variables without help.
I fleshd out the octahedral offerings, taking advantage of my new setup that makes it more convenient to mix and match existing configurations and face-projections. while I was there I couldn't help but tighten the boundaries around antarctica on Cahill–Keyes to better match Gene Keyes's original material, and create a new Waterman butterfly map with antarctica detatchd. I'm really happy about that last part since it feels like it's been a real oversite until now. I didn't reproduce those sleek polygonal cuts that Waterman has but opted for simple cuts along parallels, which are much easier given the stuff I've already implemented. it's definitely not the same, but I think it's close enuff. closer than leaving antarctica in place, anyway. I haven't seen anyone online doing parallel cuts in this way so in a way it's a bold new take on an old projection! it required making the drawShape method slitely more complicated to allow for multiple parts to a single projection's shape, which I've never had before (not even for T-shirt or Hammer Retroazimuthal where I seem to have gone out of my way to avoid just that!)
the greek prefix for 8 is "octa-". the *latin* prefix for 8 is "octo-". and, well, the greek prefix is also sometimes "octo-". octapus should probably be spelld with an a! in any case, I see no reason to prefer this distinctly nonstandard spelling of octahedron.
it seems when I wrote this I optimized it to make the Projection constructions as consise as possible, which is stupid and annoying because now I don't remember how to use any of the fancy constructors that automaticly construct descriptions. so I got rid of that. when you construct a projection, you pass its constructor. also, the stupid "fisc" int that is actually four booleans in a trenchcoat is now four booleans not in a trenchcoat. wow, writing the thing you mean instead of encoding it to save twenty bytes of code? the horror!
I fixd the bonkers outlines of the cahill concialdi and cahill keyes projections by giving them base face projections off of which to base. i think it simplifies the math a bit in general, in particular for the shape definitions. it's nice, I like it.
I've added a cassini projection (the only projection that's portrait by default!) and based lemons off of it. this simplifies the implementation of its shape.
I'm not adding this to the input/ folder at the moment, but it's a nice capability to have. for now I'm using this to contribute to a wikipedia argument.
I replaced all the linkedlists of path commands with arraylists because it was actually making the projection exteremely slow. I could alternatively have reritten all of my for-loops over paths to be for-each instead of index-based, which would have solved the same problem, but I think arraylists are just better in general for this. it's not like I'm short on memory here. there's only one instance of me calling .remove(), and it's right after some funky indexing stuff, so a linkedlist wouldn't really help there anyway.
I set a flag to prevent multiple maps from being calculated at once. idk how important this will be since I found out why it's currently so slow and intend to fix that, but just in case someone has a slow computer or one of the projections is really intensive, this will prevent the map from jerking around annoyingly as the sliders are dragd.
I accidentally ignored aspect when projecting points. I'm glad I noticed that was rong while just looking at the code rather than discovering that later when finalizing my template maps.
I implemented shapes! now when you input a map with a rectangle over the full equirectangular domain, rather than merely fitting it to the output map's dimensions, it conforms to its shape! it looks wonderful. I can't beleve I never saw fit to implement this before. and it will especially help with the Elastic projections. I ended up implementing this new Path class because there ended up being a lot of Path manipulation in my shape implementation, and things like "translate this path dx dy" and "invert this path in y" turn out to be useful in a lot of parts of my code.
unfortunately this doesn't quite work rite for the octohedral projections just because their shapes are pretty complicated and I pmelemnted them in a way I know to be imperfect. my pland solution is to break the faceProject() method out into a separate map projection for each projection formula, so I can then use that projection's drawLoxodrome() method to define the shape of the full octohedral one. (btw did you realize how powerful drawLoxodrome() is? I should be using this for everything like damn).
apparently Janos himself preferd B over C because the differences between them are indistinguishable but B is a bit more well-behaved, so I see no reason why I shouldn't be using that one.
