In previous versions, there was a singleTile option (for OpenLayers.Layer.WMS) to avoid labels and features cut along tile borders and repeated labels.
Open layers 3 does not seem to have this option and some layers do not show at certain zoom levels.
Please help.
Use ol.layer.Image with ol.source.ImageWMS instead
Related
If I select some items of the model using-
viewer.select(dbids, viewer.model, Autodesk.Viewing.SelectionType.OVERLAYED)
and then try to zoom in/out or rotate the model, the viewer gets slower. But if I select some items using mouse click it doesn't affect the viewer at all.
If I select items using-
viewer.select(dbids, viewer.model, Autodesk.Viewing.SelectionType.REGULAR)
the viewer first hides everything except the selected items and a moment later shows up. It also hide some parts of the selected item(s). The navigation is smooth now.
This is before selection-
This is after selection-
Is there any way to overcome this slowness and the hidden parts issue.
Let me first explain the difference between the overlaid and regular selection highlighting:
Overlaid highlighting means that the selected objects are rendered twice. Once with their standard material, and once with the overlay material (so that they can be seen through obstacles as well). Of course, this doubled rendering may have significant impact on performance, especially if you select many objects (for example, by selecting a group of a large number of objects in the model browser).
Regular highlighting was introduced to mitigate the performance problems. In this case, instead of rendering the selected objects twice, they're simply rendered once, with a specific color tint applied to their regular materials. The drawback of this approach is that the selected objects are not visible through obstacles.
Now, to your problem: "regular" selection highlight is definitely the right way to go if the "overlay" highlighting is slow, but the fact that parts of your model disappear is strange. I'm thinking there might be a problem with the model itself. Perhaps it's too granular or tessellated (has too many parts or triangles), so applying the "selection tint" to all the selected parts takes unusually long time. Could you please try both the "overlay" and the "regular" selection with another type of 3D model? If it works well, you may need to look at the settings of the application that's creating this problematic model, and see if you can decrease the tessellation levels.
I have a chart with multiple modifiers that provide different behaviors on rollover. The chart used to have a vertical line that would show up on rollover. I was asked to get rid of it, which was easy:
<sci:RolloverModifier
DrawVerticalLine="False"
but I noticed that the label that shows up under the X axis is still there. I've tried to remove it, I didn't figure out how to do it.
I've examined some other graphs in the application, and found a similar one, which has the labels showing on both the X and the Y axis
[edit: image removed to prevent potential client IP issues]
I tried comparing the charts, and they do have different sets of modifiers, but I didn't find out what causes one graph to only have the graph on the X axis, and the other one on both.
The property you want is RolloverModifier.ShowAxisLabels.
However, the screenshot you've posted looks like the CursorModifier. If you find out that the CursorModifier is adding the labels then you can either remove this modifier, or you can try a workaround like this one on the SciChart Forums (which is 4 years old so may be out of date!)
This is my first posted question despite using StackExchange for a few years now. I've been stuck for quite some time trying to figure out this issue with OpenLayers. The problem is as follows:
I have a bunch of features plotted on a map and am able to select features in various ways (e.g. drawing a box around them, clicking on individual features, entering a zip code that selects all features within that zip code, etc.). This all works fine. The issue is that I have a clustering strategy on the features layer and when I zoom out, currently selected features get clustered together with unselected features and those unselected features will become selected when I zoom back in. What I'm trying to accomplish is to NOT have the previously unselected features become selected after clustering.
This behaviour (keeping selection of subfeatures after zooming in with selected cluster) is buried quite deep inside of Strategy.Cluster code. One solution would be to get deep into the code of Strategy.Cluster and making it remember really selected features and select only those on zoom in (actually - on reclustering, or calling Strategy.Cluster.cluster()). Second would be to track the selected features outside of openlayers by subscribing to event featureselected and reselecting features on zoomend.
I'm developing a visualization for certain parts of a Warehouse with Flex 3. In this visualization there are lot of blocks where 1 to x pallets can be placed where x is between 9 and 15. I need to represent each pallet with a black square, each place which is already assigned to a pallet but not physically taken with a grey square and each free place with a white square. I first thought to just use a canvas for each place on a block and change their color if the state changes. But the hundreds of canvases which are there as a result of this approach are not updated quickly enough for my purposes (screen freezes for a few seconds).
I don't want to use embedded images because of the great amount of images I had to embed in the application (those Images appear in 4 orientations).
My idea was to create background images which reflect the state of the whole block only when needed for that certain state and cache them, so that the computation time is spread over the whole runtime.
My problem now is I don't know how to create them in a way that I can use them as "backgroundImages". As far as I understand I would need them as a class object but I don't know how to achieve that, when not embedding the images.
I'm of course open to better approaches to solve my problem. Thanks for your support.
I would suggest using Graphics property of a Sprite for example. It provides basic drawing API, like drawing lines, circles and rectangles.
Besides, you can draw bitmap images on the Graphics to produce more advances results.
My first KML project was an animated map of the Washington DC Metro system (see Animating Metro with KML and Google Earth). Unfortunately, where Metro lines share the same track, only one color prevails. The real map shows a wider line with both colors side by side.
Is there a way to draw a line in KML (Google Earth) with two side-by-side colors? I've seen a way to have a different color on the edges of the line, but that's different.
I could cheat by changing the coordinates of each station, but aside from computational difficulties, I'd have to continuously changes to positions every time the user zooms, to prevent a gap between colors (or an overlap).
Other subway systems show more than two colors running alongside each other, so an option to show multiple colors would be nice. And this is not really a gradient, as the colors don't fade together; they should be distinct, assuming the pixel width is wide enough.
This is probably a feature request, though surely someone else has run across this problem before Google Earth v6? Would love to be able to do this, or find a good workaround in the interim.
Michael
http://www.mvjantzen.com/blog/
The short answer is no, although you could probably create a custom MVC object that renders the line for you as desired (i.e. you would not need to alter the Kml)
http://code.google.com/apis/maps/articles/mvcfun.html
That said, your cheat method could work too - and I would disagree that
"...I'd have to continuously changes to positions every time the user
zooms, to prevent a gap between colors"
You can set the <gx:physicalWidth> property which allows you to set the width of a LineString to be in meters, rather than pixels.
https://developers.google.com/kml/documentation/kmlreference#gxphysicalwidth
In the case of your track example, this means you can set the width of the track to match the underlying imagery no matter what altitude the end user views it from.