use geocoding::{Opencage, Forward, Point}; - using version 0.3.1 in cargo.toml

let oc: Opencage = Opencage::new("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx".to_string()); let address = "Schwabing, München"; let res: Vec<Point> = oc.forward(&address).unwrap(); let first_result = &res[0];

The third line above responds with the error below:

thread 'main' panicked at 'called Result::unwrap() on an Err value: Error { kind: Json(Error("invalid type: sequence, expected a string", line: 1, column: 393)), url: None }', src/main.rs:91:53

Could it be due to a change in API with OpenCage? I tried OpenStreetMap too, which also responds with a type error. 3rd option not workable as it's limited to Switzerland vs being worldwide.

Use case is to get long lat by address (city, state, zip, country).

This is an implementation of forward and reverse geocoding traits, and the provision of these traits for the OpenCage geocoding service.

The traits are deliberately split, and are deliberately minimal; any geocoding provider should be able to return an address, and accept an address, returning one or more Points. In order to avoid possible incompatibilities, I've re-used the Coordinate and Point structs from Geo. I'm happy to import them, but I'm aware that

a) this will blow up compile times for this crate b) it will make interaction between the two crates less flexible.

The initial implementation makes this trait available for the OpenCage provider, and also makes its full API responses available so that more flexible methods can be added (that isn't WIP, but they'll land at some point in the near future)

It makes it easier to store.

Here is a code example with diesel:

use chrono::NaiveDateTime;
use diesel_as_jsonb::AsJsonb;
use geocoding::opencage::Results as OpenCageResult;
use geocoding::openstreetmap::OpenstreetmapResult as OSMResult;
use uuid::Uuid;

use crate::schema::locations;

#[derive(Serialize, Deserialize, Debug, AsJsonb)]
pub enum LocationData {
    OSM(OSMResult<f64>),
    OpenCage(OpenCageResult<f64>),
}

#[derive(Queryable)]
pub struct Location {
    pub id: Uuid,
    pub provider: String,
    pub data: LocationData,
    pub label: String,
    pub lat: f64,
    pub lon: f64,
    pub created_at: NaiveDateTime,
    pub updated_at: NaiveDateTime,
}

#[derive(Insertable)]
#[table_name = "locations"]
pub struct NewLocation {
    pub provider: String,
    pub data: LocationData,
    pub label: String,
    pub lat: f64,
    pub lon: f64,
}

Build is stalled: https://github.com/georust/geocoding/pull/48#issuecomment-896745354

It seems like maybe bors is set up OK and has appropriate access, but the build status never updates.

I think this is because this repo still relies on travis-ci.

There's too much verbage here for me to be willing to read right now: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

But I believe the take away is that travis-ci is no longer an option for us unless we want to pay, so I'd recommend switching to github actions instead of travis, like we have for most of our other repositories.

Thanks for putting this library together! I took a stab at implementing an OpenStreetMap provider here since it was listed in #1

I tried to follow the patterns from the OpenCage provider and used the builder pattern for specifying additional parameters, but I'm new to Rust so let me know if anything seems off. I'd like to use the InputBounds struct for the viewport parameter here, but wanted to check and see what the best way of restructuring that would be

First of all, thanks for the great library!

It appears I'm running into an error when attempting to deserialize the JSON response from a OpenCage forward geocode request.

Here's my code:

fn forward_geocode(place: &str) -> Option<geocoder::Point> {
    let oc = Opencage::new("redacted".to_string());

    let res = oc.forward(&place);
    let res = match res {
        Ok(res) => res,
        Err(e) => panic!("Oops: {:?}", e),
    };

    println!("Got a response: {:?}", res);

    return Some(geocoder::Point{
        lat: res[0].lat(),
        lng: res[0].lng(),
    });
}

and here's the error I'm experiencing:

thread 'tokio-runtime-worker' panicked at 'Oops: Request(reqwest::Error { kind: Decode, source: Error("invalid type: integer `18`, expected a string", line: 1, column: 4362) })', src/server-old.rs:111:19

After inspecting the raw JSON the issue appears to with this line:

https://github.com/georust/geocoding/blob/444829de1b281a11a6e139c7a58c3ae4e930c768/src/opencage.rs#L535

where the HashMap expects all values to be of type String. This is not the case given the below response payload that shows the house_number property is in fact an integer:

{
  "documentation": "https://opencagedata.com/api",
  "licenses": [
    {
      "name": "see attribution guide",
      "url": "https://opencagedata.com/credits"
    }
  ],
  "rate": {
    "limit": 2500,
    "remaining": 2490,
    "reset": 1606608000
  },
  "results": [
    {
      "components": {
        "ISO_3166-1_alpha-2": "AU",
        "ISO_3166-1_alpha-3": "AUS",
        "_category": "building",
        "_type": "building",
        "city": "CONCORD",
        "continent": "Oceania",
        "country": "Australia",
        "country_code": "au",
+        "house_number": 18,
        "postcode": "2137",
        "state": "NEW SOUTH WALES",
        "state_code": "NSW",
        "street": "SYDNEY ST"
      },
      "confidence": 10,
      "formatted": "18 SYDNEY ST, CONCORD NSW 2137, Australia",
      "geometry": {
        "lat": -33.8641922,
        "lng": 151.0979607
      }
    }
  ],
  "status": {
    "code": 200,
    "message": "OK"
  },
  "stay_informed": {
    "blog": "https://blog.opencagedata.com",
    "twitter": "https://twitter.com/OpenCage"
  },
  "thanks": "For using an OpenCage API",
  "timestamp": {
    "created_http": "Sat, 28 Nov 2020 20:27:48 GMT",
    "created_unix": 1606595268
  },
  "total_results": 8
}

I'd create a PR to resolve the issue myself but I'm extremely new to Rust. This geocode service I'm writing is my first ever project using the language. I tried making the following change but that didn't seem to do anything. I'm not sure I fully understand how type interfaces work in Rust just yet.

pub struct Results<T>
where
    T: Float,
{
    pub annotations: Option<Annotations<T>>,
    pub bounds: Option<Bounds<T>>,
-    pub components: HashMap<String, String>,
+    pub components: HashMap<String, T>,
    pub confidence: i8,
    pub formatted: String,
    pub geometry: HashMap<String, T>,
}

Thanks for the help!

In some cases/some providers, there exists no response from reverse gecoding. I ran into this issue while adding a new geocoding provider #26 The proposed solution to address this, is to return an Option. Alternatives would be an empty string or an empty Vec similar to forward geocoding.

Like in this case for example: https://api.opencagedata.com/geocode/v1/json?q=10.4645969,-64.1781702&no_annotations=0&no_record=1&key=<OPENCAGE_KEY_HERE>

Hey @groteworld, are you open to adding more owners to the crate on crates.io? If so, I think you can do cargo owner -a georust/core. No worries if you want to be the sole owner!

Also sorry I just pushed a few commits straight to master 🙈 I'll use PRs going forward

As mentioned in #11 there is a new low dependency crate for geo types.

There seemed to be an issue with serde.Deserialize trait and the new geo-types.Point. Review should be done to let me know what this could hurt in the future.

This PR adds:

• methods which receive full OpenCage responses for forward- and reverse geocoding
  • an optional bounding box which restricts the search space for forward-geocoding
• Debug is now available on all response structs
• tests and doctest examples for all the above
• more polishing of the docs generally

I haven't bumped the version, since we haven't cut a release yet anyway.

I recently found this crate and absolutely love it. Thanks for the amazing project and keep up the good work! :+1:

During usage I wonder why the provided functions aren't async as the data must be fetched from somewhere. After looking into the code base I found that we currently use blocking requests.

At first it seems like an easy implementation for me, since we just have to migrate the usage of the blocking reqwest client to a non blocking and transform some traits and functions to async. What maybe could be implemented with a optional feature flag. However, after trying to prototype this on my own fork (https://github.com/jontze/geocoding/tree/feat/async-fetching) I came to the conclusion that it is not that easy :laughing: . Since it looks like that there have to be done some refactor of at least the Point struct in the geo-types crate to support rust futures.

Furthermore, a feature flag is definitely not the cleanest solution to implement this since it will lead to some code duplication, I guess. On the other side transforming the whole crate to async will be a major breaking change for the user...

However, before continuing on that, are there any plans for the future to support async data fetching instead of blocking?

Add a simple method to add some proxy configuration.

I wonder if the code should not go further and offer the possibility to accept any Reqwest::Client instance.