I have an OLAP multidimensional cube and I changed the UnknownMember property to None for some of my dimensions where I'm confident the fact tables will always have a value for it since I have an unknown key built into the dimension table. When I went to process it threw this error for each dimension:
DimensionAttribute [Center].[Center Key]: The 'KeyColumns' #0 has NullProcessing set to 'UnknownMember', but the dimension doesn't have UnknownMember set to 'Visible' or 'Hidden'.
I can't find this NullProcessing property anywhere, hoping someone can point me in the right direction as how to get rid of this error.
Found it nested under the KeyColumns property of the dimension attribute. So I went to the dimension, clicked on Center Key (under either the Dimension Structure or Attribute Relationships tab) and then expanded KeyColumns, expanded again, and found NullProcessing. I changed it from UnknownMember to Error since I'm okay with it erroring if it doesn't find one.
Related
When I attempt to train a CreateML model, I get the following screen after inputting my training data:
Create ML error message
I am then unable to add my test data or train the model. Any ideas on what is going on here?
[EDIT] As mentioned in my comment below, this issue went away when I removed some of my training data. Any newcomers who are running into this issue are encouraged to try some of the solutions below and comment on whether it worked for them. I'm happy to accept an answer if it seems like it's working for people.
This happens when the first picture in the dataset has no label. If you place a labeled photo as the first in the dataset and in the coreML json, you shouldn't get that issue.
Correct:
[{"annotations":[{"label":"Enemy","coordinates":{"y":156,"x":302,"width":26,"height":55}}],"imagefilename":"Enemy1.png"},{"annotations":[{"label":"Enemy","coordinates":{"y":213,"x":300,"width":69,"height":171}}],"imagefilename":"Enemy7.png"},{"annotations":
Incorrect:
[{"annotations":[],"imagefilename":"Enemy_v40.png"},{"annotations":[],"imagefilename":"Enemy_v41.png"},{"annotations":[],"imagefilename":"Enemy_v42.png"},{"annotations":
At the minimum you should check for these 2 situations, which triggered the same generic error for me (data analysis stopped), in the context of an Object Detection Model:
One or more of the image names referenced in annotations.json is incorrect (e.g. typo in image name)
The first entry in annotations.json has an empty annotations array (i.e. an image that does not contain any of the objects to be detected)
If you are using any random Split or something similar, make sure, its parsing the data correctly. you can test this easily by debugging.
I suggest you check to see if your training data is consistent and all entries have all needed values. The error is likely in the section of data you removed.
That would cause the error Nate commented he is seeing when he gets that pop up.
Getting the log would be the next step in any other evaluation.
I've got a flat object that I want to split in multiple pieces (background: I want to print it later, but the surface of my printer is not large enough). I've modeled a simple puzzle-shape:
I would like to use this shape to cut through my object, but if I use the boolean modifier, blender generates vertexes where the shape and the object intersects, but it won't cut the object since my shape got a thickness of 0:
I don't want to make my shape thicker, because otherwise it would delete something of my object...
You are able to separate the two sides of the object from each other, and then rejoin them afterwards if you need to. (This does include the use of the boolean modifier)
First, you should add the boolean modifier to the main mesh where you want it, with the 'difference' operation. Then in edit mode, as you explained before, the vertexes are created but there isn't the actual 'cut' that you were looking for.
I recreated the scenario with a plane intersecting a cube:
This is what it looks like in edit mode after having applied the boolean modifier:
Second what you can do is (after applying the boolean modifier) select the faces you want to be separated in edit mode. Then, pressing P (shortcut for separate, you can get to it by right clicking) click on 'selection' and you should have two separate objects. One of the objects will have what looks like a missing face: If you wanted two separate objects, then you just need to add a face on the object with the missing face and you can look no further. If you wanted separate parts of objects that are separate within edit mode (all together one object in object mode) then you can select the two objects and press crtl+j. Hope this helps somehwhat!
I have selected half of the cube that I want cut out (the selection does not include the face in the middle):
There are now two objects, completely seperated from each other:
The Face API gives coordinates of the lips but can we specifically get the color of the lips?
There's one property that you might find useful: faceAttributes.makeup.lipMakeup. But, it's just a boolean. You get it by adding makeup to the returnFaceAttributes parameters.
For example, if I declare types as such:
:types
bag
light heavy - bag
That is to say there are two types of bags, light and heavy. Would it be possible within an action to check if a variable of type bag is of type light without having an instance of light to compare to?
I know it's possible to have an equality comparison as such:
(when ( = ?light ?bag))
but this checks if two variables have the same value, rather than the same type.
I tried (when ( = light ?bag)) and even though the planner doesn't throw up errors it doesn't seem to work.
In response to Prof. Chaos' comment where they state this is not possible, I've derived a workaround where we create the predicate (is_light ?x - light) and use (when (is_light ?lightobj) (dosomething)) in the action. The predicate is utilised in the problem file when initialising light objects.
What is the difference (if any) between setting indexNodeName=true on the node type definition and defining a virtual nodeName property with the attribute name=:nodeName. indexNodeName is defined as follows:
Default to false. If set to true then index would also be created for
node name. This would enable faster evaluation of queries involving
constraints on Node name
Index the nodename as property aims the be similar to indexNodeName, but this doesn't imply "the same as". The docs are not saying that much about this:
The string :nodeName - this special case indexes node name as if it’s
a virtual property of the node being indexed. Setting this along with
nodeScopeIndex=true is akin to setting indexNodeName=true on indexing
rule.
So is it required to set both or only one of the settings in order to query the nodename. If just one of them, which one and what is the difference?
Examples:
//element(*, app:Asset)[fn:name() = ‘kite’]
//*[jcr:like(fn:name(), ‘kite%’)]
//element(kite, app:Asset)
//element(*, dam:Asset)[(jcr:like(fn:lower-case(fn:name()), 'kite%')
indexNodeName=true is a shortcut to having a property definition with name=:nodeName AND nodeScopeIndex=true.
The name=:nodeName allows for more flexibility (at the cost of a bit of complexity) to index node names for other usages too - suggestions, spellchecks, etc.
So, if you just want to query for node names using either of the methods should work well (although, imo, indexNodeName=true is simpler and cleaner).
Otoh, if you also want for node names to show up as suggestion/spellcheck results, then you'd have to resort to have a property definition with name=:nodeName AND nodeScopeIndex=true AND useInSuggest=true.