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

jyutzler opened this Issue Aug 2, 2016 · 5 comments


None yet
3 participants

jyutzler commented Aug 2, 2016

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

@jyutzler jyutzler added this to the post-1.1 milestone Aug 2, 2016

@jyutzler jyutzler referenced this issue Aug 2, 2016


Add some ATS tests #193

3 of 4 tasks complete

This comment has been minimized.


cclark1984 commented Aug 23, 2016

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.


This comment has been minimized.


pepijnve commented Aug 23, 2016

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.


This comment has been minimized.


jyutzler commented Aug 23, 2016

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.

jyutzler added a commit to jyutzler/geopackage that referenced this issue Aug 23, 2016

@jyutzler jyutzler referenced this issue Aug 23, 2016


Extensions #239

@jyutzler jyutzler closed this Aug 23, 2016


This comment has been minimized.


pepijnve commented Aug 24, 2016

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.


This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment