I am trying to identify the cause of this openweathermap api error. I could not find any references in the documentation.
This request is a SUCCESS:
https://api.openweathermap.org/data/2.5/box/city?bbox=-96.8466%2C37.0905747%2C-92.5829684%2C41.7686%2C9&appid=<apikey>
While this request FAILS
https://api.openweathermap.org/data/2.5/box/city?bbox=-96.5829684%2C26.5383355%2C-79.37923649999999%2C41.0905747%2C9&appid=<apikey>
response
{"cod":"400","message":"Requested area is larger than allowed for your account type (25.00 square degrees)"}
I know it has something to do with the bbox range, but I can't find any documentation. I am currently testing with the free subscription.
It basically means that you are fetching an area larger than what the free subscription area allows. A 25°² area means a region between 4 lat/lng position that is covering 25 degrees, for example :
An area ranging from 75 to 70 degrees North, and 0 to 5 degrees East (5x5° = 25°)
75°N,0°E ---- 75°N,5°E
70°N,0°E ---- 75°N,5°E
Related
Recently I've been occasionally receiving odd results from the Google Reverse Geocode API.
For example when looking up the address for coordinates 43.2379396 -72.44746565 the result I get is:
6HQ3+52 Springfield, VT, USA
In another case looking up 43.703563 -72.209753 results with:
PQ3R+C3 Hanover, NH, USA
Does anyone know what the initial 7 bytes of the returned address symbolize? When I receive this type of result it's always 4 bytes of alphanumeric data followed by a plus sign then 2 more alphanumeric bytes.
After some additional research I found that these are Plus Code addresses, a relatively new feature in Google Maps. These are used for places that don't have a street address. These seem to have some similarities to "what 3 words" addresses.
Summary - Our products are very configurable and have many valid options such as model, color, height, activationtype, etc...
This is not difficult to model. I have used an EAV model but what is tripping me up is the dependency metadata. Based on the product model some colors may not be available. So the application DEV only wants the colors for that model. 1 dependency is easy enough. However, oftentimes an attribute is only valid based on a combination of previously selected values.
If model = 123 and color = Blue and ShipToCountry = USA then height can be 54 to 154 inches
If model = 123 and color = BLue and ShipToCountry = Canada then height can be 54 to 175 inches
If model = 123 and color = Black and ShipToCountry = Canada then height can only be 96 inches
I have seen up to 5 dependencies used to dictate what the next attribute's valid list of value is.
Question - What would a schema look like to hold the dependency metadata. I have tried a cross ref table that links possible value combinations based on dependencies. It works but the SQL result set is messy. Hoping for a suggestion that pushes me in the right direction.
How we currently store data
Visual of Application to Choose Product Options
This previous post is close but I am not sure it solves my issue.
I am following this tutorial:
https://python-graph-gallery.com/292-choropleth-map-with-folium/
I have zcta-level geojson for all of the state of New York from here:
https://github.com/OpenDataDE/State-zip-code-GeoJSON/raw/master/ny_new_york_zip_codes_geo.min.json
I am seeking to make a choropleth restricted to some values in Harlem:
harlem = ["10026", "10027", "10030", "10037", "10039", "10029", "10035"]
df2 = df[df.zcta.isin(harlem)]
df2['C_pct'] = df2.C/df2.C.sum()
df2.head()
C zcta C_pct
89 40 10026 0.4
90 40 10027 0.4
91 20 10030 0.2
However, when I do this, it seems to default to coloring all zip codes not in my dataset as if they were 100%, rather than as if they were 0%.
I can see from related questions, I am correctly keying my "key_on" field, which in the data comes from the zcta given in: "features.properties.ZCTA5CE10"
My call is the following:
ny_geo = 'ny_new_york_zip_codes_geo.min.json'
m.choropleth(
geo_data=ny_geo,
name='choropleth',
data=df2,
columns=['zcta', 'C_pct'],
key_on='feature.properties.ZCTA5CE10', # this matches the geojson
fill_color='YlGn',
reset=True,
legend_name='Configurations on 20170203'
)
And yet non-Harlem zips have color, even though there is no data for them.
How can I fix this? Eg, why are Brooklyn and Queens green instead of empty?
(I understand there to be updated syntax to geojson that eschews the choropleth function, but also wasn't able to express this in terms of the pure geojson() function--the error I had there was a key error on "id" which I was never calling, so I assume I misused a default keyword somewhere.)
The project I am working on involves static offline GTFS data in a mobile app. All the GTFS data is available inside realm-objects (or SQLite if needed).
Now, I would like to establish all train- or bus-connections from A to B (starting after a certain departure-time).
How do I query the GTFS-data in order to get a connection from A to B ???
I reealized to get all trips leaving from A.
I realized to get all station-names along that trip including times.
But I find it very hard to get the connection information between two locations A and B. What SQL queries do i have to set up in order to get that information ?
Any help appreciated !
If you just want to dynamically calculate shortest travel routes between static hubs, in an offline application, determined like the following image, you can use the following formula:
(Source)
Here's the pseudo code:
1 function Dijkstra(Graph, source):
2
3 create vertex set Q
4
5 for each vertex v in Graph: // Initialization
6 dist[v] ← INFINITY // Unknown distance from source to v
7 prev[v] ← UNDEFINED // Previous node in optimal path from source
8 add v to Q // All nodes initially in Q (unvisited nodes)
9
10 dist[source] ← 0 // Distance from source to source
11
12 while Q is not empty:
13 u ← vertex in Q with min dist[u] // Node with the least distance
14 // will be selected first
15 remove u from Q
16
17 for each neighbor v of u: // where v is still in Q.
18 alt ← dist[u] + length(u, v)
19 if alt < dist[v]: // A shorter path to v has been found
20 dist[v] ← alt
21 prev[v] ← u
22
23 return dist[], prev[]
(Source)
Alright, I'll admit so far my answer was a tad facetious...
I suspect you don't realize just how complicated it is to do what you're asking, especially in an offline environment. Companies like Google and Microsoft have spent millions on research with huge teams of data scientists.
If this is something you are serious about, I'd encourage you to start with a 10×10 grid and work on the logic of getting from "Point A → Point B" when you start adding barriers in random places (this simulating roads beginning & ending). Recently I was surprised how complicated a seemingly-simple, somewhat-related Stack Overflow "pipe sizes conversion" question that I answered had become.
If you didn't have the "offline" condition, I would've suggested looking into getting a [free] API Key for Google Web Services Directions API. Basically you tell it a where Points A & B are, and it gives you detailed route information, via transit or other methods.
Another of Google's many API's that could be helpful is the Snap to Roads API, which turns partial or error-ridden paths into driveable ones.
The study Route Logic and Shortest Path Logic is actually really fascinating stuff, and there are some amazing resources to learn about the related theories (see below), including a video from Google explaining how they went about it.
...but unfortunately this isn't something that's going to be accomplished with a simple SQL Query.
Actual Resources:
YouTube : Google Tech Talk: Fast Route Planning
Wikipedia : Shortest path problem
Wikipedia : Dijkstra's algorithm
...and some slightly Lighter Reading:
Wikipedia : Travelling Salesman Problem
Why UPS drivers don’t turn left and you probably shouldn’t either
Google Web Services : Directions API Developer's Guide
Stack Overflow : Shortest Route of converters between two different pipe sizes?
Wikipedia : Seven Bridges of Königsberg
I need to get the available options for a certain question in Watson conversation api?
For example I have a conversation app and in some cases Y need to give the users a list to select an option from it.
So I am searching for a way to get the available reply options for a certain question.
I can't answer to the NPM part, but you can get a list of the top 10 possible answers by setting alternate_intents to true. For example.
{
"context":{
"conversation_id":"cbbea7b5-6971-4437-99e0-a82927607079",
"system":{
"dialog_stack":["root"
],
"dialog_turn_counter":1,
"dialog_request_counter":1
}
},
"alternate_intents":true,
"input":{
"text":"Is it hot outside?"
}
}
This will return at most the top ten answers. If there is a limited number of intents it will only show them.
Part of your JSON response will have something like this:
"intents":[{
"intent":"temperature",
"confidence":0.9822100598134365
},
{
"intent":"conditions",
"confidence":0.017789940186563623
}
This won't get you the output text though from the node. So you will need to have your answer store elsewhere to cross reference.
Also be aware that just because it is in the list, doesn't mean it's a valid answer to give the end user. The confidence level needs to be taken into account.
The confidence level also does not work like a normal confidence. You need to determine your upper and lower bounds. I detail this briefly here.
Unlike earlier versions of WEA, the confidence is relative to the
number of intents you have. So the quickest way to find the lowest
confidence is to send a really ambiguous word.
These are the results I get for determining temperature or conditions.
treehouse = conditions / 0.5940327076534431
goldfish = conditions / 0.5940327076534431
music = conditions / 0.5940327076534431
See a pattern?🙂 So the low confidence level I will set at 0.6. Next
is to determine the higher confidence range. You can do this by mixing
intents within the same question text. It may take a few goes to get a
reasonable result.
These are results from trying this (C = Conditions, T = Temperature).
hot rain = T/0.7710267712183176, C/0.22897322878168241
windy desert = C/0.8597747113239446, T/0.14022528867605547
ice wind = C/0.5940327076534431, T/0.405967292346557
I purposely left out high confidence ones. In this I am going to go
with 0.8 as the high confidence level.