Handling of simple style properties
rowanwins opened this issue · 7 comments
Would be great if we could look into this issue around handling of the simple style properties that get added to features.
@stevage has offered me 4 brownie points to get this issue resolved, 4 can you believe it, it's so worth it!
I'm happy to take a preliminary look at it
I'm not sure if we should port over simplestyle support at all in the first revision; Mapbox abandoned it, no other organizations adopted it. It was a nice and semi-standardized way to style features, but without future support (zero GL compatibility, for example), it's kind of hosed.
I was not happy with how simplestyle polluted the properties object of a feature. What would you think about keeping this kind of styling, but moving the styling properties to their own object such as Feature.style?
High-level wise, it's far out of scope for this project to be the first implementation of a new style spec. In terms of the specific proposal: per previous discussions, I still think that keeping data anywhere other than properties means risking it being botched in a round-trip. It would require some field research to discover whether that is still true. I would bet it is, and it'd be even worse in stuff like the rust-geo project, where all GeoJSON objects are very strictly typed. Adding a new top-level key seems like trading a pretty minor issue (property conflicts?) for an ongoing, major issue (data loss, implementation pain).
Round-tripping of GeoJSON extensions is supported by GDAL since version 2.1 (https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr) which means, to a first approximation, that it is supported everywhere.
I don't especially like simplestyle, and think that geojson.net could do the web a big favor by supporting better extensions (that have yet to prove their worth, I admit), but removing it will catch users off-guard, I think.
Okay, well - my position is that I'll implement an "improved / better-liked style spec" if one exists. But probably won't write another spec of that sort, or throw a lot of time into being the reference implementation, because there's enough work involved in this project just to get the basics solid, and I don't have a dog in the race of geospatial standards anymore.
Bit of a tough space because there are so few options, and the ones that do exist have limited like-ability and adoption.
In lieu of implementing a simplestyle I wonder if you/we could have a button to allocate random colours to features (eg a colorbrewer palette) and use the leafletjs style options rather than any properties on the geojson itself. In 90% of cases that would suffice for my use cases where I'm just trying to visually differentiate between different features.