leontoeides/google_maps

An unofficial Google Maps Platform client library for the Rust programming language.

google_maps's Issues

Distance matrix api response elements are private

The response elements of the distance matrix api Response are private and so can't be retrieved.

Feature Request - nearby_search

Hi I would like to use some existing functionality that is mapped here, as well as google's nearby_search request. Would you be interested in implementing this functionality, otherwise providing some high level steps on how to add support.

I don't see a great example PR towards adding a new function, if you'd like me to take a stab at this, could you point me to some specific commits.

Thanks.

Cannot be used in async context, conflicts with parent runtime

I am using this library from an async context, and it seems to break with the message:

thread 'tokio-runtime-worker' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.'

I have worked around it using an additional thread to wrap the google_maps usage.

But really, shouldn't the library be modified to be able to be used in a context with an existing runtime?

I was thinking, maybe it would be possible to provide either an async API? Alternatively, google_maps could simply return a reqwest::RequestBuilder and let me execute the request with my own reqwest::Client, then I could pass the response back into this library.

Or maybe there is some other obvious solution I am missing?

Thanks for your efforts, it works fine so far!

Support providing a preconfigured reqwest client to ClientSettings

This would make it far easier to write tests for systems that use this library

Add landmark to place type

Currently getting the following error:

called `Result::unwrap()` on an `Err` value: Google Maps Platform API client: `landmark` is not a recognized place type code. For a list of supported place types see https://developers.google.com/places/web-service/supported_types at line 67892 column 10

while landmark is showing up in the documentation.

`Result::unwrap()` on an `Err` value: Google Maps Directions API client in the Serde JSON library: missing field `html_instructions`

Code

// self.address = "Regensburger Str. 35 93180 Deuerling".to_string()

let api_key = std::env::var("MAPS_API_KEY")?;
let google_maps_client = GoogleMapsClient::new(&api_key);

let transit_directions = google_maps_client.directions(
    Location::LatLng(LatLng::try_from_f64(48.8525837, 2.3723538)?),
    Location::Address(self.address.clone()),
)
    .with_travel_mode(TravelMode::Transit)
    .execute()
    .await?;

Error

called `Result::unwrap()` on an `Err` value: Google Maps Directions API client in the Serde JSON library: missing field `html_instructions` at line 447 column 25

Replacing

google_maps/src/directions/response/step.rs

Line 46 in 1afac5d

pub html_instructions: String,

by

pub html_instructions: Option<String>,

fixes it

It's weird cause I've intercepted the request and it seems that each html_instructions field is defined.

Deserialization of PlaceType is not invertible.

This code does not work.

use google_maps::prelude::PlaceType;
let z: PlaceType = serde_json::from_str(&serde_json::to_string(&PlaceType::Accounting).unwrap()).unwrap();

Distance matrix struct, makes a request with coordinates in degrees

When doing a request, with the distance_matrix, the coordinates on the URL are being send as degrees, such as:

https://maps.googleapis.com/maps/api/distancematrix/json?key=XXXXXXX&origins=19.4431618° N 99.2912182° W&destinations=19.4118438° N 99.1755364° W&mode=driving which if you paste it into a browser window, it returns

{
   "destination_addresses" : [ "" ],
   "origin_addresses" : [ "" ],
   "rows" : [
      {
         "elements" : [
            {
               "status" : "NOT_FOUND"
            }
         ]
      }
   ],
   "status" : "OK"
}

but if you modify manually the coordinates to: https://maps.googleapis.com/maps/api/distancematrix/json?key=XXXXXXX&origins=19.4431618,-99.2912182&destinations=19.4118438,-99.1755364&mode=driving

It does return correctly:

   "destination_addresses" : [
      "Av. Amatlan 84, Colonia Condesa, Cuauhtémoc, 06140 Ciudad de México, CDMX, México"
   ],
   "origin_addresses" : [
      "Vicente Saldivar 15, Olímpica Radio 2a Secc, Olimpica, 53690 Ciudad de México, Méx., México"
   ],
   "rows" : [
      {
         "elements" : [
            {
               "distance" : {
                  "text" : "19.0 km",
                  "value" : 19017
               },
               "duration" : {
                  "text" : "24 min",
                  "value" : 1469
               },
               "status" : "OK"
            }
         ]
      }
   ],
   "status" : "OK"
}```

Handle optional Geocoding fields in response

I use the Google Maps Javascript API, and can select which fields I get in response.

I'm having an issue where Google's JS library returns a different type of viewport -- north, east, west, south -- instead of southwest, northeast, when using the Autocomplete API.

Two options to solve this:

1. Make viewport an Option and not request it through the API.
2. Make it an enum to support both formats.

Would be happy to create a PR, do you have a preference to 1 or 2?

References:
https://developers.google.com/maps/documentation/javascript/reference/places-service#PlaceResult
https://developers.google.com/maps/documentation/javascript/reference/coordinates#LatLngBounds

[Feature request] Place autocomplete API

Hello,

Would you be willing to implement Places API? In reality, I only need the place autocomplete one, which I guess I could implement if you don't have the time for it. But the whole API is outside of my use case and time constraints.

Please let me know!

Thanks,
Mark

(full) Web Assembly support

Currently, enabling enable-reqwest feature enables reqwest/default-tls, which for obvious reasons does not compile on wasm32.

Reqwest works on WASM using JS' fetch API, so usage of a transport features (TLS, gzip, brotli) is not necessary.

Sadly, by disabling the enable-reqwest feature, the get (and execute) extensions to Requests are disabled, altough they would work just fine. This leaves Web Assembly half-supported - the requests can be built and validated, but not executed (they can still be executed manually though).

TLDR: Making enable-reqwest feature not require incompatible extensions on wasm32 target should be enough to enable _full _ Web Assembly support.

PS: One could argue that it is not a good idea to give access to API keys in a client application in the first place ¯\_(ツ)_/¯

Switch from `log` to `tracing`

We currently use log for logging, but we also pull in tracing through Hyper, and the nesting structure of tracing might be a good fit for us anyway. So, we should switch to tracing everywhere.

Proposal

• Replace all uses of the log crate with tracing (there are verbatim replacements for the logging macros, so no code changes)
• Replace all uses of {:?} in tracing macro invocations with ?value infront of the format string

native-tls included in dependencies even with rustls enabled

Hello 👋

I upgraded from 2.x to 3.x and saw that native-tls features for reqwest are included in the build, even when the rustls feature is specified for the google_maps crate. It would seem that this new dependency for reqwest-maybe-middleware causes this. I don't know much about this project, but considering it has no README, no stars, and seems to be relatively inactive, it may be best to just include its source code into the project (or fork it, publish your own version, and maintain it separately).

Additionally, it would be helpful to upgrade reqwest to 0.12 from 0.11.

Thanks!