I am trying to get the world coordinates( i.e. viewer coordinate) of a markups position. But I am unable to get It.
What I am doing:
In case of Arrow:-
I have drawn an arrow and I am getting its head and tail. Then I am trying to convert it to world client using viewer.clientToWorld as shown below
In Above screen shot m is my markup
Reason I am doing this is that I want to set a cutPlane in viewer which is exactly parallel to my markup.
Also suggest how can I find a plane which is parallel to the line and will be along z axis.
Thanks & Regards
Saurabh A.
viewer.clientToWorld could only get you the world positions when the client coords intersect a node (a point/part of the model).
To get world positions when the client coords are not intersecting see here
I have a set of data points where each point is expressed as a lat/lng. Each of these points has a value associated with it that changes over time. I would like to produce a heatmap animation overlay on top of a map that reflects this change in value over time. Note: I am fine with producing a series of static "snapshots" and piecing them together frame-by-frame into an animation, so the heatmap library itself does not have to support animation.
My first attempt was to use the HeatMapLayer which is a part of the Google Maps visualization library. However as per the question Heatmap based on average weights and not on the number of data points, it would seem that this particular visualization library insists on weighing the density of points in determining what color to use surrounding a given point.
I am after a solution that only considers the value of the points rather than the density. To give an example, assume one wanted to visualize the ambient temperature of a city over time, but there were more thermometers installed in some parts of the city than others. You wouldn't want a small area with many thermometers installed to show up red just because there were many thermometers - you'd want it to show up red only if it was hot there.
Basically, I want a single color for each of my points that reflects the intensity of the point's value, and then a gradient spatial transition between any two point's colors. It doesn't have to be Google Maps - the key criteria is just i) must base colors off point values not point densities ii) must overlay on top of a map and iii) ideally has a programming abstraction that talks in terms of lat/lng's, rather than requiring manual conversion to e.g. Euclidean space.
global tempsYou can do this with multiple:
gmaps.symbol_layer
and then just layer them up:
fig_gmap.add_layer(red_markers)
fig_gmap.add_layer(yellow_markers)
fig_gmap.add_layer(green_markers)
fig_gmap.add_layer(blue_markers)
I haven't been able to successfully pass a value that gives me a good temp color for the heat maps, just always get some variation on the density thing, which is a one trick pony. It would be nice having a way to do this and animate the marker icon without java.
Maybe you should try heatmap.js. It has a plugin for Google Maps: http://www.patrick-wied.at/static/heatmapjs/plugin-gmaps-layer.html
This library uses datasets made of coordinates and values. I think it will behave the way you described.
I am writing some code which clusters markers on a Google map. The clustering algorithm relies on knowing how many degrees latitude and longitude are currently visible to the user, as I break the map into a grid of n/map_pixels_width x n/map_pixels_height squares and need to know how many degrees of lat/lon are in each square to know which square each marker point belongs to.
Under normal circumstances where the map does not wrap this is relatively easy to calculate using getBounds() on the Google Map object and doing the calculations to figure out the latitudinal and longitudinal distances between the returned North-East and Sout-West points. Where I'm running into issues is where the map is zoomed out to the extent that it wraps the entire Earth > 1 times. For example, I can zoom out the map so that the entire Earth is "tiled" 5 times over which equates to 360 * 5 = 1800 longitudinal degrees and, but then the call to getBounds() no longer provides useful information:
m.getBounds().getNorthEast().lat()
88.31833020528785
m.getBounds().getNorthEast().lng()
180
m.getBounds().getSouthWest().lat()
-88.5485785544835
m.getBounds().getSouthWest().lng()
-180
Basically, the longitudes getBounds() reports are just the min and max for one whole globe which says nothing about how many times the Earth is repeated. Although Google Maps doesn't tile the map vertically (it just inserts gray filing space if zoomed out far enough), I have conceptually the same problem -- I need to know how many total degrees of space the vertical area would consume.
Is there a way to get the total number of visible longitudinal degrees?
So based on this answer to another question, I found a (hackish) way to solve this. Basically, the Google Maps OverlayView class has a getProjection() method returning a MapCanvasProjection object, which in turn has a getWorldWidth() method which returns the width of the world at the current zoom level in pixels. So the way to solve the problem then is to:
Add a dummy OverlayView to the map that doesn't actually present an overlay.
Get the overlay's projection.
Get the world width from the projection.
Calculate the number of visible longitudinal degrees as pixel_width_of_map_element / world_width_in_pixels * 360
It would be better if there were a way to do this without creating a dummy overlay, but this method seems to work.
I'm creating Google Static Maps with a path between markers and have come across certain coordinate combinations that break the path.
The path breaks in this example (markers # Beijing, SF, NY, Azores, Rome):
http://maps.google.com/maps/api/staticmap?path=color:0xff0000cc|weight:3|39.904214,116.407413|37.77493,-122.419416|40.714353,-74.005973|38.721642,-27.220577|41.89052,12.494249&markers=39.904214,116.407413|37.77493,-122.419416|40.714353,-74.005973|38.721642,-27.220577|41.89052,12.494249&maptype=terrain&sensor=false&size=640x404
And works in this example (marker # Rome removed)
http://maps.google.com/maps/api/staticmap?path=color:0xff0000cc|weight:3|39.904214,116.407413|37.77493,-122.419416|40.714353,-74.005973|38.721642,-27.220577&markers=39.904214,116.407413|37.77493,-122.419416|40.714353,-74.005973|38.721642,-27.220577&maptype=terrain&sensor=false&size=640x404
The cause is not crossing over the Greenwich Meridian as I initially thought. It breaks even if I add a marker before that, seemingly any a point East of the automatically calculated centerpoint of the map...but only when the path starts on the other side of -180 longitude.
To prove that, you can see that the Beijing, SF, NY, Azores, Rome path displays correctly when I set the map centerpoint to -170,35
http://maps.google.com/maps/api/staticmap?path=color:0xff0000cc|weight:3|39.904214,116.407413|37.77493,-122.419416|40.714353,-74.005973|38.721642,-27.220577|41.89052,12.494249&markers=39.904214,116.407413|37.77493,-122.419416|40.714353,-74.005973|38.721642,-27.220577|41.89052,12.494249&maptype=terrain&sensor=false&size=640x404¢er=-170,35
Unfortunately, I can't programmatically set center like this because I never know the collection of points I'm going to get, and it would be next to impossible to detect that the passed points would cause a line break.
Any ideas?
First: you can calculate the center even if you don't know the collection of points (locations) at compile time: at runtime you know all the points (otherwise it would be not possible to insert the coordinates into the URL), therefore you can easily iterate over all the points and compute the center. You can computing the average of all coordinates and you get the geometric center (also called centroid): this is the easier way. Another way to do is to check the most distant pair of locations (for both, latitude and longitude) and then set the middle point as center: this requires slightly more coding (for instance to compute the longitude distance you need to take into account the you have to compute the distance in two directions, since it is possible to go 'around the world) and it has an higher complexity.
I don't go deeper in this topic because, even if you compute correctly the center of your points, this does NOT resolve the problem, and moreover the center provided automatically by the Google static map API is always correct: again the center is related to the problem, but it is not the (couse of the) problem.
An aspect that is trivial but important to keep in mind: Google static map draws a path between two locations always by considering the shortest path, i.e. by drawing the shortest straight line.
Therefore if you are in a situation where your path has to go from a location A to a location B, and the shortest path between A and B goes 'around the world' (or better, it goes out from one side of the image), then the path appears 'borken' as in maps that you have shown. In practice A and B are near the left and right margins of the map, and the map can not be centered in some point along the shortest path between A and B because of the others point of the path. And this is what happen when you remove 'Rome': without Rome the map can be centered in a way that the path is not borken.
Formally, I think that the problem appears (i.e. the path is broken), when the projection of the path on the equator is longer than 360 degree of longitudes, and the path always goes in the same direction (i.e. always west to east or always east to west).
Google static map in this situation simply adds another world map next to the first one: if you set the zoom to the minimum, you can see up to three world maps. This is really impractical for several reasons:
you can not zoom out infinitely;
if you want also insert markers into the map they will be drawn only on the 'main' map;
potentially you can have a path that goes around the world (passing in sequence from America, Europe, Asia, and America again and so on...) many times, and it would be really terrible to have so many little maps one after each other;
I googled a lot about this problem, and I didn't find any solution, there is a bug open on the bug tracker, but it is unsolved.
In my opinion the 'right' way to do is simply the following: at most one map and if a path has to goes out from one margin of the map/image, then it should appear on the opposite margin and continues to the destination, drawn on the same map.
So I found a first workaround:
you draw your path, and with the same style (line's color, etc) you also draw the path in a reversed way (Google static map allows to draws multiple paths in the same map), i.e. path=A|B|C&path=C|B|A and this will solve the problem in many situations (i.e. the path exits from one side of the image and enters from the other). Unfortunately this not works always: if you have a path that cross the image margin two consecutive times, then you lose a portion of your path
To solve this problem I found a second workaround:
- not draw simply the path and its reverse, but draw a different path for every pair of locations of the path (and reversed), i.e. for a path A->B->C then: path:A|B,path=B|C,path=C|B,path=B|A and this works always
The drawback is that in this way the URL becomes very long and the limit of 2048 characters for URLs is easily reached.
The best solution would be to compute manually the center, check manually where the path will cross the margin, and only for this portion of the path draw an additional path going between the two locations at the margin (and maybe also the reverse), but I do not think it really worth, although I do not think Google ever will solve this problem.
I have a requirement to calculate the centroid or geodesic midpoint of
when a user clicks in between the lat/long grid crossing.
The crossing forms a square in most parts of GE and sometimes
elongated rectangles. This is due to the shape of the earth of course.
I'm looking for a valid mathematical formula that would allow a user
to click anywhere in between this grid and then an accurate function
(in Javascript or server side code) that would take an assumed grid
resolution (say 1km intervals for this discussion) and the input
coordinates that should return a centroid coordinate within that
graticule grid.
To clarify please take a look at the attached image to my google group post:
http://google-earth-api.googlegroups.com/web/Picture+5.png?gda=h5oFPz8AAAD315KpovipQeBwdfGpmW3ZhBc9PTADwYa-n193hZ6AItFmHuno63c7phcEXYVuRA6ccyFKn-rNKC-d1pM_IdV0&gsc=sz6bbAsAAABBKF7YXWYyc4GmXg-QruHj
What I need to be able to do is if a user clicks anywhere in this grid
square, I need to find the centroid or center point of that grid
intersection/square or at least the bounding grid coordinates (that make the square).
If we assume that the grid is UTM standard and has a max resolution of
1km (or make this a parameter), I need to detect the four other points
nearby and then calculating the centroid is not as difficult.
I welcome any feedback you all may have and appreciate it.
I don't have a simple way of letting a user click anywhere on the grid and finding the grid bounding coordinates (making a square of 4 coordinates) or the centroid / midpoint of the graticule grid square necessary.
One thought is to use assumptions as much as possible using a reference such as UTM coordinate reference.
If I assume that the grid is X degrees wide, can we have a pure javascript function take any input coordinate and return for me the bounding graticule coordinates in Decimal Degrees?
Another thought I had was to create the grid in a geo-spatial layer to take any input coordinate and return the nearest centroid of the graticule?
Does this make sense?
Thanks!
Omar
this seems to be a rounding problem
1) your users click anywhere on the map
2) you want to trap the click to read out the actualLat/actualLon values
3) and round it down to the nearest discrete grid values minLat/minLon
4) then you want to calculate and return in some way the midpoint of the grid as
midLat = minLat + deltaGridLat/2;
midLon = minLon + deltaGridLon/2;
ad 2) look up the .js file in my Maidenhead locator viewer - you can surely reuse code for initializing the GE event handler and the handler for a mouse click (note I am trapping a RIGHT click)
The event handler essentially takes the user chosen location, passes it to function CoordToLoc() where the coordinates are converted to a Maidenhead locator string, which then is displayed in field inpLocator on the web page.
ad 3) this depends on your grid - if it is bound to discrete Lat/Lon values (as in my case) it's as simple as rounding. If the grid points are defined as distance offsets in km from a reference point, the simple approach would be to divide your argument by the unity length and disregard the decimal places
Hope this helps
Good luck
MikeD