👋 Hi @groteworld - you're the sole user-owner of the geocoding crate on crates.io.

Following up on georust/meta#21, I created a new geocoding-publishers team for publishing to crates.io with you as it's sole member and maintainer.

Could you please update the crates.io owners? Specifically:

• update geocoding crate owners on crates.io:

cd geocoding

# 💥 remove large publishing group
cargo owner --remove github:georust:core
# 🔐 add small publishing group
cargo owner --add github:georust:geocoding-publishers

# 🚨 you're currently the only user-owner of geocoding.  Consider adding @urschrei or @frewsxcv as a user-owner, 
# that way if for some reason you become inaccessible we have someone else who can edit the owners. 
# See https://github.com/rust-lang/crates.io/issues/2906
cargo owner --add urschrei
cargo owner --add frewsxcv

# make sure everything looks good 👀 
cargo owner --list

And if there's anyone else you'd like to be able to publish the crates, feel free to add them to your publishing team, or as a user-owner. Consider that user-owners, as opposed to owners-via-team, can themselves edit the crate's owners, which could be desirable, or not, depending.

In particular @urschrei and @frewsxcv have been pretty active in this crate. Consider adding them to geocoding-publishers if not as explicit user-owners, otherwise they will lose publishing access... though I suppose as GH organization owners, they could technically add themselves to the GH team once you've added it to the cargo owners.

Let me know if you have any questions, or you can review georust/meta#21.

Build is stalled: #48 (comment)

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.

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:

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!

Perhaps with thiserror?

Openstreetmaps supports road names, but AddressDetails doesn't have that attribute.

Fixing this should be a simple one-liner, like in #45.

Some geocoding tests and examples fail due to provider side response changes.

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).

I'm trying to get a forward search going with version 0.0.3, similar to the test code in
https://github.com/georust/geocoding/blob/master/src/opencage.rs#L648

use geocoding::{Opencage, Forward};

fn main() {
    let oc = Opencage::new("dcdbf0d783374909b3debee728c7cc10".to_string());
    let address = "Schwabing, München";
    let res = oc.forward(&address);
    println!("{:?}", res.unwrap());
}

Compiling via cargo build returns

   Compiling test-rust-geocode v0.1.0 (/private/tmp/test-rust-geocode)
error[E0283]: type annotations required: cannot resolve `_: num_traits::float::Float`
  --> src/main.rs:35:18
   |
35 |     let res = oc.forward(&address);
   |                  ^^^^^^^

Reverse search works and I can't see an obvious difference in how forward and reverse are implemented. I tried importing the num_trait module. Is there anything I'm missing in my code?

Rust/Cargo version 1.33.0

thanks a lot

It would be great to be able to query in a structured way. Nominatin osm gives this option.

georust/geo#201

It's not uncommon to use the location's native language when geocoding (especially for forward geocoding).
Could we consider adding this as a default ? or would it be better to make it an optional parameter ?

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 rust-geocoding developers
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @grotewold

I typically use the google v3 api and osm. what other ones should be addressed first?

Web Services to support:

• Google v3 API
• OpenStreetMap
• OpenCage

EDIT: ADD OPENCAGE AND IMMEDIATELY CLOSE IT THANKS TO @urschrei ;)

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

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 😆 . 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?

I am just making some simple tests with rust and I some mildly interesting casting handling where creating new Point actually takes what ever values is given even Point is shorter. Conversion back to f64 just prints something garbage. Not very safe I think.

use geocoding::{Point};
struct Mining {
    id: u64,
    location: Point<f32>
}
fn main() {
    let mine = Mining{ id: 1, location: Point::new(2.128703454232323, 41.40139) };
    println!("Hello, world! {lat}", lat= mine.location.x() as f64); # Hello, world! 2.1287033557891846
}

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