Query server flexibility

[NoahSchiro]

Change the osm_query function such that users can provide their own endpoint.

[NoahSchiro]

Perhaps in support of this, we should abstract the query into a structure which can carry meta data / information like this. This will also allow us to set some defaults.

[NoahSchiro]

Features I would like on this:

Create a QueryEngine struct which contains information like the base URL we want to query.

Methods on the QueryEngine:

• [x] new() to create a default instance
• [x] with_url() to set the URL (returns a new instance of the struct)
• [x] with_filters() allows the user to set filters on the ways (so we only get highways, or bike paths or whatever they might be interested in. We have to look more into what types of ways there are). We can filter ways with the following modification to the query string: way(area.searchArea)[highway="type_of_way_we_want"];
• [x] query() allows the user to pass a raw string. Currently this functionality is taken up by osm_request() so this will just be a rename and a shift to be a method on this struct
• [x] query() needs a blocking version as well
• [x] query_place() allows a user to just pass in the place they are interested in
• [x] query_polygon() allows a user to pass in a polygon

A few notes about how we are currently querying:

• admin_level controls how restrictive the query is. In general: admin_level=2: Usually represents countries admin_level=4: Often represents states, provinces, or regions admin_level=6: May represent counties or districts admin_level=8: Often represents municipalities, cities, or towns admin_level=10: May represent neighborhoods or suburbs