Hello, I've got some ideas how to improve the current projection handling in the lib. As I will spend my next month or so with writing papers about the WebGL renderer, I'm leaving these ideas here to sink and develop. These are quite heavy changes, and unlike the WebGL renderer, it's not trivial for me if you would like these implemented, hence the mail and not a PR. Also note, that my following statements come from studying an earlier version, thus they might not cover fixes since then. If there is a false statement, please correct and excuse me.
First of all, the current projection system is not prepared for changing projections consistently. I assume, I don't have to explain to you, projecting coordinates to outside of the destination projection's validity extent can shoot coordinates up to infinity. However, as the lib uses permanent transformations, these unhandled cases can result in messing up a layer's geometry for the current session. I propose an option users can provide to a vector layer (e.g. onTheFlyProjection: true). If they use this feature, the lib stores the original geometries with their projection identifier, and transforms them for rendering if necessary. In these transforms, we could discard geometries with coordinates outside the validity extent for rendering. This alone would solve two problems: invalidating geometries and "geometry migration" (when the transformation leaves a remainder). With this approach, we could easily do some fancy rendering out of the box. For example, we could have an option for condensing segments/edges when source projection != destination projection. This could result for example in nice satellite orbits visualised on a 2D map next to the 3D visualisation provided by OL3-Cesium. On the top of that, as the original coordinates are stored apart from the rendered ones, syncing between the two apps would be less error prone, thus more feasible. Please don't take these ideas too strictly, they are just some early drafts for a feature I think would be awesome to have. For example, I think it wouldn't be less great if we would only store geographic (e.g. WGS84) coordinates in the permanent storage. I'm looking forward for your opinions and suggestions. Best regards, Gábor Farkas -- You received this message because you are subscribed to the Google Groups "OL3 Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to ol3-dev+unsubscr...@googlegroups.com. To post to this group, send email to ol3-dev@googlegroups.com. Visit this group at https://groups.google.com/group/ol3-dev. To view this discussion on the web visit https://groups.google.com/d/msgid/ol3-dev/dc02c750-f491-4900-8e67-435ee6ee20d5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.