I imagine this is a simple problem for anyone really familiar with Cesium's CZML files. I'm just trying to display a series of lat/long/alt points as a flight path using Cesium. Can someone tell me what the "position" tag should look like?
Unless I'm looking in the wrong places, I don't see a lot of examples for CZML. So it's hard to know what tags can be used and how to use them (and the Java console doesn't show the errors if you get them wrong).
In the Sandcastle CZML example on the Cesium website, the relevant section looks like this:
"position" : {
"interpolationAlgorithm" : "LAGRANGE",
"interpolationDegree" : 1,
"epoch" : "2012-08-04T16:00:00Z",
// Trimmed to just 2 points
"cartesian" : [0.0, -2379754.6637012, -4665332.88013588, 3628133.68924173,
3894.996219574019, -2291336.52323822, -4682359.21232197, 3662718.52171165]
}
If it's two points, why are there 8 values? If it was ECEF coordinates, I would expect only three per point...
For example, when I tried this, I got an "uncaught error" message in the console... which isn't very helpful:
"cartographic" : [-1.472853549, 0.589580778, 1000,
-1.472962668, 0.589739552, 1000 ]
According to the documentation, cartographic takes (long, lat, height) where long and lat are in radians and height is in meters.
The first coordinate is in each set of 4 is time, so it's actually (t, x, y, z). In the example you posted, t is the number of seconds after the specified epoch that the waypoint exists.
You can also use cartographicRadians or cartographicDegrees, but they would still be specified as (t, lon, lat, alt).
If you want to draw a route that is not time-dynamic (i.e. just a static line) you can use the polyline CZML object instead; which has a list of x/y/z positions without time.
Matthews answer is correct, took a littke bit of tweaking to get it working so for others looking at this here is an example showing cartographicDegrees in use.
"position": {
"interpolationAlgorithm": "LAGRANGE",
"interpolationDegree": 1,
"epoch": "2012-08-04T16:00:00Z",
"cartographicDegrees": [
//time, lat, long, alt
0,-116.52,35.02,80,
300,-116.52,35.04,4000,
600,-116.52,35.08,9000,
900,-116.52,35.02,3000,
1100,-116.52,35.02,1000,
1400,-116.52,35.02,100
]
}
Related
I am using the viewer with the Edit2D library and am trying to convert the length between two x and y points into real measurements.
For example, after a shape is drawn using the polygon tool, I want to get the length of the first edge.
I get the drawn shape and the first two points on the event shown below, get 2 points, and get the distance between them. It seems they are in Autodesk Units or something. Is there an easy way to convert the units to feet or inches?
I have found
Edit2DExtension.defaultContext.unitHandler.fromDisplayUnits()
as well as
Edit2DExtension.defaultContext.unitHandler.toDisplayUnits()
and also
Autodesk.Viewing.Private.convertUnits().
I've tried all three, but am unsure how to use them and haven't found any good results with them yet.
There may be a way to do it through Edit2d but I haven't found a way yet and there is next to no documentation I can find on this library.
beforeEdit2DAction(event) {
console.log('After Shape has been drawn -> ', event);
let shape = event.action.shape;
let pointA = shape._loops[0][0]; // Value: {x: 21.393766403198242, y: 20.934386880096092}
let pointB = shape._loops[0][1]; // Value: {x: 25.082155227661133, y: 20.934386880096092}
// Distance between 2 points (Assuming Autodesk units)
let length = Autodesk.Edit2D.Math2D.distance2D(pointA, pointB); // 3.6883888244628906
// Need to convert to real world units (preferably ft or inches)
}
The real length is 29.5 FEET
Any ideas, or comments are welcome! Thanks
Edit: Trying Petr's suggestion here's what it returned:
That's an interested question. The "unit handler" keeps track of two types of units:
layer units (Edit2DExtension.defaultContext.unitHandler.config.layerUnits, can be inch for example)
display units (Edit2DExtension.defaultContext.unitHandler.config.displayUnits)
These two properties control how the actual lengths and areas are displayed. For example, the unit handler's toDisplayUnits method is implemented like so:
toDisplayUnits(fromUnits, value) {
this.updateConfig();
return Autodesk.Viewing.Private.convertUnits(fromUnits, this.config.displayUnits, this.config.scaleFactor, value);
}
With that, configuring fromUnits and displayUnits (and scale) properly should give you the real measurements you need.
I want to compare two smoothing methods for a bigram model:
Add-one smoothing
Interpolated Absolute Discounting
For the first method, I found some codes.
def calculate_bigram_probabilty(self, previous_word, word):
bigram_word_probability_numerator = self.bigram_frequencies.get((previous_word, word), 0)
bigram_word_probability_denominator = self.unigram_frequencies.get(previous_word, 0)
if self.smoothing:
bigram_word_probability_numerator += 1
bigram_word_probability_denominator += self.unique__bigram_words
return 0.0 if bigram_word_probability_numerator == 0 or bigram_word_probability_denominator == 0 else float(
bigram_word_probability_numerator) / float(bigram_word_probability_denominator)
However, I found nothing for the second method except for some references for 'KneserNeyProbDist'. However, this is for trigrams!
How can I change my code above to calculate it? The parameters of this method must be estimated from a development-set.
In this answer I just clear up a few things that I just found about your problem, but I can't provide a coded solution.
with KneserNeyProbDist you seem to refer to a python implementation of that problem: https://kite.com/python/docs/nltk.probability.KneserNeyProbDist
There exists an article about Kneser–Ney smoothing on wikipedia: https://en.wikipedia.org/wiki/Kneser%E2%80%93Ney_smoothing
The article above links this tutorial: https://nlp.stanford.edu/~wcmac/papers/20050421-smoothing-tutorial.pdf but this has a small fault on the most important page 29, the clear text is this:
Modified Kneser-Ney
Chen and Goodman introduced modified Kneser-Ney:
Interpolation is used instead of backoff. Uses a separate discount for one- and two-counts instead of a single discount for all counts. Estimates discounts on held-out data instead of using a formula
based on training counts.
Experiments show all three modifications improve performance.
Modified Kneser-Ney consistently had best performance.
Regrettable the modified Version is not explained in that document.
The original documentation by Chen & Goodman luckily is available, the Modified Kneser–Ney smoothing is explained on page 370 of this document: http://u.cs.biu.ac.il/~yogo/courses/mt2013/papers/chen-goodman-99.pdf.
I copy the most important text and formula here as screenshot:
So the Modified Kneser–Ney smoothing now is known and seems being the best solution, just translating the description beside formula in running code is still one step to do.
It might be helpful that below the shown text (above in screenshot) in the original linked document is still some explanation that might help to understand the raw description.
I have two entities on my page; a satellite and its "ground position", both of which move as time passes in Cesium. I'd like to connect the two with a straight line that moves with them.
The CZML Showcase seems to demonstrate similar functionality if you're using a CZML file, but I would like to know how to do this in code. Their demo contains several lines between satellites and ground positions, and in fact they go one step further and only show the line if it doesn't intersect the earth (if line-of-sight exists between the two entities). I don't need anything quite that fancy.
Are there any good examples of this, or docs that someone could point me to? Thanks!
Figured it out: #emackey started me on the right track by pointing me at this section of simple.czml. The part I had trouble translating from CZML to javascript was this section that dynamically specifies where the line should begin and end:
"positions":{
"references":[
"Facility/AGI#position","Satellite/ISS#position"
]
}
It turns out the classes I needed for that were PositionPropertyArray and ReferenceProperty. With those two I can add a dynamic line to either of my entities like this:
var groundTrackEntity = cesiumViewer.entities.add({
id: "groundTrackEntity",
position: groundTrackPosition,
point: /* ... */,
path: /* ... */,
polyline: {
followSurface: false,
positions: new Cesium.PositionPropertyArray([
new Cesium.ReferenceProperty(
cesiumViewer.entities,
'orbitEntity',
[ 'position' ]
),
new Cesium.ReferenceProperty(
cesiumViewer.entities,
'groundTrackEntity',
[ 'position' ]
)
]),
material: new Cesium.ColorMaterialProperty(
Cesium.Color.YELLOW.withAlpha( 0.25 )
)
}
});
This is done by adding PolylineGraphics to one of your entities. Make sure to set "followSurface": false for this, since you don't want the line to bend with the curvature of the Earth. The options here are similar to what you see in simple.czml, except you don't need the list of visibility intervals, and can simply set "show": true here.
I am trying to define a rotated pole projection in Proj4JS where the north pole is now is 48N and 176E. I haven't been able to find any other example of rotated-poles in Proj4JS so I have tried to convert one I found for PROJ.4.
proj4.defs('myProjection', '+proj=ob_tran +o_proj=latlon +o_lon_p=-176 +o_lat_p=48 +lon_0=0 +a=1 +to_meter=0.0174532925199');
That line of JS is run without problem, but when I try to use that projection
proj4('EPSG:4326', 'myProjection', [175, -41]);
I get this error
uncaught exception: myProjection
I've tried replacing the projection definition the one for WGS84 and it works fine, so I believe my use of the function is correct, it's the parameters in that string that I am unsure of.
I think what you want is the so-called Azimuthal Equidistant projection. It's the best choice for measuring true distances radiating away from a center point.
If this is what you're looking for, I asked a similar question a while back over on GIS.SE, and for the coordinate you provided (48N, 176E), you could declare the Proj4js projection definition as so..
Proj4js.defs["CUSTOM:10001"] = "+proj=aeqd +lat_0=48.0 +lon_0=176.0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs";
I hope it helps.
Following up on a previous question... I've got my minimal horizon chart example much more minimaler than before ( minimal cubism.js horizon chart example (TypeError: callback is not a function) )
<body>
<div class="mag"></div>
<script type="text/javascript">
var myContext = cubism.context();
var myMetr = myContext.metric(function(start, stop, step, callback) {
d3.json("../json/600s.json.php?t0=" + start/1000 + "&t1=" + stop/1000 + "&ss=" + step/1000, function(er, dt) {
if (!dt) return callback(new Error("unable to load data, or has NaNs"));
callback(null, dt.val);
});
});
var myHoriz = myContext.horizon()
.metric(myMetr);
d3.select(".mag")
.call(myHoriz);
</script>
</body>
The d3.json() bit calls a server side .php that I've written that returns a .json version of my measurements. The .php takes the start, stop, step (which cubism's context.metric() uses) as the t0, t1, and ss items in its http query string and sends back a .json file. The divides by 1000 are because I made my .php expect parameters in s, not ms. And the dt.val is because the actual array of my measurements is in the "val" member of the json output, e.g.
{
"other":"unused members...",
"n":5,
"val":[
22292.078125,
22292.03515625,
22292.005859375,
22292.02734375,
22292.021484375
]
}
The problem is, now that I've got it pared down to (I think) the bare minimum, AND I actually understand all of it instead of just pasting from other examples and hoping for the best (in which scenario, most things I try to change just break things instead of improving them), I need to start adding parameters and functions back to make it visually more useful.
Two problems first of all are, this measurement hovers all day around 22,300, and only varies +/- 10 maybe all day, so the graph is just a solid green rectangle, AND the label just says constantly "22k".
I've fixed the label with .format(d3.format(".3f")) (versus the default .2s which uses SI metric prefixes, thus the "22k" above).
What I can't figure out is how to use either axis, scale, extent, or what, so that this only shows a range of numbers that are relevant to the viewer. I don't actually care about the positive-green and negative-blue and darkening colours aspects of the horizon chart. I just used it as proof-of-concept to get the constantly-shifting window of measurements from my .json data source, but the part I really need to keep is the serverDelay, step, size, and such features of cubism.js that intelligently grab the initial window of data, and incrementally grab more via the .json requests.
So how do I keep the cubism bits I need, but usefully change my all-22300s graph to show the important +/- 10 units?
update re Scott Cameron's suggestion of horizon.extent([22315, 22320])... yes I had tried that and it had zero effect. Other things I've changed so far from "minimal" above...
var myHoriz = myContext.horizon()
.metric(myMetr)
.format(d3.format(".2f"))
.height(100)
.title("base1 (m): ")
.colors(["#08519c", "#006d2c"])
// .extent([22315, 22320]) // no effect with or without this line
;
I was able to improve the graph by using metric.subtract inserting it above the myHoriz line like so: (but it made the numerical label useless now):
var myMetr2 = myMetr.subtract(22315);
var myHoriz = myContext.horizon()
.metric(myMetr2)
.format...(continue as above)
All the examples seem so concise and expressive and work fine verbatim but so many of the tweaks I try to make to them seem to backfire, I'm not sure why that is. And similarly when I refer to the API wiki... maybe 4 out of 5 things I use from the API work immediately, but then I always seem to hit one that seems to have no effect, or breaks the chart completely. I'm not sure I've wrapped my head around how so many of the parameters being passed around are actually functions, for one thing.
Next hurdles after this scale/extent question, will be getting the horizontal time axis back (after having chopped it out to make things more minimal and easier to understand), and switching this from an area-looking graph to more of a line graph.
Anyway, all direction and suggestion appreciated.
Here's the one with the better vertical scale, but now the numerical label isn't what I want:
Have you tried horizon.extent? It lets you specify the [min, max] value for the horizon chart. By default, a linear scale will be created to map values within the extent to the pixels within the chart's height (specified with `horizon.height or default to 30 pixels).