此刻，无法自抑

阿琳的病情却在逐步地恶化。1945年6月16日，她去世了，那时他们结婚才三年，离第一次核爆炸只有一个月了。理查德陪她度过了生命的最后一刻，可是他很麻木，仿佛失去了知觉。他对自己的缺乏感情感到很吃惊。几个星期以后，当他路过一家商店的时候，看到了一件连衣裙，他想要是阿琳穿上一定很美。这时他才突然悲从中来，他失声痛哭，无法自抑。

此刻，无法自抑

出处：the whole universe is in a glass of wine
更多：百度百科：理查德·费曼

ArcGIS 10.1 for Server加入站点时报错Unable to access the config store on …

在一台Windows Server 2003 R2 X64 SP2机器上装好ArcGIS 10.1 for Server后，加入已有site时，Manager报错：

Failed to join the site 'http://esri-wzf:6080/arcgis/admin/'. Server machine 'http://esri-wzf:6080/arcgis/admin//machines/register' returned an error. 'Failed to register the server machine 'WIN03'. Server machine 'http://WIN03:6080/arcgis/admin' returned an error. 'Unable to access the config store on '\\esri-wzf\arcgisserver\config-store'.''

排查和解决办法：

1. 确保config-store目录的权限正确：文件夹属性中“共享”和“安全”两个标签页中都需要让系统账户（默认为“arcgis”）具有读写权限；
2. 确保ArcGIS Server的Windows服务的登陆账户为ArcGIS的系统账户（默认为“arcgis”），而不是localsystem。因为以localsystem启动的Windows服务进程对局域网共享位置没有访问权限。正确设置如下：
   

这回问题出在第二点，ArcGIS 10.1 for Server的安装进行过一次修复，之后Windows服务的启动账户就变成localsystem了。改回默认的arcgis账户即可。

ArcGIS中读取.bil文件

客户现有一应用程序可读取.bil栅格文件作为高程背景显示，如下图：
 
数据文件有：demo.bil文件（2,077,616字节），index文件（74字节），projection文件（58字节）。现需要转入ArcGIS平台来进行显示，查看帮助，ArcGIS对.bip栅格格式有原生支持。但在ArcMap中加载该文件时，确报错无法打开。
查看ArcGIS关于.bil格式的帮助说明，得知.bil是一种未经过压缩的二进制文件。存储格式如下图：
是按行依次存储每个波段每列像元信息的。要在ArcGIS中显示，必须有一个.hdr头文件描述其所需的一些元数据信息才行。而拿到的数据中并没有这个.hdr文件，所以要构造出该文件。查看.hdr文件的说明，是以文本方式记录了该栅格文件的行、列数，每个像元值所占的大小等内容。而原来的应用程序之所以能够读取该图像，也离不开这些信息。用记事本打开index文件，内容如下：

demo.bil 641890.000000 656130.000000 3251870.000000 3281050.000000 20.000000

乍一看并没有.hdr文件中所需的信息，但能看出上述的5个数字分别代表了.bil文件空间范围和空间分辨率。由此我们来推导.hdr文件所需的元数据信息：

• NROWS：栅格文件的行数，(3281050-3251870)/20=1459；
• NCOLS：栅格文件的列数，(656130-641890)/20=712；
• NBANDS和NBITS：分别代表栅格文件的波段数和存储一个波段中每个像元值所需的比特数（pixel depth），index文件中并没有这两个信息。但.bil文件是未经过压缩的，所以我们用.bil文件的大小除以行数再除以列数，2077616/1459/712=2，得知每个像元位置上所有波段值共占2个字节（16bit）空间。理论上可以是NBANDS等于1，NBITS等于2×8=16，也可以是NBANDS等于2，NBITS=8。但我们知道逻辑上此图记录的是高程信息，相当于dem，所以应该只有一个波段，由此得知NBANDS=1，NBITS=16；
• PIXELTYPE：由于是高程信息，所以pixel value都是正值，因此此处是UNSIGNEDINT；
• BYTEORDER：存储每个像元值字节的排列顺序。可以由高位到低位的M，也可以是由低位到高位的I。结合原程序代码，得知此处是M。

由此创建的.hdr文件如下：
  有了正确的.hdr文件后，就可以在ArcMap中直接加载了（projection文件用于设置正确的投影信息）：

感谢@红毛小屁孩的指导帮助，比帮助文件好用得多。

Portable Basemap Server发布2.0.7版本

更新内容：
~为影像数据源增加本地缓存（.cache文件）功能。详见这里；
~在线地图转换/下载到MBTiles格式时，增加按Shapefile文件范围下载功能。详见这里；
~为转换后的MBTiles文件增加了”压缩”选项，某些情况下可大幅减小MBTiles文件体积。详见这里；
下载地址：https://geopbs.codeplex.com/
详见：http://blog.newnaw.com/?p=890

出租车拼车应用

和上回的地图微博一样，这只是个想法，欢迎各位转载（请注明出处），讨论，实现。
拼车应用搜索一下已经有不少，可问题是普遍功能过于繁琐,需要注册，并且拼车需要事先商定，不够自由和实用；前些天看了有报道说重庆推出了打车的移动应用，用户可以呼叫附近的空车。可问题是，在大多数人需要打车到时候不是看不到附近的出租车，而是根本就没有空车。这个与用手机查询附近厕所在哪，加油站在哪一样，有点多此一举，直接动嘴问问要快速环保得多。
所以这次设想的是一个专门针对出租车的拼车移动应用。虽然一些城市已经开始鼓励拼车，但实施起来问题很多，经常造成矛盾，设想有了这个应用后，出租车拼车可能会变得方便可行受欢迎。应用分两种客户端，一个是乘客用的，一个是出租车司机用的。

1. 如何拼车：乘客打开应用后，可自动获取自己当前所在位置，只需输入自己想去的目的地即可；出租车司机在每拉到一个客人后，输入一下本次送客的目的地即可。这样出租车的客户端就可以计算出从当前位置到达目的地的所有路线，并显示出所有可行路线附近，与本次目的地相同的想要搭车的乘客位置，司机就能根据意愿，准确找到可以捎带的乘客，而不用盲目停车询问；乘客输入目的地后，可在手机上看到，行进路线经过当前或附近位置，并且目的地与自己相同或相近的附近出租车，通过点击该出租车，就可以向出租车司机发出拼车请求，出租车司机收到请求后（可能有多个拼车请求），可以根据意愿选择要捎带的乘客。在没有拼车成功之前，出租车的客户端可根据当前的行进路线，动态刷新周围需要拼车乘客的信息；而乘客也可实时看到，可以满足自己拼车要求的出租车位置；乘客和出租车都有发起请求或接受请求的机会；
2. 如何避免抢客或抢车冲突：仅仅有匹配机制还不行，因为如果多辆出租车同时想拉同一个乘客或者多个乘客想拼同一辆车就会产生冲突，这时可以通过和阿凡达星球的生物配对一样的机制，来解决这个问题。当乘客向出租车发起请求，该出租车应答了乘客请求后，或出租车向乘客发起请求，乘客应答了出租车后，即认为他们配对成功，就会同时从其他所有乘客和出租车的客户端上消失；对于出租车而言，本来想去拉乘客A，但还未走到跟前发现A已经消失了，就知道A被同行拉走了，应用会自动推荐并显示下几个适合捎带的乘客，由于没有绕路和停车，就不会影响最先上车的乘客；对于乘客来说，本来想搭乘出租车A，但还没发起请求或发起请求未收到应答之前，就发现A已经消失了，就知道A拉了别的乘客或者出租车拼的已经满掉了，即可向下一辆车发出请求，这对于打车的人来说再正常不过；
3. 如何避免恶意请求或恶意应答：这个可以借助评价体系和移动设备的定位功能来解决。乘客和出租车都有相应的信誉值，比如淘宝的几颗心或者几颗钻。乘客发起或应答请求时自然会选择钻比较多的出租车，出租车应答或发起请求时自然会选择心比较多的乘客。信誉值如何累计呢？如上面所说，乘客和出租车建立阿凡达连接双双消失在地图上后，他们必然会为本次建立连接而增加或减少信誉值。依据就是乘客的位置和出租车的位置是否有过重叠。如果是乘客发出的请求，系统会以乘客当前位置为评价标准，如果出租车到过该位置而最终此次拼车没有成功，则可能是乘客放了鸽子，搭别的车走了，乘客信誉减少；如果是出租车发起的请求，系统仍然以需要搭车乘客的当前位置为标准，如果此次拼车未能成功是因为出租车根本没有经过该位置，则可能是出租车放了乘客的鸽子，出租车信誉减少；拼车成功并结束后，双方信誉加一；
4. 如何计算合理的收费：有了位置信息后这个就很简单了，按照乘客上下车经过的路线来计程即可，避免了传统拼车司机不好合理收费的问题。而收费时可以利用移动设备NFC（近场通信）功能来完成，只需将手机和出租车客户端接近一次即可完成收费付费过程，具体应用可以是支付宝/paypal或者网银/google wallet。

一些补充：

• 出租车使用的客户端可以是具有语音输入输出，大字体显示功能的平板设备，方便司机在不停车的情况下进行操作（这在国外已经是事实了）；
• 这个应用双方无需注册即可使用，减少部分用户对于任何注册过程的抵触情绪。但如果不注册则无法显示用户信誉，减少拼车成功的可能性（对于低信誉的用户如果想要通过匿名使用的方式来隐藏自己的劣迹的话，若干次后服务器可将其列入黑名单或标记该移动设备为欺诈等级，依据是设备的mac地址或其他唯一标识）；
• 对于平台运营方来说，功能简单所以实现成本小，应用必须通过服务器端交互所以具有很强的用户粘黏度，不用担心用户流失或被抄袭；
• 可抽成，在每一次拼车成功支付时抽成5毛，做为平台报酬；
• 如此拼车若可行，可考虑适当降低燃油附加费甚至起步价，降低乘客成本的同时也可给司机带来更多的收入机会；
• 至于拼车是否合法的问题在此不做讨论。