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" ? On Wed, Apr 1, 2015 at 10:17 AM, Daniel Morissette <[email protected] > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
