<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 01/04/15 15:31, Matt Hanson wrote:<br>
<span style="white-space: pre;">> I think this is a great idea,
finally users can be forced to stop using all those silly
formats. <br>
><br>
> But I think GDAL 3.0 needs a good slogan, may I suggest
"There can be only one" ?<br>
></span><br>
<br>
Or, "One Format to rule them all"...<br>
<br>
Homme<br>
<br>
<span style="white-space: pre;">><br>
><br>
> On Wed, Apr 1, 2015 at 10:17 AM, Daniel Morissette
<a class="moz-txt-link-rfc2396E" href="mailto:dmorissette@mapgears.com"><dmorissette@mapgears.com></a> wrote:<br>
><br>
> Good morning Even,<br>
><br>
> 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?<br>
><br>
> 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?<br>
><br>
> Have a nice ... day.<br>
><br>
> Daniel<br>
><br>
><br>
> On 2015-04-01 8:16 AM, Even Rouault wrote:<br>
><br>
> Hi,<br>
><br>
> Since some time a few ideas came to my mind and I
felt today was a good one to<br>
> share them and get feedback.<br>
> Considering the never ending proliferation of GIS
file formats, currently 220<br>
> handled in GDAL trunk, it seems wise to put an end to
it. Especially since the<br>
> counter used to iterate over the drivers is a
unsigned 8 bit, so we will soon<br>
> be unable to add more, or at the expense of
sacrificing our ports to Intel 8008<br>
> or Motorola 6800, which would be pretty sad.<br>
><br>
> Therefore I'd like to propose the UFO format, which
stands for Universal<br>
> Format Oh-yeaaah!<br>
> The basic idea of UFO is that it isn't a fixed
format, but a varying and self-<br>
> described one. XML (or perhaps EXI?) + XSD + XSLT +
XPath + Schematron could<br>
> probably do it, but for efficiency I thought to a
byte-code interpreted by<br>
> libgdal and whose interface with libgdal would match
the GDAL driver<br>
> interface. So basically each dataset would contain
its own driver. The big<br>
> plus is that you could write image translators that
would generate binary<br>
> encodings optimized for the particular dataset being
encoded: for example, it<br>
> is kind of stupid to write the values of each pixel
of a Mandelbrot fractal<br>
> whereas its mathematical description fits into a few
lines of code.<br>
> Furthermore, still pursuing with that example, we
could even have raster of<br>
> arbitrary resolution, since that's a characteristics
of fractals. And many GIS<br>
> datasets have indeed fractal charasterics, such as
coastlines (<br>
> <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Coastline_paradox">http://en.wikipedia.org/wiki/Coastline_paradox</a> )<br>
> For security reason, we should aim at supporting only
simple & verifiable<br>
> languages, so Brainfuck (Brainf**k for the most
puritans of us) seems to be a<br>
> good fit : <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Brainfuck">http://en.wikipedia.org/wiki/Brainfuck</a>.
Basically it is a Turing<br>
> complete language with only 8 commands. So as much
powerful as needed, while<br>
> being very easy to learn and implement. To save some
efforts, I'd humbly<br>
> suggest we adopt libbf (
<a class="moz-txt-link-freetext" href="http://savannah.nongnu.org/projects/libbf">http://savannah.nongnu.org/projects/libbf</a> ), an older<br>
> project of mine that also incorporates a on-the-fly
optimizer & compiler for<br>
> most popular architectures.<br>
><br>
> The plan would be to have an initial version of the
UFO driver ready for GDAL<br>
> 2.0 and push strongly for its widespread adoption in
all GIS, remote sensing,<br>
> OSS & proprietary vendors, etc.... Perhaps we
should establish a dedicated<br>
> workgroup at OGC to make it a standard ? Then we
could deprecate and remove<br>
> all existing drivers and at the time of GDAL 3.0, UFO
would be the only one<br>
> remaining driver, making the Intel 8008 port very
happy!<br>
><br>
> Happy to hear from your thoughts before formalizing
that as a RFC,<br>
><br>
> Even<br>
><br>
><br>
><br>
> -- <br>
> Daniel Morissette<br>
> T: +1 418-696-5056 #201<br>
> <a class="moz-txt-link-freetext" href="http://www.mapgears.com/">http://www.mapgears.com/</a><br>
> Provider of Professional MapServer Support since 2000<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></span><br>
<br>
<br>
</body>
</html>