ases where you have angled shades and the component is doing trigonometry to figure out how close the blinds could be to the glass without touching. I just re-wrote the code so that, now you cannot have the blinds closer to the glass than half of the blind slat depth, which seems to be the limit of what E+ will tolerate.
Also, E+ does not like it when you input blinds that are perfectly at 90 degrees so I changed the component to automatically write out shades at 89 degrees when you connect up 90.
Using the Shade geometry as context worked perfectly for me and I am not sure what was wrong in your situation.
See your working file attached.
-Chris…
est of the best)
Crucial DDR4 2133 ECC (what else?)
4* WD RE 500 in Raid combo (not shown)
Some stupid 2.5'' HD thingy (avoid 2.5'' disks)
No SSD thingy
Corsair CPU cooler (Tequila replaced the OEM liquid: it works)
…
rees west to 1 degree west). Changing the latitudinal domain from, say, 0:1 (the equator to 1 degree north) to 88:89 (88 degrees north to 89 degrees north), has zero effect on the x,y shape of the topography map generated. However, in reality, the map should be far, far thinner in the latter case, because longitudinal lines get closer together toward the north and south poles. In actuality, the shape should be close to a trapezoid in both cases, but this is probably not a necessary detail for most people producing maps, since, at an urban or smaller scale, the latitudinal lines bounding the north and south of the map will probably not be that significantly different in length. But the maps should at least stretch from close-to-square for a 1 degree x 1 degree map near the equator to an extremely thin rectangle for a 1 degree x 1 degree map near the north pole.
As an example, I'm looking at a location in Sheffield, UK. The relevant SRTM HGT file spans from 53 N to 54 N, and 2 W to 1 W. The length of the map in the north-south direction should be approximately 111 km, as is the case with the topo map generated by Elk (and a near-standard for 1 degree latitude anywhere in the world). The length of the map in the east-west direction, however, should be somewhere in the range of 67 km, since the 2 W and 1 W longitudinal lines are much closer together at this latitude than they are at the equator. Thus the map should be nearly twice as long in the North-South direction as it is wide in the East-West direction.
If this were to be sorted out, I think it would be really nice to then have the SRTM topo map be positioned automatically in relation to the OSM map being brought in. I think it's good that the OSM map is positioned at 0,0, rather than it's world coordinates, but maybe the SRTM topo map could be aligned with it based on the latitude and longitude domains we input to the SRTM grasshopper module.…
xt as scimport Rhino
if active: for i in range(len(geo)): geo_id = geo[i] sc.doc = ghdoc doc_object = rs.coercerhinoobject(geo_id) geometry = doc_object.Geometry attributes = doc_object.Attributes
when i test it it returns:
Runtime error (MissingMemberException): 'NoneType' object has no attribute 'Geometry'Traceback: line 17, in script
I DID CHANGE TO LIST ACCESS which is the most common problem. So i don't know what is wrong? I'll post the file below.…