Does someone have a handy example of a CZML file that uses sample properties to track a pedestrian walking a terrain.
I need a billboard at the head of the trail for the person, who will have some custome properties I want to see in the infoblock (about 18K samples).
And my assumption is that a separate id for a path that grows as trace of the path (with the head being the billboard). And this would be in a separate packet, shown as a polyline with material.
and Both would have a epoch for the start and then sample properties for each time step
I.e. the epoch would be today at noon, and the sample properties would be 1 second intervals for each position of the pedestrian which would be duplicated for both the polyline and the billboard.
But is there a better way, and I assume someone has done a sandcastle with an example, right?
I found an example that shows how one can do this more effectively than what I thought (that is you can do this just by adding the data to the coordinates of the billboard as Sampled Data).
https://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=CZML%20Path.html&label=
Related
I was wondering if it were possible to extract coordinates from a static map picture like this:
Is it possible to extract the coordinates of the routes? The only idea I can come up with, other than manually getting them by hand, is by overlaying the map and extracting the exact coordinates that way.
The process that you are looking for is called georeferencing in a GIS context.
In order to determine the latitude/longitude coordinates of a point (or series of points in a line), you need to first establish coordinates of other known points. These are reference points of known locations (such as a distinctive coastline, or a city). Applying these to the raster image that you have, you can then overlay it on a map in a GIS application and then query other unknown locations on the image (such as the routes) to establish their latitude/longitude.
You could attempt this in a graphics program by looking at the x/y coordinates of the route pixels and compare to a known reference point pixel; however, the math on that is going to be tedious and you also wouldn't account for the map projection. Both of those are taken care of by georeferencing.
I would note that you should consider the results you get, even in a well-referenced GIS, to be approximate. The map deals with a very large spatial area, and the routes cover long distances. But since it dates from 2012 it was presumably made in a GIS application and so at least the source data is likely to be accurate :)
Additional resources:
Help Page for ArcGIS (both overview and instructions)
Help Page for QGIS (tutorial)
I am working on a Wysiwyg Editor for CesiumJS content.
The user will be able to create many points, lines and other graphics, connect them according to definable relations and group them in separate Groups.
Now I am wondering what the best practises are in terms of performance.
At the moment I create one PointPrimitiveCollection for each Group
and then add points:
group.points = scene.primitives.add(new Cesium.PointPrimitiveCollection());
and then
group.points.add({
position : cartesian,
...
});
for each new point.
Polygons are created using:
network.hull_polygon = viewer.entities.add({
name : 'xxx',
polygon : {
hierarchy : Cesium.Cartesian3.fromDegreesArray(points_array),
material : color,
...
}
});
polylines similarly.
Now since the Objects can also be dragged around / animated, I was wondering where Cesiums entity logic would come in?
Thanks for all help!
Cesium's Entity logic is useful primarily for objects that move along a known path over time, for example the flight plan of an aircraft in the future, or a GPS recording of the route taken by a vehicle in the past. Such routes can be loaded into the Entity system (often via CZML), and the user can run the simulation time forwards and backwards at arbitrary speeds, to review the routes of all the vehicles. The Entity system owns the logic for updating graphics primitive positions based on simulation time changes.
Entities are also often used as a quick way to make some disparate graphics primitives associate with each other. For example, a polygon, a point, and a label can all be created as a single Entity even if they are three separate graphics primitives at the same location. This saves a bit of effort on the part of the application developer, and doesn't hurt performance too much since the properties involved are all marked as constants, so the Entity layer knows not to update them with simulation time.
But, it sounds like you may have a case where paths are not known in advance. For things like user interactive edits or real-time telemetry being received, the Entity system can't know what's coming up next, so its whole system for updating positions from simulation times is not doing you any good. In that case it may be better to skip the Entities, and deal exclusively with graphics primitives for this. This would mean you need to write your own update function to alter graphics positions as new information is being received, similar to the Entity layer's update functions, but based on your own live inputs instead of recorded paths.
Note that the public "Sandcastle" demos only include Entity demos. But, if you download and build the source for Cesium and run Sandcastle locally from a dev build, a separate tab appears in the Sandcastle Gallery called Development that shows a whole set of demos based on graphics primitives as opposed to Entities. This can be useful for seeing examples of how to control things at this layer.
Hopefully this is helpful in understanding how the different layers of Cesium interact.
As you can see in the reference picture below, we have placed two Pivot Doors onto a AEC Wall Object. We have modified the door opening to 60*deg and 0*deg from the Parameters dropdown.
Our question is, would it be possible to target this parameter after the MAX file has been translated to SVF to visually close/open the door (by changing the Open parameter)?
Adding to Petr's answer, 3ds Max does not output even the properties, so the "open/close percent" is not available. The translator takes the current state of the geometry and outputs that. Another thought might be to duplicate the doors you want to control in desired state, and then hide the states you don't want, and show only the state you want.
About making the transform separately, it might work, but I think the challenge will be to discover the geometry as the entire assembly is treated as single element in 3ds Max scene.
Hope it helps.
Is there any chance you could share the MAX file with us? If you can't/don't want to share it publicly, feel free to send it to our email: forge (dot) help (at) autodesk (dot) com. That way we can do a bit more research on what could be done.
Without having a specific example file in hand, here's my two cents:
the SVF file format itself doesn't support any "parametric behavior" (like the "Open" parameter in your example)
if both the door and the door frame are converted into an atomic element in SVF, it would be very difficult to extract and modify the geometry
if the door and the door frame are converted separately, you might be able to emulate the desired behavior by manually changing the element's transform
I've been playing with Mapbox's blog post about converting heat maps to contour lines, and I'm stuck at the extraction part of this process.
I used the CSV plugin to create a vector layer of points, then a heat map raster layer based on that, but I can't seem to be able to see the contour lines based on that raster layer after that. When I looked at the properties and selected categorized, it didn't seem to have any symbols listed.
I'm guessing this is probably some kind of type error since I had to create the raster layer based off of map units and not meters, but I don't know how to correct it. What am I missing?
Okey dokey. After the holiday weekend I figured it out.
It was basically a type error with the CRS. Although it's not explicitly stated, I got in touch with MapBox and found out they were working in Google Mercator. It's also a perfectly acceptable CRS to use when you eventually have to import the .shp file into MapBox/Tile Mill.
I am trying to take a shapefile of subdivisions within a county that I have created and line it up with another shapefile that was given to me by the County Appraisal District (parcel data). When I try to get them to line up then my streets shapefiles is not aligned with everything else. They are all on the same coordinate system and I do not want to have to recreate the shapefile for the subdivisions. Any thoughts?
This is a question with answers that may be simple or may be very complex, depending on your situation. As a GIS developer, I've most commonly seen this as a symptom of an incorrectly defined coordinate system. However, whether this is the case or not, and what the solution is strongly depends on your environment. From here on, I'll assume that you're working in an ESRI package...
I agree with the other posters that your problem is one of mismatching projections and/or datum definitions.
The most important thing to understand as regards projections in ESRI software is this:
Manually setting the projection of a dataset (shapefile, geodatabase feature class, etc) in ArcCatalog does NOT reproject that dataset!!!
In order to reproject your data, you must EXPORT the data from an ArcMap session in which you've been working and where the data is obviously lined up correctly. During the EXPORT, you are given the choice of saving your data with the coordinate system of the underlying map or that of the original dataset.
Your best bet is to follow these steps to create a new dataset with the correct projection and then extrapolate what you need to do to fix your specific problem:
Create a new ArcMap session and set its coordinate system:
Do this in a fresh ArcMap session with NO OTHER DATA. Be sure to explicitly set the coordinate system of the ArcMap mapview to your desired coordinate system (I recommend the one that matches the data you're trying to overlay, or one from another well-established dataset).
Add one other dataset with a known good coordinate system.
Create your new dataset in this ArcMap session. Give your new data the same coordinate system as the ArcMap mapview and the one other dataset in the map. Set the XY domain of the new data to exceed the area defined by your other dataset, but don't go beyond the size that will reduce your desired spatial resolution.
Create your data. It can be any data at this point. Some lines, some polygons, etc. Save your work.
Export your new dataset. When prompted, choose to save with the coordinate system of the underlying mapview.
Create a new ArcMap session and add your new dataset. Then add your parcel dataset. They should now occupy the same space in your map window.
Edit your new data to your heart's content.
Some probable issues if this doesn't help:
You didn't follow these steps correctly - check the ESRI documentation; this is a well documented issue.
The parcel data you're trying to match doesn't have properly defined coordinate system. It's always possible that the keepers of this data don't know what they're doing and have munged it up. I've seen this problem more times that I care to admit.
You've matched the projection but have mis-matched the datum. Many municipalities are still using data in NAD27, which is way out of date. Some have moved to the modern NAD83. The difference can be up to 300 meters, depending on where in the country you are. Also, data that originates from surveying or GPS equipment is usually collected in WGS84 (the typical default for satellite surveying), which is for all practical purposes the same as NAD83, at least at mapping scale resolutions.
Try researching these issues and see how it goes. I'll say it again:
Manually setting the projection does NOT actually project that data!!
Good luck!
Your problem is probably one of projection
| projection: character string that names a map projection to use. See
| 'mapproject' (in the 'mapproj' library). The default is to
| use a rectangular projection with the aspect ratio chosen so
| that longitude and latitude scales are equivalent at the
| center of the picture.
`-----
Agree that your problem is projection. Is there a .prj file extension associated with either of your files? If not key first is finding out what projects you have. I would guess State Plane of some sort if you are dealing with U.S. centric local data from a local government.
Cadastral tools (surveyer tools) usually let you specify a handful of control points and will then "warp" the data to fit to your control points. This can be anything from a simple shift to something more complex. If everything is shifted by a few feet, you can also just use your "editor" to select all shapefiles and then move them however many feet necessary.
If you've verified that both shapefiles are using the same coordinate system, then projection is less likely to be the problem. It's fairly common for parcel data to be "offset" from other data sources (such as roads). This comes from inconsistent collection methods and points of reference.
Another source of error can be that one of the shapefiles has the wrong coordinate system specified. For example, if the roads were actually WGS 1984, but it's prj is set to NAD1983, you will see some significant errors. This usually happens if you had to manually set the coodinate system for a shapefile (i.e. it didn't include a PRJ and you created one).