2.0.1 • Published 4 years ago

hexmap v2.0.1

Weekly downloads
1
License
MIT
Repository
github
Last release
4 years ago

Update 2.0.0

ok, you may be thinking "dude, 4 days and already a major version update?". Well yeah, this may be a case of what you call bad planning, but this update changes hashes and point generation methods, although not all implemented yet, but hey, better late than never, even though it's only been about 4 days.

So here are the changes:

  • hashes used to follow the format resolution|row|col, now they follow the format mapOrientation|rotationMethod|resolution|row|col.
  • before there was rotationMethod, and it had to be provided for almost all Icosahedron instance methods, now there's also mapOrientation for when dymaxion orientation is added, and these now only have to be set when creating a new Icosahedron instead of every time you want to generate a hash or some points.

hexmap

hexmap is a lazy-loading hexagon map. This means that it can hash locations, and it can also support hexagon navigation (not implemented yet). If you want to see it in action, check out this link (CodeSandbox) (ps, if you click on the hex map it generates another random point and its hash). If you want to know how it works, I explain it towards the bottom.

installation

npm install hexmap --save

usage

import { Icosahedron, point3, Vectors3 } from 'hexmap';
// or const { Icosahedron, point3, Vectors3 } = require('hexmap');

// generate point
const point = Vectors3.fromCoordinates({ lat: 36.05, lon: -112.14 });
// initialize icosahedron
const icosahedron = new Icosahedron({ mapOrientation: 'ECEF', rotationMethod: 'gnomonic' });

And then you can generate a hash.

const hash = icosahedron.generateHash({ p: point, res: 74 });

And generate a point from it, and its icosahedron (same mapOrientation and rotationMethod as point)

const [parsedIcosahedron, parsedPoint] = Icosahedron.parseHash(hash);

And that's pretty much it, for hashes at least. If you're wondering about res (resolution), there's a table with estimated hexagon radius below, and if you're wondering about rotationMethod, don't worry about it, but if you're already worrying about it you can see the difference between them at (CodeSandbox), just set tripBalls to true and it'll make sense.

If you're thinking "that's it?", well for now yes. There's more stuff that this baby can do, it just needs to be added, see at the bottom for subreddit and contact info, and if people request stuff it'll almost definitely be added, as long as it's coherent with the project.

estimated hex radius for resolutions

Now, this might push the boundaries of the word estimation, since the way I calculated it is ≈ 63.435 degrees (angle between 2 icosahedron triangle vertices) divided by the number of divisions along each side, and used that to convert to km and miles. Now, this may not sound so bad, and I think it's not too far off for higher resolutions, but it is kinda is bad because, since gnomonic projections are used, there's some distortion from the side to the center of the triangles, so these values are probably under-estimations. If this picks up some traction I'll do some proper estimations.

Estimated hex radius is biased down (better to estimate down than up for encompassing radius). These tables were generated with some code, so if you want to mess around with the values or target a range of values more specifically here it is: CodeSandbox

Anyway, here are the most notable resolutions, since it's kind of ridiculous how high the resolution values can get.

kilometers

resolutionside angle (deg.)hex radiusestimated hex radius
121.145°2353.8488 km2350 km
210.5725°1176.9244 km1170 km
37.0483°784.6163 km780 km
45.2862°588.4622 km590 km
54.229°470.7698 km470 km
63.5242°392.3081 km390 km
73.0207°336.2641 km330 km
82.6431°294.2311 km290 km
92.3494°261.5388 km260 km
102.1145°235.3849 km230 km
111.9223°213.9863 km210 km
121.7621°196.1541 km190 km
131.6265°181.0653 km180 km
141.5104°168.1321 km170 km
151.4097°156.9233 km150 km
171.2438°138.4617 km140 km
181.1747°130.7694 km130 km
191.1129°123.8868 km120 km
211.0069°112.0880 km110 km
230.9193°102.3413 km100 km
250.8458°94.1540 km95 km
260.8133°90.5326 km90 km
280.7552°84.0660 km85 km
290.7291°81.1672 km80 km
310.6821°75.9306 km75 km
340.6219°69.2308 km70 km
360.5874°65.3847 km65 km
390.5422°60.3551 km60 km
430.4917°54.7407 km55 km
470.4499°50.0819 km50 km
520.4066°45.2663 km45 km
590.3584°39.8957 km40 km
670.3156°35.1321 km35 km
780.2711°30.1775 km30 km
940.2249°25.0409 km25 km
1180.1792°19.9479 km20 km
1570.1347°14.9927 km15 km
2350.09°10.0164 km10 km
2620.0807°8.9842 km9 km
2940.0719°8.0063 km8 km
3360.0629°7.0055 km7 km
3920.0539°6.0047 km6 km
4710.0449°4.9976 km5 km
5880.036°4.0031 km4 km
7850.0269°2.9985 km3 km
11770.018°1.9999 km2 km
23540.009°0.9999 km1 km
26150.0081°0.9001 km0.9 km
29420.0072°0.8001 km0.8 km
33630.0063°0.6999 km0.7 km
39230.0054°0.6000 km0.6 km
47080.0045°0.5000 km0.5 km
58850.0036°0.4000 km0.4 km
78460.0027°0.3000 km0.3 km
117690.0018°0.2000 km0.2 km
235380.0009°0.1000 km0.1 km

miles

resolutionside angle (deg.)hex radiusestimated hex radius
121.145°1462.6138 mi1460 mi
210.5725°731.3069 mi730 mi
37.0483°487.5379 mi490 mi
45.2862°365.6535 mi360 mi
54.229°292.5228 mi290 mi
63.5242°243.7690 mi240 mi
73.0207°208.9448 mi210 mi
82.6431°182.8267 mi180 mi
92.3494°162.5126 mi160 mi
102.1145°146.2614 mi140 mi
111.9223°132.9649 mi130 mi
121.7621°121.8845 mi120 mi
131.6265°112.5088 mi110 mi
141.5104°104.4724 mi100 mi
151.4097°97.5076 mi95 mi
161.3216°91.4134 mi90 mi
171.2438°86.0361 mi85 mi
181.1747°81.2563 mi80 mi
191.1129°76.9797 mi75 mi
211.0069°69.6483 mi70 mi
220.9611°66.4824 mi65 mi
240.881°60.9422 mi60 mi
270.7831°54.1709 mi55 mi
290.7291°50.4350 mi50 mi
330.6408°44.3216 mi45 mi
370.5715°39.5301 mi40 mi
420.5035°34.8241 mi35 mi
490.4315°29.8493 mi30 mi
590.3584°24.7901 mi25 mi
730.2897°20.0358 mi20 mi
980.2158°14.9246 mi15 mi
1460.1448°10.0179 mi10 mi
1630.1297°8.9731 mi9 mi
1830.1155°7.9924 mi8 mi
2090.1012°6.9982 mi7 mi
2440.0867°5.9943 mi6 mi
2930.0722°4.9919 mi5 mi
3660.0578°3.9962 mi4 mi
4880.0433°2.9972 mi3 mi
7310.0289°2.0008 mi2 mi
14630.0145°0.9997 mi1 mi
16250.013°0.9001 mi0.9 mi
18280.0116°0.8001 mi0.8 mi
20890.0101°0.7002 mi0.7 mi
24380.0087°0.5999 mi0.6 mi
29250.0072°0.5000 mi0.5 mi
36570.0058°0.3999 mi0.4 mi
48750.0043°0.3000 mi0.3 mi
73130.0029°0.2000 mi0.2 mi
146260.0014°0.1000 mi0.1 mi

how it works

hexmap uses an icosahedron as a base, and generates points with either gnomonic projections or quaternions. These points are split into rows and columns, and since all icosahedron triangles are equilateral, there are some pretty nice relationships between point row and column numbers and whether they're hexagon centers or vertices. Point generation is done by triangles, and those points are numbered according to their location on the map, and respective rows and columns. Once these points are generated, they can be used to either generate a hash (hashes only use hexagon centers, not hexagon vertices), or to generate a hexagon.

Now, all this considered, hexmap has the potential to be a flexible library with more features, I just need to know people will use it to actually work on it, so in the next section I'll explain how you can help out or contact me, and some of the current problems we need to solve.

how to help

If you want to help out, welcome to the team. Here are some pending features, and below that some of the problems I'm currently trying to solve:

pending features

  • hexagon navigation: hexagon navigation requires 2 things: hexagon generation from lazy points, and how to actually navigate. The first one is pretty easy and I could add it in a couple minutes, but how to actually navigate requires some thought, and maybe some input from you, the reader! If enough people request this I'll definitely add it since it would definitely come in handy. --- Maybe instead of navigation we could just add something that generates the hexagons around another one, but either way, it's all up to you guys. Subreddit and contact info at bottom.

current problems

  • quaternion triangle side percent: currently, only gnomonic rotation mode can be used for hash generation, since there is a pretty considerable difference between the calculated lazy point range and the point that needs to be hashed. Pero Porque? This is because in order to generate points around another point (since hexmap uses triangles for point generation), hexmap calculates the percent of a point's projection along its sides for each of them. Now, this works for gnomonic projection pretty nicely (vectors, straightforward), but for quaternions I'm thinking it requires quaternion algebra, and that's a whole different beast. If you think you can do this, and want to, send me an email, or look at contact info below and I'll explain it in more detail.

subreddit and contact info

I think this library has some potential, so I've done created a whole subreddit for it: r/hexmapz. There you can request features, and if enough people need it I'll start working on it, or add it above so others can help too.

This might be a bad idea, but my email is watchouthomes@gmail.com, so if you want to talk about hexmap or anything in general just send me an email.

2.0.1

4 years ago

2.0.0

4 years ago

1.0.4

4 years ago

1.0.2

4 years ago

1.0.3

4 years ago

1.0.1

4 years ago

1.0.0

4 years ago