I'm working on a project with hourly data for some buildings of different areas.
I have asked this question is the Cesium forum, but got no answer.
Check link Here.
The idea is that I need to represent these data sets in CZML.
The data has different values for each hour of the year of each building.
these values are energy kilowatt values.
To explain it further:
Each building, has an energy value, that changes every hour.
Different buildings will have different values for the same hour!
So an example:
for A building I have the following:
"hour_1" : 0.0, "hour_2" : 0.0, "hour_3" : 0.0, "hour_4" : 0.0, "hour_5" : 0.0, "hour_6" : 0.0, "hour_7" : 0.0, "hour_8" : 0.0, "hour_9" : 1.0, "hour_10" : 29.1265, "hour_11" : 55.0334, "hour_12" : 68.0527
I need the "color" to change for each building, at each hour depending on the value it has in the attribute table.
Is it possible to be represented in CZML data?
or what other alternatives can be used with Cesium?
Thank you in advance.
-Ayah
Related
I don't know if my question will be clear but here's my question.
i have here a print of a list as you can see below.
as you can see, those in the red border is a duplicate. while I plan that the yellow borders be combined in a single list since they have a duplicate header (red border).
Result list should look something like this (combined):
[2022-177916, Installing Cut-Out, WEXEC, 2022-03-22 00:37:26.000Z, CP, LEXT, , , 212618, [2034132, CUT-OUTS, HT FUSE, 100A, 36KV, 170KV BIL, 1.0, 0.0, 1.0, -88.0, , UNIT, false, false, 0.0, 0.0, 0.0, 2035103, FUSELINK, 3K, 1.0, 0.0, 1.0, -10.0, , PC, false, false, 0.0, 0.0, 0.0]]
Here, yellow bordered data are now in a single list. then the duplicate (red border) was combined.
Hope someone could guide me in the right direction. im stuck :(
Edit:
More info on the codes below.
List<ChildrenCreateMRO> mroTempChildrenCreateSend = []; //this is the list i declared
I made a listview.builder wherein each item has a checkbox. if the user taps the checkbox, then I add some data to the list by using mroTempChildrenCreateSend.add()
so the list grows but i have several duplicates.
the sample output above was from two checked checkboxes.
Use the spread operator.
For example: final newList = [...list1, ...list2, ...list3];
list1 is the name of one of the lists, and so on. the ... is the spread operator, dropping all of the contents into the new list.
Please update your question with the code so I can better answer the question.
To an array I want to update some elements and keep array's size no great than N. How to do it in an single operation?
Lets' make an example to make my question clear:
1)db.test.insertOne({a:[1, 100, 3, 5, 600]});
{
"_id" : ObjectId("5fc5a14e1b800790b21afa65"),
"a" : [
1.0,
100.0,
3.0,
5.0,
600.0
]
}
2) change it to
{
"_id" : ObjectId("5fc5a14e1b800790b21afa65"),
"a" : [
1.0,
100.0,
5.0
]
}
As shown above, a[2]->5, and N=3, only keeps a[0],a[1],a[2]. I have to make these happen in one single operation to make data consistent(don't consider multiple clients)
How could I do ? Thanks!
In your case, I'd recommend to follow this logic:
If the array in the memory has not been changed - do nothing.
If your array was changed and it's small then just update the whole array.
If your array was changed only a little bit and it's pretty big then calculate in your app what exactly elements were changed and create an update with corresponding operations for everyone (remove, update, insert). Be careful, it's an error-prone approach.
If your app runs into case number 3 "often", it means you designed a wrong data structure to solve your problem.
My goal is to have products that have some basic information like
Name
Description
Brand/Manufacturer
Dimensions & Weight
And optionally each product can have options based on
Size
Color
Material
I've read a few articles but couldn't find a suitable answer for my problem, which is how to reflect that all those possible combinations of options can have different SKUs, prices and amounts in stock.
And additionally I'd like to have different images for different colors of a product.
So my current thought is to have separate collections for all the options:
Size
Color
Material
Then have arrays of pointers for all those options within the product document and and additional array of variations which reflects every possible combination of options and adds a SKU, price and stock field.
{
_id: "12345",
name: "My Product",
...
colors: [
{
_id: "Color_1",
images: [
"http://myserver.com/images/product_12345_1",
"http://myserver.com/images/product_12345_2",
]
},
{
_id: "Color_3",
images: [
"http://myserver.com/images/product_12345_3",
"http://myserver.com/images/product_12345_4",
]
}
],
sizes: [
{
_id: "Size_5"
},
{
_id: "Size_9"
}
],
materials: [
{
_id: "Material_2"
}
],
variations: [
{
color: "Color_1",
size: "Size_5",
material: "Material_2",
SKU: "98765"
price: 10,
stock: 2
},
{
color: "Color_1",
size: "Size_9",
material: "Material_2",
SKU: "87654"
price: 11,
stock: 5
},
...
],
}
But somehow I feel that there might be an easier way to accomplish what I'm looking for.
Data modelling of Product information is more an art than a science.
It is very common to define Products as the entities sales thinks about. Let's say a car model or a cable. E.g. a "cat 5e Ethernet cable".
Such a product has attributes and dimensions. Attributes might be
standard / norm (e.g. EIA/TIA-586)
Manufacturer (Kabelwerk Eupen)
Number of Wires (8)
Packaging (Plastic Bag)
Tags (Network, Ethernet, Cabling, Infrastructure)
RHoS (Compliant)
etc.
Attributes tend to vary between industries and even between different product categories in the same company.
Dimensions distinguish between different variants of a Product. One or more Dimensions can define a concrete Product. Typical Dimensions are size and colour. For cables, we might have:
size / length (0.5, 1, 2, 5, 10 meters)
colour (green, red, blue)
flame retardant (yes, no)
So Products are the concept of one of your merchandise. In a paper catalogue a Product usually is described as a single thing (maybe on a single page). E.g. a jacket available in blue and brown in sizes S, M, L and XL.
What defines a single Product is somewhat fuzzy. The blue and green sneaker might be the same Product, but the orange and the golden might not be seen as the same product.
Before E-Commerce, we tended to expect the same price for all Dimensions of a Product - not long ago, people were scandalized if a size 8 shoe would be more expensive than a size 9 shoe.
Along some dimensions - colour mostly - users usually except pictures. Along other dimensions - e.g. shoe size - usually there is no expectation of specific pictures.
With some products the manufacturer might be considered an Dimension (cables), for others it might be considered irrelevant (cable ties) and for others two identical looking goods from different manufacturers might be considered completely different Products (e.g. sneakers).
The other concept are SKUs - the stock keeping units are the stuff which is actually in the warehouse. Usually per Product we have Dimensions multiplied with each other SKUs. So 5 sizes x 3 colours x 2 fire retardant variants - so there could be 30 SKUs. Usually each SKU has a distinct GTIN/UPC/EAN ("Barcode" 4423456789012).
Keeping SKUs and Products separate is best practice because they are related to different concerns: Products are of importance for marketing and sales. SKUs concern auditing, bookkeeping and logistics. Products represent concepts, SKUs represent physical goods. Amount of stock usually should be kept in or near the SKU - because on large commerce applications it might get updated several times per second. I would never design a system where transaction data - amount of stock - is mixed up with master data - product description, etc.
Pricing information has been historically attached to the product because product and price data is somewhat static but dynamic pricing might change that.
You seem to be asking for a Product Database. Schemaless Databases work nicely for this because it is very hard to anticipate all needed dimensions for the next few years. Normalizing the whole thing for a Relational Database can certainly be done, but tents to result in less than elegant, and slowish code.
{
name: "Cat 5e Cable",
…
dimensions: {
color: {
title: "Color",
red: {
title: "Red",
images: [
"http://myserver.com/images/product_12345_3",
"http://myserver.com/images/product_12345_4",
],
},
green: { … }
},
size: {
title: "Size"
s05: {
title: "0.5 m",
images: [],
},
s1: {...},
fireretardant:
title: "Size"
yes: {
title: "fire retardant",
images: [],
},
no: {
title: "not fire retardant",
images: [],
}
}
// here you need a stable way of generating keys from dimension data
variations: [
{
dimensions: {color: red, size: s1, fireretardant: no}
SKU: "98765"
price: 10,
},
{
dimensions: {color: red, size: s1, fireretardant: yes}
SKU: "98765"
price: 10,
},
},
…
]
I have implemented applications with such a schema. Usually you want to limit available dimensions and valid values per dimension in the Admin GUI so staff does not come up with obscure new dimensions all the time. But this should be an administrative restriction, not one of the underlying schema.
Non-existent combinations ("fire retardant is only available in green and not in 0.5 m), conflicting instructions ("make all 5 m cables 10 € and all red ones 8 €"), differing and inconsistent ideas what e.g. needs a image, what images should be shared between Dimensions, inconsistent definitions, what considered a separate product ("USB C) or just a Variant ("3.5 mm or 5.5 mm headphone jack"), translation and conversion (don't get me started with shoe sizes) makes real life database design and maintenance interesting …
this is what the so-called "domain knowledge" is about. You need to involve a shoe salesman to design a good shoe database.
I have an Android plugin in Unity which will do some native rendering using OpenGL ES.
I have simplified the code to this, and it successfully reproduces the problem:
GLES20.glBindFramebuffer(GLES20.GL_FRAMEBUFFER, fboId);
//Draw texture to framebuffer
GLES20.glViewport(0, 0, width, height);
GLES20.glUseProgram(program);
GLES20.glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
GLES20.glClear( GLES20.GL_DEPTH_BUFFER_BIT | GLES20.GL_COLOR_BUFFER_BIT);
GLES20.glUniformMatrix4fv(u_MVPMatrix, 1, false, matrix, 0);
GLES20.glEnableVertexAttribArray(a_Position);
GLES20.glVertexAttribPointer(a_Position, 3, GLES20.GL_FLOAT, false, 0, verticesBuffer);
GLES20.glEnableVertexAttribArray(a_texCoord);
GLES20.glVertexAttribPointer(a_texCoord, 2, GLES20.GL_FLOAT, false, 0, uvBuffer);
GLES20.glDrawElements(GLES20.GL_TRIANGLES, indices.length, GLES20.GL_UNSIGNED_SHORT, indicesBuffer);
GLES20.glFinish();
GLES20.glFlush();
GLES20.glBindFramebuffer(GLES20.GL_FRAMEBUFFER, 0);
It is working fine when I am forcing Unity to use only OpenGL ES20, but if using OpenGL ES30, I get unexpected results and the input array given here:
GLES20.glVertexAttribPointer(a_Position, 3, GLES20.GL_FLOAT, false, 0, verticesBuffer);
Is ignored and the given quad is drawn in a different shape. No matter what I change the input coordinates to, I still get the same odd shape.
I am not an OpenGL coder, so I cannot find the issue. Am I missing to set some states here?
As suggested by Reto Koradi in the comments, client side vertex arrays are deprecated in ES 3.0. And when switching to VBOs it works. Not sure why, but assume it is related to some unknown OpenGL state left after Unity.
Is there a way to find out what polygons (specifically circles) a specific Point lies in?
In this case I would have stored a documents containing circles, like below, I would pass in a latitude and longitude for a point, and would like to get back all documents where the point is within the given circle.
{
"_id" : ObjectId("53e3e85ce4b0c2e8227a1dad"),
"name" : "Menlo College",
"location" : [-122.1928, 37.45632],
"radius" : NumberLong(215),
},
{
"_id" : ObjectId("53e43d19e4b0aeabcb3d3f9d"),
"name" : "West Valley College",
"location" : [-122.01021194458008, 37.263226547586207],
"radius" : NumberLong(604),
}
If this is not possible, then is it at least possible with other GeoJSON shapes? Everything I've found so far indicates that the inverse is possible (find all points which like inside a circle), but nothing for this scenario.
Thanks
It is possible using MongoDB's $geoIntersects Geospatial query operator.
So, if you have a collection of GeoJson polygons and you want to find out all the polygons that intersect with your given point, then you need to run the following:
db.places.find( { <locationFieldOfYourDocuments> :
{ $geoIntersects :
{ $geometry :
{ type : "Point" ,
coordinates: [long, lat]
} } } } )
In the command above, loc is that attribute of each document that contains the coordinates for GeoJson polygon. Also, make sure that you have 2dsphere index over <locationFieldOfYourDocuments>.
Now, to get your original problem solved I will use a little bit of javascript. There may be better solutions but not in my knowledge.
Let's say all your circles are stored in Circles collection. I would query that collection and fetch each circle one by one and then perform an intersect with another collection that would contain a single point which would be the one you wanted to query if it intersects with the circles or not. So let the point be stored in SinglePoint collection.
The script would look like...
db.Intersections.remove({}); // emptying the output collection
var circleCursor = db.Circles.find();
while (circleCursor.hasNext()) {
var circle = circleCursor.next();
var coord = circle.location;
var radiusInRadians = circle.radius * conversionFactorForRadius;
var intersect = db.SinglePoint.find({loc :
{ $geoWithin :
{$centerSphere : [coord], radiusInRadians}
}});
if (intersect.hasNext()) {db.Intersections.add(circle)} // this will add all intersecting circles to Intersections collection
}
All you have to do is save this script in a file (myScript.js) and make a call:
mongo DBName pathTomyScript.js
This will store all the circles that intersect with your input point in the Intersects collection. All the above collections should be in DBName database.