there is a few methods to call a map
sometimes its a direct call to a beginning of a map like lamfa with moving map addr to r12 and axes to r13,r14 (iirc)
another way - map with axes in front of it with structure like X-axis size;Y-axis size;X-axis data;Y-axis data;Map data in that way called first x-axis size (ldrxn for example)

sometimes there is page/segment offsets in code like a example in your link

and special way - call with some kind of shit like a mov r12, [r4+#460h]

yeah because there is 10 00 before axis (16bit data) which means axis size = 00 10 => 10h => 16
and thats where is code called map in this case

you should load it to ida, hex searching for map calls is not a good idea

So, as mentioned above the addressing has been figured out for LDRXN.

I wanted to go forward and use this "call" location and place another call that leads down to free memory. I have done this and added some custom code to point at another free section which points to an exact duplicate of LDRXN in free space.  I am able to keep the ECU happy and it calls towards the new map however map access according to OLS300 shows that only the first section of the "new LDRXN" is being called. 

If I were to look at LDRXN in its normal location I would see access at both the first axis data and the first point in the map itself (when engine is not running)

I am not seeing this characteristic.  Any ideas?

Link below is to show that in small blank space below LDRXN I was able to add a second map with the switch working perfectly.  However, when I try to do the same thing in a further blank space it will only call the beginning of the axis info, not the map information as it does in this video. I can only imagine somewhere in the code there is something that is pointing to a specific page in the flash.  Any input would be much appreciated

https://youtu.be/gaou_7Y2sdU

Success with LAMFA (3D Map), now onto timing and other relevant maps!
Shit this is fun as hell!!!

https://youtu.be/L0TRI55xcXE

well there is a call to math routine after kfzw/2 maps/axes moved to registers

and as i remember there is no availability to change page/segment in this case, its hardcoded to 204 or 206 some kind of that
so when you want to mov your kfzw maps at the end of a file you should basically run your own math routine based on a stock but with page pointers before every memory mov operator i.e.

mov r12, kfzw (ive done this years ago and really forget how to, just example)
mov r13, kfzw_axis
etc
calls #81h, #FFFh ; some routine to calc kfzw outpu

this calls to stock math routine; some kind of

mov r3, [r12+2] ; this square brackets means read from memory where kfzw starts + map offset
mul r3
etc

add some kind of
extp #22Ah, #1 ;new kfzw page num

before every square brackets operation with moved map / axis. (and no change if axis on a stock place)

put this math routine anywhere you want (personally im using 0xB0000 for my own routines and maps because of a tonns of free space usually) and call it instead of a stock

One of the workarounds I've done previously:
Find some large flat (filled with constant values) map in the same page that you need (e.g. 0x10000-0x13FFF). Then find where it's read in the code. Replace the "lookup" call with "mov r4, <map value>". Now you basically have free space where that map used to sit.

Be careful with implementing, and make sure that you don't mess up.

Just had another idea recently (didn't test how it works, though): you can try changing DPP1 to alternate page before "lookup" call, then change it back after you got the result.