Skip to content
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

Numerous administrative edits #160

Closed
jyutzler opened this issue Nov 18, 2015 · 1 comment
Closed

Numerous administrative edits #160

jyutzler opened this issue Nov 18, 2015 · 1 comment
Milestone

Comments

@jyutzler
Copy link
Contributor

From Carl Reed:

  1. Remove "Inc." from the Patent Call. The use of "Inc." in OGC standards stopped a couple of years ago. "Inc" was not in the Foreward in the 2014 edited version. Inc was in the Patent Call. In the published version, the Foreward was removed and the Patent call clause was kept.
  2. Remove the duplicate paragraph from the introduction. The paragraph starts with, "This OGC Encoding Standard . . .". The words are the same as in the abstract.
  3. I would suggest changing the first sentence in the Abstract. I have been struggling with the wording. The standard actually specifies SQLite rules and extensions that allow the creation and use of a container we call a GeoPackage. I will think some more about this.
  4. In section 1.1.1. change GeoPackage specification to "GeoPackage standard"
  5. Observation: Requirement 2 will need to be more generalized if and when there is a new version (1.1, 1.2, 2.0).
  6. Requirement 4. Suggesting changing sentence, "SQLite databases that use constructs from the GeoPackage specification but extend that to contain any of these elements are referred to as Extended GeoPackages throughout this specification." to "SQLite databases that use constructs from the GeoPackage standard but extend those constructs to contain elements not specified in the core GepPackage standard are referred to as Extended GeoPackages throughout this standard."
  7. A general suggestion. All the footnote references are at the end of the entire document. This makes navigation a bit of a pain at times. Perhaps informative clarifications should simply be embedded in the main text and not a footnote. And references to external documents should also just be links to the document and not included in a footnote. An example would be for Requirement 6 and 7. Instead of having the reader jump to footnote 4 at the end of the document, simply put that text in the main document. I would also add an informative statement and reference/link; e.g. "The PRAGMA statement is an SQL extension specific to SQLite and used to modify the operation of the SQLite library or to query the SQLite library for internal (non-table) data. (https://www.sqlite.org/pragma.html)"
  8. Observation: In requirement 11, "Cartesian coordinate reference systems" and "geographic coordinate reference systems" are not defined.
  9. Section 2.1.1 - "International specifications" should be "International standards". Whether the OGC document says "spec" or not, the references are ISO standards.
  10. Section 2.1. - "closed topology". I think you need a definition. When I quickly think of closure, I think of a closed polygon boundary. However, in topology, "closure of a subset S in a topological space consists of all points in S plus the limit points of S". Now this will mean about absolute nothing to the average reader. Perhaps a link to a reference or some English words?
  11. Section 2.2.1 - The sentence/paragraph " Unfortunately, no applicable existing consensus, national or international specifications have standardized practices in this domain." may need to be changed when DGGS becomes an OGC standard.
  12. Requirement 45: Expand WMTS to Web Map Tile Service as this is the first instance.
  13. Table 13. The term "glob" suddenly appears. I had to look that one up. Perhaps definition somewhere? http://man7.org/linux/man-pages/man7/glob.7.html
  14. Section 2.5.1 (sort of) to a few OGC staff and members, the GeoPackage Extension template(s) cannot be normative as they have never been independently presented, discussed, and approved by the OGC Membership. I would suspect that the majority of Members who voted on the document never saw the extension templates. This is actually my fault. I should have caught this back in early 2014. As TC Chair, I would have raised a red flag at that time and asked that the templates be presented at a DocTeam SC meeting and then go through a formal OGC vetting process. Individual SWGs should not be defining document templates. The can make recommendations.
  15. Extensions. Perhaps the extensions should be in a separate document.
@jyutzler
Copy link
Contributor Author

11 - No action at this time?
13 - see #159
14 - what is the corrective action here?
15 - see #132
The rest of these look to me like friendly administrative edits. I'll throw together a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant