Thursday, November 11, 2010

This blog has moved


This blog is now located at http://blog_en.locapoint.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://blog_en.locapoint.com/feeds/posts/default.

Thursday, June 07, 2007

Google Mapplets "Map Surfer"

Now Opening multi map sites with same location is as easy as net surfing.

I developed and submitted Google Mapplets called "Map Surfer".

You can 'surf' to various map site, with current Google Map's location, by just one click.

http://www.locapoint.com/publicutil/mapplets/mapsurfer.xml

I hope you enjoy it.

Wednesday, December 14, 2005

Categorization of Geocodes (The Story of Locapoint: 6)

In previous posts, I introduced many Geocodes. Although there are many Geocodes, they can be categorized into three types. Every Geocode is belonging to one of them, or combination of them.

1. Mesh-Code Type
Subsequently divide target area into small area, and use mesh id number as a code. Mapcode of Denso is a good example.

2. Encoded type
Use the value of geographic parameters (latitude/longitude, or XYZ, etc) and encode them by specific algorism. Sony’s patent is a good example.

3. Database Type
Store a part or whole of location data into database, and use the key to identify its data as a code.
For example, Navigation-code(by Aishin A.W.) is replace degree part with city name. When decode, use city name to get degree data, and restore location data.

Each type havs following merit and demerit.

























  Mesh-Code type Encoded type Database type
Short display digit Poor Good Good
readability Good Poor Good
maintainability Good Good Poor

I select “Encoded type” as a base of Locapoint. So my task is to improve readability.

Continue...

Wednesday, December 07, 2005

Previously published "Geocodes" (The Story of Locapoint: 5)

Before designing a Locapoint, I had a research for previously published technologies, especially in Patent documents.

I guess everyone thought "Latitude and Longitude format is not convenient", like I did. So there are many 'Geocode's are proposed. There should be more and more code, but I will respectfully introduce some code that I found.
(notice: I wrote some comments on each Geocode. These comments and merit/demerit are my personal opinion and it is NOT an evaluation or blame for these Geocode.)

Mapcode (by Denso)
The Geocode developed by Denso Co. Denso is a Toyota Moter's group company, so Mapcode is basically developed for Car Navigation system.
Divide all Japan regions by some square shapes, and give them a number. Each square will be divided into 900 squares (30 times 30). In this fashion, square will be subsequently divided into 900 squares. With 10 digit of number, Mapcode can represent any place in Japan with 30 X 30 meter precision. 12 digits Mapcode can express 3 X 3 meter area.
The most unique point of Mapcode is optimization of its numbering. High populated area has priority assign of a small number. For example, the number which is assigned to top level and second level square of Tokyo area is 000 and 000. Thus any place in Tokyo is expressed by 000000XXXX -> XXXX. In this way, total length of code can be compressed. On the other hand, minor region still needs 10 digits.
This is a same concept as "G-code" for VCR recording. G-code assigns short (small) number for major TV programs, and leave long number for minor programs.
I guess the Mapcode is the first Geocode that uses this concept.
The demerit of Map code is covered area which is limited in Japan domestic use. In Mapcode's Web sight, Mapcode is preparing to export to other countries. However, to keep 30 X 30 meter precision by 10 digit of number, the square of cover area should be limited. Even if Mapcode is applied in various countries, the codes are not compatible among them.

Sony's patent
Sony has a patent of Geocode in USA.(US Patent 6,005,504)。
Convert Latitude and Longitude into steps (by unit of 0.1 second). Then Convert them into Binary, and join them. Finally, express this binary number in 37th Radix notation, and get 9 digits of code. To express notation with the base of 37, use number (0 to 9), Alphabet (A to Z), and "=".
The key of patent is to add error correcting code on it. For example, make it 10 digit, and use last digit as a check digit. This is a merit to detect input error, especially for this kind of 'Random-look' Code.

The Natural Area Coding System (by NAC Geographic Products Inc)
The Geocode developed by Dr.Xinhang Shen of Canadian venture company, NAC Geographic Products Inc.
According to its web site, it was developed around 1995. I think NAV is the most sophisticated in various Geocodes that I found.
Divide full range of Latitude and Longitude by 30, independently. Subsequently dividing by 30. Dislike other code, separate latitude and longitude data, instead of dividing "area". Expression of code is also display latitude data and longitude data separately. They are expressed in notation with base of 30, using number (0-9) and 20 alphabets. The letters that are not used are bawl (A, E, I, O, U) and (Y). NAC does not have any confusion between I and 1, or O and 0.
Dr. Shen proposes use NAC as a universal address.
For standard format, "5digit + blank + 5digit" have a precision of 0.0000148 degree (=1.6meter) in longitude direction at an equator, and 0.0000 74 degree (=0.8meter) in latitude direction. This has the highest precision in Geocode I saw.
NAC does not has digit limitation, so "6 digit blank 6 digit" can be X30 precision!
There are many merits. With using a "-", it can express areas. it can express "Height" data by format "XXXXX XXXXX HHHHH". Using a 30th radix notation, calculation affinity to degree (360 degree) is well.
I found NAC after I developed Locapoint. However, the concept of Locapoint is very close to NAC.

Compact text encoding (by Microsoft)
After denying the offer from NAC, Microsoft will apply US Patent of Geocode, which is very similar to NAC. Difference between NAC is, a)use small case (NAC:upper case), b)non-use continent is "l" (NAC:"Y"), c)there is no "blank" between latitude and longitude data, and d)the position of latitude and longitude data is opposite. Basically, the concept is exactly same as NAC.

New-Geocode (by Asia aerial survey)
Divide areas into square tile, express in binary, divide them by 6bit, and express it using Japanese "Hiragana" Characters (64 characters). Radix of 64 has good calculation affinity for computer usage.
Demerit is using Japanese Characters.

Navigation Code(by Aishin A.W.)
Express location by Degree, Minutes, and Second, then store ‘degree’s part in database, and use geographic name for its key.
For example, code is like this format :Tokyo23'56"12'33"

BINGEO(United States Patent 6,552,670)

A kind of "Mesh dividing" code. Each Mesh is square, and divided into 4 smaller squares. This smaller is assigned 00, 01, 10, and 11. Repeat this dividing until precision is OK.
For one level of mesh needs 2 byte. The merit of this code is affinity in computer usage, since this code is a binary.

Others:
There are more and more Geocode are proposed by individual, commercial companies, industry, or governments

Continue..

Wednesday, October 19, 2005

The definition of “easy usage” that Locapoint aim to be (The Story of Locapoint: 4)

The definition of “easy usage” that Locapoint aim to be

I have to define the meaning of “easy usage” for Locapoint, in another word, the significance of existence of Locapoint.

First, I re-consider merits and demerits of traditional latitude/longitude format. One of demerit is of course its length. That is why many ‘geo-codes’ are developed. In addition, other demerits are

1.Needs two data (latitude and longitude) to specify a location
2.Variable formats
3.Variable datum

On the other hand, merits are
1.Can be used at any precision level
2.Global availability
3.Values and physical location is continuously related. Increase or decrease in value in latitude/longitude can be intuitively related to physical location movement to North, South, West, and West.
4.Can locate on map, without electronic devices

Reviewing characteristics of traditional Lat/Lon format, it is not bad. Many ‘Geo-Codes’ is certainly shorter than Lat/Lon, but sacrifices most merit of Lat/Lon format. May Geo-code require electronic devices to encode/decode, and code-place relativity is not intuitive.

When I start developing Locapoint, I was about to startup a kind of ‘distress call dispatching service’ business. So, Geo-code that can’t be easily decoded into Lat/Lon without electronic devices is out of my option, because I mainly consider emergency or distress situation usage.
I also focuses on audio recognize ability. I imagine a emergency situation, digital devices are down or out of battery, and only you can use is ‘primitive devices’ such as telephone, walky-talky, Radio communication, or similar ‘analog audio’ devices.
If Geo-code is confusing, miss-listening the code could cause fatal result.

From this viewpoint of “easy usage for human”, I require Locapoint following restrictions.

1. Easily decodable to latitude and longitude with calculator.
2. Easy to read, say, listen.
3. Global availability.
4. Enough precision (hopefully, less than one meter = 3 feet)
5. Relativity between code value and physical location is intuitive.

These are very difficult conditions to realize. How other Geo-Codes is doing. What is merit and demerit of them?

Next, I’m going to introduce other ‘Geo-Codes’.

Continue..

Data compression technique and length compression (The Story of Locapoint: 3)

The method to shorten display length using large base of radix (more than ten) is called digit length compression. I wrote about it in my previous post.

These is a similar word, "data compression". (Concept is different, though).
I consider about losslessly data compression techniques large file could be compressed a lot. In fact, there are lots of compression techniques in IT world. zip, cab, or tgz are a very popular extension for compressed file.
However, latitude and longitude for a point with 1 meter precision is only 50 bit. In byte, it only 7 bytes. Latitude and longitude for any place on earth means, data could be random value. Then 50 bit is minimum requirement. Data compression technology can't be used for single location data.

There is another way to 'fake' compression. Like G-Code on video recording, assign small number for frequently used object. For example, major channel, high viewing rate time, fixed record time (like one hour, two hours) will be assigned small number. When G-code is "23", it originally comes from "0000000000023" etc. (I don't actually know about G-code length). If you want record a minor TV-program, its G-Code should be long and close to original length.
Similarly, Major street in Paris is assigned a short digit, so address will be short and simple.

With this concept, Location code could assign short and convenient code to major cities, and assign longest code for ocean area.
"MAPCODE" designed by Denso Co. in Japan use this concept. Assign short number to Tokyo area, so any location in Tokyo can be expressed in 4 digits of numbers. But in country side, it needs 10 digits.

This method needs "assign" information between area and codes to encode/decode. In fact, if you want to use MAPCODE, you need to buy data from Denso Co.


I have written about demerit of latitude/longitude format. "too long".
However, what is the Merit of traditional latitude/longitude format ?

When someone is in distress in sea or mountain, Lat/Lon format is generally used for SAR(Search and rescue) operation. If you send a mayday with "MAPCODE" and SAR entity didn't buy a assigned data?
The biggest merit of Lat/Lon format is its generality.


I tried to create a code for "easy usage" but now I have to define what is "easy usage".


Next, I will write about my definition of "easy usage" for geographic location code.

Continue...

Wednesday, October 12, 2005

Amount of information and Display length needed (The Story of Locapoint: 2)

To express ANY location on earth with about one meter (or 3.28 feet) precision, I calculated following.

Meridian of the earth is 40,000,000 meter, thus it needs 40,000,000 steps for 1 meter precision. Actually, it requires

20,000,000 steps in latitude direction (a half of meridian),
times
40,000,000 steps in longitude direction
= 8*10^14 steps

is required.

From technology's point of view, 8*10^14 steps is 49.507 bits of information.
To express this data, following length of digits is needed in various radix.

50 digits: binary notation (radix = 2)
15 digits: decimal (radix = 10)
13 digits: HEX (radix = 16)
11 digits: radix=26
10 digits: radix=36
9 digits: radix=60
4 digits: radix=10000

If I choose to create a code which is only using number, it requires at least 15 numbers. Like a credit card number (16 numbers), this is not easy to remember for human.

If I choose HEX notation (0-9 and A-E as 10-15), it needs at least 13 digits. it is shorter, but "28a6f6b021cf3" is NOT as easy to remember as telephone number.

If you know Chinese characters, and know 10000 characters, you may use only four letters for a code. This is much sorter, but it seems inconvenience. In addition, increasing in radix base doesn't look effective in decreasing display digits.


So, I had a two choice.
1. Decrease amount of information
with lower precision (like 30 meter or 100 feet)
by limiting cover area of the code (US only, Japan only, etc.)
2. Keep amount of information
but try to create a "Easy" code for human


Many existing code chose the first one. For example, "map code" by Denso Co. can express any location in Japan with 30 meter precision by 10 numbers. Or 3 meter precision by 12 numbers.

I wanted to create UNIVERSAL geographic code, then I had to choose the second one.
But at this time, I had no idea how to do it.


Continues..

Tuesday, October 11, 2005

The Story of Locapoint

I'd like to record how Locapoint was born.

On 25th, October 2004, I was on a train from Nagano. I met a CEO of venture company in GIS (Geographic Information System) industry to ask some advice, because I was about to start up my own company next week.

I was on my way home to Nara from Nagano. That was a long trip. In a train, I was half-sleep, half-awake. I imagined situation like this.


I'm on my way to a bar to attend a party. But I don't know where the bar. I know telephone number, and I call the bar.
"Hi, I want to go there, but I don't know where you are. We,, I've got a latest cell-phone with GPS navigation. Tell me your latitude and longitude, so I can input them to my Navigator"
"Hey....We can tell you a direction but latitude and longitude!"

Who remember latitude and longitude of own home? Maybe no one.
But most people remember their telephone number. Why?

This question is the beginning of Locapoint Stories.


I thought, may be latitude/longitude is too long for human. There must be a limit in brain capacity to remembering, and it must be between telephone number (10 digits) and latitude/longitude (15-16 digits).

I thought about "G-code" that is used for VCR recording. G-Code is a compressed code that contains channel, start time, and end-time(or time length).

I thought I may develop a 'G-code' for location, so latitude/longitude information can be shorter than brain capacity limit. If people can easily use GIS information, so world will be more convenient!

I opened a lap-top, open excel, and start some calculation.

Continues..