标注的压盖避让和同步化显示

要素的压盖避让的定义: 标注尽量避开矢量符号

要素的压盖避让的目的: 矢量符号和标注文本尽量的显示在一张地图上

要素同步化显示的定义: 要素的标注文本和矢量符号要么都显示,要么都不显示.

要素同步化显示的意义: 只出现文本或者只出现矢量符号都不符合地图出版的一般规则.

压盖避让的实现:在标注显示以前,事先把要素按照矢量符号的大小添加到冲突集中,可以根据点线的类型不同,使用不同的冲突集.但是如果图层本身是要素同步化显示,那么就没有必要实现压盖避让了,因为这个过程可以在同步化显示的过程中实现.

要素的同步化显示的实现: 判断是否可以放置标注,判断是否可以放置矢量符号,如果这两个条件同时满足,那么同时放置矢量和符号,同时把二者都添加到冲突集.

在实现的层面上,要素的同步化显示同时意味着压盖避让;反之则不然.

第一次和小妞妞去吃大排档

昨天是端午节的第二天假期，老婆大人建议去新都环岛去吃海鲜大排档。那个地方离我们家不远，走路即可到达。

 

其实我担心的是小妞妞，她还不到7个月，如果带她去的话，会不会有些麻烦？

 

不过万事总有第一次，在做了充分的准备以后，我们就出发了。在半路一个拐角处，还把了小妞妞一泡尿，这让我们更加的放心了。

 

当时里面的人还不是很多，我们找了边缘一个人少的地方。老婆和岳父去点菜，我和岳母守着小妞妞。好像是因为第一次出来吃饭，她也比较兴奋。

 

我们把她放在婴儿车上，期间还因为担心她看着我们吃海鲜，而她却不能，所以会哭闹。但是她很乖，看着我们吃海鲜，她也吃着磨牙棒，竟然相安无事。磨牙棒是她姥姥，姥爷在上菜期间在超市刚买的。

 

一个多小时以后小妞妞有些哭闹了，她可能饿了。老婆决定她和岳母先带着小妞妞回去喂奶，我和岳父继续吃海鲜。中途我给老婆打电话，她却告诉我她们在外面的小孩娱乐中心正玩着欢呢。

 

后来我们又在一起吃了一会，大约快9点的时候才向家走。过了十字口天气就好像变了，好像要下雨的样子。我对老婆说，我们不到家，是不会下的。好像老天爷也照顾小妞妞，我们到家的一瞬间，大雨就来了。

 

一路上小妞妞也没有哭闹。

 

综合这第一次小妞妞外出吃饭，我给她打90分。

 

要求别人和要求自己

我现在控制着一套接口和实现的研发，也就是一个平台的研发，我的原则是：如果接口要想变动，必须在观念上把这个接口定义清楚；否则我们可以通过一些其他的途径实现之。

这当然是对的，这也是我的经验。问题是什么时候算是接口在概念上定义清楚了呢？

对于和我类似的工程人员来说，实现是一个必须要考虑的因素。一个接口定义的再好，如果实现很难，那么也仅仅是在形式上支持一下而已。甚至有的时候，还会通过实现来影响接口的定义。这虽然有些本末倒置的倾向，但是并不少见。我就有过这样的一个例子。

先前孙同学想在接口上添加一些新的函数，被我阻止了，原因就是在概念上还不清楚，至少我认为不清楚；而且在GeoAPI的接口定义中也没有这样的说法。后来由于需求人员的要求，我也需要增加这样的一个接口，我当时认为我已经充分的理解了需求，也有了一个初步的实现方案，所以在接口层面上就做了修改。但是后来证明这个做法没有达到预期的效果。那个同学当然有充足的理由质疑我的做法，因为这里的情况是：要求别人的，自己没有做到。

我想知道的是，为什么会出现这种情况，因为我觉得应该不会出现这种情况才对。我总结了一下，有以下的几个原因：

1. 孙同学先前提出的接口在他看来是简单的，易于理解的；但是在我看来不是这样。所谓“当局者迷，旁观者清”，能够抽身事外看待事情，并不是很容易做到的，这正如我自己增加一个接口一样
2. 接口本身链接这实现，这我和孙同学是一样的，但是孙同学所不了解的是，增加一个接口，不仅是关联实现，而且关联序列化，这两个是我所能够控制的，而孙同学可能只是控制“实现”而已。
3. 我本身有更大的权利，这让我更加容易的去实现某些事情；而别人则不能够。这是一种特权意识下的行为。

所以我的教训是：尽量客观的抽身事外的看待事情；严格的警惕自己的特权意识。