[gdal-dev] UFO format / GDAL 3.0

[Daniel Morissette]

Did you notice the "..." in the salutation above my signature? Replace 
the "..." with what your calendar says.  :-)


On 2015-04-01 11:30 AM, Andre Vautour wrote:
> 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
>>>
>>
>>


-- 
Daniel Morissette
T: +1 418-696-5056 #201
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000