Hi Tim,
I'm very happy to hear your thoughts about this. I don't think the current
geometry handling is a design mistake, the minor performance gain from
storing projected coordinates is pretty neat, especially for those, who
only use one CRS. Hence, I think making this method optional, and allowing
the users to choose if they would like to store their geometries in a
geographic ref. sys. would be the way to go.
Additionally, what do you think about changing the current spaghetti model
to a topological vector model in the future? It sounds pretty extreme, but
it might have a potential in OL3.
Regards,
Gábor
2016.11.18. 21:03 ezt írta ("OL3 Dev on behalf of Tim Schaub" <
[email protected]>):
>
> Hi Gábor,
>
> Thanks for your thoughts and suggestions.
>
> For some of the reasons you suggest and others, I think it was a design
mistake to transform all geometries and store projected coordinates. We
have to transform again when rendering, and I'm not convinced that the
additional geographic -> view projection transform would kill rendering
performance (we already cache render instructions and could alternatively
cache transformed geometry coordinates under different rendering scenarios).
>
> I think the library would be significantly more usable if the API
accepted and provided geographic coordinates - we could still support
arbitrary map/view projections and could provide convenient ways to
transform incoming data if in a projected SRS. This feels like something
to take on in a major version bump. There are a number of other usability
gains we could couple with this - so the idea is pretty compelling to me.
>
> Tim
>
>
>
> On Fri, Nov 18, 2016 at 11:18 AM Farkas G via OL3 Dev <
ol3-dev+apn2wqefzwtgu8xmktteclxco6alow7shab3hq_itybgrgzi_1aac...@googlegroups.com>
wrote:
>>
>> 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 [email protected].
>>
>> To post to this group, send email to [email protected].
>> 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.
>
> --
> You received this message because you are subscribed to a topic in the
Google Groups "OL3 Dev" group.
> To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ol3-dev/9GSVTd8iKuM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
[email protected].
> To post to this group, send email to [email protected].
> 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/CAKdrn%2Bd5tqqbF6t--h_pnoup%3DD-ErdpvkqmbRf17WHco-a8GSw%40mail.gmail.com
.
>
> For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
To post to this group, send email to [email protected].
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/CAEDoQEHcX3z%3DunjsAX%3DMXaLz%2B4NJjH5sG16R8V0yNpCdqgyz-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
