How do I calculate the distance covered by the user using the google fit API?
Related
The goal is to display large amount of data on Google Maps. By large amount I mean around 10 millions of segments stored in PostgreSQL database. The segments represent some characteristics of roads, so segments should overlay the roads in base map. The segment properties may change over time.
The best technical solution for this problem is to use custom tile server (please correct if wrong).
According to Google Maps JS API, I found out two ways to draw over the map using custom tile server:
using GeoJson/KML data (https://developers.google.com/maps/documentation/javascript/datalayer#load_geojson)
using PNG images (https://developers.google.com/maps/documentation/javascript/maptypes#ImageMapTypes)
I have tried both. The first one does not fit my needs because GeoJson appears too large, what results in performance issues. The second one is bad from UX point of view, because it is using raster tiles, whereas nowadays we should use vector tiles. I also looked at OpenLayers / Leaflet, but didn't find an official way to go with Google Maps (see https://github.com/mapbox/mapbox-gl-js/issues/1791).
The key here would be to use vector tiles, however I cannot manage to render vector tiles (MVT) on Google Maps.
Is there any ways at all to render vector tiles on Google Maps Platform?
I've reached Google Maps Platform support and they advised me to use a deck.gl.
It is a technology for displaying huge data sets on a map, including Google Maps. It uses official Google Maps API for rendering, especially OverlayView.
There is a good blog post about Google Maps & deck.gl here:
https://cloud.google.com/blog/products/maps-platform/high-performance-data-visualizations-google-maps-platform-and-deckgl
I've managed to display custom vector tiles on Google Maps using angular and here is the sample repo:
https://github.com/yterletskyi/deckgl-angular
BTW, thanks to LuisTavares solution about the https://github.com/landtechnologies/Mapbox-vector-tiles-basic-js-renderer library which relies on OverlayView too. I have not tried it but the approach is the same as in deck.gl so there should not by any issues.
UPD:
After playing around with deck.gl, the problem turned to implement this on mobile iOS & Android platforms. After some research I had contacted Google Support but unfortunately there seems to be no solution to this. Google Support quote:
Hello Yura,
Unfortunately there is no way to render vector tiles with the mobile APIs. I also have no recommendations for services that allow you to do this with the Google Maps API.
My apologies,
Check this library to load vector tiles in Google Maps:
https://github.com/techjb/Vector-Tiles-Google-Maps
You just have to create an mbtiles file, then upload to Mapbox or another server, and finally connect to Google Maps.
Why does the Google Places API provide more Points of Interests (POI) by providing a smaller radius? The definition of radius is noted below:
radius — Defines the distance (in meters) within which to bias place results. The maximum allowed radius is 50 000 meters. Results inside of this region will be ranked higher than results outside of the search circle; however, prominent results from outside of the search radius may be included.
When using the API I get significantly more POIs by providing a radius of 50 vs. 200 meters. What is the "bias" that is mentioned in the definition above? Does anyone know how the radius meter search may translate to a zoom level when using Google Maps? Any information provided would be great. Thanks!
I found this issue while experimenting with shapes. As written in documentation, we can draw circle with radius specified in meters. But Google Maps use cylindrical projection of the Earth (edit: ok, it doesn't), so logically, in Arctic regions our circles should be something similar to ellipse. So I conducted simple experiment and drew a circle near The Egde. That's the result:
As we can see, we still have a circle.
So, my question is, how Google Maps API calculates meters? Is there some constant coefficient between meters and coordinates, used consequently? Or maybe this is a bug and in all other cases one meter in Google Maps equals one meter in reality?
So, as I said in comment, the problem was my misinterpretation of the north edge of the map. When it comes to measuring, Google Maps API is reliable. This is how my 400-meters circle looks like near the real north pole:
I want to calculate the image dimensions in GPS coordinates scale based on a certain zoom level in google maps. Basically I want to find the distance between adjacent pixels in GPS coordinates scale.
How can I do this (what's the equation)?
You can find a class dealing with Mercator projection and tile size conversion here. You should be able to use a lot of these utility functions to compute this.
I'm trying to find an effective way to visualise feedback from some real-world sensors measuring wind speeds at various heights. Does anyone know if it's feasible to display 3D data in google maps?
I was imagining 3D arrows indicating direction and wind speed. If it's possible to load a model and position it to a particular GPS position / elevation and then change its orientation to point to a particular azimuth / elevation what could work.
Another alternative I was considering would be to create an image for each height and display the arrow by scaling / rotating the disk. The documentation suggests you could do a single layer at ground level with an overlay but doesn't make any mention of pulling those images up into the air.
I've played with google maps before, but not Google earth. Just trying to get a feel for what might be possible here. Has anyone tried anything like this?
Google maps is 2d and as such does not support 3d objects, things are located via a latitude and longitude only. However, you could easily create a '3d looking' image and incorporate it in to a map using the maps Api.
Google earth is 3d (latitude, longitude, altitude) and supports models and geometries loaded via kmz archives or constructed via the Api. It is fairly trivial to include using either method.
The reason you see no mention of 'pulling those images up into the air' in the doc you reference is because the document covers 'ground overlays' - so they are fixed to the ground...
Anyhow, take a look at the geometries and models section in the google earth api - should be exactly what you need.
http://code.google.com/apis/earth/documentation/geometries.html
http://earth-api-samples.googlecode.com/svn/trunk/examples/model.html