I want to be able to store a circle using a fixed point g and radius d, then get those values back when retrieving the information.
The only way I've found to use those arguments to create a geographic object is to use buffer which produces a polygon:
https://dev.mysql.com/doc/refman/5.6/en/spatial-operator-functions.html#function_buffer
SELECT ASTEXT( BUFFER ( POINT( 10, 10 ), 5 ) );
| POLYGON((10 0,9.50932325672582 0.012045437948275506,9.019828596704395 0.048152733278032045,8.532695255446383 0.10823490035219052,8.049096779838717 0.1921471959676957,7.570198200967361 0.2996874680545609,7.097153227455378 0.4305966426779104,6.631101466077799 0.5845593481697922,6.173165676349102 0.7612046748871322,5.724449065697179 0.9601070687655664,5.286032631740024 1.1807873565164506,4.858972558067784 1.4227138999972784,4.444297669803978 1.6853038769745474,4.043006955075667 1.9679246851935517,3.6560671583635447 2.2698954663726303,3.2844104515298165 2.5904887464504087,2.9289321881345254 2.9289321881345254,2.5904887464504087 3.2844104515298165,2.2698954663726303 3.6560671583635447,1.9679246851935517 4.043006955075667,1.6853038769745474 4.444297669803978,1.4227138999972784 4.858972558067784,1.1807873565164506 5.286032631740024,0.9601070687655664 5.724449065697179,0.7612046748871322 6.173165676349102,0.5845593481697922 6.631101466077799,0.4305966426779104 7.097153227455378,0.2996874680545609 7.570198200967361,0.1921471959676957 8.049096779838717,0.10823490035219052 8.532695255446383,0.048152733278032045 9.019828596704395,0.012045437948275506 9.50932325672582,0 10,0.048152733278032045 10.980171403295605,0.10823490035219052 11.467304744553617,0.1921471959676957 11.950903220161283,0.2996874680545609 12.429801799032639,0.4305966426779104 12.902846772544622,0.5845593481697922 13.368898533922202,0.7612046748871322 13.826834323650898,0.9601070687655664 14.27555093430282,1.1807873565164506 14.713967368259976,1.4227138999972784 15.141027441932216,1.6853038769745474 15.555702330196022,1.9679246851935517 15.956993044924333,2.2698954663726303 16.343932841636455,2.5904887464504087 16.715589548470184,2.9289321881345254 17.071067811865476,3.2844104515298165 17.409511253549592,3.6560671583635447 17.73010453362737,4.043006955075667 18.03207531480645,4.444297669803978 18.314696123025453,4.858972558067784 18.577286100002723,5.286032631740024 18.81921264348355,5.724449065697179 19.039892931234434,6.173165676349102 19.238795325112868,6.631101466077799 19.41544065183021,7.097153227455378 19.569403357322088,7.570198200967361 19.70031253194544,8.049096779838717 19.807852804032304,8.532695255446383 19.89176509964781,9.019828596704395 19.95184726672197,9.50932325672582 19.987954562051726,10 20,10.49067674327418 19.987954562051726,10.980171403295605 19.95184726672197,11.467304744553617 19.89176509964781,11.950903220161283 19.807852804032304,12.429801799032639 19.70031253194544,12.902846772544622 19.569403357322088,13.368898533922202 19.41544065183021,13.826834323650898 19.238795325112868,14.27555093430282 19.039892931234434,14.713967368259976 18.81921264348355,15.141027441932216 18.577286100002723,15.555702330196022 18.314696123025453,15.956993044924333 18.03207531480645,16.343932841636455 17.73010453362737,16.715589548470184 17.409511253549592,17.071067811865476 17.071067811865476,17.409511253549592 16.715589548470184,17.73010453362737 16.343932841636455,18.03207531480645 15.956993044924333,18.314696123025453 15.555702330196022,18.577286100002723 15.141027441932216,18.81921264348355 14.713967368259976,19.039892931234434 14.27555093430282,19.238795325112868 13.826834323650898,19.41544065183021 13.368898533922202,19.569403357322088 12.902846772544622,19.70031253194544 12.429801799032639,19.807852804032304 11.950903220161283,19.89176509964781 11.467304744553617,19.95184726672197 10.980171403295605,19.987954562051726 10.49067674327418,20 10,19.95184726672197 9.019828596704395,19.89176509964781 8.532695255446383,19.807852804032304 8.049096779838717,19.70031253194544 7.570198200967361,19.569403357322088 7.097153227455378,19.41544065183021 6.631101466077799,19.238795325112868 6.173165676349102,19.039892931234434 5.724449065697179,18.81921264348355 5.286032631740024,18.577286100002723 4.858972558067784,18.314696123025453 4.444297669803978,18.03207531480645 4.043006955075667,17.73010453362737 3.6560671583635447,17.409511253549592 3.2844104515298165,17.071067811865476 2.9289321881345254,16.715589548470184 2.5904887464504087,16.343932841636455 2.2698954663726303,15.956993044924333 1.9679246851935517,15.555702330196022 1.6853038769745474,15.141027441932216 1.4227138999972784,14.713967368259976 1.1807873565164506,14.27555093430282 0.9601070687655664,13.826834323650898 0.7612046748871322,13.368898533922202 0.5845593481697922,12.902846772544622 0.4305966426779104,12.429801799032639 0.2996874680545609,11.950903220161283 0.1921471959676957,11.467304744553617 0.10823490035219052,10.980171403295605 0.048152733278032045,10.49067674327418 0.012045437948275506,10 0)) |
1 row in set (0.00 sec)
My problem with this is that I cannot retrieve the point and radius when selecting this row in the future, instead I get the polygon back.
Is there not a better way to store a circle for use with MySQL GeoSpatial Extensions?
Spatial databases are not great at storing curves; rather they tend to be approximated by lots of straight segments, so you're not actually retaining a circle. Support for curved geometries is improving but it's still not really there.
I would probably store the geometry as you have, as well as the radius as a floating point value.
Alternatively, if you only want to store the geometry, you can obtain the centre of the polygon ("circle") with the Centroid function, and then get the radius by converting the polygon to a line and determining the distance between the centroid and the line. There are other ways to determine this distance, too. the caveat is that because this is only an approximation of a circle, the distance between the centre of the circle and its edge is different when measured between the centre and one of the vertices, and when measured from the centre and an edge between two vertices. So if you do not store the radius independently of the geometry, ideally you should measure distance between a vertex and the centre, which will be equal to the original radius (buffer distance). Practically the difference will be rather small so long as your "circle" has dense vertices.
When using ol3-cesium and the map is in 3d mode, calling map.getView().getZoom() returns undefined. This might affect setZoom as well.
I understand we are in a 3d world, so there are no z-levels as in the tiled maps. On the other hand, Google Maps calculates a z-equivalent when coming back grom 3d to 2d.
How can I convert from height to a z-equivalent? Any formula, taking into account the latitude and altitude, to get the z equivalent?
There's no easy formula to get a 2D "Z" value from 3D, because the 3D camera can be tilted, can see different levels of tiles in the foreground vs the background, etc.
For individual tiles however, there are specific known "Level" values from the imagery quadtree. You can see these in Cesium Inspector by clicking the little + next to the word Terrain on the right side, and then put a checkmark on Show tile coordinates. The coordinates shown include L, X, and Y, where L is the tile's level (0 being the most zoomed-out, higher numbers more zoomed in), and X and Y are 2D positions within the imagery layer.
I posted an answer on GIS SE that shows how to reach in and grab these tiles, the same way Cesium Inspector does, along with a number of caveats involved. You could potentially look for the highest-level visible tile, and use that as your "Z" value.
I know this is not accurate, but sharing in case this is of use to anyone.
I have moved to several altitudes in Google Maps, switching between the 2D and 3D maps, writing down the z or altitude shown in the address bar:
z altitude (metres)
----- -----------------
3 10311040
4 5932713
5 2966357
6 1483178
7 741589
8.6 243624
11.35 36310
13.85 6410
15.26 2411
17.01 717
18.27 214
19.6 119
20.77 50
21 44
With the above correspondences, I have approximated the following function:
function altitudeToZoom(altitude) {
var A = 40487.57;
var B = 0.00007096758;
var C = 91610.74;
var D = -40467.74;
return D+(A-D)/(1+Math.pow(altitude/C, B));
}
Based on your formula, the reverse conversion should be:
altitude = C * Math.pow((A-D)/(zoomLevel-D) -1, 1/B);
I am having this problem, where I have several cars, numbers and letters, and need to put 5 cars in the starting places. -random order is ok.
I' having trouble finding in AS3 a way so that the EndX and EndY of each object can be in the starting lines and be considered right no matter the order!
I'm having trouble putting the code here so, heres a titanpad with the code:
this is the code:
being (um, dois, tres, quatro) the movieclip instance name for each numbered car.
https://titanpad.com/42vtnCbvLu
First of all, you could probably benefit by using the distance between two points formula and seeing if the distance is less than a certain value rather than checking in all 4 directions manually:
Math.abs(Math.sqrt((x2-x1)^2 + (y2-y1)^2))
Let the position of the car be (x1,y1) and the start position (x2,y2).
This formula will give you the distance between the two points in any direction, and you could test maybe whether this value is less than your offset.
As for the cars in any order part, I'm interpreting that you have your cars and you want the user to drag them to one of 5 spots, a bit like this:
spot1
spot2
spot3
spot4
spot5
All with respective coordinates. My suggestion would be to have a boolean flag for whether each spot is occupied that stops the program checking whether a car is put there after it has been taken once.
Once all these flags are true, then you can proceed.
Hope this helps.
I'm playing with body animation in AS3. I did a body with all parts (excluding fingers) and make a XML with the "skeleton". The XML got the instances of each part and the place of the articulation of the next part. I make it work with cardinal coordinates (x,y) and the body moves when I rotate a part and recalculate all the links again (each part in each articulation).
However, this will demand some calculation each little modification of the body, so now I'm optimizing it. As for de design x,y is easier, so when the body instance is created, the class re-build the XML converting coordinates to Polar system (r,t), like this ("Quadro" is the node with coordinates):
dx = Quadro.#x;
dy = Quadro.#y;
Quadro.#r = Math.sqrt(Math.pow(dx,2) + Math.pow(dy,2));
Quadro.#t = (dy>0)? Math.asin(dx/Quadro.#r) : Math.acos(dy/Quadro.#r);
I did some changes to make it work but at list one quadrant is always wrong! In this case, the upper left is wrong. The neck and the head should be in this place and they are in upper right (mirrored).
Any tips for a right conversion in AS3?
Try to use this:
Quadro.#t=Math.atan2(dy,dx);
From Wikipedia:
The Cartesian coordinates x and y can be converted to polar
coordinates r and φ with r ≥ 0 and φ in the interval (−π, π] by:
I'm on the FIRST robotics team at my high school, and we are working on developing a kiwi drive robot, where there are three omni wheels mounted in a equilateral triangle configuration, like this:
The problem is programming the robot to drive the motors such that that the robot moves in the direction of a given joystick input. For example, to move "up", motors 1 and 2 would be powered equally, while motor 3 would be off. The joystick position is given as a vector, and I was thinking that if the motors were expressed as vectors too, vector projection might be what I need. However, I'm not sure if this is right, and if it is, how I would apply it. I also have a feeling that there may be multiple solutions to one joystick position. Any help would be greatly appreciated.
I've built 9 robots during my time at school (1 FIRST, 8 RoboCup). We used the same omnidrive layout as you do. Beta's answer looks correct but add rotation to all wheels afterwards:
W1 = -1/2 X - sqrt(3)/2 Y + R
W2 = -1/2 X + sqrt(3)/2 Y + R
W3 = X + R
[This is Beta's formula with some added Rotation]
You need to think about the available ranges for your motors. I am guessing it can take a PWM signal of +/-255, so either the input or the output has to be adjusted somewhat. (It's not that hard...)
A good paper with details
To answer your specific questions: Vector projection is essentially what you are doing here. You apply it by having a matrix M, your input from the joystick I and your output to the motors O. Thus O = M * I;
M = [(-0.5 -sqrt(3)/2 +1)
(-0.5 +sqrt(3)/2 +1)
(1 0 +1)]
First let's define some terms. In keeping with the usual convention, the X axis will point to the right and the y axis will point up (so that the thrust of wheel 3 is along the X axis). We'll call the motion of the wheels W1, W2 and W3, each defined so that Wi > 0 means that the wheel rotates in the clockwise direction. In your example, if W1 < 0, W2 = W1 and W3 = 0, the robot will move in the +Y direction.
If all three wheels rotated at the same rate (W1 = W2 = W3) the robot would rotate in place. I'm guessing you don't want that, so the sum of the rotations must be zero: W1 + W2 + W3 = 0.
The motion of each wheel contributes to the motion of the robot; they add as vectors:
W1 = -1/2 X - sqrt(3)/2 Y
W2 = -1/2 X + sqrt(3)/2 Y
W3 = X
So if you know the desired X and Y from the joystick, you have W1, W2 and W3. As we've already seen, the difference between W1 and W2 is what drives Y motion. Their sum drives motion in X.
Though this system can be solved mathematically, in 2002, FIRST Team 857 chose to solve it mechanically. Our control system used three joysticks mounted with their X-axes forming an equilateral triangle, and handles replaced with ball-socket arms connected with a Y-shaped yoke. Map the X-axis of each stick directly to a motor speed, and the control system has been solved. As an advantage, this system is very intuitive for laypeople to run--push the yoke in the direction you want to go, rotate it to turn.
As you have recognized, the first part of this will be finding an appropriate equation to represent the resultant motion for any motor settings. Depending on the level of control and feedback you have on your motor speeds, I would suggest the process you go thorough should start with writing a vector equation: (define positive X as straight ahead)
-M1Cos(30)+M2Cos(30)=X (the negative is because 1 and 2 must be powered the same magnitude, but opposite polarities for forward motion)
M1Sin(30)+M2Sin(30)-M3 = Y (as anticlockwise motion on 1 and 2 will result in the robot moving left in the Y and anticlockwise motion on 3 will result in the robot moving to the right)
The other input that you need to add into this is the desired rotation of the robot, thankfully, M1+M2+M3 = W (Rotational velocity)
Your joystick input will give you X,Y and W, so you have 3 equations with 3 unknowns.
From here it is simultaneous equations, so you may end up with multiple solutions, but these can generally be restricted based on possible motor speeds and the like.
An example of this is the rec::robotino::com::OmniDrive Class - the source code for this method is available too...