[gdal-dev] UFO format / GDAL 3.0

[Andre Vautour]

Did you happen to look at the date on your calendar this morning?
:p

On 2015-04-01 11:17, Daniel Morissette 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
>>
>
>