[mapserver-dev] Re: RFC for XMP metadata support

Paul Ramsey pramsey at cleverelephant.ca
Thu Jul 7 13:04:29 EDT 2011

Re-sending to list...

On Thu, Jul 7, 2011 at 9:39 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> On Thu, Jul 7, 2011 at 8:35 AM, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>> Paul,
>> How involved would it be to set this metadata in the PNG tXMP tag
>> through libpng?
> As far as I can ascertain: very involved. The XMP embedding standard
> necessarily has different rules for every file type, so once you start
> trying to do it at the image level you have to right special code for
> every format. This is where a support library like exempi comes in
> useful, but unfortunately exempi only writes to files on disk, it
> can't handle a stream or a memory segment.
>> Going through libgdal has the inconvenience that you loose the
>> quantization/paletization, along with the fact that you'll be
>> requiring an additional write to the disk before sending to the
>> client.
> Yes, but the convenience that there's already a file on disk. I know,
> cheasy, but I'm trying to make this happen in a sane budget :)
>> Or maybe the xmp users are confined to non png formats, and in that
>> case this isn't a concern ?
> No, I expect they'll use PNG and JPG mostly with occasional GIF.
> Am I right that with our now numerous output drivers it's hard to find
> a single place where the process can be hijacked and I can say "now,
> write this to disk" and then hit it with exempi? At the extreme, if I
> hit up mapserv maybe? But then I'll have hooks scattered into a number
> of places, while with GDAL driver I only have it in one place. I'm
> trying to balance the code affect with the relatively niche appeal of
> this feature. Hm.
> P.
>> --
>> thomas
>> On Thu, Jul 7, 2011 at 17:29, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>>> No concerns, questions?
>>> On Mon, Jul 4, 2011 at 9:10 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>>>> Devs,
>>>> I've prepared a draft RFC for adding embedded metadata into output
>>>> images produced by MapServer.
>>>>  http://trac.osgeo.org/mapserver/attachment/ticket/3932/ms-rfc-7X.txt
>>>> I'm looking for feedback now before I number and commit it and ask for
>>>> a vote. Here's the preamble so you don't have to click:
>>>> XMP is the "extensible metadata platform" [1]_ which allows the
>>>> embedding of metadata information across a wide range of document and
>>>> image formats: PNG, GIF, JPEG, PDF, etc. XMP was originally developed
>>>> by Adobe [2]_ and is supported across their product line. It is now
>>>> being increasingly included in other standards for metadata embedding
>>>> and supported by tools for viewing image information (e.g. exiftools).
>>>> Creative Commons has standards for using XMP to embed commons
>>>> licensing [3]_ in images and other document, including a specific
>>>> creative commons schema. One of the challenges of advertising
>>>> licensing and terms of use in WMS and other web mapping services is
>>>> that the terms are usually advertised separately from the actual
>>>> content. So a WMS service might specify terms in the Capabilities
>>>> document, but the images themselves will be unmarked. Embedding
>>>> license URLs inside the images themselves using a standard marking
>>>> allows organizations to be unambiguous about the conditions attached
>>>> to their content.
>>>> The goal of this change is to allow users the option of embedding XMP
>>>> metadata in their MapServer output using an open source XMP utility
>>>> library.
>>>> .. [1] http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
>>>> .. [2] http://www.adobe.com/products/xmp/overview.html
>>>> .. [3] http://wiki.creativecommons.org/XMP
>>>> .. [4] http://libopenraw.freedesktop.org/wiki/Exempi
>>>> Thanks,
>>>> Paul
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

More information about the mapserver-dev mailing list