[Geopackage] New Blog Post
jeffy at imagemattersllc.com
Sat Dec 17 12:58:56 EST 2016
I don't dispute any of that but the fact is that we don't have an
interoperable way to express that information and mandating one way or
another was deemed too heavy-handed.
This is an issue that transcends GeoPackage and applies to anyone trying to
do gridded coverages. I will take this up with OGC's architecture board to
find out if there is any guidance for handling the situation properly.
On Fri, Dec 16, 2016 at 1:33 PM, Pepijn Van Eeckhoudt <
pepijn at vaneeckhoudt.net> wrote:
> There's a difference between not restricting choices and leaving it
> completely undefined :) The latter is bound to lead to different systems
> interpreting the data in different ways.
> As an example, suppose you naively transcode dted to geopackage, where
> every source dted sample corresponds to a pixel in a png tile. How is a
> client supposed to figure out that the samples on the file edges overlap
> between adjacent tiles for instance?
> One client may assume that and convert the elevation samples to a 3D mesh
> correctly; another one might assume area samples and end up displaying
> duplicate samples and have every sample at an incorrect location.
> If the spec does not describe anything at all regarding interpretation
> neither of the implementations is either right or wrong.
> On 16 Dec 2016, at 18:41, Jeff Yutzler <jeffy at imagemattersllc.com> wrote:
> We deliberately didn't specify this because we didn't want to mandate one
> flavor over another. We felt that this could be handled out of band or
> through the metadata.
> On Fri, Dec 16, 2016 at 3:27 AM, Pepijn Van Eeckhoudt <
> pepijn at vaneeckhoudt.net> wrote:
>> Hi Jeff,
>> I might have missed it, but there doesn't seem to be any description of
>> the geographic location of the sample values.
>> Are the pixel values located on grid points or at the grid cell center?
>> Have they been point sampled or are they area averages? etc.
>> This information is pretty critical to know when interpreting the data
>> and interpolating values (evaluating the coverage in topic 6 terminology).
>> Best regards,
>> Pepijn Van Eeckhoudt
>> On 15 Dec 2016, at 17:42, Jeff Yutzler via Geopackage <
>> geopackage at lists.opengeospatial.org> wrote:
>> I just published a new blog post regarding the new Elevation Extension:
>> Jeff Yutzler
>> Image Matters LLC <http://www.imagemattersllc.com/>
>> Mobile: (703) 981-8753
> Jeff Yutzler
> Image Matters LLC <http://www.imagemattersllc.com/>
> Mobile: (703) 981-8753
Image Matters LLC <http://www.imagemattersllc.com/>
Mobile: (703) 981-8753
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Geopackage