-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
User settable GeoJSON defaults #2167
Comments
I don't think this is a problem; certainly not a serious one. 3 is easy to implement, lets users do a large swath of the things they want to do, and is easy to understand. Users can always loop over the entities after load if they need to do something more unusual. We can also extend this in non-breaking ways in the future if necessary. For example, 1 can be used as the source of the defaults that would be hard-coded in 3. It's also easy to imagine adding a callback that is invoked during entity creation. The callback would be given the GeoJSON feature plus the entity that Regarding your specific example of a default In short, I think letting users specify default styles in the exact same way they specify per-feature styles makes a ton of sense, even if we eventually provide other things as well. |
Just so we are clear, you are advocating 3 as your preferred solution in the short tem? |
Yes :) |
I was one of the people asking about this feature on the mailing list. I also like option 3. I don't think its limitations wrt Cesium-specific features are too big of a hurdle; someone loading GeoJson probably isn't looking for the advanced features of Cesium. (I'm not, anyway.) |
Okay. I really liked 3 as well, my concerns were only in their limitations. I'll open a PR soon with the change. (though it probably won't make it into today's release). |
I just opened #2256 to handle this (mostly what we agreed on with some tweaks to make the options more Cesium-friendly), let me know what you guys think. |
The ability to set default properties on GeoJSON features has been a hot topic on the mailing list. There are some subtleties that make it tricky. Me and @kring started to discuss them in #2162. To summarize that conversation:
PolygonGraphics
,BillboardGraphics
, andPolylineGraphics
instances and be done with it. However this is limited, for example it wouldn't be possible to usePointGraphics
instead ofBillboardGraphics
orWallGraphics
instead ofPolylineGraphics
. This limitation may be no big deal (since you could fall back to the load and loop approach if you wanted to do that).symbol=undefined
,color=Color.ROYALBLUE
, andsize=48
. Just turn each of these into properties on GeoJsonDataSource. Definitely limited, but might be enough for what people want.GeoJsonDataSource
which are the default simplestyles for each feature type. So you check for each style property on the feature, if it's not there you check for the same one on the default for that feature type, and if it's not there either you use the hard-coded default as you're doing right now. Simple and convenient.The problem with the last two ideas is that it doesn't account for properties that only Cesium has. For example, what if we wanted to put a default
NearFarScalar
on thebillboard
. How would the user easily turn that off (or even know it was on)? I find 3 the most elegant, but I think it may be too limiting. 1 might be the best approach, since it's the least limiting and will most closely match the loaded result. We're open for other ideas as well.The text was updated successfully, but these errors were encountered: