I am trying to exclude certain features from being clustered, by using the geometryfunction as described in the API here:
http://openlayers.org/en/latest/apidoc/ol.source.Cluster.html
It is recommended to return null, when the feature should not be considered for clustering. I would expect that to mean, that the feature would still be shown, but not included in clusters. What i see is, that the feature is not shown at all. Is this to be expected?
IconLayer.clusterSource = new ol.source.Cluster({
distance: 40,
geometryFunction: this.clusterFunction,
source: mySource,
});
private clusterFunction(icon: Icon) {
return icon.geo.isMoving ? null : icon.getGeometry();
}
Seems like it cant be done that way. See this answer on github:
https://github.com/openlayers/ol3/pull/4917#issuecomment-224875452
As describe in the above link, a possible solution is to create a 2nd vector layer and show the non clustered features there.
EDIT: For the record i ended up creating two vector layers. But instead of using geometryFunction to disable rendering on the first layer, i simply removed the feature in question from the source of the first layer and added it to the second.
Related
We are currently building an asset tracking widget using Mapbox-GL.
When zoomed in, we show the actual assets, and this works fine.
But, when zooming out, we would like to switch to a cluster view to get a proper overview of how many assets are where.
From my understanding, such layer needs to have a predefined datasource. eg. GeoJson.
Is there any way to feed Mapbox-GL data from live JS data?
The assets themselves are markers, an afaik there is no way to switch from makers to something else.
So I assume we would have to generate the datasource from the data that makes up the markers somehow?
The sources seems to be using URL's for getting the actual data so I'm at loss here,
Can I transform a set of geo points into something that MapboxGL can use as a data source?
It's rather confusing what you are asking, but in general, there is no problem with updating data live.
Create the data source:
map.addSource('assets', { type: 'geojson', data: { type: 'FeatureCollection', features: [] }})
Then update it:
map.getSource('assets').setData({ ... })
I didn't understand what you mean by:
such layer needs to have a predefined datasource. eg. GeoJson.
or
The assets themselves are markers,
or
an afaik there is no way to switch from makers to something else
I've been implementing a chat client in Electron (Chrome) and React. Our top priority is speed. It behooves us, then, to use a virtualized list component (also known as "buffered render" or "window render"). We've explored react-virtualized, react-window, and react-infinite, among others.
One issue all these components have in common is that if supporting list elements of variable heights, the heights need to be known in advance. Now, some chats are very long, and others are very short, so that presents a challenge for us. (Images and video are easy thanks to EXIF data and ffprobe).
So, we're faced with the challenge of measuring heights while also straining to be extremely performant. One obvious technique is to put the elements in a browser container off-viewport, perform the measurements, and then render the list. But that hurts us on the performance requirement aspect. Software like react-virtualized/CellMeasurer (which is no longer maintained by the original author) and react-window make us of this technique, built in to the library, but performance is somewhat slow as well as unreliable. A similar idea that might be more performant would be to use a background Electron Browser window to do the rendering and measuring, but my intuition is that wouldn't be that much faster.
I submit that there must be some solved way to figure out string height in advance, according to word wrap, max width, and font rules.
My current idea is to use a library like string-pixel-width in order to calculate row heights as soon as we get the text data through our API. Basically, the library uses this piece of code to generate a map of character widths [*]. Then, once we know how wide each text, we separate each line when it maxes out the computed max row width, and finally infer list element height through row count. It's going to require a little bit of algorithmic fiddling due to break-word but there are libraries to help with that – css-line-break seems promising.
[*] We would have to modify it a bit to account for all Unicode character ranges, but that is trivial.
Some options I haven't fully explored yet include the python weasyprint project and the facebook-yoga project. I'm open to your ideas!
Using the canvas capabilities to measure text could solve this problem in a performant way.
Electrons canvas text is calculated the same as the regular text, there are some diffrences in rendering though especially in reguard of anti-aliasing but that does not affect the calculation.
You can get the TextMetrics from any text with
const canvas = document.getElementById('canvas')
const ctx = canvas.getContext('2d')
// Set your font parameters
// Docs: https://developer.mozilla.org/en-US/docs/Web/CSS/font
ctx.font = "30px Arial";
// returns a TextMetrics object
// Docs: https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics
const text = ctx.measureText('Hello world')
This does not include line breaks and word wraps, for this feature I would recommend you to use the text package from pixijs, it uses this method already. In addition you could fork the source (MIT licence) and modify it for additional performance by enabling the experimental chromium TextMetrics features in electron and make use of it.
This can be done when creating a window
new BrowserWindow({
// ... rest of your window config ...
webPreferences: {
experimentalFeatures: true
}
})
Now to the part I mentioned in the comments since I don't know your codebase, your calculations and everything should be happening in the Render Process. If that is not the case you definitely should move your code from the main process over to the render process, if you do file access operations or anything node specific you should still do this but in a so-called preload script
it's a additional parameter in the webPreferences
webPreferences: {
preload: path.join(__dirname, 'preload.js')
experimentalFeatures: true
}
In this script you have full access to node including native node modules without the use of IPC calls. The reason I discourage IPC calls for any type of function that gets called multiple times is that it is slow by nature, you need to serialize/deserialize to make them work. The default behaviour for electron is even worse since it uses JSON, except you use ArrayBuffers.
I have downloaded the community samples, installed SDK and run the solution successfully in Visual Studio to use the default add-in. I am now interested in customizing the control to:
1) display specific layers (not all of the active/displayed layers)
2) open to a specified zoom extent.
I have located some of the snippets on the git site (zoom to extent specifically) but do not know how to format the coordinates and am unclear as to what heading they go under. I cannot find related code to mimic and am unfamiliar with coding in C# (pretty well versed in python and AHK). Any help or resources would be GREATLY appreciated. Thanks in advance!
I got this response, for those who are interested:
see thread here
MapControl has a ViewContent property that can be set to any custom view content. In the sample, I am using the MapControlContentFactory.Create method to set the view content (within the InitializeMapControl method in MapControlDockpane.xaml.cs). This Create method has many overloads. This particular overload might be exactly what you need: (Note the first parameter which takes a list of any layers you need)
Create Method: http://pro.arcgis.com/en/pro-app/sdk/api-reference/#topic12607.html
public static MapControlContent Create( IEnumerable layers, Envelope initialExtent, MapViewingMode viewingMode )
MapControl's zoom extent is also defined when you create the content using the Create method (the envelope parameter). In the sample, I am listening to the ActiveMapViewChangedEvent and MapViewCameraChangedEvent events and modifying the MapControl's extent to match that. You can remove that for your workflow and set the MapControl's content the way you want it to be.
I'm using Opeonlayers 3.18 + GeoServer. I can make a ogc filter for comparing a field and a value. How can i compare two fields?
Code below shows what i'm looking for:
var f = ol.format.ogc.filter.greaterThan('Field1', 100); // this works nicely
var f = ol.format.ogc.filter.greaterThan('Field1', 'Field2'); // this doesn't work
Equivalent working CQL filter is: 'Field1 > Field2'
Regards
This sort of filtering should work. I'd note that many databases may not have a way to perform that filter in an optimal way, and as such, there's a chance that the handling for such a filter is not correct.
The first thing to check out is if the GeoServer logs have any additional information. For most requests, there are log messages which will provide all the details (including the filter) for the request.
If OL3 is making a non-sense request, there should be some kind of parse error first. If the datastore is having trouble with the request, you might see an exception.
To help further, which version of GeoServer and which datastore are you using? Also, is there additional information in the logs?
Update: Based on the comment below, I checked out the Open Layers 3 source. If you look here, it looks like OL3 is treating the first argument as a properyName and the second as a literal. It is probably worth filling a bug/feature request on the project's GitHub page.
Given this example http://openlayers.org/en/v3.0.0/examples/vector-wfs.js and using BBOX strategy , does it mean it is necessary to use &bbox=' + extent.join(',') part in source URL?
The OpenLayers3 Strategy BBOX strategy says “request new features
whenever the map bounds are outside the bounds of the previously
requested set of features.”
Yes, the &bbox=' + extent.join(',') if required. If you take it out, you will get no wfs features at all. The example is actually somewhat misleading, in that, it calls it a BBOX strategy, whereas in fact it is a createTile strategy, using the BBOX from each underlying tile, as the wfs BBOX. If you look internally at the source code for ol.source.ServerVector you will find a function loadFeatures that calls ol.loadingstrategy.createTile from ol.loadingstrategy which returns the required extents for each tile, which is then used for each wfs call. That is the extent that you see in the extent.join above.
Or to look at it another way, for every call to get an imagery tile, there is a corresponding call to a wfs tile -- which you can verify by looking in the network tab of your browser's dev tools. So, really, this is a tile BBOX strategy, not a view BBOX strategy.
I thoroughly recommend getting local debugging working for OL3 to understand what is going on. You can do that either by loading ol-debug.js, for a non-compressed version of the js, or by setting up a local server, see these instructions