How to use Google Map API in server?

1

Is it possible to call Google Map API in server? If yes, how?

I would like to show only Markers that is 10 miles from the user Geolocation during publish. I did pass the user Geolocation parameter during subscribe however when I tried calling google in the server it says “google is not defined”

var arrPharma = [];
var arrayMarkers = Markers.find().fetch();

_.each(arrayMarkers, function (xmarker) {
  if ( distancer( new google.maps.LatLng(origin[0], origin[1]), new google.maps.LatLng(xmarker.Lat, xmarker.Lng), 10 ) )
    arrPharma.push(xmarker.pharma);
  console.log(arrPharma);
  });

Thanks for the help.

1 Like
2

Good question and very funny. That’s on my todo list for today.
I also plan to have some google api call from the server.
I need geo reverse encoding from the server.

Try to use one this packages:
https://atmospherejs.com/classcraft/googleapis
https://atmospherejs.com/percolate/google-api

3

Can you point to me on how percolate google-api be used? I haven’t seen some sample of using it =)

4

If you’re talking geodesic distance, you should use mongo, it’ll be WAY faster. Store your location in standard JSON format & put an index on it. Then, you can do this all on your service with very little overhead and no external calls. If you have to use google on the server, you don’t call it via the javascript wrapper, but rather via a server call. That means you’ll be limited to 2500 calls on YOUR server IP, not the client IP, so the solution doesn’t scale. But seriously, don’t call google, it’s useless to make an external call to just do a geometry problem (see haversine & equirectangular distance formulas).

If you’re doing road distances, what you want is called an isodistance and those get real expensive real fast because basically you run an a* algo in every direction until a threshold is reached. Since you have a finite number of destinations, you could first use mongo to establish everything within 10 “crow-fly” miles, and then use the google distance matrix API on those possibilities to reduce the result to 10 “wolf-run” miles. Careful though, google is a nazi when it comes to rate limits, you’ll have to mitigate that by using a recursive callback in your code…

Hope I’ve made it obvious that you should just stick to a clean and easy $near in your good ol mongo. Cheers

3 Likes
5

I tested both packages, but I decided to use just plain HTTP.call’s
using the standard http package.

Just create a normal URL (test it in the browser), then call this
var options = {};
var response = HTTP.call(“GET”,requestURL,options);

The response object has a statusCode and a data field.

I use a simple query cache to avoid reaching the limit to fast.

1 Like
6

@mattkrick after reading your reply I was able to find this link after googling about Geospatial query operator $ near. So I thought I’d share it hear to help other people who have the same problem with mine. https://github.com/n0ne/localgeo

The code:

var nearMarkers = allMarkers.find({
      location: {
        $near: {
          $geometry: {
            type: "Point",
            coordinates: location
          },
          $maxDistance: radius
        }
      }
    });
7

You might want to have this in your collection as well: Rooms._ensureIndex({ location : "2dsphere" });, I had problems without it.

8

@benjick should I declare it on the server during startup?

9

Yes, I think so. I only run it on the server, but startup might be good as well

10

You found my link, cool (-:
But in my case I publish all markers and make search on the client.
In your case, it might make sense to publish the markers within 30-50 miles, and the client has to make a selection within 10 miles

11

Yes, look at https://github.com/n0ne/localgeo/blob/master/server/server.js#L5
And don’t forget about MongoDB specific Geo-field:

location: {
      type:    'Point',
      coordinates: [longitude, latitude]
}

Longitude first.

If you use aldeed:simple-schema you can add index: 2dsphere to the location and then you don’t need it in startup.

12

I would just add that geo $range etc meteor cursors are not using oplog, so performance does not have to be top notch.