Since BATC started using Navigraph’s data for runway lengths, Inibuilds EGCC 23L is no longer depicted fully within BATC, the scenery itself however, has the full runway implemented properly as per the SDK.
I understand this is due to your data not depicting what would be considered the extended threshold, and therefore it’s not “useable runway” However, at EGCC, aircraft can, will, and do, use the holding points at T and VA for departure, and will use the entire runway length. I understand this may a fringe case, but could the data here be looked at please? And just to cover the bases, the runway was depicted properly before your data was implemented 
Hello! Welcome to our forum!
Hmm, this is what we have in our own app:
This looks like an issue on the SayIntentions side. It appears that they are not showing the “Shoulders” (taxiway/runway) - both types are included in the data they have access to.
Unfortunately, that means we can’t do much to help in this instance! We’re happy to help them out if they need it, but it looks like they would just need to include these elements in their current selection!
Kind Regards,
Malte
Hi!
So, it’s BeyondATC no SayIntentions 
I think the issue lies, as you can see in that first picture, the actual “runway” ends just before VA which leads to a “non-depcition”
What ideally should be the case, is that it extends all the way to the end of the extended threshold.
I’ll feed back to the devs and see what they say about it! Hopefully some kind of compromise, or solution can be reached.
Haha… Of course! Mixed up different things - my apologies!
Yes, but that is correct, as you mentioned. The runway does end there. The rest is the runway/taxiway shoulder, at least as defined in our AMDB database.
It’s all a matter of the presentation of the available data at that point! In my honest opinion, that extension should not be treated (or visualized) as a runway:
I assume that if you would treat it as a runway, the aircraft would start taking off from this section, which I am quite convinced would not be allowed IRL given the arrows. Might be wrong though - do you know how it is used IRL? You definitely should not land there at least, that’s for sure! 
Haha I’m sure you’ll be forgiven!
So yeah, I completely understand what you’re saying, however, this is a bit of a niche/fringe case.
23L is used 99.9% of the time as a departure runway, and aircraft do/are allowed to start their roll on the arrowed section (I worked there for 10 years, seen it plenty)
Landing though, you are exactly right, on the extremely (and I do mean extremely) rare occasions landings happen on 23L, the displaced threshold is, of course, adhered to.
I know it’s niche/fringe, but is there any way the data can be modified/manipulated for this?
No, unfortunately, there is no chance of that happening. Our AMDB data comes from the real world, and the real world will follow the rules without exception.
Looking at the data (and the chart), the area in question is divided into two parts: An extended threshold and a “starter extension”. This aligns with the AIP:
Landing threshold displaced by 186 M.
Starter extension of 150 x 30 M. Hard shoulder width at starter extension is 15 M. Hard inner shoulders along full length of Runway 05R/23L have a width of 7.5 M and a PCN of 42/R/C/W/T. A stabilised grass outer shoulder is prepared to a width of 7.5 M along the full length of the runway.
Red = extended threshold, Blue = starter extensions 1 & 2
So it looks like we provide all the necessary information to visualize the runway exactly the way it is painted in real life. Even extending the runway slightly with an extended threshold that is not painted IRL on Google Maps (but documented in the AIP)!
You could ask them (BATC) to visualize the starter extension, too, of course! Or just paint the runway/taxiway shoulders, which would result in something similar to Navigraph Charts. But we cannot modify this information in our database - that would reflect badly on the source of the data (Jeppesen AMDB).
Just FWIW, the runway section before the threshold, with the white arrows pointing towards the “displaced” threshold is indeed available for takeoff in either direction (and for rollout after landing), generally (rather than specifically at EGCC).
The VIDP 29L example mentioned on WikipediA is rather noteworthy, almost 5 thousand feet
Edit: As I understand it, it’s also why, while for many runways, the TORA is equal to the LDA (even though the first touchdown zone markings and the aiming point markings are 500 resp. 1000 feet from the threshold, the LDA still starts at the runway threshold), whenever there is a displaced threshold, then the TORA will exceed the LDA (usually by however much those runway portions extend beyond the respective thresholds).
Regards,
Tim
Thank you for the extra trivia!
Do you see any contradictions between this information and what’s already mentioned? That part of the runway is indeed noted as starter extensions in our data and the AIP, so to me it aligns well!
Nope, the Navigraph Charts depiction (and thus, presumably, the data driving it) looks fine to me. It does seem like the issue is with the way BeyondATC is depicting/parsing the data.
Regards,
Tim