Open smalers opened 3 years ago
To follow up on a conversation, it seems like the most robust way to do highlighting is to handle similar to how selected features are handled, in which case the extended layer class object instance will maintain a list of highlighted features. Below are some technical considerations.
After some discussion, I think we should take a step back and really evaluate the general design for selection and highlighting. Below are some thoughts. The design should to a degree be independent of Leaflet features, but of course is impacted by Leaflet features and limitations.
First, rendering a layer may involve several visual components:
Circle
layer for drawing radius, etc. An example of annotations is user-supplied mark-up of a map such as text labels, lines, and other basic shapes.All of the above are specified to Leaflet, which then renders/draws the data. Is it possible to let custom code do some rendering without depending on Leaflet to do so? Maybe, but assume no and that the above need to be created.
The Leaflet documentation has vector Layer
classes including Path
base class and other classes derived from it such as Polygon
, Polyline
, and Circle
. The GeoJSON
layer helps ingest GeoJSON data files and must handle the different geometries.
There are several requirements for layer interactions, including:
In addition to the visible map, there are several design considerations, including:
Polygon
layer rather than full GeoJSON layer would make sense.The new code has been merged with some changes. The code is quite similar to what I had before, but has some changes of how things are being made.
The selected layer is made with a separate geoJSON layer, added to a MapLayerItem (layerItem) object, and added before the layerItem on the map. This way, a layer toggle will effect both the Leaflet and selected features on the layer. For now it is not being added on top of a feature, so the mouseover and mouseout events won't be affected. This is the same for both polygons and points.
As of now the highlighting has been reverted back to an updating of each feature's style.
The issue where certain Dialogs were only allowed to open once should be taken care now. Let me know if something is still off.
The InfoMapper extensively uses GeoJSON with Leaflet. However, one problem is that polygon shapes don't always render well when highlighting polygons. For example, see the image below from:
http://poudre.openwaterfoundation.org/latest/#/map/entities-basins
My understanding is that highlighting is typically done my detecting the feature to highlight, change its Leaflet styling, let it render as highlighted, and then set the style back to original once not highlighted.
The problem is that the polygons have overlapping borders (coordinates are repeated in each polygon) and the order of polygon in the data controls the rendering order. One solution would be to ensure that highlighted features are always drawn on top of the specific layer, maybe by drawing the entire layer and then only the highlighted feature using highlighted style. Is this possible without overly-complicating the code? The SNODAS web application uses
bringToFront
to ensure that highlighted and selected features are drawn on top but this may not work with multiple layers or more complex maps?InfoMapper uses an extended GeoLayer for selected features and map marker. Should there be a dynamic list of highlighted features? This list would perhaps only contain the single feature currently under the mouse pointer. It would be nice to not change the styling on features over and over again just due to moving the mouse, but creating shapes dynamically could be slow and result of a lot of memory being used. Maybe there is a way to internally use a pointer to the shape data for drawing but specify different styling. That way memory would not need to be manipulated for shape data.
A different solution is to use a data format such as TopoJSON (for example, see: Topojson on a Leaflet map), which has only a single line when shared between polygons. The benefits of TopoJSON are that files are smaller (since polygons share lines) and performance is faster. Downsides are that additional processing needs to occur to create the file, and software would need to be updated to handle. Would also solve the issue of highlights? I'm thinking NO because the draw order of the polygons would still be an issue.
Maybe it does make sense to add a highlighted features list to the extended layer class to handle this also. Then the original layer would always render using its style and highlights, selects, and additional markers (such as from address search) would be rendered on top of the layer. This seems reasonable for display-only software. Interactive editing might be harder to deal with but currently we don't do editing.