The documentation for the google.maps.Size function says:
Size(width:number, height:number, widthUnit?:string, heightUnit?:string)
The default for the widthUnit and heightUnit arguments seems to be pixels. The function works properly if it is called as new google.maps.Size(30,30,"px","px")
I would like to know what other unit types are supported.
Andrew is correct. All the CSS length units that a particular browser supports are also supported by google.maps.Size. For many of its uses, this is because the string you get by concatenating the number and unit is used directly in styling by setting it as the value on CSS width, height, etc properties (in other cases, the Maps API calculates what those sizes would be in that context if it wants to (for instance) use absolute units or draw to a canvas).
If you want to use relative lengths, remember that they'll be interpreted relative to their place in the cascade. Depending on the object whose size you're setting, the end result might not be what you expect. Since the Maps API places your content in a variety of places in the DOM tree it creates, the size may be dependent on implementation details that aren't guaranteed to stay stable between versions of the API. Similarly, '%' often works as a unit (even though it technically isn't a CSS length type), but it may end up defining your size relative to a DOM element you have no control over. At the very least, test carefully!
Related
I'm working on a project where I need to generate an IFC file, and am given not much more information than geometry (I have access to the density and heat-conductivity of materials, and basic labeling for Objects).
So far I could only find what IFC can store, never what IFC needs to store.
What do I need to include in an IFC file so it is properly functional?
What does an IFC file need besides basic geometry?
Disclaimer: I have not read (or bought) the standard. My knowledge primarily stems from working with IFC files and trying different things. And reading the buildingSMART documentation. So I can't give you a hard guarantee, but I am rather confident my information is correct/usable.
As an alternative to buying the official standards file, you could look into the official documentation by buildingsmart. (Also have a look here for more general information and availability of other/more modern releases).
Now assuming you are familiar with the basic STEP file layout (header and data segment), let's jump to what an IFC file absolutely has to include to be considered correct (as far as I understand the documentation; there might be parsers/loaders which can load incorrect/incomplete files, but we aren't aiming for them). Also note I am building this example for IFC 4.0. This should be correct for the current IFC 4.1 standard, but probably not for the older IFC2X3 standard (there have been some relaxations in IFC4 from IFC2X3). Also I am skipping on names and descriptions - you can set those fields for testing to recognize your structures in a viewer (it's easier than comparing GUIDs).
IfcProject
The root of all elements is the IfcProject. It also contains most basic properties and definitions for all other elements. The attributes required per documentation on this entity are only the unique id. But for a working example you usually also need a minimal unit assignment and representation context.
#20= IFCPROJECT('344O7vICcwH8qAEnwJDjSU',$,$,$,$,$,$,(#19),#13);
In the unit assignment you define required units, starting from geometric units to monetary, thermal, etc. The minimum is length, area and angle to meaningfully define geometric items. So for our example we include only those: metre as length, square meter as area and radians as angle. If you need foot or inch or degree you can define those as derived units.
#10= IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#11= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#12= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#13= IFCUNITASSIGNMENT((#10,#11,#12));
The representation context defines for a given class of representations (=geometric/parametric descriptions) the basic coordinate system. So the simple case would be a 3-dimensional right handed system at point zero. IFC is working with the z-axis pointing up - this might be important if your are working with models/files originating from 3D/OpenGl applications which usually assume the y-axis pointing upwards. You also need a precision value - I am using 1.0e-5 here, but you might want to test out if you can go with less or need more. The precision is usually applied when comparing points/edges when combining geometry (during constructive solid geometry steps). If you have errors, try a different precision value.
The second attribute of the representation context is the context type. This is a string identifying on which representations this context should be applied. The documentation states that values are based on "implementers agreement" - which means AFAIK "look what the others are using". From my experience using "Model" works for 3D geometry. Using "Plan" for 2D plans and sketches should work, too.
#14= IFCDIRECTION((1.,0.,0.));
#15= IFCDIRECTION((0.,0.,1.));
#16= IFCCARTESIANPOINT((0.,0.,0.));
#17= IFCAXIS2PLACEMENT3D(#16,#15,#14);
#18= IFCDIRECTION((0.,1.));
#19= IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.0E-5,#17,#18);
Spatial container for elements
Elements can't be added to the IfcProject directly - they need to be placed into a spatial element which is contained in the project. There are three possible choices: IfcSite, IfcBuilding and IfcSpatialZone (see section Spatial Decomposition on the IfcProject page). The IfcSpatialZone is defined as non-hierarchical spatial element - its usage is slightly different from the other two (elements are added using a different relation).
A single site is sufficient as spatial container. Adding all elements to it might be sematically vague (mostly fences are directly added to it, other elements are usually inside a building) but not incorrect. (IFC does not care if you have electrical appliances in your garden). As nearly all attributes of IfcSite are optional we can skip on those. But beware: if you give your site a representation (=some geometric shape) you will need to include a placement for it. The site will be aggregated into the project to be related to it.
#30= IFCSITE('20FpTZCqJy2vhVJYtjuIce',$,$,$,$,$,$,$,.ELEMENT.,$,$,$,$,$);
#31= IFCRELAGGREGATES('0Du7$nzQXCktKlPUTLFSAT',$,$,$,#20,(#30));
Elements
Actually that is all that is needed as absolute minimum structure. Now you can add your elements - entities of some type derived from IfcProduct. As all those elements have some sort of meaning attached to it you either need to select those closely matching the objects you have, or you might want to use IfcBuildingElementProxy which is the most "meaningless" (or better: no specialized semantic meaning) object type. The following code places one proxy without geometry. The placement references the same coordinate system definition that is used to create the coordinate system out of convenience as it doesn't transform or move anything. Your geometry would be added through a product definition shape which has shape aspects and finally some geometry items. The building smart documentation has a few examples with assigned geometry.
#40= IFCLOCALPLACEMENT($,#17);
#41= IFCBUILDINGELEMENTPROXY('3W29Drc$H6CxK3FGIxjJNl',$,$,$,$,#40,$,$,.NOTDEFINED.);
#42= IFCRELCONTAINEDINSPATIALSTRUCTURE('04ldtj6cp2dME6CiP80Bzh',#12,$,$,(#41),#30);
Conclusion
So there isn't much needed as bare minimum to add elements:
a project
basic unit definitions
one spatial container
The complete example file would be:
ISO-10303-21;
HEADER;FILE_DESCRIPTION(('IFC4'),'2;1');
FILE_NAME('example.ifc','2018-08-8',(''),(''),'','','');
FILE_SCHEMA(('IFC4'));
ENDSEC;
DATA;
#10= IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#11= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#12= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#13= IFCUNITASSIGNMENT((#10,#11,#12));
#14= IFCDIRECTION((1.,0.,0.));
#15= IFCDIRECTION((0.,0.,1.));
#16= IFCCARTESIANPOINT((0.,0.,0.));
#17= IFCAXIS2PLACEMENT3D(#16,#15,#14);
#18= IFCDIRECTION((0.,1.));
#19= IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.0E-5,#17,#18);
#20= IFCPROJECT('344O7vICcwH8qAEnwJDjSU',$,$,$,$,$,$,(#19),#13);
#30= IFCSITE('20FpTZCqJy2vhVJYtjuIce',$,$,$,$,$,$,$,.ELEMENT.,$,$,$,$,$);
#31= IFCRELAGGREGATES('0Du7$nzQXCktKlPUTLFSAT',$,$,$,#20,(#30));
#40= IFCLOCALPLACEMENT($,#17);
#41= IFCBUILDINGELEMENTPROXY('3W29Drc$H6CxK3FGIxjJNl',$,$,$,$,#40,$,$,.NOTDEFINED.);
#42= IFCRELCONTAINEDINSPATIALSTRUCTURE('04ldtj6cp2dME6CiP80Bzh',$,$,$,(#41),#30);
ENDSEC;
END-ISO-10303-21;
Note that loading this one up doesn't show anything, because it doesn't contain any geometry. Also please note that I have not yet verified if it is error free - I currently don't have my IFC tools at hand (if you would like to verify your files have a look at stepcode which can check if your files are syntactically correct - it won't check semantic meaning or enforcement of the mentioned concepts in the building smart documentation.)
Also good to know is that the order of references/ids (like #20) can be freely arranged - you can reference elements that you add later in the file and the references only need to be unique to this one file. This means the lines of the example file can be shuffled and it is still a valid file - parsers usually use a two-step apporach to create an in-memory representation (1. parse into IFC classes, 2. resolve references).
I have initially work units with the size of 11*11*6779. For the sake of simplicity I dont want to translate it into 1D global work size. When when i changed it into 21*21*6779 the performance is 5-6x slower than before. the code as far as i know has nothing to do with the number of threads being ran.
The amount of data transfered is only 4x bigger, which I dont think is a reason why the programm runs slower, because i tested the memory allocation process.
Note that my device has a max work items of 256*256*256, meaning I would be use half of all available work items, and this is not a dedicated device (also used for display..).
I wonder if setting the work item sizes into 21*21*6779 uses too many of my work items, or the dimensions are simply inconvenient for openCL to adjust ?
If your max work items is 256x256x256 then why are you using 21x21x6779 (where 6779 is greater than 256)? Note that if the work group size is not specified, the runtime will try to pick one that can divide up your global work size. If your dimensions not easily divisible by the runtime, it might pick bad work group sizes. That could explain why the performance changes based on global work size. I recommend you specify the work group size, and make the global work size a multiple of that (if necessary, pass in the real size as parameters and in each work item check if it is in range; this is a typical pattern you will see a lot in OpenCL).
I'm look for a DICOM image reconstruction tag. Is there any tag to recognize a DICOM Image is result of a reconstruction?
First try searching for "MPR" (multiplanare Rekonstruktion) but just for Siemens?
(0008,0008);Image Type;DERIVED\PRIMARY\AXIAL\CT_SOM5 MPR
(0008,103e);Series Description;Abdomen nativ 3.0 MPR kor
Image Type (0008, 0008) is the field you are searching for. Unfortunately, you will run into three issues:
Not all vendors stick to the defined terms for this attribute, some treat them as free text. So does Siemens - "CT_SOM5 MPR" is not a defined term for this attribute.
it depends on the type of object (SOP Class UID) which defined terms apply and from which component of Image Type they can be obtained.
DERIVED\SECONDARY\MPR (MPR is value 3 for MR objects)
DERIVED\SECONDARY\ANGIO\RESAMPLED (RESAMPLED is value 4 for Enhanced IODs)
There are several reconstruction techniques, MPR is just one of them
There is an attribute Volume Based Calculation Technique (0008, 9207) from which this could be safely determined, but so far I have never seen it included in practical datasets. Plus, it is not allowed for all IODs
Long story short: Using Image Type and sticking to the rules and defined terms applying to this attribute would be DICOM conformant and correct, but fail in some practical cases. I do not see any other generic approach. To include more practical cases, you will need to implement vendor-specific heuristics.
Let's say I have circular objects. Each object has a diameter of 64 pixels.
The cells of my quad tree are let's say 96x96 pixels.
Everything will be fine and working well when I check collision from the cell a circle is residing in + all it's neighbor cells.
BUT what if I have one circle that has a diameter of 512 pixels? It would cover many cells and thus this would be a problem when checking only the neighbor cells. But I can't re-size my quad-tree-grid every time a much larger object is inserted into the tree...
Instead och putting objects into a single cell put them in all cells they collide with. That way you can just test each cell individually. Use pointers to the object so you dont create copies. Also you only need to do this with leavenodes, so no need to combine data contained in higher nodes with lower ones.
This an interesting problem. Maybe you can extend the node or the cell with a tree height information? If you have an object bigger then the smallest cell nest it with the tree height. That's what map's application like google or bing maps does.
Here a link to a similar solution: http://www.gamedev.net/topic/588426-2d-quadtree-collision---variety-in-size. I was confusing the screen with the quadtree. You can check collision with a simple recusion.
Oversearching
During the search, and starting with the largest objects first...
Test Object.Position.X against QuadTreeNode.Centre.X, and also
test Object.Position.Y against QuadTreeNode.Centre.Y;
... Then, by taking the Absolute value of the difference, treat the object as lying within a specific child node whenever the absolute value is NOT more than the radius of the object...
... that is, when some portion of the object intrudes into that quad : )
The same can be done with AABB (Axis Aligned Bounding Boxes)
The only real caveat here is that VERY large objects that cover most of the screen, will force a search of the entire tree. In these cases, a different approach may be called for.
Of course, this only takes care of the object that everything else is being tested against. To ensure that all the other large objects in the world are properly identified, you will need to alter your quadtree slightly...
Use Multiple Appearances
In this variation on the QuadTree we ONLY place objects in the leaf nodes of the QuadTree, as pointers. Larger objects may appear in multiple leaf nodes.
Since some objects have multiple appearances in the tree, we need a way to avoid them once they've already been tested against.
So...
A simple Boolean WasHit flag can avoid testing the same object multiple times in a hit-test pass... and a 'cleanup' can be run on all 'hit' objects so that they are ready for the next test.
Whilst this makes sense, it is wasteful if performing all-vs-all hit-tests
So... Getting a little cleverer, we can avoid having any cleanup at all by using a Pointer 'ptrLastObjectTestedAgainst' inside of each object in the scene. This avoids re-testing the same objects on this run (the pointer is set after the first encounter)
It does not require resetting when testing a new object against the scene (the new object has a different pointer value than the last one). This avoids the need to reset the pointer as you would with a simple Bool flag.
I've used the latter approach in scenes with vastly different object sizes and it worked well.
Elastic QuadTrees
I've also used an 'elastic' QuadTree. Basically, you set a limit on how many items can IDEALLY fit in each QuadTreeNode - But, unlike a standard QuadTree, you allow the code to override this limit in specific cases.
The overriding rule here is that an object may NOT be placed into a Node that cannot hold it ENTIRELY... with the top node catching any objects that are larger than the screen.
Thus, small objects will continue to 'fall through' to form a regular QuadTree but large objects will not always fall all the way through to the leaf node - but will instead expand the node that last fitted them.
Think of the non-leaf nodes as 'sieving' the objects as they fall down the tree
This turns out to be a very efficient choice for many scenarios : )
Conclusion
Remember that these standard algorithms are useful general tools, but they are not a substitute for thinking about your specific problem. Do not fall into the trap of using a specific algorithm or library 'just because it is well known' ... your application is unique, and it may benefit from a slightly different approach.
Therefore, don't just learn to apply algorithms ... learn from those algorithms, and apply the principles themselves in novel and fitting ways. These are NOT the only tools, nor are they necessarily the best fit for your application.
Hope some of those ideas helped.
From using a number of programming languages and libraries I have noticed various terms used for the total number of elements in a collection.
The most common seem to be length, count, and size.
eg.
array.length
vector.size()
collection.count
Is there any preferred term to be used?
Does it depend on what type of collection it is? ie. mutable/immutable
Is there a preference for it being a property instead of a method?
Length() tends to refer to contiguous elements - a string has a length for example.
Count() tends to refer to the number of elements in a looser collection.
Size() tends to refer to the size of the collection, often this can be different from the length in cases like vectors (or strings), there may be 10 characters in a string, but storage is reserved for 20. It also may refer to number of elements - check source/documentation.
Capacity() - used to specifically refer to allocated space in collection and not number of valid elements in it. If type has both "capacity" and "size" defined then "size" usually refers to number of actual elements.
I think the main point is down to human language and idioms, the size of a string doesn't seem very obvious, whilst the length of a set is equally confusing even though they might be used to refer to the same thing (number of elements) in a collection of data.
FWIW (and that's vanishingly close to nothing), I prefer 'Count' because it seems to indicate that it's going to return the number of elements/items in the collection pretty unambigously.
When faced with the terms 'Length' or 'Size' I'm often left wondering for a moment (or even being forced to re-read documentation) whether the damn thing is going to tell me how many elements are in the colection or how many bytes the collection is consuming. This is particularly true for collections that are intended to be contingous like arrays or strings.
But no one who was responsible for the naming conventions used by the Java, BCL/.Net, or C/C++ standard frameworks/libraries bothered to ask me, so you're all stuck with whatever they came up with.
If only I were much smarter than I am and was named Bjarne, all of you might be spared the misery...
Of course, back in the real world, you should try to stick with whatever naming convention is used by the language/platform you're using (eg., size() in C++). Not that this seems to help you with your Array.Length dilemma.
The terms are somewhat interchangeably, though in some situations I would prefer one over another. Usually you can get the best usage if you think about How would you describe the length/size/count of this element verbally to another person?
length() implies that the element has a length. A string has a length. You say "a string is 20 characters long", right? So it has a length.
size() implies that the element has a size. E.g. a file has a size. You say "this file has a size of 2 MB", right? So it has a size.
That said, a string can also have a size, but I'd expect something else here. E.g. a UTF-16 string may have a length of 100 characters, but as every character is composed out of two byte, I'd expect size to be 200.
count() is very unusual. Objective-C uses count for the number of elements in an array. One might argue if an array has a length (as in Java), has a size (as in most other languages) or has a count. However, size might again be the size in byte (if the array items are 32 bit int, each item is 4 byte) and length... I wouldn't say "an array is 20 elements long", that sounds rather odd to me. I'd say "an array has 20 elements". I'm not sure if count expresses that very well, but I think count is here a short form for elementCount() and that again makes much more sense for an array than length() or size().
If you create own objects/elements in a programming language, it's best to use whatever other similar elements use, since programmers are used to accessing the desired property using that term.
Count I think is the most obvious term to use if you're looking for the number of items in a collection. That should even be obvious to new programmers who haven't become particularly attached to a given language yet.
And it should be a property as that's what it is: a description (aka property) of the collection. A method would imply that it has to do something to the collection to get the number of items and that just seems unintuitive.
Hmm...I would not use size. Because this might be confused with size in bytes.
Length - could make some sense for arrays, as long as they are supposed to use consequent bytes of memory.
Though...length...in what?
Count is clear. How many elements. I would use count.
About property/method, I would use property to mark it's fast, and method to mark it's slow.
And, the most important - I would stick to the standards of the languages/libraries you are using.
Adding to #gbjbaanb's answer...
If "property" implies public access to the value, I would say that "method" is preferred simply to provide encapsulation and to hide the implementation.
You might change you mind about how to count elements or how you maintain that count. If it is a property, you're stuck - if it is acessed via a method, you can change the underlying implementation without impacting users of the collection.
Kotlin answer
from _Collections.kt
/**
* Returns the number of elements in this collection.
*/
#kotlin.internal.InlineOnly
public inline fun <T> Collection<T>.count(): Int {
return size
}
In Elixir there is actually a clear naming scheme associated with it across types in the language.
When “counting” the number of elements in a data structure, Elixir
also abides by a simple rule: the function is named size if the
operation is in constant time (i.e. the value is pre-calculated) or
length if the operation is linear (i.e. calculating the length gets
slower as the input grows).
To me, this is a little like asking whether "foreach" is better than "for each". It just depends on the language/framework.
I would say that it depends on particular language that you are using and classes. For example in c# if you are using Array you have Property Length, if you have something that inherits from IEnumerable you have extension Method Count(), but it is not fast. And if you inherited from ICollection you have Property Count.