[gdal-dev] OGC announces a new standard that improves the way information is referenced to the earth

[Kurt Schwehr]

See also space filling curves like the hilbert curve and Google's S2...

https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSngKwvS_jwNVHRPZTTDzXXn6Q/view#slide=id.i0

On Tue, Oct 31, 2017 at 8:09 AM, Stadin, Benjamin <
Benjamin.Stadin at heidelberg-mobil.com> wrote:

> To me this proposal looks too complicated for practical application in
> it‘s current form. I think the surface model (or a „default“ model) and
> related algorithms should be part of the proposal.
>
> I needed to solve some of the problems they mention for our 3d rendering
> engine (store  vector data of multiple projections in an indexed storage
> and separate vector storage, projection and visible projection when
> rendering) as well as for parallel data processing of large data sets.
>
> I found that systems which use ellipsoidal polygons on the surface model
> of the earth impractical for a variety of reasons: Image data and rendering
> systems mostly deal with rectangular tiles, there are commonly accepted
> (but not standardized) properties like zoom levels and tile sizes which
> many software adheres to, and also algorithm complexity and implementation
> effort.
>
> I ended up with an adaptation of the MODIS grid for our application (
> https://modis-land.gsfc.nasa.gov/MODLAND_grid.html) so that cells (which
> are equal area in MODIS) are of the same length as OSM / Web Mercator tiles
> (at the equator), also considering zoom levels.
>
> I think there is a real need for such concept, but in my opinion there
> needs to be a default model and algorithms in order to be relevant.
>
> Best
> Ben
>
> Von meinem iPad gesendet
>
> Am 31.10.2017 um 13:40 schrieb Roberto Ribeiro <robertofig85 at gmail.com>:
>
> I too took that understanding from the text, Ari. I'll read the specs
> later, but since they mention a lot Big Data and the raster <> vector
> integration, I  it is akin to a geometry collection, but encompassing a
> wider range of data types, and arranged in a pyramid/r-tree -esque
> environment for faster processing.
>
> If so, it's not an entirely novel idea (Esri's File GDB is mostly that, as
> well as the entire CAD modelling), but one that would be interesting to
> have an open standard for.
>
> 2017/10/31 午前4:23 "Ari Jolma" <ari.jolma at gmail.com>:
>
>> That also caught my eye. The text sounds a bit like marketing talk but
>> maybe there is something.
>>
>> From a quick look my understanding is that the idea is to create a grid
>> that divides the whole earth into cells of similar shape in a sequence of
>> increasing cell size. And that sounds to me like a new idea.
>>
>> Any other thoughts? Did I get the idea right?
>>
>> Best,
>>
>> Ari
>>
>>
>> Helmut Kudrnovsky kirjoitti 29.10.2017 klo 01:16:
>>
>>> Fyi
>>>
>>> http://www.opengeospatial.org/pressroom/pressreleases/2656
>>>
>>> "The goal of DGGS is to enable rapid assembly of spatial data without the
>>> difficulties of working with projected coordinate reference systems. The
>>> OGC
>>> DGGS Abstract Specification standard defines the conceptual model and a
>>> set
>>> of rules for building highly efficient architectures for spatial data
>>> storage, integration and analytics. ....."
>>>
>>>
>>>
>>> -----
>>> best regards
>>> Helmut
>>> --
>>> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171031/de95e950/attachment.html>