[Gfoss] [gdal-dev] UFO format / GDAL 3.0

Per chi non legge la mailing list gdal-dev una buona notizia per il futuro...

---------- Forwarded message ----------
From: Even Rouault <even.rouault@spatialys.com>
Date: 1 April 2015 at 14:16
Subject: [gdal-dev] UFO format / GDAL 3.0
To: gdal-dev@lists.osgeo.org

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

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Grazie.
Molto interessante davvero.
Se va in porto apre scenari importanti per l’interoperabilità.

Il 01/apr/2015 17:48 “Luca Delucchi” <lucadeluge@gmail.com> ha scritto:

Per chi non legge la mailing list gdal-dev una buona notizia per il futuro…

---------- Forwarded message ----------
From: Even Rouault <even.rouault@spatialys.com>
Date: 1 April 2015 at 14:16
Subject: [gdal-dev] UFO format / GDAL 3.0
To: gdal-dev@lists.osgeo.org

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


Spatialys - Geospatial professional services
http://www.spatialys.com


gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015

Sì Andrea,
ma Even si è dimenticato di dire che, nella sua prima implementazione, funzionerà solo un giorno all’anno.
Per cui l’interoperabilità potrà essere garantita solo il 1° di Aprile di ogni anno :slight_smile:

giovanni

···

2015-04-01 18:13 GMT+02:00 Andrea Peri <aperi2007@gmail.com>:

Grazie.
Molto interessante davvero.
Se va in porto apre scenari importanti per l’interoperabilità.

Il 01/apr/2015 17:48 “Luca Delucchi” <lucadeluge@gmail.com> ha scritto:

Per chi non legge la mailing list gdal-dev una buona notizia per il futuro…

---------- Forwarded message ----------
From: Even Rouault <even.rouault@spatialys.com>
Date: 1 April 2015 at 14:16
Subject: [gdal-dev] UFO format / GDAL 3.0
To: gdal-dev@lists.osgeo.org

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


Spatialys - Geospatial professional services
http://www.spatialys.com


gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015

Giovanni Allegri
http://about.me/giovanniallegri
Gis3W - http://gis3w.it
Ikare - http://ikare.it

Twitter: https://twitter.com/giohappy
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

Si ma temo che il driver UFO sarà utilizzabile un solo giorno l’anno, il primo di ogni Aprile :slight_smile:

Il 01/apr/2015 18:13 “Andrea Peri” <aperi2007@gmail.com> ha scritto:

Grazie.
Molto interessante davvero.
Se va in porto apre scenari importanti per l’interoperabilità.

Il 01/apr/2015 17:48 “Luca Delucchi” <lucadeluge@gmail.com> ha scritto:

Per chi non legge la mailing list gdal-dev una buona notizia per il futuro…

---------- Forwarded message ----------
From: Even Rouault <even.rouault@spatialys.com>
Date: 1 April 2015 at 14:16
Subject: [gdal-dev] UFO format / GDAL 3.0
To: gdal-dev@lists.osgeo.org

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


Spatialys - Geospatial professional services
http://www.spatialys.com


gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015

Eh già.
Ci ho pensato subito dopo.

Comunque se funzionasse anche 1 giorno all anno a me andrebbe bene comunque.
Tanto abbiamo dei dataset che si aggiornano ogni 10 anni.
:slight_smile:

···

2015-04-01 18:13 GMT+02:00 Andrea Peri <aperi2007@gmail.com>:

Grazie.
Molto interessante davvero.
Se va in porto apre scenari importanti per l’interoperabilità.

Il 01/apr/2015 17:48 “Luca Delucchi” <lucadeluge@gmail.com> ha scritto:

Per chi non legge la mailing list gdal-dev una buona notizia per il futuro…

---------- Forwarded message ----------
From: Even Rouault <even.rouault@spatialys.com>
Date: 1 April 2015 at 14:16
Subject: [gdal-dev] UFO format / GDAL 3.0
To: gdal-dev@lists.osgeo.org

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


Spatialys - Geospatial professional services
http://www.spatialys.com


gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
750 iscritti al 18.3.2015

Giovanni Allegri
http://about.me/giovanniallegri
Gis3W - http://gis3w.it
Ikare - http://ikare.it

Twitter: https://twitter.com/giohappy
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus