Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Maps] force vector layer to only contain single feature type #35666

Closed
nreese opened this issue Apr 26, 2019 · 5 comments
Closed

[Maps] force vector layer to only contain single feature type #35666

nreese opened this issue Apr 26, 2019 · 5 comments
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation discuss

Comments

@nreese
Copy link
Contributor

nreese commented Apr 26, 2019

The current vector layer implementation does not enforce vector layers to be homogeneous (all the same feature type - point, line, or polygon).

Not knowing the vector layer feature type impacts the vector style UI. Some style properties are only needed for some feature types. For example, the Symbol size property is only used by points and Fill color style property is not used by lines. The problem is going to get worse when enhancements like custom icons get added.

Allow vector layer to be heterogeneous and display points, lines, and polygons

The vector style UI problem could be solved by breaking the styling out into three sections, for point, line, and polygon. Users could style each feature type independently.

pros
  • This solution provides the greatest flexibility since all feature types could be displayed in a layer
  • No need to filter out features that do match layer type
cons
  • This would break the legend icon. What icon would you show for the layer in the legend? It could be three independently styled icons. Which one would you use?
  • Complicates layer configuration since layer could be any feature type

Force vector layer to only contain single feature type

The vector layer feature type would be a user configured setting that would be set in the layer details panel. The selected type would drive the displayed style properties. Only features that matched the selected feature type would get rendered on the map.

pros
  • Legend icon is simple and understandable, showing either point, line or polygon
  • Style UI only shows properties that are relevant to the feature type
  • Simplifies layer configuration since layer is only single feature type
cons
  • This could have backwards compatibility problems with Saved objects created in prior releases. The feature type would have to be guessed by looking at the returned features.
  • This solution provides less flexibility since only a single feature type could be displayed in a layer

Please vote on this issue

  • thumbs up vote for Force vector layer to only contain single feature type
  • thumbs down vote for Allow vector layer to be heterogeneous and display points, lines, and polygons. If you vote thumbs down, please provide suggestions on how to solve the highlighted problems.

cc @cchaos @alexfrancoeur

@nreese nreese added discuss [Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation labels Apr 26, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-gis

@nreese
Copy link
Contributor Author

nreese commented Apr 26, 2019

Just chatted things over with @thomasneirynck and it sounds like there is a path forward that retains Allow vector layer to be heterogeneous and display points, lines, and polygons.

When we originally discusses the vector style property data structure it looked like the structure below where each feature type had its own copy of each style property. This created the problem of the legend icon since points could have one fill color while polygons could have another.

{ 
  points: {
    fillColor: {},
    lineColor: {},
    lineWidth: {},
    iconSize: {},
  line: {
    lineColor: {},
    lineWidth: {},
  },
  polygon: {
    fillColor: {},
    lineColor: {},
    lineWidth: {}
  }
}

Instead, we can keep the existing data structure and only have a single copy of each style property.

{
  fillColor: {},
  lineColor: {},
  lineWidth: {},
  iconSize: {},
}

The idea of styling by feature type is just a UI construct that hides styles that are not applicable to that feature type. Under the covers, there is only one set of properties so points and polygons will always have the same fill color.

The Vector style UI would be updated to show a button group with point, line, polygon.

  • When set to point, the UI would show the properties: fill color, lineColor, lineWidth, iconSize
  • When set to line, the UI would show the properties: lineColor, lineWidth
  • When set to polygon, the UI would show the properties: fill color, lineColor, lineWidth

The default selected feature type would be generated by looking at the current feature collection for the layer. If the feature collection only contains points then points would be selected by default. If the feature collection only contains lines then lines would be selected by default. If the feature collection is in neither of those states then polygon would be selected by default.

This solves the problem of the legend icon because there can only be one style per property regard less of feature type. The icon type could be a point if the feature collection only contains points, a line if the feature collection only contains lines, and a polygon for an other cases. Since all of the feature properties are the same across the feature types then there are not problems about multiple icons.

Thoughts?

@thomasneirynck
Copy link
Contributor

thomasneirynck commented Apr 26, 2019

voted down, since @nreese's suggestion #35666 (comment) satisfies a lot of requirements

  • legends remain simple
  • no backward compatibility issues due to changes in the shape of the descriptor
  • no added complexity of having to filter features based on geometry-type on the client and/or server
  • UI will be more intuitive for users. I'd expect in 9/10 of cases a simple inspection on what the geometry-types in the data-response will be what the geometry-types are in all of the data.

@thomasneirynck
Copy link
Contributor

Can we close with #36280 merged?

@nreese
Copy link
Contributor Author

nreese commented May 20, 2019

Closed by #36280

@nreese nreese closed this as completed May 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation discuss
Projects
None yet
Development

No branches or pull requests

3 participants