Follow your heart (106)---sculpture park and POI

下午,带朋友去了雕塑公园. 突然很想爸爸妈妈,想接他们来住. 现在,奶奶不在了,他们也可以走的开了.我们全家最不后悔的事情之一,就是带从没到过大城市的小脚奶奶来过一次北京.那时她88岁.当时,我们都做好了她万一回不去的心理准备,她自己也做好了准备. 之前,家里,为这事情,有过激烈的争论.奶奶自己是想的,爸爸开始是坚决反对的,我和妈妈是支持的.那是她几十年,唯一一次离开我们那小镇.一辈子唯一一次出省,唯一一次坐火车.站在广场上,她说现在这里的人除了躺着的那个老爷爷,大约我最大了? 我笑,说是的,奶奶.

现在还能想起她回去拿着照片给其他老太太老爷爷看时开心的笑容.有时,真的很想她.想到她,就觉得死亡,不可怕.到了那边,可以见到她.

可惜,我没带她坐过飞机. 后来,没陪她去乡里的亲戚转一圈.没和她坐一起反复看还珠格格,希望,在父母身上少些遗憾,不过,好像是不可能的.我们总是在自己亲人身上会有很多遗憾. 老指望以后,能做些什么什么,老是拖延,拖到后来,很多,总是没机会去真正做... 其实,我们在自己身上也有很多遗憾.

我想象爸爸妈妈来后,自己陪他们来这里的情景,这个公园很适合他们休息时转转的.坐车很方便就到了,里面空气也好.还有免费的锻炼的器具.

在那里遇到一个坐在偏处,一个人拉京胡的女的,她说过了60岁了,买的年票进来的,一年50元. 她说她刚刚开始学京胡.我坐在那里安静地听了一会.确实是拉的不成调,但我喜欢这样的状态.任何时候,开始做自己喜欢的事情,都不晚.任何时候,都要认真对待自己.

走走,锻炼一下,看看人家放风筝,心情很平静平和. 好久没这么平静享受了. 我和p说,这大半年和程序员打交道,我的感觉是,这些在室内工作,在城市工作的人,好像很少有真正enjoy自己的工作和生活的,很少真正开心的,都在计算和算计M中生活...很少有以工作为乐趣的...精神寄托也少...能遇到一个享受自己的工作,把日常的工作做为乐趣的人,实在太难了...

在你们国家,我去IWC表厂参观时,遇到一个工作40年的修理工,后来,给汽车换机油时遇到一个汽车修理工,去地里帮人家摘葡萄时,和那个葡萄农交谈,他们都很享受他们的工作....真正的是享受工作...现在,实际接触的程序员,就没有遇到这样的...可是,在网上,还是能看到有的啊...

我自己这点倒还算是幸福的了,很多年来,当时做的事情,都是自己当时很享受其中乐趣的...即使有很多别人眼里或自己实际的困难,但还是很享受做那些事情的过程本身的...即使现在,这么困难,这点上,还是觉得很好,是自己选择的做的自己想做的...

只要当时能生存,我倒是很少过于从M的方面计较是得还是出,只选择自己当时最想做的.在我的概念里,在生命本身的角度来说,那肯定是得的.你选择自己当时很喜欢做的事情,真正享受那段日子,肯定是得.任何其他的得,肯定是附带而来的.只要真正努力,真正付出,那些纯粹的谋生还是顺带能做到的..活着,很简单...享受活着,要态度...不过,现在,有时,也真的很不享受了...我好像和社会有点格格不入了...我要争取尽量重新适应...

然后去全聚德吃烤鸭. 朋友比我还中国,不吃那甜面酱,用辣酱吃烤鸭...

早上问了一个问题,天凉不在线.我从谷歌抓了一个地址 名称 经纬度信息,保存了.填的自己的感受,后面,要是一个用户,也去了这个地方,但他填了很多其他的,比如照片,他的感受,这个地址数据,是再存一次吗.还是先直接建一个地址库,其他和这个相关的业务信息另外存.

印度人的答案是:What is POI database stands for? Is it just another database MySQL database. Yes, I can design the app to write to two databases but the same database structure should be there in both the databases, if we have some different schema in POI then it will be extra work.

一个上海的朋友的答案是:
存毛了
当我新手啊
肯定有个主表的咯
配一个 业务关系表
具体的 业务表

有很多种方法
一般都是  业务表 主表 业务和主表的关系表
这3类

这个那他以什么为主体了
印度人可能认为 地址是主体业务对象
也没错

一般都是 BIZ表 REC表  BIZ-REC表
这样 IZ表 REC表  都是独立的
我们做系统就是这么叫的

这样做的好处就是  我要去掉一个业务 只要断开他们的关系就好了
人-一个对象  地址一个对象
他们本来就没关系

我问,那嗯,这个人,旅行,地址
人 有很多次旅行, 一个旅行里,有很多地方

还就是 多个关系

BIZ-TYPE BIZ-ID
还个一个关系类型
REF-TYPE
有这3个量 啥都好搞

什么类型的某个业务 和谁发生了什么类型关系

我觉得这个 数据库结构还是蛮科学的
这样做以后 的 数据或者业务的迁移啊什么都会很EASY
就改一个关系表么就好了嘛


这哥们在找工作,5年java经验,希望找到一份月薪1万的工作,但不愿意离开上海.

评论

3 楼 Jennycn 2011-10-10  

openrace 写道

引用

5\这只是个人理解，有大部分用于地址及经纬度相互解析的，应该说命中率比较高的，也就 说用户经常用到的居住地，行走路线起止点进行标注时，应该是可以缓存的。

这个,我就是不懂啊,点是可以缓存或者完全保存在自己这里,可是,线呢?

线是由点组成的，缓存的只能是点，而不是线，如果按照google map api渲染路线的方法所需要数据的组织方式可以实现的，那么线也是可以缓存的。但缓存的只是点的数据。

function calcRoute() {
  var start = document.getElementById("start").value;
  var end = document.getElementById("end").value;
  var request = {
    origin:start,
    destination:end,
    travelMode: google.maps.DirectionsTravelMode.DRIVING
  };
  directionsService.route(request, function(result, status) {
    if (status == google.maps.DirectionsStatus.OK) {
      directionsDisplay.setDirections(result);
    }
  });
}

也就是说，只要已经有了缓存的必要路线点（起止点，路标点），按照directionsDisplay.setDirections所需要的数据result)结构方式组织数据传入。估计应该可以实现调用google map api 渲染路线的效果。这个没有试过，只是这么猜想。实现这个问题的难点在于缓存足够的地址信息，并打包成相应合适的result数据结构传入。

嗯,谢谢哈,学习了

看来是,有点,有生成路线的方式,就相当于缓存线路了,不用再次调用了

2 楼 openrace 2011-10-10  

引用

5\这只是个人理解，有大部分用于地址及经纬度相互解析的，应该说命中率比较高的，也就 说用户经常用到的居住地，行走路线起止点进行标注时，应该是可以缓存的。

这个,我就是不懂啊,点是可以缓存或者完全保存在自己这里,可是,线呢?

线是由点组成的，缓存的只能是点，而不是线，如果按照google map api渲染路线的方法所需要数据的组织方式可以实现的，那么线也是可以缓存的。但缓存的只是点的数据。

function calcRoute() {
  var start = document.getElementById("start").value;
  var end = document.getElementById("end").value;
  var request = {
    origin:start,
    destination:end,
    travelMode: google.maps.DirectionsTravelMode.DRIVING
  };
  directionsService.route(request, function(result, status) {
    if (status == google.maps.DirectionsStatus.OK) {
      directionsDisplay.setDirections(result);
    }
  });
}

也就是说，只要已经有了缓存的必要路线点（起止点，路标点），按照directionsDisplay.setDirections所需要的数据result)结构方式组织数据传入。估计应该可以实现调用google map api 渲染路线的效果。这个没有试过，只是这么猜想。实现这个问题的难点在于缓存足够的地址信息，并打包成相应合适的result数据结构传入。

1 楼 Jennycn 2011-10-10  

天凉回答了我的问题,我分段消化一下.

1\个人理解，这个数据存储应该是相同的只存一次，不同的不断添加。在每次添加时，取得相应的需要信息如：名称，地址，经纬度（也就除了这些数据外，不知道是否还需要其它的相关数据），保存起来。

嗯,应该就这些吧,就是地名会有中文英语的,不过,是结构化的,也就是说有级别的.

今天重读google的api文档,看到它的关于抽取结构化地址的那段了:
抽取结构化地址
如果要访问有关某个地址的结构化信息，GClientGeocoder 还提供了 getLocations() 方法，该方法返回包括以下信息的 JSON 对象：
Status

request - 请求类型。在本例中，始终是 geocode。
code - 响应代码，类似于 HTTP 状态代码，指示地址解析请求是否成功。请参见状态代码完整列表。
Placemark - 如果地址解析器发现多个匹配项，则可能返回多个地标。

address - 格式化良好，大小写正确的地址版本。
AddressDetails - 格式化为 xAL（或可扩展地址语言，一种地址格式化的国际标准）的地址。

Accuracy - 表示指定地址的地址解析所能达到的精确度的属性。请参见可能值列表。
Point - 三维空间中的点。

coordinates - 地址的经度、纬度和海拔。在本例中，海拔始终设置为 0。
下面我们展示使用地址解析器解析 Google 总部地址返回的 JSON 对象：


2\视不同的情况进行利用。也就是说按不同情况处理，比如说：当用户输入居住地时，如果需要标注，在数据存储里有的，可直接取出经纬度，便可在地图上标度注，而不用调用google map的api先取经纬度，再进行标注,

嗯,谢谢,这个我明白了. 是只标注,就不用再次解析了,是吧.只用谷歌地图标注,是没有限制的.


3\如果要想使用自动完成输出的方式，可能分两阶段处理，一是直接从存储数据中取，取不到，再调用google map api展现结果，同时并保存不存在的地址数据，但这样处理起来就需要多做些事情。

就是在自己的存储数据里,先autocomplete,找不到就去谷歌那边autocomplete? 这个,技术人员做不做的到的? 也是,要是先谷歌autocomplete,再回来和自己库里的判断有没重复,决定保存不保存,是多了一道了...而且,要是不会用的,可能对那个解析次数的限制还有问题.


4\另外就是路线起止点的标注，如果起点及路标都存在本地数据存储中，那么可以直接取经纬度标注，否则也需要调用google map api来进行地址解析来标注.

我的理解和疑问是,2点生成路线,实际在系统保存的是2点的地理数据,和一个连接2个点生成路线的模式...不可能是保存2点之间的无数个点连成线路,所以,每次无论哪个用户要看那条路线,或编辑那条路线时,是每次都要调一次谷歌api的,是吗? 或者是,这个,只要在第一次保存后,后面是不用调用google map的api的? 对,这个就是你下面这句话,我想问的.


除此，关于路线标注，如果无法组织数据实现连线，则必须调用google map api来实现。这时，即使有缓存数据，也无法可用于实现。

5\这只是个人理解，有大部分用于地址及经纬度相互解析的，应该说命中率比较高的，也就 说用户经常用到的居住地，行走路线起止点进行标注时，应该是可以缓存的。

这个,我就是不懂啊,点是可以缓存或者完全保存在自己这里,可是,线呢?

6\但是自动完成，路线标注连线，如果不能实现连线效果(这个我了解不多，估计可能比较麻烦，没有了解过按照google连线的方式组织数据)，那也就是说要使用google map api来实现这样的效果，另外，还有的自动完成（数据不全，很难说有需要的结果）效果，当然用google map api就很方便