[mapguide-internals] Review RFC 108 - support Watermark

Thu Aug 5 07:33:42 EDT 2010

Hi Jason, I agree with you about the copy watermark to the referenced layers should be done in client side. So I will remove the related statement from the RFC.

@Dave, it's possible to request multiple WMS layers in one single image. We can merge these layers into one layer and publish it as WMS. But it's not in the scope of this RFC.
If we have enough development resource, we will address it in the other RFC.

Thanks for your reply.
-Buddy 

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, August 05, 2010 1:22 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Review RFC 108 - support Watermark

By client side, I meant that Studio or Maestro be responsible for
doing any Map->Layer migration of the watermark assignment, rather
than having this be done automatically server side when the watermark
is defined on the Map.

Your point about a server-wide definition for a  watermark is a good one.

WMS allows specification of multiple layers in one call (LAYERS= I
think) but I don't know if MapGuide supports this.

On 2010-08-04, Dave Wilson <dave.wilson at autodesk.com> wrote:
> I'm not sure what you mean by client side.
>
> I think we need to separate and or determine when a "layer" based watermark
> would be used.
>
> In a dynamic map I would expect it rare that an individual layer would
> contain a watermark. I would expect the map to contain the watermark, but I
> won't preclude the option to set a layer based watermark, the question is is
> this for dynamic maps, WMS or both?
>
> When configuring a layer for WMS I can see setting a watermark specific to
> the layer. Alternately I can see setting a default watermark resource to be
> set for any WMS request not requiring a layer specific value to be used. The
> server level default could be disabled if desired or overridden by the layer
> level. If the end user has a map which requests multiple transparent layers
> from the same WMS server would we expect each to contain a watermark? If
> ideally it ends up in the same location hopefully they appear as one, but I
> suspect things may be off by a pixel or two: this would look really ugly. Do
> we anticipate multiple WMS layers from the same server to be displayed at
> once?
>
> Is it possible in any way to request multiple WMS layers be integrated into
> a single image from a WMS server?
>
> Dave
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
> Sent: Wednesday, August 04, 2010 10:08 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] Review RFC 108 - support Watermark
>
> I understand point #4 from an ease-of-use perspective, but personally
> would be really annoyed if something I did at the map level had an
> effect on any of the layers I've developed and maintain independently
> for use in multiple maps. I also think that this should be implemented
> client-side (as an intermediate screen when wms-published layers
> detected? "Also apply watermark to these WMS published layers?")
> rather than server-side.
>
> Jason
>
> On 2010-08-04, Buddy Hu <Buddy.Hu at autodesk.com> wrote:
>> Hi Trevor, Tom, Jason and Jackie,
>> Thanks for your comments! Here is my reply.
>>
>> 1. For the image storage, I agree with you guys. We will abandon the DWF
>> file for image storing. And using Symbol Definition to define the
>> content(but NOT the position) of the Watermark. And the position of
>> watermark is defined in Layer Definition/Map Definition.
>>
>> 2. For the watermark resource , I still think we need a new resource type,
>> and the map/layer definition can reference this resource.  As Tom
>> mentioned,
>> the separate resource type is easy for reusing. And I don't think the
>> Watermark is very simple, we need to define the position, rotation,
>> transparency and etc. So I think a separate watermark resource type is
>> necessary. At the same time, we will support inlining watermark in the Map
>> Definition and Layer Definition.
>>
>> 3. The Layer Definition also support watermark reference. A map support
>> multiple watermarks, and the complete watermark group is the collection of
>> all the watermarks of underlying layers and defined watermark in Map
>> Definition.
>>
>> 4. For the WMS publishing, I think we still need to discuss whether copy
>> the
>> watermark of MapDefinition into the each referenced layers.
>>
>> And I will give you the xsd of watermark and the updated xsd of
>> MapDefiniton/LayerDefinition tomorrow.
>>
>> Thanks all!
>> -Buddy
>>
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom
>> Fukushima
>> Sent: Saturday, July 31, 2010 11:38 AM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Review RFC 108 - support Watermark
>>
>> Jason,
>>
>> I'll wait for updates to the RFC before replying to some items below.
>>
>> With respect to the "Watermark requirements are generally pretty simple"
>> statement; that's true for simple copyrights statements; but for anyone
>> who
>> wants a more professional looking map with, for example, some branding,
>> then
>> a full-fledged vector-based symbol is required and defining it in XML is a
>> pain.
>>
>> Images do not make good watermarks because they do not print well.
>>
>> Tom
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
>> Birch
>> Sent: Friday, July 30, 2010 8:30 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] Review RFC 108 - support Watermark
>>
>> Watermark requirements are generally pretty simple, text or image.  I
>> can't
>> imagine that adding an incredibly simple WaterMark editor that only places
>> those types into a SymbolDefinition would be too hard, and that folks with
>> more more complex requirements would be unable to hand-craft the XML in
>> those cases.
>>
>> I wasn't questioning the need for an external watermark definition, just
>> the
>> need for a dedicated resource type for it.  Could the MapDefinition schema
>> and LayerDefinition WMS header information be updated to point to an
>> appropriate resource, along with whatever additional positional
>> information/overrides required?  So add a <Watermark /> entity to the
>> MapDefinition which contains the symbol definition's ResourceID along with
>> positional preference (TL, T, TR, L, C, R, BL, B, BR), and dimension/scale
>> overrides.
>>
>> I'm assuming that you'd need positional preference rather than precise
>> placement due to the possible need to stack WaterMarks?  Does the
>> WaterMark
>> need its own Opacity too?
>>
>> I'd prefer not to make assumptions about whether DWF was weighed against
>> SymbolDefinition, and would like to hear whether there is still some
>> potential to reconsider this decision. If this call is always going to be
>> made because clients have easy ways of generating DWF symbols, then we're
>> going to see continued propagation of DWF (which is not under an
>> OSI-certified license) throughout the code base.  I really, really don't
>> like this, and would prefer to see the feature deferred if there are
>> inadequate resources to do it "right" (by my admittedly narrow definition
>> of
>> right).
>>
>> Jason
>>
>> On 30 July 2010 14:06, Tom Fukushima wrote:
>>
>>> Hi All,
>>>
>>> I agree with Jason, Jackie, Trevor,... that SymbolDefinition resources
>>> should be supported. But I don't think that means we can't also support
>>> DWF
>>> symbols. So I think it should be fine to support DWF now and then not
>>> exempt
>>> ourselves from supporting SymbolDefinitions in the future. (I'm assuming
>>> that the ADSK team that is working on this has weighed using DWF symbols
>>> and
>>> SymbolDefinitions already and has decided on DWF symbols, and only has
>>> the
>>> development resources for that right now.)  Let me say though, that I'm
>>> not
>>> that keen on propagating the use of DWF symbols in MGOS, and if we had a
>>> WYSIWYG symbol definition editor somewhere I would be all for
>>> SymbolDefinitions everywhere.
>>>
>>> I wish that the watermark resource could just refer to a DWF Symbol
>>> library
>>> instead of attaching it as DWF symbol data, but I guess this might create
>>> a
>>> pretty unusable UI.
>>>
>>> Buddy, I would like to see what the changes to the MapDefinition will be
>>> for this (XML is API and needs to be documented in the RFC).  Please add
>>> this to the RFC.
>>>
>>> Please also provide the watermark resource schema.
>>>
>>> Jason, I was also wondering why a new resource is required, but after
>>> thinking about it, I think that it will make maintaining a bunch of Maps
>>> and
>>> WMS layers simpler.  Just tweak one place and all other places are
>>> adjusted.
>>> That said, maybe it could be made possible to also allow for inlining the
>>> watermark specification into the MapDefinition.  If we only had
>>> development
>>> resources for doing one or the other right now, I think I would pick
>>> using
>>> a
>>> separate resource; no strong preference here though.
>>>
>>> Thanks
>>> Tom
>>>
>>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals