Get Denso Mapcode from Denso server using a bash command

get-denso-mapcode.sh

wget http://post.denso-communications.jp/dn/navicon_start.php --method=POST --body-data="lat=35.872722875676274&lng=139.73869658316153" -O - -q | grep -Po '(?<=id="mapcode">)([^<]*)'

Disclaimer

Denso Co Ltd keep for themselves how to generate these codes, so using their server seems okay to me. Denso Mapcodes are widely used in Japan, especially in car satnavs, so obtaining mapcodes ought to be as free as free speech. Well, it bloody sure isn't. I understand that Japanese businesses do not yet fully understand the appeal of being open, so I suppose scripting it is the next best thing. They don't even provide the simplest of API's, so the second-best thing would be to scrape a webpage they return when requesting a code. And this command does exactly that.

References

https://en.wikipedia.org/wiki/Denso_mapcode
For more information on Denso Mapcode

Visually get mapcodes

http://japanmapcode.com/en
Does use its own proper JSON API, but since it's a personal project, I rather not "punish" him for Denso's fault of keeping everything a secret.

I found a Chinese site that had info about Mapion
https://josephliu1206.pixnet.net/blog/post/25753253

Mapion seem to have an algorithm to find the japan-mapcode. Example:
https://www.mapion.co.jp/f/mmail/send_mobile/SendMobile_map.html?lon=130.99586961830084&lat=34.272715550129554

Still not ideal.

I dont know if scraping is what we want...
Maybe figure out if there is any logic in the Zone/Block/Unit blocks.
Maybe its just counted 30x30 = 900 for Block and Unit ? S core seems weird... looks like 9hor 9vert ?
https://www.denso-solution.com/mapcode/en/whats.html

Im going to look into this... Maybe the blue japan is giving us a hint on the Zones...
(Can't find any sense in it just yet)

This is an interesting site:
https://saibara.sakura.ne.jp/map/convgeo.cgi

There's definitely logic, but it's also littered with exceptions. Especially the first block of digits is often tied to a city or region, rather than a translation from geographic coordinates. I think only the last two digits (after the asterisk) are truly and always coordinates-based, as the graphic explains as well.

And because of this, I gave up on trying to reverse-engineer an algorithm of sorts, because exceptions can make it really annoying (if not impossible) to get accurate results algorithmically.

Well, if anyone is interested. I've scraped the zones from saibara.sakura.ne.jp/map/convgeo.cgi
google drive: denso-mapcode-zones.js
As it turns out they are a bit off... Looking into that.
I'm going to check them on mapion, but random checks show it looks okay.
Next is figure out the Block/Unit/S-core

I'm seeing a lot of overlaps. I wonder how those are handled. Maybe it's just simply the lower zone number get prioritised.

Also, kudos for visualising the zones on a map. Definitely a useful way to ensure/verify everything is covered.

We are getting there... 😄
Still not seeing how the overlap actually matters.. Some places even have 3 overlapping zones.
All these mapcodes seem to point to the same lat/lon when reverse searching.
The code I have now picks the highest number by accident because the code is not very smart yet.
Still trying to figure out how it actually works.
I did find I scrapped the zones to tight. They should be 9m bigger...

Good to see in overlapping zones:

For putting the mapcode in a car navi these differences don't really matter I think.
And I don't know if a car navi in Japan is okay with wrong zones.
But yeah,... needs to be fixed just to be more neat.
More later.

I think I will create a client-side (Vite-Vue3-Leafjs-OpenStreetMap) solution.
And I don't know if Denso is going to be happy with their "secret" zone data on the clients browser.

I've made a story on medium about my adventures with mapcode:
https://bespired.medium.com/adventures-in-denso-japan-mapcode-6743694d26a8
with a repo in github https://github.com/bespired/mapcode

Very cool! There are a few typos, but that's okay. Maybe extend the article to answer the seemingly important questions in the comment. But other than that I think your contribution is going to be really helpful 😎 I really respect how you allowed yourself to "bite" into this issue and not let go until you found a suitable solution 👍🏻

Thanks Martijn.
Still need to check if any random coordinate actually gives the correct answer.
But I found something I don't really understand yet.
Apparently the Longitude/Latitude of Japan are not the same as the Longitude/Latitude of the world (???)

So putting global lon/lat into Mapion doesn't actually works. Because they are not the same as the Japanese lat/lon... I don't know, I find this very confusing.

Apparently Japan has earthquake shifted lat/lon?
https://www.fig.net/resources/proceedings/fig_proceedings/fig_2002/Ts5-5/TS5_5_ishihara.pdf

This is all far beyond my comprehension. Pretty nuts if you ask me...
And way beyond my initial wish to just have a Japan Mapcode from under my cursor.

Hi there

We recently hired a car in Hokkaido and came across MapCodes for the first time. I thought it would be cool to use MapCode instead of WGS coordinates or telephone numbers for POI lists for future travels. This is, how I landed here.

I noticed the same problem a while ago with deviations of typically a few hundred meters between WGS coordinates and those of NTTs public telephones shown on their map (e.g. https://publictelephone.ntt-east.co.jp/ptd/map/guidemap/135928390_505721060).
After a lot of investigations, I found the correct method to transform coordinates from Tokyo datum to WGS84. The method is called "Molodensky transformation".

The parameters I used to obtain correct results were:

dx = -148
dy = 507
dz = 681
da = 739.845 // 6378137 - 6377397.155
df = 0.00001003749114 // (1 / 298.257223) - (1 / 299.1528128)

I used the following Python code to verify correctness of the conversion:

from pyproj import Transformer
# Define the transformer using Molodensky parameters including da and df
transformer = Transformer.from_pipeline(
    "+proj=molodensky +ellps1=bessel +ellps2=WGS84 +dx=-148 +dy=507 +dz=681 +da=739.845 // 6378137 - 6377397.155 +df=0.00001003749114 // (1 / 298.257223) - (1 / 299.1528128)"
)
# Sample points (Tokyo Datum)
points = [
    (34.70838000, 135.52248000),  # P1
    (34.73319170, 135.55993810)  # P2
];
# Transform the points
transformed_points = [];
for lat, lon in points:
    # lat_transformed, lon_transformed = transformer.transform(lat, lon);
    lon_transformed, lat_transformed = transformer.transform(lon, lat);
    transformed_points.append((lat_transformed, lon_transformed));
    print(lat_transformed, lon_transformed);
transformed_points

The results correctly show "my" two public telephones at (34.71162167071122 135.51966303882074) and (34.736431415423006 135.55711700823204), respectively. As always with these things... your mileage may vary ;-)
Best regards and good luck with your project
Peter

@MrZuerrer
That's amazing. And goes way above my sense of comprehension.
Nice to see more people interested in Japan Mapcode.
I think for practical use I would not mind when visiting Japan again that the actual destination is a few 100m away from what my App says, because we need to find a parking spot anyway. And we use it to visit tourist attractions, not Ms Tanamakas house...
But a bit weird Denso keeps it a secret.

@MrZuerrer
Brilliant work! It's weird that we "have to" reverse-engineer it, as @bespired said, but it's pretty amazing how you were able to come up with those numbers. I'm curious, are they based off of any type of logic, or just magic numbers to "make it work", so to speak?

My use case involved solving a puzzle with the solution pointing to a particular public phone in Osaka. Hence my need for precision.

The parameters I used are "well" documented. You can find one such example in https://gis-lab.info/docs/nima-tr8350.2-wgs84fin.pdf. Documentation, however, is not meant for the uninitiated such as me... But I am persistent ;-)

BTW... I used Mapion in the past but did not realize they also provide MapCode. I will refine my PowerShell / Selenium script to drive the Mapion web page (e.g. https://www.mapion.co.jp/m2/34.735775957141,135.55287836095266,16) and with a few simulated clicks I can get the MapCode.
This addresses my requirements in a pragmatic way and given I typically need less than 50 waypoints, I can easily feed the coordinates to the script and collect the MapCodes.