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.

Reply via email to