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.
Related
I set up a PostGIS database that I added in GeoServer via a parameterized SQL view. I use Leaflet to display this layer via WMS.
I would like to limit the number of features I see in the bounding box (5 maximum in my case). I tried to add a LIMIT 5 at the end of my SQL view but it affects the number of features on the whole map not in the bouding box.
Here is a simplified example to illustrate the issue. The aim is to get the 5 most populated cities located in the bounding box. It would work if Geoserver made this query :
SELECT geometry FROM table_cities
WHERE geometry && ST_GeomFromText(
'POLYGON ((-5.185 41.954, -5.185 51.374, 23.378 51.374, 23.378 41.954, -5.185 41.954))',
4326)
ORDER BY population LIMIT 5
But instead it wraps the SQL view inside a new SELECT dedicated to keep only the features located in the bounding box:
SELECT geometry FROM
(SELECT geometry FROM table_cities ORDER BY population LIMIT 5)
WHERE geometry && ST_GeomFromText(
'POLYGON ((-5.185 41.954, -5.185 51.374, 23.378 51.374, 23.378 41.954, -5.185 41.954))',
4326)
Is there a way to force Geoserver to put the bouding box verification before the LIMIT 5 selection?
Or maybe there is a different method to achieve what I want ?
You can add the Geoserver Where Clause placeholder :where_clause:
Because an and is automatically/systematically added, you must already have a where clause, even if it is a dummy 1=1 clause that always evaluate to true.
SELECT geometry
FROM table_cities
WHERE 1 = 1 :where_clause:
ORDER BY population
LIMIT 5
Note the absence of and between the 1=1 and :where_clause:
I am working on a project using the Sentinel 1 GRD product in Google Earth Engine and I have found a couple examples of missing data, apparently in swath overlaps in the descending orbit. This is not the issue discussed here and explained on the GEE developers forum. It is a much larger gap and does not appear to be the product of the terrain correction as explained for that other issue.
This gap seems to persist regardless of year changes in the date range or polarization. The gap is resolved by changing the orbit filter param from 'DESCENDING' to 'ASCENDING', presumably because of the different swaths or by increasing the date range. I get that increasing the date range increases revisits and thus coverage but is this then just a byproduct of the orbital geometry? ie it takes more than the standard temporal repeat to image that area? I am just trying to understand where this data gap is coming from.
Code example:
var geometry = ee.Geometry.Polygon(
[[[-123.79472413785096, 46.20720039434629],
[-123.79472413785096, 42.40398120362418],
[-117.19194093472596, 42.40398120362418],
[-117.19194093472596, 46.20720039434629]]], null, false)
var filtered = ee.ImageCollection('COPERNICUS/S1_GRD').filterDate('2019-01-01','2019-04-30')
.filterBounds(geometry)
.filter(ee.Filter.eq('orbitProperties_pass', 'DESCENDING'))
.filter(ee.Filter.listContains('transmitterReceiverPolarisation', 'VH'))
.filter(ee.Filter.listContains('transmitterReceiverPolarisation', 'VV'))
.filter(ee.Filter.eq('instrumentMode', 'IW'))
.select(["VV","VH"])
print(filtered)
var filtered_mean = filtered.mean()
print(filtered_mean)
Map.addLayer(filtered_mean.select('VH'),{min:-25,max:1},'filtered')
You can view an example here: https://code.earthengine.google.com/26556660c352fb25b98ac80667298959
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
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.)
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.