I'm using the ESRI JavaScript API v3.8. (I know 3.11 is out - can't upgrade yet.)
What I'm trying to do is to create a geometric buffer of a size provided by the user from an arbitrary line (or point) selected by the user. Some of the relevant code is shown below:
var params = new esri.tasks.BufferParameters();
params.distances = [values.distance]; //the input distance
params.geometries = [gr.geometry]; //the input geometry
params.unit = esri.tasks.GeometryService.UNIT_FOOT;
params.outSpatialReference = mapView.map.spatialReference; //always 3857
params.bufferSpatialReference = gr.geometry.spatialReference; //always 3857
esri.config.defaults.io.corsEnabledServers.push('mydomain.com');
esri.config.defaults.io.proxyUrl = 'https://serverdomain.com/proxy';
var gsvc = new esri.tasks.GeometryService('https://tasks.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer');
gsvc.simplify(params.geometries, function(geometries){
params.geometries = geometries;
gsvc.buffer(params, function(geometries){
//add output geometry to the map and perform spatial query with it
}, function(err){
//handle error
});
}, function(err){
//handle error
});
The problem is that, if I use an input distance of 500 (feet), then measure the distance from the center line of the input geometry on self._queryGeometry, using ESRI's measurement tool, the actual width of the polygon created is something like 370 feet on either side of the center line.
I've managed to get this to work more accurately using the Illinois State Plane spatial reference, as my test objects are in Illinois, but the logic needs to work everywhere.
When I try various incarnations of doing a geodesic buffer, the input distance unit seems to get ignored and, using an input distance value of 500, I get a buffer that spans the entire world! Either that or the results are exactly the same, depending on how things are set up.
I believe I need to do a geodesic buffer, but I have absolutely no idea how to go about that in such a way that the geometry service will actually pay attention to the units I'm sending in.
Any ideas would be greatly appreciated. Let me know if I've left anything out.
Sounds like there might be a spatial reference issue somewhere. You can try re-projecting geometry into 3857 if that's what the map is and I would inspect the geometry being returned from the buffer and simplify to make sure it looks like what your expecting. I have had issues with the geometry service area's and length's returning slightly incorrect geometries and in my case it ended up being an issue with an incorrect spatial reference. Also, I know you said you can't upgrade, but 3.13 is out and can do geometry options locally without the need for a proxy or any network requests, if possible, it would be worth trying out.
Related
This has had me beat for a while now. I'm making a game, and the main map is a model using the obj format. I load it like this:
var objLoader = new THREE.OBJLoader();
objLoader.setPath('Assets/');
objLoader.load('prison.obj', function(prison){
prison.rotation.x = Math.PI / 2;
prison.position.z += 0.1;
prison.scale.set(15, 15, 15)
scene.add(prison);
});
So when I was loading the same model, but smaller, it worked normally. But, now I have added more to the model, and it is much bigger. WebGL starts giving me this warning: [.WebGL-0x7fb8de02fe00]GL ERROR :GL_INVALID_OPERATION : glDrawArrays: attempt to access out of range vertices in attribute 1. This warning happens 256 times before WebGL says WebGL: too many errors, no more errors will be reported to the console for this context.
And with this warning, my model doesn't load completely. In Preview, I see the model as this, as expected:
But in Three.js, I see something different:
Well, I'm not exactly sure what's wrong here:
Maybe because I'm using OBJLoader CDN
Maybe my model size is too large
Maybe I have no idea what I'm doing
Any help is appreciated, thanks. Let me know if you need more detail.
This error is telling you that your geometry attributes count don't match up. For example, your geometry could have:
100 vertex positions
99 vertex normals
99 vertex UVs
... or something of that nature. When looking up info on that 100th vertex, it says "attempt to access out-of-range vertices"
Ideally, you'd want to re-export the OBJ asset so you don't have to manually find the geometry that's causing the problem. However, in case you cannot get a new OBJ, you could either:
prevent the problem geometry from rendering with mesh.visibility = false
Fix the geometry attribute count. To fix it, you'll have to find which attribute is short:
// We assume you already found the mesh with the problem.
const problemGeometry = mesh.geometry;
// Now we dig through the console to see each attribute.
// Look up each attribute.count property to see which one is short.
console.log(problemGeometry.attributes);
// Then you'll have to set the draw range to the lowest of these counts
// Here I assume the lowest is 99
problemGeometry.setDrawRange(0, 99);
Don't forget to also look at the geometry.index attribute, if your geometry has it. That should fix your geometry to render with the lowest common number of attributes. See here for info on setDrawRange
I'm having a problem
I would like to ask what the most efficient way is to check if latitude and longitude coordinates are inside a range (for example 100 meters) from a list of latitudes and longitude points.
For example I have this list of coordinates:
[[48.34483,51.16.24517],[48.484,16.2585],[48.361,51.87739419],[6.38477205,51.87745015],[48.3645,51.16.73167],[6.38391099,51.87755068],[48.3575,16.725],[6.38380232,51.87720004],[6.38376297,51.87708017],[6.38375183,51.87704018],[6.38373055,51.8769829]]
I would like somehow that all points that are in a specific range (100m for example),
to be somehow grouped.
Is there any way how I can indicate that for example from the above list:
[48.484,16.2585],[48.361,51.87739419] and [48.3575,16.725]
are in a radius of 100m ( distance between these points is less then 100m) and they should be groped
Sounds like a great question for a GIS professional; you could perhaps post on gis.stackexchange.com. Are you using a mapping technology where you already have access to an API? The functionality that you're looking for are referred to as geometric operations. I'd start by looking into geometry functions available in an API which calculate the distance between points. You could find the geometric center of all of the points, then request the geometry API to create a buffer around that point. Next, query if each point falls within that buffer.
Found a post which might help with finding the center of the points here:
How do I find the center of a number of geographic points?
Also found a post on stackexchange which sounds very similar to yours, only the post is in reference to ArcGIS and the Point Distance (Analysis) tool:
https://gis.stackexchange.com/q/91571/81346
Ideally you'd use a geospatial db for this, to avoid performance issues when dealing with increasing numbers of points. MySQL, Postgres etc all support geospatial functions.
But as you've tagged your question with javascript, I'll post a JS solution. There's an npm package called haversine - with it, you should be able to loop through each point and return the other points that are within 100m. Something like:
// bring in haversine from npm
var haversine = require("haversine");
// define the full list of points
var data = [
[48.34483,51.1624517],
[48.484,16.2585],
[48.361,51.87739419],
[6.38477205,51.87745015],
[48.3645,51.1673167],
[6.38391099,51.87755068],
[48.3575,16.725],
[6.38380232,51.87720004],
[6.38376297,51.87708017],
[6.38375183,51.87704018],
[6.38373055,51.8769829]
];
var points = data.map(point => new Object({latitude: point[0], longitude: point[1]}));
// var to store results in
var results = [];
// loop through the points
points.forEach((pair) => {
var nearby = points;
// filter the full list to those within 100m of pair
nearby.filter(point => haversine(pair, point, {unit: 'mile'}) <= 100);
results.push({
'point': pair,
'nearby': nearby
});
});
console.log(results);
Note: I corrected some of the points in your list, which had double decimals so weren't valid
I am testing Cesiumjs to see if it can reflect a near-real-time expreience - for example: position of airplanes.
For that, I need to draw billboards and make them move - which I know is possible with cesium, just not sure how.
The code looks like this:
var billboards = scene.primitives.add(new Cesium.BillboardCollection());
var billboard = {
image : '/path/to/logo.png',
position : Cesium.Cartesian3.fromDegrees(-75.59777, 40.03883)
};
billboards.add(billboard);
My question is how do I change the position of the billboard. I couldn't find ant documentation that would explain.
I thought doing:
billboard.position = ... //new position
but how will cesium know that I've changed the position attribute unless it somehow turns that reference into a observable object.
So how do I update the location?
Thanks.
Cesium does indeed listen for changes to billboard.position
(source code here), so it is correct behavior for apps to simply write a new position.
Note that you must write the whole position at once, meaning you may not write to billboard.position.x. Instead, keep a "scratch" Cartesian3 around (don't create a new one every animation frame at 60fps), write to the x,y,z properties of your scratch variable, and then assign your scratch variable to billboard.position. You can see in the source that the assigned value will be cloned into another pre-existing Cartesian3, so you may immediately reuse the scratch variable.
Here's an example:
// Just once at app startup. Don't call "new" at 60fps.
var scratchCartesian3 = new Cesium.Cartesian3();
var ellipsoid = viewer.scene.mapProjection.ellipsoid;
function onTick() {
// This is safe to call at 60fps.
billboard.position = Cesium.Cartesian3.fromDegrees(
lon, lat, alt, ellipsoid, scratchCartesian3);
}
Also note that your question and the above answer are focused on the "Graphics Primitive" layer of the Cesium API. Cesium has one higher layer, called the "Entity" API, that you can use if you want Cesium to handle the concept of user-selectable objects with pop-up descriptions etc. Here's a Sandcastle demo showing how to add a billboard as a property of an entity, instead of as a primitive. This allows you to add other properties to the same entity, for example a name, description, label, 3D model, etc, and have them all be controlled from the same position property, and have Cesium take care of popup descriptions. The position property is more complex for entities than for primitives, for example it can be constant or sampled. This allows entities to change position over time when the timeline is shown.
I'm trying to make a little scene for viewing 3D models.
I modified the GLGE Collada example to add a .dae model from code.
http://goleztrol.nl/SO/GLGE/01/
What I've got
So far it works. The camera is rotated using an animation.
Using the buttons 'Add' and 'Remove' the model is added and removed from the scene, using the following code (Don't mind 'duck'. It was a duck in the original example.)
var duck = null;
function addDuck()
{
if (duck) return;
duck = new GLGE.Collada();
doc.getElement("mainscene").addCollada(duck);
duck.setId("duck");
duck.setDocument("amyrose.dae");
duck.setLocY(-15);
duck.setRotX(1);
duck.setScale(2);
}
function removeDuck()
{
if (!duck) return;
doc.getElement("mainscene").removeChild(duck);
duck = null;
}
Problem
Now the model is lying down, while it should stand up. The various methods of the element seem to work. The location is set, and the scale is set, but the call to setRotX seems to be ignored. I tried various others methods from the api, but setRotY, setRot, setQuatX and setDRotX all seem to fail. I don't get any errors (well not about this method). I tried values of 1.57 (which should be about 90 degrees), but other values as well, ranging from 1 to 180.
I can't find out what I'm doing wrong. Of course I could rotate the model itself in Blender, but I'd like to do it using the GLGE API.
Update
When I load the demo-model, seymourplane_triangulate.dae, the rotation works. Apparently my model differs in that it cannot be rotated. I just don't understand why. I figured it may be because the model is built of various separate meshes, but I don't understand why scaling and moving does work.
Does anyone know what's wrong with this model, and what I could do to fix it (maybe using Blender)?
Setting an initial rotation in the XML file that contains the scene does work. Setting rotation on another element (like the whole scene) works as well.
You need to rotate it after it has been loaded.
You can do this in the callback to setDocument
duck.setDocument("amyrose.dae", null, function() {
duck.setLocY(-15);
duck.setScale(2);
duck.setRotX(0);
duck.setRotY(0);
duck.setRotZ(3);
});
I am using the Google Maps v3 API. I currently am making a request to fetch new data each time a person changes the viewport (by either zooming or shifting the map) and am throwing away the old data I have. This works great, but now I want to cache the data so that I don't need to fetch the data each time the viewport changes. The Google Maps API defines a viewport by its Northeast and Southwest coordinate consisting of a latitude and a longitude. They are stored in objects called LatLngBounds.
I have come up with 2 ways I can do this:
Store the bounds of each new viewport the user visits and check if the new viewport is in an old viewport and fetch new data only of the part of the new viewport that is not within an old viewport. Essentially,
Divide each new viewport up into rectangular sections of data that we have and data that needs to be fetched. Store the bounds of each of the rectangular sections.
If anyone can think of a better way to do this, feel free to suggest new approaches.
My question is which one is going to be better in terms of better performance/memory usage and overall speed? They are both similar algorithms so does it really matter?
Also, right now both algorithms rely on dividing up the new viewport based on old viewports. What would the algorithm to divide new viewports look like? (Assume I implemented my 2nd algorithm)
var prevBounds = [ /* Array of previously seen bounds */ ];
var newViewport = map.getBounds(); // New Viewport to divide up
var sw = newViewport.getSouthWest();
var swlat = sw.lat();
var swlng = sw.lng();
var ne = newViewport.getNorthEast();
var nelat = ne.lat();
var nelng = ne.lng();
// newViewport.intersects(bounds)
// Returns true if this bounds shares any points with this bounds.
I might consider doing this more or less exactly the way Google serves up map tiles - instead of loading data for the entire viewport at once, carve up the entire map into square areas (though probably bigger areas than Google's 256x256 tiles), determine which areas are in the current viewport, and load data for those areas. As the user pans and zooms the map, check the viewport bounds to see whether new areas have come into the frame, and load them as necessary. Rough pseudocode:
var cache = {}
function onViewportChange() {
// get new bounds
var bounds = map.getBounds();
// identify all the areas in the bounds
var areas = getAreas(bounds);
areas.forEach(function(area) {
if (area.key in cache) {
// do nothing, or load items from cache
} else {
// load new data, storing the key (and maybe the data)
// to the cache
}
})
}
function getAreas(bounds) {
/* given a set of bounds, return an array of objects like:
[
{
x: 1,
y: 2,
zoom: 4,
key: "4-1,2",
bounds: b // lat/lon bounds of this area
},
...
]
*/
}
(See the Google explanation of map coordinates and this example for an idea of how to implement getAreas.)
The appeal of this is that the areas you're retrieving are much simpler, and it becomes very easy to check whether you've already loaded data for a given area - each area can have a simple unique key, probably a string made out of the x/y/zoom coordinates, and as each new area is loaded you save the key (or maybe the key and the data - it depends on whether you're removing old data from the map or just leaving it there) to some cache object. Then all you have to do when the viewport moves to a new area is check for the existence of that key in your cache.
The downside is that you might often load data outside the current viewport, and you're probably sending more requests to the server than you would with the implementations you suggest. This method might work best if you're serving up different data at different zoom levels - otherwise you might be stuck trying to choose a single-size cache area that works well at different zooms.