I don't know if this is supposed to happen, but it is definitely not what I want.
I have a python script that creates a kml file based on latitude, longitude and altitude from a database. Once the kml is created, everything looks fine, but the bearing gets messed up whenever you zoom out or get near +/- 90 latitude (the poles).
Does anyone know if this is a glitch with Google Earth or if this is how it is supposed to be? Does anyone know how to fix it?
Before you conclude that the arrows on Google Earth should reorient themselves, hear me out: the arrows on the map should point to the back of one another, and they do (most of the time). However, like I said, if you zoom out or get near the poles, then the arrows flip sideways.
I think the problem is that Google Earth assumes that the orientation of all of the Placemarks should be the same based on one Placemark, and thus the majority of the arrows point the wrong way in many instances.
Check this kml file out if you don't believe me... (Go to the north pole and move over it a couple of times and you should see what I am talking about.) (Also, after you download, right click and select open with... Google Earth - make sure you download it too.)
https://docs.google.com/file/d/0B_achbIA2bcBdnp5b3J3WlJ3U1U/edit?usp=drive_web
Any ideas?
In your KML file, you are specifying the icon heading in the <heading> tag inside <IconStyle>. To me, it looks like your computation of bearing is producing the undesirable results. Are you doing something `bearing = atan2( (lon2-lat2)/(lat2 - lat1) ) in your code? If so, your calculations will blow up near the poles (and the bearings will be inaccurate). I suspect you're doing this type of calculation because the arrows are misaligned with the track as you proceed higher in latitude where that bearing calculation's error increases.
If you want to accurate compute bearing from subsequent lat-lon-alt pairs, I recommend converting the lat-lon-alt pairs into 3D Cartesian position vectors, approximating the velocity vector by finite difference, and then resolving the velocity direction in the North-East-Down coordinate system (or East-North-Up, if you prefer). Then you can solve accurately for bearing.
tl;dr: It's not Google Earth that's messing up. I think it's your bearing calculation.
Related
I am trying to draw a concave circle, e.g. something like a soup bowl to form the "pips" on a die in a Yahtzee like program I am working on using C#.
It seems to me that in graphics "concave" has a different, and quite complex, meaning to what I am trying to achieve - the opposite of convex.
I can draw quite a realistic ball using a PathGradientBrush with white at a position one third of the way across and one third down and SurroundColors of the ball colour and I had hoped by moving the white spot to two thirds across and down I might get what I want but sadly not.
Can anybody give me a steer please? Even a pointer to what might be better search term would be a good start.
Many thanks.
Back story: I'm creating a Three.js based 3D graphing library. Similar to sigma.js, but 3D. It's called graphosaurus and the source can be found here. I'm using Three.js and using a single particle representing a single node in the graph.
This was the first task I had to deal with: given an arbitrary set of points (that each contain X,Y,Z coordinates), determine the optimal camera position (X,Y,Z) that can view all the points in the graph.
My initial solution (which we'll call Solution 1) involved calculating the bounding sphere of all the points and then scale the sphere to be a sphere of radius 5 around the point 0,0,0. Since the points will be guaranteed to always fall in that area, I can set a static position for the camera (assuming the FOV is static) and the data will always be visible. This works well, but it either requires changing the point coordinates the user specified, or duplicating all the points, neither of which are great.
My new solution (which we'll call Solution 2) involves not touching the coordinates of the inputted data, but instead just positioning the camera to match the data. I encountered a problem with this solution. For some reason, when dealing with really large data, the particles seem to flicker when positioned in front/behind of other particles.
Here are examples of both solutions. Make sure to move the graph around to see the effects:
Solution 1
Solution 2
You can see the diff for the code here
Let me know if you have any insight on how to get rid of the flickering. Thanks!
It turns out that my near value for the camera was too low and the far value was too high, resulting in "z-fighting". By narrowing these values on my dataset, the problem went away. Since my dataset is user dependent, I need to determine an algorithm to generate these values dynamically.
I noticed that in the sol#2 the flickering only occurs when the camera is moving. One possible reason can be that, when the camera position is changing rapidly, different transforms get applied to different particles. So if a camera moves from X to X + DELTAX during a time step, one set of particles get the camera transform for X while the others get the transform for X + DELTAX.
If you separate your rendering from the user interaction, that should fix the issue, assuming this is the issue. That means that you should apply the same transform to all the particles and the edges connecting them, by locking (not updating ) the transform matrix until the rendering loop is done.
I have this fun idea of a project i'd like to do, but i'm not really sure about the math part of it. Here is the idea:
Make a plastic card that would simulate a 9 finger multitouch gesture when it is held against a capacitive screen
Based on the "9 finger" placement, determine some sort of a unique string and use it as an encryption/decryption key for an app
This way i could just open an app, touch the screen with the card and it would get authorized.
But here's the problem:
It shouldn't matter where you place the card on a screen, because the card would be pretty small to fit various screen sizes
The rectangle in which we can randomly position the 9 "fingers" would optimally be 4.5cm x 3cm
The "finger" itself is only recognized as a touch if it is about a 6mm circle (not sure if this can be made smaller)
I figured we could find the left-top "finger" and get every other "finger's" X and Y difference from it. Then concatenate the resulting numbers into a string and use it as a decryption/encryption key. So basically:
key = concat(X2 - X1, Y2 - Y1, X3 - X1, Y3 - Y1, ...)
But i think such an approach would have very few possible combinations (given a relatively small card size and a relatively big "finger") and one could easily write a program to generate all possible combinations and break the key in no time. Am i right about this? If so, how could i improve this?
Thanks for your thoughts
UPDATE 1: actually tried it out on iOS. The result is not promising, since the "fingers" get detected differently each time. The distance between them varies significantly (by as much as 40 pixels!). So i guess this is not as easy as i expected, since the OS seems to detect the touch differently each time for the same two circles.
Your question is lacking some relevant information: how far apart need the circles be so that the system can still distinguish them? What resolution can you realistically expect for the circle centers? And by “6mm circle”, do you mean 6mm diameter or radius (or even circumference)?
Lacking details, I'll make some pretty rough approximations. I'll start by requiring that two of the circles will be placed in opposite corners of the card. That way, you can find them by looking for a pair with maximal distance, and from that compute the orientation and size of the card and correct for that. This leaves 7 fingers to be placed randomly. I'll assume 1mm resolution, and restrict myself to a 45×30mm area. Which means 39×24=936 positions per circle, for a total of 9367≈6,3×1020≈269 combinations. OK, this does not exclude overlapping circles. But since the card is still rather sparsely covered, that shouldn't amount to too much. I'd say 64 bit of entropy (i.e. 264 possible combinations) should be reasonable even if you enforce non-overlapping circles. If you can really detect the circle centers with the required resolution, that is. This should be sufficient security for most applications. Far better than 8-letter passwords, but worse than the symmetric keys usually used for e.g. AES.
Since all of this depends very much on the resolution, it might be worthwhile to investigate that aspect first. Usually you'll get pixel coordinates for your finger positions, but it would be expecting too much to assume that you'd always get the pixel coordinate closest to the center of your circle. So you might start by writing a small application which draws a 6mm circle and records coordinates it receives. Then place a 6mm artificial circle in that drawn one a large number of times. Look how far the recorded positions differ from the center of circle. Take the maximum of those differences, perhaps after removing outliers. I'd add a pixel or two to that, to account for rounding errors due to the rotation of the card. Then turn that pixel count back into a metric length. This is the resolution you can expect. You might have to do this for several devices. If you do perform these experiments, let me know what you find and I'll update my answer accordingly.
I have the coordinates of a point and an azimuth.
I want to place a pin in the coordinate of the point, and draw a line segment of a certain length L beginning from the point, and oriented in a certain given azimuth.
Is there a simple manner to do that in KML?
I do not want to calculate the coordinate of the second point to draw the segment.
Thanks for help
There seems to be no way to do a calculation in kml itself so the line segment end point would have to be calculated before the construction of the kml or as kml supplied from a server. So the short answer would seem to be that it is not possible.
However I wonder if you could create a model consisting of the line of known length and orientation and plot the 'model' at the pin position. This of course would allow construction of much more sophisticated lines with arrow heads or planes extending to ground etc.
I tried a quick example using Google Sketchup and it seems to work OK
Hope this helps
Bob J.
KML does not do calculations for you. You'll need to do the calculation yourself.
I am trying to create an application similar in UI to Sketchup. As a first step, I need to display the ground surface stretching out in all directions. What is the best way to do this?
Options:
Create a sufficiently large regular polygon stretching out in all directions from the origin. Here there is a possibility of the user hitting the edges and falling off the surface of the earth.
Model the surface of the earth as a sphere/spheroid. Here I will be limiting my vertex co-ordinates to very large values prone to rounding off errors. (Radius of earth is 6371000000 millimeter).
Same as 1 but dynamically extend the ends of the earth as the user gets close to them.
What is the usual practice?
I guess you would do neither of these, but instead use a virtual ground.
So you just find out, what portion of the ground is visible in the viewport and then create a plane large enough to fill that. With some reasonable maxiumum, which simulates the end of the line of sight aka horizon as we know it.