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

[Andrea Peri]

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.
:)
 Il 01/apr/2015 18:15 "G. Allegri" <giohappy a gmail.com> ha scritto:

> 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 :)
>
> giovanni
>
> 2015-04-01 18:13 GMT+02:00 Andrea Peri <aperi2007 a 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 a 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 a spatialys.com>
>>> Date: 1 April 2015 at 14:16
>>> Subject: [gdal-dev] UFO format / GDAL 3.0
>>> To: gdal-dev a 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 a lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>>
>>> --
>>> ciao
>>> Luca
>>>
>>> http://gis.cri.fmach.it/delucchi/
>>> www.lucadelu.org
>>> _______________________________________________
>>> Gfoss a 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 a 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
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20150401/e610f5ab/attachment.html>