tag:blogger.com,1999:blog-38936466223633113542024-03-04T21:24:30.947-08:00GeoPackageViews from the chairman of the GeoPackage Standards Working GroupSlarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.comBlogger46125tag:blogger.com,1999:blog-3893646622363311354.post-80567446263912311652023-06-11T11:03:00.000-07:002023-06-11T11:03:12.779-07:00GeoPackage 1.4<p><span style="font-family: arial;">We are working on a minor revision to the GeoPackage Encoding Standard. We propose three <a href="https://github.com/opengeospatial/geopackage/blob/master/spec/core/release_notes/1.4.0/clause-6-substantive.adoc">substantive changes</a> to the standard.</span></p><p></p><ol style="text-align: left;"><li><span style="font-family: arial;"><b>Making DATETIME more flexible.</b> "Rules as Written," a GeoPackage <a href="https://www.geopackage.org/spec131/#table_column_data_types">DATETIME</a> must have the format </span><span style="font-family: courier;">YYYY-MM-DDTHH:MM:SS.SSSZ</span><span style="font-family: arial;">. In practice, this has proven to be unnecessarily strict. Now we will accept anything that is compatible with ISO-8601 (or its non-ISO counterpart, <a href="https://datatracker.ietf.org/doc/html/rfc3339">RFC-3339</a>) with a Zulu / UTC time zone.</span></li><li><span style="font-family: arial;"><b>Relaxing Requirement 4.</b> When GeoPackage 1.0 was published, <a href="https://www.geopackage.org/spec131/#r4">Requirement 4</a> established a distinction between "GeoPackage" (a GeoPackage with no extensions) and "Extended GeoPackage" (a GeoPackage with at least one registered extension). While there was sound reasoning for this at the time, now that the standard has been out for 9 years, extensions have proven to be essential for non-trivial operations. Meanwhile, adjudication of this requirement created test skips in the <a href="http://cite.opengeospatial.org/teamengine/about/gpkg12/1.2/site/">Executable Test Suite</a>. These skips were difficult to interpret. By relaxing this requirement, we remove the confusion.</span></li><li><span style="font-family: arial;"><b>Changing some R-Tree spatial index triggers.</b> We discovered that one of the triggers used to maintain the R-tree spatial index was incompatible with <a href="https://www.sqlite.org/lang_UPSERT.html">UPSERT</a> statements. We corrected this problem by replacing </span><span style="font-family: courier;">..._update1</span><span style="font-family: arial;"> with two new triggers, </span><span style="font-family: courier;">..._update6</span><span style="font-family: arial;"> and </span><span style="font-family: courier;">..._update7</span><span style="font-family: arial;">. By deprecating the old trigger, we make it easier for clients to determine whether the change has been applied. While we were at it, we made a similar change for the trigger that was patched as part of <a href="https://portal.ogc.org/files/18-024r1#_removing_erroneous_part_of_trigger_annex_f_3">GeoPackage 1.2.1</a>, deprecating </span><span style="font-family: courier;">..._update3</span><span style="font-family: arial;"> in favor of </span><span style="font-family: courier;">..._update5</span><span style="font-family: arial;">.</span></li></ol><div><span style="font-family: arial;">We just initiated a public comment period for this change. If all goes well, we plan to publish GeoPackage 1.4 as an adopted standard by the end of this calendar year.</span></div><p></p>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-4314453779296935242019-06-12T08:42:00.000-07:002019-06-12T09:11:26.553-07:00Introducing Application Profiles<span style="font-family: "arial" , "helvetica" , sans-serif;">Bottom Line Up Fron</span><span style="font-family: Arial, Helvetica, sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;">t: we want GeoPackage to be interoperable, but w</span><span style="font-family: "arial" , "helvetica" , sans-serif;">e are not there yet. </span><span style="background-color: white; color: #222222; orphans: 2; widows: 2;">It is not easy to achieve interoperability in an ecosystem that is extensible by design. </span></span><span style="font-family: arial, helvetica, sans-serif;">Organizations that want to be use GeoPackages from disparate sources are not having great success. We have learned important lessons from the interoperability experiments that have been conducted:</span><br />
<ul>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">GeoPackage has many degrees of freedom, including but not limited to extensions (e.g., SRSs, geometry types, tile matrix sets, tile formats, etc.)</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">conformance to the standard is no guarantee of interoperability</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">there is currently no clear way to determine whether a client will be able to fully use the information available in a particular GeoPackage</span></li>
</ul>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I propose to solve this problem by introducing application profiles to GeoPackage. An application profile would itemize all of the optional elements in use in the database. In terms of roadmap or capability evolution, I propose a set of three incremental capability levels.</span></div>
<div>
<ol>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Verbal/written agreement</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Machine-readable manifests that declare what options are in use in the GeoPackage so that a GeoPackage Client can determine whether it can be fully used</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Allowing consumers to provide a "bill of materials" with a GeoPackage production request so that the ensuing GeoPackage only uses white-listed options</span></li>
</ol>
</div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">While Capability Level 1 would be better than nothing, I do want to propose a specific approach for the machine-readable document. Last week I introduced the concept of <a href="https://geopackage.blogspot.com/2019/06/its-time-we-had-little-talkabout.html">metadata profiles</a>. Now I propose a <a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/spec/10-metadata-manifest.adoc">new metadata profile</a> (metadata scope: "manifest", reference scope: "geopackage") for a JSON document that captures this information. The working version of the JSON Schema for that document <a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/schema/manifest-schema.json">is on GitLab</a> along with a <a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/schema/manifest-opf-required.json">sample manifest document</a>.</span></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-42327563174978732382019-06-04T08:05:00.000-07:002019-06-04T08:05:50.869-07:00It's Time We Had A Little Talk...About Metadata<span style="font-family: Arial, Helvetica, sans-serif;"><i>I know this is going to make people uncomfortable, but it is time to talk about this. <u>People want to put metadata in GeoPackage.</u> It is just a fact of life. We need to be ready and that is why we are having this discussion. </i></span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">While GeoPackage has had </span><a href="http://www.geopackage.org/spec121/#extension_metadata" style="font-family: Arial, Helvetica, sans-serif;">support for metadata</a><span style="font-family: Arial, Helvetica, sans-serif;"> since its inception, I acknowledge that there is something missing. There is currently no agreement on how metadata should be used in GeoPackage to serve any particular purpose. Someone opening a GeoPackage would have no way of recognizing that the file has any particular type of metadata in it, short of inspecting every single row in the </span><span style="font-family: Courier New, Courier, monospace;">gpkg_metadata</span><span style="font-family: Arial, Helvetica, sans-serif;"> table. No way.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">I propose that we address this gap by introducing "metadata profiles" to GeoPackage. A metadata profile is an agreement on what a metadata document will look like and how it will be used in the GeoPackage. I propose to leverage the extension mechanism to express this information. This approach has two parts:</span><br />
<br />
<ol>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Introduce a <a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/spec/7-metadata-profiles.adoc">new extension</a> that defines a new extension "scope" (i.e., the </span><span style="font-family: Courier New, Courier, monospace;">gpkg_extensions.scope</span><span style="font-family: Arial, Helvetica, sans-serif;"> column) of "metadata"</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Create an extension for each metadata profile:</span></li>
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif;">using this new "metadata" extension scope</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">defining the <a href="http://www.geopackage.org/spec121/#metadata_scopes">metadata scope</a>, standard/specification, and MIME type that uniquely identify it</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">defining the reference scope ("geopackage", "table", "row", or "row/col") that it will be used for </span></li>
</ul>
</ol>
<div>
<span style="font-family: Arial, Helvetica, sans-serif;">As part of OGC's Testbed-15, I intend to explore this concept further. Here are some profiles that we are considering:</span></div>
<div>
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/spec/11-metadata-styles.adoc">Styles</a> metadata</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/spec/8-metadata-dataset-provenance.adoc">Dataset provenance</a></span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/spec/9-metadata-updates.adoc">Delta updates</a></span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><a href="https://gitlab.com/imagemattersllc/ogc-tb-15-opf/blob/master/spec/10-metadata-manifest.adoc">Manifest</a></span></li>
</ul>
<div>
<span style="font-family: Arial, Helvetica, sans-serif;">I will explore these further in subsequent blog posts.</span></div>
</div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-7419739370217593922019-05-06T12:17:00.000-07:002019-05-06T12:17:30.287-07:00Views and GeoPackage<span style="font-family: "arial" , "helvetica" , sans-serif;">From the beginning, the intent of GeoPackage was to allow views to be used (instead of tables) wherever appropriate. In general, "appropriate" means user-defined tables (features, tiles, or attributes). There is some confusion here because, for example, the <a href="http://www.geopackage.org/spec/#example_feature_table_cols">sample feature table or view definition table (Table 7)</a> and <a href="http://www.geopackage.org/spec/#_sample_feature_table_informative">sample feature table definition SQL (Annex C.4)</a> specifically call out primary keys and the notion of primary keys for view does not exist in SQLite.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">In response, the GeoPackage SWG has approved some changes designed to clarify how views should be implemented. </span><span style="font-family: arial, helvetica, sans-serif;">While implementers should use primary keys wherever as possible, Requirements </span><a href="http://www.geopackage.org/spec/#r150" style="font-family: arial, helvetica, sans-serif;">150</a><span style="font-family: arial, helvetica, sans-serif;"> (for features) and </span><a href="http://www.geopackage.org/spec/#r151" style="font-family: arial, helvetica, sans-serif;">151</a><span style="font-family: arial, helvetica, sans-serif;"> (for attributes) specify that if the database element lacks a defined primary key (i.e., it is a view), then the first column shall be primary-key-like (i.e., be a unique integer). There is a </span><a href="http://www.geopackage.org/spec/#r54" style="font-family: arial, helvetica, sans-serif;">similar note for tiles</a><span style="font-family: arial, helvetica, sans-serif;"> but no new requirement was needed there because the schema for tiles tables already requires the first column to be the ID.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Currently, these changes are available on the <a href="http://www.geopackage.org/spec">working version</a> of the standard. The working version may get published as another GeoPackage revision (1.2.2 or 1.3.0) but there is currently no timetable for doing so. One thing that we would need to do is update the </span><span style="font-family: "arial" , "helvetica" , sans-serif;"><a href="https://github.com/opengeospatial/ets-gpkg12">Executable Test Suite</a> (ETS) to have tests. (These tests would only apply to GeoPackages with a version <i>after</i> 1.2.1.) As always, i</span><span style="font-family: arial, helvetica, sans-serif;">f you have a GeoPackage that fails the ETS and you believe the ETS is in error, please let us know.</span><span style="font-family: arial, helvetica, sans-serif;"> </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">P.S. Some of you in the community have asked about updatable views. It is theoretically possible to do this with a combination of tables and triggers but I don't recommend it. </span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-28347634559898339372019-02-20T07:11:00.001-08:002019-02-20T07:16:25.315-08:00The Vector Tiles Pilot<span style="font-family: "arial" , "helvetica" , sans-serif;">Last year, I <a href="https://geopackage.blogspot.com/2018/06/what-about-vector-tiles-in-geopackage.html">posted regarding vector tiles</a>. I am pleased to announce that I have much more to report on this front. For the last six months, OGC has been sponsoring the <a href="https://www.opengeospatial.org/projects/initiatives/vt-pilot-2018">Vector Tiles Pilot</a> (VTP). The purpose of the VTP was to investigate how vector tiles (or tiled feature data, if you will) in the <a href="https://docs.mapbox.com/vector-tiles/specification/">Mapbox Vector Tiles</a> (MVT) and <a href="https://tools.ietf.org/html/rfc7946">GeoJSON </a>formats can be supported through the OGC standards baseline, particularly Web Feature Server (WFS), Web Map Tile Server (WMTS), and GeoPackage (GPKG). </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">The initial effort concluded late last year and culminated in <a href="https://www.youtube.com/playlist?list=PLQsQNjNIDU84lBvF_QTyIz4gn_ne231EJ">some videos</a> and the following Engineering Reports (ERs):</span><br />
<ul>
<li><span style="border: 0px; color: black; font-family: "arial" , "helvetica" , sans-serif; margin: 0px; padding: 0px; vertical-align: baseline;"><a href="https://docs.opengeospatial.org/per/18-086r1.html" rel="noopener noreferrer" style="border: 0px; color: black; margin: 0px; padding: 0px; vertical-align: baseline;" target="_blank">OGC Vector Tiles Pilot: Summary Engineering Report</a></span></li>
<li><a href="https://docs.opengeospatial.org/per/18-074.html" style="font-family: Arial, Helvetica, sans-serif;">OGC Vector Tiles Pilot: GeoPackage 1.2 Vector Tiles Extensions Engineering Report</a></li>
<li><a href="https://docs.opengeospatial.org/per/18-076.html" style="font-family: Arial, Helvetica, sans-serif;">OGC Vector Tiles Pilot: Tiled Feature Data Conceptual Model Engineering Report</a></li>
<li><a href="https://docs.opengeospatial.org/per/18-083.html" style="font-family: Arial, Helvetica, sans-serif;">OGC Vector Tiles Pilot: WMTS Vector Tiles Extension Engineering Report</a></li>
<li><a href="https://docs.opengeospatial.org/per/18-078.html" style="font-family: Arial, Helvetica, sans-serif;">OGC Vector Tiles Pilot: WFS 3.0 Vector Tiles Extension Engineering Report</a><span style="font-family: "arial" , "helvetica" , sans-serif;"></span></li>
</ul>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Following the completion of the VTP, the sponsors funded an extension to the pilot (the <i>Vector Tiles Pilot Extension</i> or <i>VTPExt</i>) to take a closer look at styling of the ensuing feature data using the <a href="https://docs.mapbox.com/mapbox-gl-js/style-spec/">Mapbox Styles</a> and <a href="https://www.opengeospatial.org/standards/sld/">Styled Layer Descriptor</a> (SLD) encodings. This effort concluded last week and the resulting videos have been <a href="https://www.youtube.com/playlist?list=PLQsQNjNIDU86fv8nJP0KT9C81ZbwvldWO">posted to YouTube</a>. The ER is under review now (OGC members can access the <a href="https://portal.opengeospatial.org/files/?artifact_id=82831&version=1">current draft</a>) and should be published in the next month or two.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">From the GeoPackage perspective, the Vector Tiles Pilot allowed us to try out a series of GeoPackage Extensions:</span></div>
<div>
<ul>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Tiled Feature Data: allowing tiled feature to be stored using the <i>tiles</i> mechanism</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Mapbox Vector Tiles: allowing tiles to contain MVT</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">GeoJSON Vector Tiles: allowing tiles to contain GeoJSON</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Styles: allowing styles documents (e.g., Mapbox Styles, SLD, or others) to be stored in a way that is loosely coupled with feature data (tiled or otherwise)</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">OWS Context: allowing for <a href="http://www.owscontext.org/">OWS Context</a> information to be stored (while we have an agreement in principle here, we did not have time to test it out)</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Vector Tiles Attributes: allowing for attributes to be stored in attributes tables instead of in the vector tiles to support better querying (this topic is very complex and we did not actually reach a consensus here)</span></li>
</ul>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">While these extensions were introduced in the ER linked above, they were further refined during the VTPExt. It is on my TODO list to add them to the <a href="http://www.geopackage.org/extensions.html">GeoPackage Extensions Page</a>. The next step is to present this information to the GeoPackage Standards Working Group (SWG) and to propose the extensions as <a href="https://geopackage.blogspot.com/2015/09/core-and-extensions-model.html">candidate standards</a>. I believe we have a clear use case and a sound technical approach. If the SWG agrees and there is a commitment to implementation, we may have an adopted standard later this year.</span></div>
</div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-36449420052016460322019-02-19T09:05:00.001-08:002019-02-21T13:20:31.119-08:00GeoPackage Executable Test Suite<span style="font-family: Arial, Helvetica, sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;">I have an update to <a href="https://geopackage.blogspot.com/2017/02/filling-gap-conformance-tests.html">my previous post</a> regarding conformance testing. OGC has recently approved and released the <a href="http://cite.opengeospatial.org/teamengine/about/gpkg12/1.2/site/">Executable Test Suite (ETS) for GeoPackage 1.2</a>. This tool allows for the testing of individual GeoPackages to verify conformance and identify any non-compliant elemen</span>ts. Organizations can <a href="http://www.opengeospatial.org/compliance/getCertified">get OGC certified</a> if they pass the test. The suite works on all GeoPackage versions from 1.0 to 1.2.1 - it will detect the GeoPackage version and alter the test requirements where appropriate. The test supports the following components:</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"></span><br />
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;">Core</span></span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Features</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Tiles</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Attributes</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Extension Mechanism</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Non-Linear Geometry Types</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">RTree Spatial Indexes</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Tiles Encoding WebP</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Metadata</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Schema</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">WKT for Coordinate Reference Systems</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">Tiled Gridded Coverage Data</span></li>
</ul>
<div>
<span style="font-family: Arial, Helvetica, sans-serif;">There are two ways to run the ETS:</span><br />
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;">If you have a GeoPackage that you want to test, go to the </span><a href="http://cite.opengeospatial.org/teamengine/">OGC Validation Website</a><span style="font-family: Arial, Helvetica, sans-serif;">. From there, you can sign in (creating an account first if needed) and create a new session. Then you can select GeoPackage 1.2 from the standard list, provide your GeoPackage (by URL or as a file upload), and run the test. The tool will provide a report indicating tests that passed, failed, or were skipped.</span></span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">If you want to run the test suite locally or contribute to its development, see the <a href="https://github.com/opengeospatial/ets-gpkg12">GitHub Repository</a>. There are instructions for compiling and running the tool locally.</span></li>
</ul>
<div>
<span style="font-family: Arial, Helvetica, sans-serif;">I recommend the ETS for anyone who plans to use GeoPackage in an operational setting, particularly when interoperability with other GeoPackage implementations is desired. Produce a GeoPackage that is representative of your operational use, run it through the ETS, and make verify that it is compliant. That's all there is to it!</span></div>
</div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-12508737422859671822019-01-28T13:07:00.002-08:002019-02-04T07:56:24.892-08:00Versioning of Extensions?<span style="font-family: "arial" , "helvetica" , sans-serif;">The GeoPackage <a href="http://www.geopackage.org/spec/#extension_mechanism">Extension Mechanism</a> gives stakeholders a way to add GeoPackage capabilities in a way that minimizes interoperability risks to systems that do not understand the extension. From my perspective, if different implementers are going to implement similar capabilities, then I want them to implement in the same way. That is the whole point of interoperability. The theory is that a client that does not understand an extension will ignore the data. I believe that the extension mechanism is a GeoPackage strength.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">The GeoPackage Standards Working Group has two questions for the community:</span><br />
<ol>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Is the extension mechanism working the way we want it to? Are we getting new capabilities? Are we getting the interoperability we are looking for?</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">What should we do if an OGC-adopted extension has to change? </span></li>
<ul>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">We are leery of adding a "version" column to </span><span style="font-family: "courier new" , "courier" , monospace;">gpkg_extensions</span><span style="font-family: "arial" , "helvetica" , sans-serif;"> because GeoPackage clients that only understand version 1.2 or prior wouldn't even know about it. It is borderline whether this is a breaking change.</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">An alternative that has some backing is to allow extensions to evolve as long as the changes are non-breaking but to force an extension to take a new name if the changes are breaking. </span></li>
</ul>
</ol>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">We would like to get positive answers to these questions because there are a number of initiatives going on that have the potential to add a number of new adopted extensions. Do we need to pivot? I believe the answer is "no" but it is possible I am too close to the situation to make a fair assessment.</span></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-73909881247097508022018-06-27T11:52:00.000-07:002019-01-28T12:50:45.198-08:00What About Vector Tiles in GeoPackage?<span style="font-family: "arial" , "helvetica" , sans-serif;">I periodically get questions about whether GeoPackage can/will/should support vector tiles. Without getting into the benefits or drawbacks of vector tiles, let's just say it is an emerging capability that is getting a lot of community interest. As it turns out, supporting vector tiles in GeoPackage is the easy part. We already have a precedent for handling types other than features and raster tiles - the <a href="http://docs.opengeospatial.org/is/17-066r1/17-066r1.html">tiled gridded coverage extension</a>.<br /><br />The real issue is that OGC has not yet adopted an approach for vector tiling. What is the content encoding for a vector tile? Is it Protocol Buffers (as per <a href="https://github.com/mapbox/vector-tile-spec/tree/master/2.1#4-internal-structure">Mapbox Vector Tiles</a> - MVT)? GeoJSON? Something else? OGC members are reluctant to support a vector tiling approach that is only used with GeoPackage. (Supporting one-off solutions often has a poor cost-benefit story.) OGC simply needs to make a decision and a <a href="http://www.opengeospatial.org/standards/community">community standard</a> would suffice.<br /><br />Once OGC makes a decision, it is a straightforward matter to support it in GeoPackage. We would create a new <a href="http://www.geopackage.org/guidance/getting-started.html#extensions">extension</a> that would define a new content type that depends on the tiles option. I don't think there would be any other ancillary tables like were needed for tiled gridded coverages, but if there are we can add those. This would get us to a <a href="http://www.geopackage.org/extensions.html">community extension</a> which will satisfy some people. If we want an official (OGC adopted) extension then we have to go through the normal process of OAB approval, open comment period, TC vote, etc. This process will probably go smoothly as long as we have proof of implementation.<br /><br /> UPDATE: After talking with a few people, I went ahead and drafted a <a href="https://github.com/jyutzler/geopackage-vector-tiles/blob/master/spec/1_vector_tiles.adoc">community extension</a> based on the MVT approach.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">UPDATE #2: In response to this issue, OGC initiated the <a href="http://www.opengeospatial.org/projects/initiatives/vt-pilot-2018">Vector Tiles Pilot</a>.</span><br />
<div style="background-color: white; color: #222222;">
<span style="font-family: "arial" , "helvetica" , sans-serif;"></span></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-8002917548712735492018-06-20T08:39:00.000-07:002018-07-17T06:47:43.834-07:00We Want Your (Technical) Feedback<span style="font-family: "arial" , "helvetica" , sans-serif;">Earlier this month, GeoPackage 1.2.1 (a corrigendum release) was approved by the OGC Technical Committee. In this release, we focused on clarifications and consistency.</span><span style="font-family: "arial" , "helvetica" , sans-serif;"> </span><span style="font-family: "arial" , "helvetica" , sans-serif;">Look for publication and formal announcement soon. Until this occurs, you can review the <a href="https://portal.opengeospatial.org/files/?artifact_id=79189&version=1">release notes</a>.</span><span style="font-family: "arial" , "helvetica" , sans-serif;"> </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I thought things would slow down after this but I was wrong. There has been a bunch of testing related to the <a href="http://www.opengeospatial.org/projects/initiatives/geoedgeplugfest">Geospatial to the Edge Plugfest</a> and this testing has revealed some areas of the standard that need to be refined. Some of these things are quite technical and I would like to get community feedback before we do anything rash. </span><span style="font-family: "arial" , "helvetica" , sans-serif;">The following items have GitHub issues and corresponding pull requests. <b>Please let us know if you think we are doing something wrong or if we can do better.</b></span><br />
<br />
<ol>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><a href="https://github.com/opengeospatial/geopackage/issues/446">Support for views</a>. We've said for the beginning that GeoPackage is supposed to support views where appropriate. We clarified this as part of version <a href="https://github.com/opengeospatial/geopackage/issues/301">1.2.0</a> and <a href="https://github.com/opengeospatial/geopackage/issues/395">1.2.1</a> but we need to do more because of our requirement for primary keys on user defined tables. The concept of primary keys does not exist for views in SQLite so we are now proposing that if there is no primary key column, then the first column must be primary-key-like, containing unique integers.<br /><i>Update: a competing approach would add a column to "gpkg_contents" to name the primary key column for a particular set of contents. I like this idea (more easily discoverable) but it may be too late to add even an optional column to that table.</i></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;"><a href="https://github.com/opengeospatial/geopackage/issues/444">Enforcing alignment between the CRSs</a> in gpkg_contents, gpkg_geometry_columns, and gpkg_tile_matrix_set. I do not see how a GeoPackage can possibly be interoperable when the CRSs are not in alignment (how would a client decide which one to pick?) and I don't think anyone is doing this now, but since the question has come up more than once, we are taking the opportunity to tighten things up.<br /><i>Update: this issue was resolved.</i></span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Ensuring that <a href="https://github.com/opengeospatial/geopackage/issues/443">feature geometries fall within the extents</a> in the Well Known Binary (WKB) values. These extents are used as an optimization for spatial querying and indexing. If they are not valid (which is apparently happening on occasion), incorrect results will be returned.<br /><i>Update: This is still being discussed.</i></span></li>
</ol>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Since we are introducing new requirements as part of these changes, they are penciled in as part of a possible 1.3.0 release. We have no timeline for when this might occur but figure some time in 2019. As always, remain committed to maintaining reverse compatibility as much as possible. We will continue to avoid introducing requirements that have the potential to break existing GeoPackages unless those GeoPackages couldn't possibly work as designed.</span></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com2tag:blogger.com,1999:blog-3893646622363311354.post-58456663156166258662018-06-01T12:51:00.002-07:002018-06-01T12:51:38.460-07:00Where We Are with Feature Styling and Portrayal<div style="background-color: white; color: #222222; font-size: 12.8px;">
<span style="font-family: Arial, Helvetica, sans-serif;">The GeoPackage SWG is very interested in solving the portrayal issue - how to encode style/symbology for GeoPackage feature data so that it can be portrayed or rendered in a client application. It is the #1 thing I hear about and I am committed to getting there. While proprietary solutions exist, we want something that will be interoperable. It is just taking a while and we need to be patient because there are a lot of moving parts. </span></div>
<div style="background-color: white; color: #222222; font-size: 12.8px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="background-color: white; color: #222222; font-size: 12.8px;">
<span style="font-family: Arial, Helvetica, sans-serif;">SWG members have asked for three things in a candidate solution:</span></div>
<div style="background-color: white; color: #222222; font-size: 12.8px;">
<ol>
<li style="margin-left: 15px;"><span style="font-family: Arial, Helvetica, sans-serif;">SQL table-based (since GeoPackage is an SQLite encoding)</span></li>
<li style="margin-left: 15px;"><span style="font-family: Arial, Helvetica, sans-serif;">Consistent across the OGC baseline (so that implementers can build a single basic approach for the baseline, as opposed to a GeoPackage-specific implementation)</span></li>
<li style="margin-left: 15px;"><span style="font-family: Arial, Helvetica, sans-serif;">Loose coupling of the features and their styles (unlike KML, for example)</span></li>
</ol>
</div>
<div style="background-color: white; color: #222222; font-size: 12.8px;">
<span style="font-family: Arial, Helvetica, sans-serif;">OGC hasn't nailed down a solution for #1 and #2 yet, but it is in progress. The Styled Layer Descriptor SWG has awoken from its decade-long slumber and is in the process of producing a v2 which is basically a total rewrite. In this version, they will implement a core and extensions model and support multiple encodings, resolving two major gaps in the original version. I was one of the contributors to a document called the Portrayal Concept Development Study Engineering Report which discusses these concepts in great detail. I hope for this document to be published in the next month or so. This will also be a hot topic at the <a href="http://www.ogcmeet.org/">OGC Technical Committee meetings</a> in Ft. Collins next week.</span></div>
<div style="background-color: white; color: #222222; font-size: 12.8px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="background-color: white; color: #222222; font-size: 12.8px;">
<span style="font-family: Arial, Helvetica, sans-serif;">To address #3, I believe the way to go is to harmonize GeoPackage and <a href="http://www.owscontext.org/">OWS Context</a> so that the two work seamlessly with each other. I have written a discussion paper on the topic. I will present this paper to the GeoPackage SWG next week and if all goes well, it will be published by OGC later this month. I believe the concept is ready to go except for the style encoding. Once that is resolved, we should be able to standardize this pretty quickly. By the way, as far as I know, this would be the first time OGC adopts a standard that is an extension for two different standards simultaneously.</span></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-54296421670926978172018-03-27T10:28:00.001-07:002018-03-27T10:28:54.777-07:00Where We Are with GeoPackage Extensions<span style="font-family: Arial, Helvetica, sans-serif;">A few weeks ago, GeoPackage achieved a new milestone when OGC adopted "OGC GeoPackage Extension for Tiled Gridded Coverage Data" (<a href="http://docs.opengeospatial.org/is/17-066r1/17-066r1.html">http://docs.opengeospatial.org/is/17-066r1/17-066r1.html</a>). This is the first time OGC has adopted a GeoPackage extension outside of the encoding standard itself. We did this because we wanted the flexibility to create and revise the standard at our own pace without being constrained with the release schedule of the core standard (or vice versa).</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">What does this mean with regards to OGC compliance? By definition, a GeoPackage may contain extensions along with tiles, features, and attributes. An OGC-compliant GeoPackage is one that contains OGC-adopted extensions. The encoding standard itself currently has seven extensions (three of the original ten were later deprecated) and this new one is the eighth. They all have equal footing and the upcoming minor revision of the GeoPackage Executable Test Suite will include tests for all of them.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">If OGC compliance isn't important to you, that's fine too. The extension mechanism is your friend. Use the </span><span style="font-family: Courier New, Courier, monospace;">gpkg_extensions</span><span style="font-family: Arial, Helvetica, sans-serif;"> table to advertise what extensions you are using (OGC-adopted or otherwise) and let client applications inspect the table and adjust their capabilities accordingly.</span><span style="font-family: Arial, Helvetica, sans-serif;"> </span><span style="font-family: Arial, Helvetica, sans-serif;">You are always free to include non-adopted extensions in your GeoPackages too (no one is going to stop you) but OGC is unable to verify foreign extensions so there is no guarantee that they are fit for any particular purpose or that they will not cause compatibility issues with other software.</span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-23090950489047261112017-11-22T18:25:00.000-08:002017-11-22T18:27:13.634-08:00My Halloween Homage to Shapefile and Johnny Rotten<span style="font-family: "arial" , "helvetica" , sans-serif;">It is part of punk rock lore that in 1975 a young John Lydon turned some heads with an "I Hate Pink Floyd" shirt. He took a normal band t-shirt, scratched out the members' eyes, and scrawled his message on top with a marker. Soon he was invited to join a punk band (which then named itself the Sex Pistols) and took the name Johnny Rotten. And the rest is history.</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1xD9IP3Bw7gHsbaQJ4EsnvTvm5ZDmaxgkk3t_S12Khd5BZNgfbT4Pc_FWlDA-OrAGA1w2AR1kuOz5kd5L7GG_TF_pdTUqEE7ikB3eOCl-CK0uqsqgiN1jkoDygIJnagVMi_vRRn98NcQ/s1600/20171102_215119.jpg" imageanchor="1" style="margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="1600" data-original-width="900" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1xD9IP3Bw7gHsbaQJ4EsnvTvm5ZDmaxgkk3t_S12Khd5BZNgfbT4Pc_FWlDA-OrAGA1w2AR1kuOz5kd5L7GG_TF_pdTUqEE7ikB3eOCl-CK0uqsqgiN1jkoDygIJnagVMi_vRRn98NcQ/s320/20171102_215119.jpg" width="180" /></a>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIUcEuj60W37W61WWIe9DiTELh8QjP6eWhQFMYVFm8oCvfKjatpPNnr2irZ9-eEonBRiqr1Bjb-3paAwY7XC53K2m38Weiz8kEOKXGqKvOaLcIXB3Em5xFJT6RGJCpT621kCBjPa-seJ4/s1600/20171102_215147.jpg" imageanchor="1" style="margin-bottom: 1em; margin-left: 1em;"> </a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIUcEuj60W37W61WWIe9DiTELh8QjP6eWhQFMYVFm8oCvfKjatpPNnr2irZ9-eEonBRiqr1Bjb-3paAwY7XC53K2m38Weiz8kEOKXGqKvOaLcIXB3Em5xFJT6RGJCpT621kCBjPa-seJ4/s1600/20171102_215147.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"> </a>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIUcEuj60W37W61WWIe9DiTELh8QjP6eWhQFMYVFm8oCvfKjatpPNnr2irZ9-eEonBRiqr1Bjb-3paAwY7XC53K2m38Weiz8kEOKXGqKvOaLcIXB3Em5xFJT6RGJCpT621kCBjPa-seJ4/s1600/20171102_215147.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1600" data-original-width="900" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIUcEuj60W37W61WWIe9DiTELh8QjP6eWhQFMYVFm8oCvfKjatpPNnr2irZ9-eEonBRiqr1Bjb-3paAwY7XC53K2m38Weiz8kEOKXGqKvOaLcIXB3Em5xFJT6RGJCpT621kCBjPa-seJ4/s320/20171102_215147.jpg" width="180" /></a></div>
<br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">Meanwhile back in the geo world, there has been a lot of back and forth about <a href="https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf">Shapefiles</a>. The industry definitely has a love-hate relationship with them. On one hand they are indispensable but on the other hand there are a lot of people who want to <a href="http://switchfromshapefile.org/">banish them</a>. Then there is the occasionally funny, occasionally annoying <a href="https://twitter.com/shapefiIe">@shapefile</a> on Twitter. When I saw two <a href="https://www.redbubble.com/people/ianturton/works/28323389-help-ban-the-trade-in-shapefiles?grid_pos=1&p=sticker&rbs=8eccf1d6-759c-4e5e-9cdf-255dcb005c7f&ref=shop_grid">opposing</a> <a href="https://www.redbubble.com/people/atanasentchev/works/28314623-i-3-shp-the-vinyl-of-geo">items</a> on Redbubble, my idea for a Halloween costume was born. All I needed was some markers, safety pins, hair spray, and blue hair dye.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">The dirty little secret is that Lydon was actually a Pink Floyd fan—his shirt was more of a publicity stunt than a statement of opinion. Likewise, I can't help but have respect for the humble data format. Shapefiles are an important part of geo history and are for all intents and purposes the first interoperability the industry has achieved. While they have their limitations and probably are not the ideal format for many modern applications, they have enabled a lot of successful activities over the years and will continue to do so for many more.</span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-17638346384166612912017-11-22T11:12:00.000-08:002017-11-22T14:15:11.444-08:00Three November Updates<span style="font-family: "arial" , "helvetica" , sans-serif;">I have three GeoPackage-related updates for you. First of all, the GeoPackage SWG has wrapped up its work on the <a href="http://www.geopackage.org/17-066r1.html">Tiled, Gridded Coverage Extension</a> (formerly the elevation extension[1]). Look for OGC to make a press release soon. There will be an open comment period followed by an adoption vote (probably electronic) by the OGC Technical Committee. Of course if you have any comments, you do not have to wait until the press release. You can go directly to the <a href="https://github.com/opengeospatial/geopackage-tiled-gridded-coverage">GitHub repository</a> and open an issue from there.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Second, you may have noticed a slight change to the <a href="http://geopackage.org/">geopackage.org</a> page. We now have separate links to the <a href="http://www.geopackage.org/spec120">adopted version of the standard</a> and the <a href="http://www.geopackage.org/spec">working version</a> on the top right. We have made a few administrative changes[2] that we want to get into the public eye even though they are not yet part of an approved document. These are now incorporated to the working version which is tentatively titled 1.3_SNAPSHOT.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">There is a third development that will affect the standard, though it should not directly affect implementers. OGC is developing a Tile Matrix Set Encoding Standard[3]. This document extracts the TileMatrixSet definition from Web Map Tile Service (WMTS) and makes it a independent document designed to be referenced by other standards such as GeoPackage. If OGC adopts this standard, we will update the GeoPackage standard to bring them into alignment. I don't have a timeline for any of this, but whenever this work is complete we will probably release it as GeoPackage 1.3.</span><br />
<br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">Happy Thanksgiving!</span><br />
<br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">[1] For a recap of this topic, see paragraphs 2 and 3 of <a href="http://geopackage.blogspot.com/2017/05/good-news-bad-news.html">http://geopackage.blogspot.com/2017/05/good-news-bad-news.html</a></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">[2] See <a href="https://github.com/opengeospatial/geopackage/pull/387">https://github.com/opengeospatial/geopackage/pull/387</a>, <a href="https://github.com/opengeospatial/geopackage/pull/392">https://github.com/opengeospatial/geopackage/pull/392</a>, and <a href="https://github.com/opengeospatial/geopackage/pull/394">https://github.com/opengeospatial/geopackage/pull/394</a> </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">[3] The working version of this draft standard, available to OGC members, is here: <a href="https://portal.opengeospatial.org/files/?artifact_id=76617">https://portal.opengeospatial.org/files/?artifact_id=76617</a>. </span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-38697618447272593292017-09-20T20:40:00.000-07:002017-09-20T20:40:28.430-07:00More on SLD and SE<div style="-webkit-text-stroke-width: 0px; background-color: white; color: #222222; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><a data-saferedirecturl="https://www.google.com/url?hl=en&q=http://www.opengeospatial.org/standards/sld&source=gmail&ust=1505574206439000&usg=AFQjCNHLKDjBIzVRSzA1Jw8cFID1P0J3_Q" href="http://www.opengeospatial.org/standards/sld" style="color: #1155cc;" target="_blank">Styled Layer Descriptor</a> (SLD) and<span> </span><a data-saferedirecturl="https://www.google.com/url?hl=en&q=http://www.opengeospatial.org/standards/se&source=gmail&ust=1505574206439000&usg=AFQjCNEBXzdf4gW3X-X1wnwxQpOq0lmk7A" href="http://www.opengeospatial.org/standards/se" style="color: #1155cc;" target="_blank">Symbology Encoding</a><span> </span>(SE) are two related OGC standards. They have been around for over a decade but I think we can safely say that they have not definitively met their primary purpose - to enable the portrayal of feature data in an interoperable way. The most common complaint with these standards boils down to one thing - a high barrier to entry. This manifests itself in a few ways:</span></span></div>
<div style="-webkit-text-stroke-width: 0px; background-color: white; color: #222222; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
<ol>
<li style="margin-left: 15px;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">SLD and SE are XML encodings. While many server-side developers are comfortable dealing with XML, this only represents a small fraction of the market these days. Most developers want nothing to do with XML if they can help it. JSON is a more natural choice for web applications, mobile applications, and many server-side frameworks. CSS is comfortable for many front-end developers. SQL developers (think GeoPackage) want to be working with SQL predominantly. A way past this issue would be to produce a conceptual model that could then be implemented in formats more appropriate for the target environment. The conceptual model could then be implemented a fairly small number of times and then abstracted for the various encodings.</span></span></li>
<li style="margin-left: 15px;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">SLD and SE are fairly complicated. The documents are long and intimidating and compliance is an all-or-nothing affair. It would be helpful to have something akin to "Simple Features" for SLD and SE - a core that only covers the most important and common options. Like most things in software development, the Pareto Principle applies.</span></span></li>
<li style="margin-left: 15px;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Tools are lacking. There is currently no public executable test suite for the two standards. While GeoServer's SLD and SE support are pretty robust, alternatives are pretty hit-or-miss. If we want people to use these standards, we need the tools that make them easy to use.</span></span></li>
</ol>
</div>
<div style="-webkit-text-stroke-width: 0px; background-color: white; color: #222222; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">On the flip side, SLD and SE also suffer from a lack of extensibility. There are use cases that cannot be handled by SLD and SE out of the box[1] and without an extension mechanism, there is no clear way for a developer to introduce interoperable solutions. This means that complex portrayals (think MIL-STD-2525) are a non-starter.</span></span></div>
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br /></span></span></div>
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">When a solution is not ideal for either the low end (lots of potential users) or the high end (lots of potential funding), all that is left is the skinny middle and it isn't enough. This is solvable if we have the will. That phrase is key - if we have the will[2]. The solution is not going to fall from the sky. It is going to take effort and leadership from a number of organizations over the course of more than a year. OGC appears to be willing to take the lead here but the effort requires community support to be successful. There will be opportunities to participate and I hope that you will find a way to do so. </span></span></div>
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br /></span></span></div>
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">[1] The "<a data-saferedirecturl="https://www.google.com/url?hl=en&q=http://portal.opengeospatial.org/files/?artifact_id%3D29160&source=gmail&ust=1505574206439000&usg=AFQjCNHCmKIxoKlytJ_zym-joNnViEe_SA" href="http://portal.opengeospatial.org/files/?artifact_id=29160" style="color: #1155cc;" target="_blank">TENET report</a>" enumerates several limitations of the OGC SE, including hierarchical symbols, multiple delineations, and pivot points.</span></span></div>
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"> </span></span></div>
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">[2] Total tangent here. I first drafted this post on 9/13/17 and happened to include this phrase which comes from a Grant Hart <a href="http://www.allmusic.com/album/the-argument-mw0002545730">song of the same name</a>. That very night he passed away (unexpectedly, at least to me). RIP Grant. </span></span></div>
</div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-78567731805928530472017-09-12T06:49:00.002-07:002017-09-12T06:49:46.775-07:00Improving geopackage.org<span style="font-family: Arial,Helvetica,sans-serif;">Part of my job as GeoPackage SWG Chair is to improve outreach. This includes disseminating information (like this blog post) but it also means making information easier to discover. I feel good about the state of the specification / encoding standard but our outreach leaves room for improvement. One potential area of improvement is our website, <a href="http://geopackage.org/">geopackage.org</a>. It is okay but it could be much better.</span><br />
<span style="font-family: Arial,Helvetica,sans-serif;"><br /></span>
<span style="font-family: Arial,Helvetica,sans-serif;">Over the next few months, I intend to revamp this site to make it more useful for its target audiences. When a visitor reaches the site, it should be self-evident where to go for relevant information. We're not there today. In response, I plan to reorganize the content to align it by reader type: general, developer, administrator, data publisher, data consumer, and SWG participant.</span><br />
<span style="font-family: Arial,Helvetica,sans-serif;"><br /></span>
<span style="font-family: Arial,Helvetica,sans-serif;">For this to work, I need more input from the user community. For example, a <a href="http://geopackage.org/">geopackage.org</a> reader may wish to learn not only what GPKG implementations are out there but what they are useful for. Therefor I will be reaching out to vendors to clarify the role of the software that is currently listed under <a href="http://www.geopackage.org/implementations.html">http://www.geopackage.org/implementations.html</a>. I am also going to solicit user guides and demonstrations that can be incorporated into the site. This content can describe FOSS or proprietary software; my goal is to inform and to present options to the community.</span><br />
<span style="font-family: Arial,Helvetica,sans-serif;"><br /></span>
<span style="font-family: Arial,Helvetica,sans-serif;">If you can help me out here, I want to know about it.</span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-12271186853384507242017-09-01T09:11:00.003-07:002017-09-05T06:29:37.836-07:00A Busy Time at GeoPackage<span style="font-family: "arial" , "helvetica" , sans-serif;">Things have been busy on the GeoPackage front. I sense an uptick in both interest and adoption of GeoPackage. FOSS4G was the most public example but there have been others. With this in mind, I would like to share three recent developments</span><span style="font-family: "arial" , "helvetica" , sans-serif;">. It is a busy time at GeoPackage!</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">1. GeoPackage 1.2 has been formally adopted by OGC. The <a href="http://www.opengeospatial.org/standards/geopackage">OGC standards page</a> has the "official" PDF version of the document (<i>edit: and now the release notes</i>) and the HTML version is what is currently at <a href="http://geopackage.org/spec">geopackage.org/spec</a>. Thanks go to the large number of people who made this release possible.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br />2. OGC has released "OGC GeoPackage Extension for Tiled Gridded Coverage Data" for <a href="http://www.opengeospatial.org/pressroom/pressreleases/2631">public comment</a>. This extension is a reworking of the <a href="http://geopackage.blogspot.com/2016/12/elevation-extension-update.html">elevation extension</a>. The primary change was expanding the scope of the extension from just elevation data to any regular gridded coverage data. The normative changes from the original extension are minimal - just a few additional columns that allow us to define what content is held in the tiles. We expect that implementers will find it easy to transition from the elevation extension to this one.</span><span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"> </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">3. OGC has <a href="http://www.opengeospatial.org/pressroom/pressreleases/2634">issued a call for participants</a> for the "GeoPackage Related Tables Extension Interoperability Experiment". Yes, that is a mouthful. The idea is that our friends at Compusult have produced an <a href="https://github.com/jyutzler/geopackage-related-tables/blob/master/spec/1_related_tables.adoc">extension</a> for associating tables with existing feature or attribute tables in a GeoPackage. Among other things, it can be used to establish a many-to-many relationship between features and multimedia files. We are looking for willing participants (OGC membership optional) to help us determine if the extension accomplishes what it is designed to do. If you are interested, please accept the <a href="https://portal.opengeospatial.org/files/?artifact_id=75290">Observer Agreement</a> and plan to dial into the kickoff tentatively scheduled for September 25.</span><br />
<br />Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-12406365067944769862017-07-08T11:53:00.000-07:002017-07-12T20:06:45.551-07:00Let's Make a GeoPackage Extensions Registry<span style="font-family: "arial" , "helvetica" , sans-serif;">One of the best ideas I have heard recently is that there needs to be a registry for proprietary GeoPackage <a href="http://geopackage.blogspot.com/2015/09/core-and-extensions-model.html">extensions</a>. While OGC has a number of <a href="http://www.geopackage.org/spec/#registered_extensions">registered extensions</a> as part of the encoding standard, is it only natural that there are going to be proprietary ones out there. What we don't have today is a way for developers to see what exists as prior art. We then run the risk of developers reinventing the wheel and the longer this persists, the harder it is to deal with. The last thing we want is multiple competing extensions out there and no interoperability between them.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I believe an extensions registry will address this problem effectively. I will do the legwork for creating it. In the short term it is going to be pretty simple - just a web page off of geopackage.org with a bunch of hyperlinks. I will use the <a href="http://leafletjs.com/plugins.html">Leaflet Plugins</a> page as inspiration; hopefully one day we will end up more like <a href="http://plugins.qgis.org/">QGIS Plugins</a> but it won't happen overnight.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><b>Update: this is now live at <a href="http://www.geopackage.org/extensions.html">http://www.geopackage.org/extensions.html</a>.</b> </span><br />
<br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">To be added to the registry, I will need from the developer a completed <a href="http://www.geopackage.org/spec/#extension_template">Extension Template</a> [1]. This template includes all of the information developers will need to understand what the extension does and how it works. I will post the template to <a href="http://geopackage.org/">geopackage.org</a> (or more likely, link to it) and help publicize it. If the extension suits other people's needs then great! If a number of implementers start using a particular extension, let the GeoPackage SWG know and we will discuss whether it is ready to be adopted by OGC.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">[1] </span><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><a href="https://github.com/opengeospatial/geopackage/blob/master/spec/annexes/extension_template.adoc">The raw AsciiDoc of the template is on GitHub</a>. </span>If filling out a template is going to be a major problem, let me know and I'll see what can be done to help you out.</span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-78453393742241628372017-07-01T13:55:00.000-07:002017-07-01T13:55:03.444-07:00The Styling / Portrayal Ad Hoc Meeting<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
<w:UseFELayout/>
</w:Compatibility>
<w:DoNotOptimizeForBrowser/>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><br />
<!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="false"
DefSemiHidden="false" DefQFormat="false" DefPriority="99"
LatentStyleCount="371">
<w:LsdException Locked="false" Priority="0" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 9"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="header"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footer"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index heading"/>
<w:LsdException Locked="false" Priority="35" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of figures"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope return"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="line number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="page number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of authorities"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="macro"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="toa heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 5"/>
<w:LsdException Locked="false" Priority="10" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Closing"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Signature"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="true"
UnhideWhenUsed="true" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Message Header"/>
<w:LsdException Locked="false" Priority="11" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Salutation"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Date"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Block Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Hyperlink"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="FollowedHyperlink"/>
<w:LsdException Locked="false" Priority="22" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Document Map"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Plain Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="E-mail Signature"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Top of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Bottom of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal (Web)"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Acronym"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Cite"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Code"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Definition"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Keyboard"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Preformatted"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Sample"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Typewriter"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Variable"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Table"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation subject"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="No List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Contemporary"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Elegant"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Professional"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Balloon Text"/>
<w:LsdException Locked="false" Priority="39" Name="Table Grid"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Theme"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" QFormat="true"
Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" QFormat="true"
Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" QFormat="true"
Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" QFormat="true"
Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" QFormat="true"
Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" QFormat="true"
Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" SemiHidden="true"
UnhideWhenUsed="true" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="TOC Heading"/>
<w:LsdException Locked="false" Priority="41" Name="Plain Table 1"/>
<w:LsdException Locked="false" Priority="42" Name="Plain Table 2"/>
<w:LsdException Locked="false" Priority="43" Name="Plain Table 3"/>
<w:LsdException Locked="false" Priority="44" Name="Plain Table 4"/>
<w:LsdException Locked="false" Priority="45" Name="Plain Table 5"/>
<w:LsdException Locked="false" Priority="40" Name="Grid Table Light"/>
<w:LsdException Locked="false" Priority="46" Name="Grid Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="Grid Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="Grid Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="46" Name="List Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="List Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="List Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 6"/>
</w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
mso-hyphenate:none;
text-autospace:ideograph-other;
font-size:12.0pt;
font-family:"Liberation Serif",serif;
mso-font-kerning:1.5pt;
mso-fareast-language:ZH-CN;
mso-bidi-language:HI;}
</style>
<![endif]-->
<br />
<div class="Standard">
<span style="font-family: Arial,Helvetica,sans-serif;">On Thursday June 29, I facilitated a Styling / Portrayal Ad
Hoc at the OGC Technical Committee Meeting. This ad hoc meeting was called because
there is broad agreement that GeoPackage would benefit from standardized
feature styling and portrayal capabilities. (Anecdotal evidence suggests that the lack of
common/standardized solutions here is already inhibiting GeoPackage adoption.)
However, there is also agreement in OGC circles that whatever capabilities used by GeoPackage should apply across all of OGC Simple Features. The meeting
was attended by over 40 people (combined in-person and on-line[1]).</span></div>
<div class="Standard">
<br /></div>
<div class="Standard">
<span style="font-family: Arial,Helvetica,sans-serif;">Much of the meeting centered around <a href="http://www.opengeospatial.org/standards/sld">Styled Layer Descriptor</a>
(SLD) and <a href="http://www.opengeospatial.org/standards/se">Symbology Encoding</a> (SE), two OGC encoding standards[2]. The consensus
was that while these are annoying (XML!) formats to work with and that they
have a number of issues, they are not that far off for meeting most needs. (The
geospatial community has created a number of specifications over the years but
none of the alternatives have been standardized and many of them have been
abandoned.) The attendees tentatively agreed that attempting to move SLD/SE
forward was the best available </span><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial,Helvetica,sans-serif;">option for</span> supporting the desired capabilities in a
timely manner.</span></div>
<div class="Standard">
<br /></div>
<div class="Standard">
<span style="font-family: Arial,Helvetica,sans-serif;">The attendees agreed on the following action items:</span></div>
<div class="Standard" style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="mso-list: Ignore;">•<span style="font-feature-settings: normal; font-kerning: auto; font-language-override: normal; font-size-adjust: none; font-size: 7pt; font-stretch: normal; font-style: normal; font-synthesis: weight style; font-variant: normal; font-weight: normal; line-height: normal;">
</span></span>Rechartering the SLD/SE Standards Working Group
(SWG) with the goal of producing updated standards that feature a core and extensions model and/or multiple conformance levels so that there is some separation between essential and non-essential elements</span></div>
<div class="Standard" style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="mso-list: Ignore;">•<span style="font-feature-settings: normal; font-kerning: auto; font-language-override: normal; font-size-adjust: none; font-size: 7pt; font-stretch: normal; font-style: normal; font-synthesis: weight style; font-variant: normal; font-weight: normal; line-height: normal;">
</span></span>Finding someone to create an executable test suite, developer’s guide, and
other materials to lower the bar for developer use</span></div>
<div class="Standard" style="margin-left: .5in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Arial,Helvetica,sans-serif;"><span style="mso-list: Ignore;">•<span style="font-feature-settings: normal; font-kerning: auto; font-language-override: normal; font-size-adjust: none; font-size: 7pt; font-stretch: normal; font-style: normal; font-synthesis: weight style; font-variant: normal; font-weight: normal; line-height: normal;">
</span></span>Initiating a pilot to experiment with the SLD/SE
changes</span></div>
<div class="Standard">
<span style="font-family: Arial,Helvetica,sans-serif;">My own next step is to take these findings back to OGC’s
Architecture Board and try to turn them into action.</span></div>
<div class="Standard">
<br /></div>
<div class="Standard">
<span style="font-family: Arial,Helvetica,sans-serif;">[1] Don't get me started on the pathetic state of hybrid in-person / on-line meetings in 2017.</span></div>
<div class="Standard">
<span style="font-family: Arial,Helvetica,sans-serif;">[2] There was also discussion of portrayal registries, but
that is a topic for another day.</span></div>
<div class="Standard">
<br /></div>
<div class="Standard">
<br /></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-80647205219442651152017-05-03T00:00:00.000-07:002017-05-03T07:42:19.011-07:00Good News / Bad News<span style="font-family: "arial" , "helvetica" , sans-serif;">First the good news. OGC's Architecture Board (OAB) has approved our request to send GeoPackage 1.2 to the Technical Committee (TC) for an electronic adoption vote. This vote will start in a couple of weeks and there is a high likelihood that this version will be fully adopted by OGC by the end of June. </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">The bad news is that the Elevation Extension has been delayed. The OAB requested that the extension be removed from version 1.2 so that it can be worked on separately. The feeling was that elevation data was too important to be rushed and that more time was needed to align it to other parts of the OGC baseline including </span><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;">things call<span style="font-family: "arial" , "helvetica" , sans-serif;">ed "</span></span>Geographic information — Schema for coverage geometry and functions<span style="font-family: "arial" , "helvetica" , sans-serif;">"<span style="font-family: "arial" , "helvetica" , sans-serif;">[</span></span></span>1] and <span style="font-family: "arial" , "helvetica" , sans-serif;">"</span>Coverage Implementation Schema"[2].</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I know this decision will cause uncertainty in the GeoPackage community. The extension does what it does and there is nothing keeping people from using it as is right now. Your mileage may vary. We should probably give it an alias (something without a <span style="font-family: "courier new" , "courier" , monospace;">gpkg_</span> prefix) to distinguish it from other adopted extensions. Other than that, we will have to wait for the process to play out. I ma<span style="font-family: "arial" , "helvetica" , sans-serif;">de sure that someone was committed to carrying the extension to adoption. </span></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;">[1]</span> <a href="http://portal.opengeospatial.org/files/?artifact_id=19820">This document</a> is dual published as OGC Ab<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;">stract Specification Topic 6 (</span></span></span><span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="-webkit-text-stroke-width: 0px; background-color: white; display: inline ! important; float: none; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Schema for coverage geometry and functions) </span>and ISO 19123 (</span></span></span><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-family: "arial" , "helvetica" , sans-serif;">Geographic information — Schema for coverage geometry and functions)</span>.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">[2] <a href="https://portal.opengeospatial.org/files/?artifact_id=48553">This document</a> used to be called GMLCOV but it was renamed when version 1.0.1 was adopted.</span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com1tag:blogger.com,1999:blog-3893646622363311354.post-18958288109149583732017-03-29T11:30:00.000-07:002017-03-29T11:30:51.137-07:00GeoPackage vs. Extended GeoPackage<span style="font-family: Arial, Helvetica, sans-serif;">One constant area of confusion is the notion of "GeoPackage" vs. "Extended GeoPackage". The idea is that a file using just core elements would be a GeoPackage and that one including extensions would be an Extended GeoPackage. However, this has caused problems in practice and we have had to adapt. A couple of months ago I wrote about <a href="http://geopackage.blogspot.com/2017/01/non-spatial-tables.html">non-spatial tables</a>. Recently we got rid of the clause that <a href="http://www.geopackage.org/spec/#r3">allowed Extended GeoPackages to use the .gpkx extension</a> (no one was). It turns out that t</span><span style="font-family: Arial, Helvetica, sans-serif;">his wasn't enough. </span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">We have been getting some push-back on the <a href="http://www.geopackage.org/spec/#extension_crs_wkt">WKT for Coordinate Reference Systems extension</a> because it adds a column to the </span><span style="font-family: Courier New, Courier, monospace;">gpkg_spatial_ref_sys</span><span style="font-family: Arial, Helvetica, sans-serif;"> table. While we feel that we were <a href="http://geopackage.blogspot.com/2016/06/maintaining-reverse-compatibility.html">justified in this decision</a>, it does affect some design decisions. For one thing, <a href="https://en.wikipedia.org/wiki/Object-relational_mapping">Object Relational Mappings</a> are more complicated when a column might or might not exist. However, we have gotten feedback from other developers that adding columns to tables as part of extensions is a reasonable and necessary technique. What to do?</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">I propose to <a href="https://github.com/opengeospatial/geopackage/pull/327">tweak a few requirements</a> to get past this. To summarize, the GeoPackage designation acts as a sort of compatibility mode. At the expense of extensions, you get maximum interoperability. If you produce a GeoPackage with extensions (by definition an Extended GeoPackage) then your risk of interoperability issues increases (though hopefully is still small). We hope that applications and libraries will grow to deal with extensions gracefully but in the meantime, avoiding unnecessary extensions does provide the greatest interoperability. </span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Does this work for you? Let me know here, on the <a href="https://lists.opengeospatial.org/mailman/listinfo/geopackage">mailing list</a>, or on <a href="https://twitter.com/slarjy">Twitter</a>.</span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-76894583720689994042017-02-28T12:00:00.000-08:002017-02-28T12:00:09.063-08:00Filling a Gap: Conformance Tests<div>
<span style="font-family: Arial,Helvetica,sans-serif;">As <a href="http://geopackage.blogspot.com/2017/02/preparing-for-geopackage-12.html">mentioned previously</a>, the GeoPackage 1.2 open comment period is under way. While we were preparing for this, we were briefed on testing performed by a consultant to a high-profile US Government organization. This testing called GeoPackage interoperability into question. Our analysis indicated that these interoperability concerns were due to either a lack of understanding of GeoPackage scope or the non-compliance of the data used in the tests. This is partially our fault - we had not completed the executable conformance tests needed to evaluate GeoPackage compliance. We have since found that some of the sample data posted to geopackage.org (and used in these tests) is not even fully compliant.</span><br />
<span style="font-family: Arial,Helvetica,sans-serif;"> </span><br />
<span style="font-family: Arial,Helvetica,sans-serif;">We are trying to fix this. As of last month, the OGC-sponsored <a href="http://cite.opengeospatial.org/te2/">conformance tests</a> for GeoPackage (<a href="http://cite.opengeospatial.org/te2/about/gpkg10/1.0/site">available here</a>) only contained tests for the core and tiles portion of version 1.0 of the standard. This month we have built <a href="https://github.com/opengeospatial/ets-gpkg12">tests</a> for the features portion and the elevation extension and brought the whole thing up-to-date to version 1.2. In the process of building these tests, we have identified a number of (hopefully) minor issues that we will resolve during the required <a href="https://github.com/opengeospatial/geopackage/milestone/12">comment resolution period</a>.</span></div>
<div>
<div>
<span style="font-family: Arial,Helvetica,sans-serif;"><br /></span></div>
<span style="font-family: Arial,Helvetica,sans-serif;">Following are our next steps:</span></div>
<div>
<ul>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Deploy the executable tests to the OGC testing site so that they are accessible</span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Update the structure of geopackage.org so that it displays multiple versions of the standard (1.0.2, 1.1.0, and the proposed 1.2.0)</span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Resolve the open issues generated during the comment period</span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Refresh all of the sample data posted on geopackage.org, ensuring that all data passes the conformance tests </span></li>
</ul>
<span style="font-family: Arial,Helvetica,sans-serif;">I ask for your patience as we work through these tasks. This is taking a long time, but we are committed to getting it right.</span></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-70531503452374023162017-02-07T14:15:00.001-08:002017-02-07T14:15:18.094-08:00Preparing for GeoPackage 1.2<span style="font-family: Arial,Helvetica,sans-serif;">The GeoPackage SWG continues to make changes to the GeoPackage <a href="https://geopackage.org/spec">Encoding Standard</a>.</span><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial,Helvetica,sans-serif;"> Our goal is to make the standard clear, concise, and self-consistent.</span> </span><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial,Helvetica,sans-serif;">Following on 1.0.1 (which focused on features) and 1.1.0
(which focused on tiles), we have made a number of changes focusing on
extensions.</span></span> As always, we insist on maintaining reverse compatibility. In fact there are no substantive changes to existing parts of the core this time around.</span><br />
<span style="font-family: Arial,Helvetica,sans-serif;"><br /></span>
<span style="font-family: Arial,Helvetica,sans-serif;">We plan to release this version as GeoPackage 1.2. For detailed information on this release, please review the <a href="https://portal.opengeospatial.org/files/72233">release notes</a>.</span><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial,Helvetica,sans-serif;"> The changes
range from typographical fixes to substantive changes that alter
requirements.</span> Following is a summary of the substantive changes:</span><br />
<ul>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Adding an "Attributes" section to describe the use of non-spatial data</span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Deprecating Requirement 69 (a mandate for extension F.1 that was nearly impossible to achieve or verify)</span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Deprecating Annexes F.2, F.4, and F.5, three extensions that were determined to be non-interoperable and non-usable</span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Updating the column name fo<span style="font-size: small;">r WKT for Coordinate Reference Systems (Annex F.10)</span></span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Adding the <a href="http://geopackage.blogspot.com/2016/12/elevation-extension-update.html">Elevation Extension</a> as Annex F.11</span></li>
<li><span style="font-family: Arial,Helvetica,sans-serif;">Changing the way GeoPackage versions are declared based on <a href="http://geopackage.blogspot.com/2016/11/internal-versioning-for-geopackage-files.html">community feedback</a> </span></li>
</ul>
<span style="font-family: Arial,Helvetica,sans-serif;">We initiated a <a href="http://www.opengeospatial.org/pressroom/pressreleases/2529">30-day comment period</a> on Friday. After the comment period concludes, we will address all of the feedback. After that we will request a vote by the OGC Technical Committee to adopt 1.2 as an official encoding standard. We hope that you will take this opportunity to check out the draft and let us know if there is anything that can be improved.</span><br />
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com1tag:blogger.com,1999:blog-3893646622363311354.post-73744561961051458992017-01-04T15:26:00.000-08:002017-01-11T06:17:01.625-08:00Fun with Interfaces and Pointers in GoNow that I am doing server-side programming again, I have fallen in love with the Go language. Long story short, it provides just about everything I need to produce quality server-side code and deliberately withholds language features that have unintended consequences in code quality and maintenance. I believe this has enabled me to produce higher quality code faster than with other languages like Java.<br />
<br />
However, it has not always been smooth sailing. I recently hit an unexpected bump in what I thought was fairly simple code. As it turned out, I had not fully grasped how Go handles interfaces and pointers. Allow me to explain the scenario, and in so doing, illustrate how Go interfaces and pointers work. (I only present the minimal code needed to get the point across. Anything extraneous to the point is omitted.)<br />
<ol>
<li>I wanted to have a custom <i>error</i> struct that had some state information in it. This was done by creating a struct called <span style="font-family: "courier new" , "courier" , monospace;">Error</span> that implements the <i>error</i> interface's one required function, <span style="font-family: "courier new" , "courier" , monospace;">Error()</span>.<br /><div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">type Error struct {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Message string</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">}</span></div>
<div style="color: #454545; line-height: normal; min-height: 14px;">
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">func (e Error) Error() string {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>return e.Message</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">}</span></div>
</li>
<li>I wanted <span style="font-family: "courier new" , "courier" , monospace;">Error</span> to lazily initialize its state. For this to work properly (i.e., retain that state after multiple calls to <span style="font-family: "courier new" , "courier" , monospace;">Error()</span>), I needed to use a <a href="https://tour.golang.org/methods/4">pointer receiver</a> in my <span style="font-family: "courier new" , "courier" , monospace;">Error()</span> function. Note the difference between the code below and the code above.<br /><div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">type Error struct {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Message string</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">}</span></div>
<div style="color: #454545; line-height: normal; min-height: 14px;">
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">func (e *Error) Error() string {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>if e.Message == "" {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>e.Message = time.Now().String()</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>}</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>return e.Message</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">}</span></div>
</li>
<li>For functions like <i>foo()</i> that are only ever going to return my own struct, I figured that I could return <span style="font-family: "courier new" , "courier" , monospace;">*Error</span> so that I would have full access to its members without any type checking. (As you will see later, this turned out to be a bad idea!)<br /><div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">func foo() *Error {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>return nil</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">}</span></div>
</li>
<li>Then I could subsequently return the results (an error or <i>nil)</i> to a higher function.
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">func bar() error {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>return foo()</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">}</span></div>
</li>
<li>Finally I would be able to call my <i>bar</i> function from high level code and check the return value.<br /><div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">e := bar()</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">if e == nil {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>fmt.Println("Hello, playground")</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">} else {</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>fmt.Println("Message:" + e.Error())</span></div>
<div style="color: #454545; line-height: normal;">
<span style="font-family: "courier new" , "courier" , monospace;">}</span></div>
</li>
</ol>
<br />
There is just one problem – this code segfaults. Try it out <a href="https://play.golang.org/p/faqkdKH1bP">here</a>.<br />
<br />
Why this happens is probably not obvious to most inexperienced Go programmers. What is it that implements the <i>error</i> interface? Not <span style="font-family: "courier new" , "courier" , monospace;">Error</span>, but rather <span style="font-family: "courier new" , "courier" , monospace;">*Error</span>. The problem is that <i>bar()</i> must return a) something that implements the <i>error</i> interface or b) <i>nil</i>. Well, <span style="font-family: "courier new" , "courier" , monospace;">*Error</span> implements that interface. As written here (without all of the other logic that makes the function meaningful) <i>foo()</i> returns a <u>pointer to nil</u>. A <u>pointer to nil</u> is not the same as <i>nil</i>. Repeat that to yourself, more than once if you have to.<br />
<br />
So what have I done? I created a struct, used a pointer receiver to implement an interface, and called a function that returns a pointer to my struct, and returned that pointer (that just so happens to point to <i>nil</i>). Well crap, since <i>nil</i> is not the same as a <u>pointer to nil</u> the equality expression fails and we try to dereference a <i>nil</i> pointer. Kaboom! The fix is simple – change <i>foo()</i> to return <i>error</i> instead of <span style="font-family: "courier new" , "courier" , monospace;">*Error</span>. Done! (Oh well, my assertion in #3 is wrong and so I will just have to manually check to see if my <i>error</i> happens to be a <span style="font-family: "courier new" , "courier" , monospace;">*Error</span>.)<br />
<br />
The moral of the story is that if your struct returns an error, return an <i>error</i> and not something else that implements the <i>error</i> interface. However, sometimes the journey is more important than the destination. You can't fully understand the language if you don't truly understand how the language handles interfaces and pointers.Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-74927157892088637692017-01-03T08:42:00.000-08:002017-01-11T06:07:59.900-08:00Non-spatial Tables<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;">About a year ago, my Twitter timeline blew up. It turns out the Esri User Conference was going on and this got a lot of people chatting together. The root of the matter was a perception that Esri was not providing reasonable support for non-spatial data within GeoPackages. This was leading people towards flawed, clumsy workarounds like inventing spatial columns to tack onto attribute tables(!). Uh, folks, this is not what we had in mind...</span></span></span><br />
<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span></span>
<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;">I am not here to point fingers and the fact is that both sides had a point. <span style="background-color: white; color: #333333;">A strict read of GeoPackage v1.1 did not allow non-spatial attribute values. However, in practice data providers routinely need to deliver data that does not contain geometry properties. We agreed that it was not reasonable to require any GeoPackage that contained non-spatial tables to be declared and documented as an "Extended GeoPackage". This does not promote interoperability. </span></span></span></span><br />
<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="background-color: white; color: #333333;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span></span></span>
<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="background-color: white; color: #333333;">In response, we modified the standard by adding a new </span><a href="http://www.geopackage.org/spec/#attributes">Attributes</a> <span style="background-color: white; color: #333333;">section that describes how to store non-spatial attribute tables in a GeoPackage. The new section is present in the on-line (working) copy of the specification and it will be incorporated in the next release (tentatively numbered GeoPackage 1.2). We hope that this addition will clarify things and encourage people to use GeoPackages as intended. We consider the change to be low-risk because it creates a new encoding option that would be ignored by previous versions of the standard.</span></span></span></span><br />
<div>
<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="background-color: white; color: #333333;"><br /></span></span></span></span></div>
Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0tag:blogger.com,1999:blog-3893646622363311354.post-10123776122682169832016-12-14T12:41:00.000-08:002017-08-20T08:15:17.833-07:00Elevation Extension Update<span style="font-family: "arial" , "helvetica" , sans-serif;">As <a href="http://geopackage.blogspot.com/2015/10/elevation-extension.html">previously mentioned</a>, the GeoPackage SWG has been investigating an extension to support tiled, gridded elevation data. A year later, we are pleased to announced that we have completed our work on this extension and that we intend to release it as part of GeoPackage 1.2. This extension will share the mechanism used in the tiles portion of the standard.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">The <a href="http://www.geopackage.org/spec/#extension_tiled_gridded_elevation_data">extension description</a> describes the metadata tables needed to manage elevation tiles and encodings for the elevation values themselves. The extension supports two encodings. Most users will use the PNG encoding which uses 16-bit integers. An optional scale and offset allow for more efficient use of the 16-bit space. For those users who require greater resolution, there is a TIFF encoding which uses 32-bit floating point values. For convenience, we also provide abstract tests and table definition SQL.</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">To ensure that this approach will work, we conducted an interoperability experiment. In this experiment, documented in an <a href="https://portal.opengeospatial.org/files/?artifact_id=70051">Engineering Report</a>[1], a number of participants produced GeoPackages containing elevation data and ran visualization and/or analytics on them. The experiment exposed a number of issues that the SWG subsequently resolved. At the OGC Technical Committee meeting in February, the SWG voted to add the extension to the standard. Do you think it is ready?</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<span style="font-family: "arial" , "helvetica" , sans-serif;">[1] Note: this post has been updated 8/20/17 with the permalink for the engineering report.</span>Slarhttp://www.blogger.com/profile/11473385549812836620noreply@blogger.com0