geojson.net

geojson.net copied to clipboard

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).

TerriaJS (https://github.com/TerriaJS/terriajs) for one supports it. I imagine there are other similar packages that do too. Seems a shame and maybe a bit premature to let it die. Otoh, I haven't used it in years so maybe fair to leave it out for now and see what the demand is?

(I agree the style should stay on the properties object fwiw)

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.