Deprecate Extensions F.2, F.4, and F.5

[jyutzler]

The SWG has determined that these extensions are fundamentally not interoperable and should be removed from the document.

• http://www.geopackage.org/spec/#extension_geometry_encoding
• http://www.geopackage.org/spec/#extension_geometry_type_triggers
• http://www.geopackage.org/spec/#extension_geometry_srsid_triggers

[cclark1984]

It is our suggestion that the Geometry Encoding Extension be removed from the specification for the following reasons

• The geometry encoding is not specified in the extension and therefore a supplemental document explaining the encoding would be required. In the absence of this document, there is no way for an application developer to support this extension and therefore it is not interoperable.
• Multiple developers could implement the encoding of a new, but similar geometry type such as EllipiticalCurve in different ways.
• Existing spatial functions will not work with the new geometry types and could potentially cause errors or skip data if used.

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.

[pepijnve]

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.
How implementations deal with these is implementation dependent. Straightforward choices are ignoring non-standard geometry or reporting an error.

[jyutzler]

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.

[pepijnve]

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.

[jyutzler]

http://ogc.standardstracker.org/show_request.cgi?id=391