上文提到Attribute语法在XAML中设置属性，.NET框架内置了TypeConverter特性使得简单的字符串可以转换为相应的类型，比如把"Blue"转换为Fill的类型Brush。<Rectangle Width="100" Height="100" Fill="Blue" />

XAML解析器在寻找TypeConverter时又是分三步：
1）检查属性是否有相应的TypeConverter特性声明，比如Rectangle的Fill属性。
2）如果没有，继续检查该属性类型定义时是否有TypeConverter特性声明，比如Brush类存在[BrushTypeConveter]声明。
3）如果还没有，XAML解析器报错。

由于用Reflector查看上述Brush类看不到……（据说WPF可以看到），换个Reflector反编译能看到的例子，Image的Source属性。 <Image Source="select.png" Height="32" Width="32" />
首先查找Image的Source，发现没有类型转换特性声明，继而查找Source属性的类型 ImageSource，示意如下。
[TypeConverter(typeof(ImageSourceConverter))]
public abstract class ImageSource : DependencyObject
{
    internal ImageSource(uint nKnownTypeIndex);
}

查看ImageSourceConverter的定义如下：
public sealed class ImageSourceConverter : TypeConverter
{
    public ImageSourceConverter();
    public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType);
    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value);
}

如果在某些情况，需要自定义类型转换器的话，从TypeConverter继承，并重写CanConvertFrom和ConvertFrom两个方法，即可实现在XAML中把字符串转换为相应类型的功能。当然，TypeConverter并不是万能的，所以特别复杂的对象属性，还是需要其他语法的，比如Property Element语法。

完整的TypeConverter定义如下，提供了从相应类型转都字符串等功能，但一般都用不到，自定义时也可以不管。
public class TypeConverter
{
    public TypeConverter();
    public bool CanConvertFrom(Type sourceType);
    public virtual bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType);

    public bool CanConvertTo(Type destinationType);
    public virtual bool CanConvertTo(ITypeDescriptorContext context, Type destinationType);

    public object ConvertFrom(object value);
    public virtual object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value);
    public object ConvertFromString(string text);

    public object ConvertTo(object value, Type destinationType);
    public virtual object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType);
    public string ConvertToString(object value);
}

XAML中设置元素属性的语法常见，也不难理解，本文也基本来自帮助文档整理。但诚如题目所言，只是为了强调一下相关语法的术语，为后续可能的文章做铺垫。后文若提到相关语法，则术语替代不会显得突兀和难于理解，同时也无需啰嗦。

对于一般的XAML元素/对象，我们可使用以下4种语法，或其中的语法组合，来设置元素/对象的属性值。

1）使用Attribute语法。

2）使用Property Element语法。

3）使用Content Element语法。

4）使用Collection语法（通常是隐式的）。

1）Attribute语法：
<Rectangle Width="100" Height="100" Fill="Blue" />

2)Property Element 语法：
<Rectangle Width="100" Height="100">
    <Rectangle.Fill>
        <ImageBrush ImageSource="forest.jpg"/>
    </Rectangle.Fill>
</Rectangle>

3）Content Element 语法：
<TextBlock>
    Hello!
</TextBlock>

4）Collection 语法：
<LinearGradientBrush>
    <LinearGradientBrush.GradientStops>
    <!-- GradientStopCollection标签通常可省略 -->
        <GradientStopCollection>
            <GradientStop Offset="0.0" Color="Red" />
            <GradientStop Offset="1.0" Color="Blue" />
        </GradientStopCollection>
    </LinearGradientBrush.GradientStops>
</LinearGradientBrush>

若再省略LinearGradientBrush.GradientStops标签，如下所示，则综合了Content Element语法和隐式Collection语法。

<LinearGradientBrush>
    <GradientStop Offset="0.0" Color="Red" />
    <GradientStop Offset="1.0" Color="Blue" />
</LinearGradientBrush>

其他语法组合示例略，比如StackPanel等。

对于最简单最常见的Attribute语法，XAML解析器帮我们做了一件工作，就是把简单的字符串转换为了相应属性的类型，比如把"Blue"转换为Fill的类型Brush。那么相关的属性或类型应用了TypeConverterAttribute特性，后文详述。

对于Content Element语法，则该类（或其父类）在定义时，应用了ContentProperty特性，比如LinearGradientBrush的父类GradientBrush应用了特性[ContentProperty("GradientStops", true)]。因此在使用时，可省略<LinearGradientBrush.GradientStops>标签。

《Google’s ‘Don’t Be Evil’ Mantra is ‘Bullshit,’ Adobe Is Lazy: Apple’s Steve Jobs》，《乔布斯：谷歌“不作恶”是扯淡 Adobe无作为》。我顶Jobs！任何一个商业公司不作恶那是根本不可能的事，不说谷歌抄袭搜狗，免得走火入魔的G粉们叫嚣那不是俺家Google。Google在非中国作恶的事应该也必须有，尽管我知道的不多，比如当年收购Keyhole和推出街景的那档子破事。其实俺老早也说过“不作恶”就是扯淡，不是拍乔布斯老师马屁，我穷至今没买过任何一款苹果产品。但据你所指如你所料那是根本没有任何影响的，除了别人把我误作百度的5毛。其实，我更不是百度的粉丝哪怕爱好者，尽管用着百度的一些产品。

更多时候，我其实是Google.com的用户。但我始终清醒的认识，这只是一个公司几款产品而已，没啥可让你崇拜膜拜甚至走火入魔的让你为它犯的错也去找理由掩饰或原谅。谷歌学百度学成了今天的熊样，百度开视频走B2C，连IM都加入休闲游戏，开始向模仿大王腾讯学习。李彦宏的“百度专注于搜索”也是扯淡，那你又觉得谁会成功？还有果粉，苹果代表的难道不是一个封闭的专制的生态系统？不过这一切真的无所谓，有好产品使用就行。你所担心的资料出卖信息安全诸如此类等等，有所谓的你脚下的土地拥有者为你保障，尽管你可能不信任它！

你不信任它又如何？有能耐去直接攻击下行政命令的光腚总急或其他单位！拿一部电影看都不看评个一星去撒气？Too Simple！尽管这部电影确实一般，不过持有期望从一部电影中能够看出来孔子如何之成为圣人的想法的同学们，Sometimes Naive！

话说李克强老师在达沃斯论坛上不愿回答谷歌的问题，施密特老师被问到烦。百度的产品出一个产品寒碜一个，连ESRI都知道4326踢走用3857来替代，搞个贴吧地图也山寨得实在见不得人面，更别说地图与大众统一。腾讯关闭滔滔，据说测试微博，其实小马的每个产品都做得相当不错。个人也并不反对山寨学习然后创新，甚至是科研包括天上飞的本来也诞生于类似的步骤。

今天感冒稍微好些，扯扯淡，意犹未尽，不过还是早点睡。如果是喜欢发哥，那么去看看门前冷落发哥独角戏的《孔子》也挺值，也许你看时你那个厅整屋子人的票价总和都不够买一台iPad。最近当当送货怎么那么慢？但哥还是不会去卓越的，尽管去年祝愿卓越一年内死掉的愿望没有成真，但今年有这共同愿望的同学们貌似在王三表、和菜头等老师们的煽动下越来越多了。还有那啥，图书限价令，以及第三极关门的真相？

我吃饱了没事干，凑博客数呢，您就当没看。

Silverlight应用程序中主要存在着两个线程：主线程，一般是UI线程，所创建的所有元素所在的线程。相对的，另一个可统为后台线程，比如从网络上获取数据等。在两者之间的交互上需要注意一些问题，比如在后台线程中无法直接获取UI线程中的元素，因此在后台线程中更改UI对象的属性，则必须调用 Dispatcher.BeginInvoke(delegate(){...});所谓Dispatcher（位于System.Windows.Threading下），即每个UI元素的Dispatcher属性，用它来获取UI线程的dispatcher，从而达到执行操作的目的。

多线程也即在同一时间执行多段代码，与.NET框架线程池十分类似，只不过有些许限制，比如不能用Silverlight代码控制线程优先级。应用多线程可能会带来一些意外的问题，比如同步烦恼、锁定并发症等，因此建议在下列情况下才开启多线程：让客户端更具响应性（比如如果不用多线程，那么在执行复杂耗时的代码时，UI会被锁定，从而影响交互。）；同一时间完成多个任务（比如从远程计算机获取数据，在这期间可以做些其他事情，不必完全陷入等待）；使服务端应用程序伸缩性更加强大。

DispatchTimer：位于System.Windows.Threading下，每隔一段时间触发一次事件，比如去获取某个网络数据看其是否更新。虽然DispatherTimer只是在应用程序主线程上执行，并非真正的多线程，但其用起来有时却和多线程看起来没有什么差异。

Thread：位于System.Threading下，每一个Thread对象代表一个单独执行的线程。如果直接用Thread的话，在程序逻辑复杂的时候可能带来维护麻烦，耦合度高等问题，因此常用构造Thread Wrapper的方式来解决。在线程包装器中，可以增添取消、状态、进度监测等，在完成事件中处理结果。

BackgroundWorker：位于System.ComponentModel下，直接利用BackgroundWorker构件（WinForm@.NET2中引进）可以减少很多包装线程的麻烦，只关注想要完成的任务即可。BackgroundWorker在完成单一异步任务执行时提供了完美的解决方案，具体用法在Silverlight帮助文档中有示例。

热点图，heat map 或 hotspot map，是在二维表面上通过颜色用图示化方法来表达二维数据的一种方式。 维基百科定义的翻译实在拗口，在Google Image（非谷歌）搜索“hotspot map” 或“heat map”可见诸多应用截图，简单明了。用LionGG的话来说，热点图图示化了离散数据（事件或事物）的分布及其相互关系，常常以一张具备显著颜色差异图片的方式呈现最终结果，亮色一般代表事件发生频率较高或事物分布密度较大，暗色反之。

在地图方面的利用，则是根据离散点数据集来源的地理位置坐标，进行相应的可视化表达。（也有人把连续场数据的插值，比如克里金插值，也归为热点图类别，但该部分不在本文讨论区间。）离散数据，点数据。本质上来看，这和点聚合（Marker Cluster）所适用的数据类型类似，只是表现方式不同罢了。

  

常见的应用有：基因热点图，点击热点图（显示了一个网页中哪些区域被点击的频率高低），HeatMap API（在豆友地图中应用过）等。具体的应用场比如交通事故发生率；犯罪发生率；电信基站分布；流行疾病发生分布；零售店分布等等。

  

利用热点图表达，不仅比单纯的点要素显示要时髦，（相关配色和地图相适应，炫目的效果更易吸引眼球。）还更容易发现事件发生频率或事物分布密度。相对关系对比更加明显，甚至可分析出未来趋势等。此外还可以提升性能，点标记太多，浏览器可能无法有效承载，生成图片则是好的选择方式。

     

算法：网上已经流传数个相似版本的各种语言的算法，比如Perl，ActionScript，C#等。原理大致如下：每个点给定一个缓冲半径（像素坐标系），每个像素的值根据距离从中心向外递减渐变；把每个像素所分配的值计算总和；然后再根据每个像素的值，赋予相应颜色即可。比较核心的就是如何确定距离递减函数，（术语：核函数），常用的可能是类似正态分布类似的，

对外而言，有4个重要的接口：点集合，颜色列表，缓冲半径（有buffer,size,resolution等之称）,强度(有scale,intensity之称)。

       

本文参考文献诸多，不再一一列出，请见 http://cang.baidu.com/LionGG/tag/Heat%20Map ，部分参考文献的参考文献也非常有价值，比如维基百科参考中的PDF，主要介绍了热点图在基因图谱中的应用历史。IDV博客也有数篇文章介绍。

订阅博客的RSS地址: RSS

遵循的创作共享协议: CCL

作者和博客详尽介绍: About

文章分类与专题介绍: Topic

A GIS Major @ NJU & CAS