[gdal-dev] UFO format / GDAL 3.0

[Homme Zwaagstra]

On 01/04/15 15:31, Matt Hanson wrote:
> I think this is a great idea,  finally users can be forced to stop using all those silly formats.
 >
 > But I think GDAL 3.0 needs a good slogan, may I suggest "There can be 
only one" ?
 >

Or, "One Format to rule them all"...

Homme

>
 >
 > On Wed, Apr 1, 2015 at 10:17 AM, Daniel Morissette 
<dmorissette at mapgears.com> wrote:
 >
 >     Good morning Even,
 >
 >     That sounds like an ambitious world (universe?) domination plan, 
but before going too deep into the implementation details, can you 
comment on the potential for real life widespread adoption of such a 
universal format in a world where everyone and their dog wants to have 
their own file format which is so much better than everybody else's?
 >
 >     In other words: GML failed in a similar attempt to replace all 
other formats, so despite the benefits of BF over XML encoding, what 
would give UFO more chances of succeeding?
 >
 >     Have a nice ... day.
 >
 >     Daniel
 >
 >
 >     On 2015-04-01 8:16 AM, Even Rouault wrote:
 >
 >         Hi,
 >
 >         Since some time a few ideas came to my mind and I felt today 
was a good one to
 >         share them and get feedback.
 >         Considering the never ending proliferation of GIS file 
formats, currently 220
 >         handled in GDAL trunk, it seems wise to put an end to it. 
Especially since the
 >         counter used to iterate over the drivers is a unsigned 8 bit, 
so we will soon
 >         be unable to add more, or at the expense of sacrificing our 
ports to Intel 8008
 >         or Motorola 6800, which would be pretty sad.
 >
 >         Therefore I'd like to propose the UFO format, which stands 
for Universal
 >         Format Oh-yeaaah!
 >         The basic idea of UFO is that it isn't a fixed format, but a 
varying and self-
 >         described one. XML (or perhaps EXI?) + XSD + XSLT + XPath + 
Schematron could
 >         probably do it, but for efficiency I thought to a byte-code 
interpreted by
 >         libgdal and whose interface with libgdal would match the GDAL 
driver
 >         interface. So basically each dataset would contain its own 
driver. The big
 >         plus is that you could write image translators that would 
generate binary
 >         encodings optimized for the particular dataset being encoded: 
for example, it
 >         is kind of stupid to write the values of each pixel of a 
Mandelbrot fractal
 >         whereas its mathematical description fits into a few lines of 
code.
 >         Furthermore, still pursuing with that example, we could even 
have raster of
 >         arbitrary resolution, since that's a characteristics of 
fractals. And many GIS
 >         datasets have indeed fractal charasterics, such as coastlines (
 >         http://en.wikipedia.org/wiki/Coastline_paradox )
 >         For security reason, we should aim at supporting only simple 
& verifiable
 >         languages, so Brainfuck (Brainf**k for the most puritans of 
us) seems to be a
 >         good fit : http://en.wikipedia.org/wiki/Brainfuck. Basically 
it is a Turing
 >         complete language with only 8 commands. So as much powerful 
as needed, while
 >         being very easy to learn and implement. To save some efforts, 
I'd humbly
 >         suggest we adopt libbf ( 
http://savannah.nongnu.org/projects/libbf ), an older
 >         project of mine that also incorporates a on-the-fly optimizer 
& compiler for
 >         most popular architectures.
 >
 >         The plan would be to have an initial version of the UFO 
driver ready for GDAL
 >         2.0 and push strongly for its widespread adoption in all GIS, 
remote sensing,
 >         OSS & proprietary vendors, etc.... Perhaps we should 
establish a dedicated
 >         workgroup at OGC to make it a standard ? Then we could 
deprecate and remove
 >         all existing drivers and at the time of GDAL 3.0, UFO would 
be the only one
 >         remaining driver, making the Intel 8008 port very happy!
 >
 >         Happy to hear from your thoughts before formalizing that as a 
RFC,
 >
 >         Even
 >
 >
 >
 >     --
 >     Daniel Morissette
 >     T: +1 418-696-5056 #201
 >     http://www.mapgears.com/
 >     Provider of Professional MapServer Support since 2000
 >
 >     _______________________________________________
 >     gdal-dev mailing list
 >     gdal-dev at lists.osgeo.org
 >     http://lists.osgeo.org/mailman/listinfo/gdal-dev
 >
 >
 >
 >
 > _______________________________________________
 > gdal-dev mailing list
 > gdal-dev at lists.osgeo.org
 > http://lists.osgeo.org/mailman/listinfo/gdal-dev


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