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
Deprecate Extensions F.2, F.4, and F.5 #235
Comments
It is our suggestion that the Geometry Encoding Extension be removed from the specification for the following reasons
The extensions for Geometry Type Triggers and Geometry SRS ID Triggers should also be removed from the specification, as they directly relate to User-Defined Geometry Types Extension and will no longer be required. The content contained in this extension and the related extensions would probably be better suited in a best practice document. This document could outline how to create a complete and interoperable User Defined Geometry Type Extension, which also contains the geometry encoding and deals with the issues of existing spatial functions. This would allow two independent developers to create User-Defined Geometry Type extensions that follow the same template and make it easier for clients of the extensions to adopt. |
I think there's a simple nomenclature issue here. The geometry encoding extension isn't actually a concrete extension you can implement; it's a template for user defined geometry type extensions. In other words, the suggested solution/best practice is already part of the spec. I guess the way it's worded is not very clear. The goal of this extension template was to require anyone who wanted to add an additional geometry type to follow the same pattern when doing so. The extension name needs to adhere to the given pattern, the X bit in the geometry header must be set and a 4-byte prefix must be used in front of the geometry encoding. The reason for this is that it makes it simpler for implementations that don't support a particular extended geometry extension to recognise them and deal with them accordingly. |
The bottom line is that we don't want these things in the encoding standard anymore. This isn't a guidance document and besides the information in the appendix is insufficient to implement such an extension in an interoperable way. At this point this technique hasn't even been proven as workable and in fact there is doubt that it can ever work. We are looking for someone (presumably from Luciad) to author a guidance document on how to do this properly. If and when such a document is created, we will consider it accordingly. |
Fair enough, just providing some historical thoughts on why that was in the spec in the first place. Odd that no one from Luciad spoke up about this. I seem to remember implementing an extension of this type to allow encoding of arcs and ellipses in our implementation. So unless I'm mistaken Luciad is/was actually using this internally. |
The SWG has determined that these extensions are fundamentally not interoperable and should be removed from the document.
The text was updated successfully, but these errors were encountered: