By Harry Sugden 1237658
#526468 This isn't an issue on ES3.1, but it has been an issue on ES3.2 for as long as I've been using the .sline function on this version. Basically, the seconds on coordinates determined using the .sline tool are pretty much always off...

Code: Select allRETSI N052.30.42.000 W002.52.33.000


Now if I zoom all the way in as far as possible on my EuroScope ASR, and use .sline exactly over the fix RETSI, I get...

Code: Select allCOORD:N052.30.42.000:W002.52.32.000


Now for another...

Code: Select allMAY 117.900 N051.01.02.000 E000.06.58.000 ; Mayfield


.sline produces...

Code: Select allCOORD:N051.01.01.000:E000.06.57.000


Infuriating!!!! :( Does anyone else have this problem?
By Harry Sugden 1237658
#526495
Jonas Kuster 1158939 wrote:Harry, did you round the decimals of the seconds yourself? Because I hardly get exactly 000 when I use sline.


If you zoom in as far as possible (until you can’t zoom anymore!), and .sline over a point in the sector file that’s .000 :)
By Harry Sugden 1237658
#526532
Jonas Kuster 1158939 wrote:Harry, what file did you take for reference for the coordinates?


Well, fixes and other navaids all come from the NATS AIP ENR documents - but that's besides the point really, since I've been involved with the sector file for over 4 years now and I'm sure it's not an issue with any of the data.

What would be helpful is if someone else could zoom all the way in on a known fix that they have the coordinates for, use .sline, and check whether they have the same issue described in my original post? That might be able to help me establish whether it's a EuroScope problem or a Sector File/.dcenter issue...

Thanks
By Jonas Kuster 1158939
#526541 Assuming you are talking about the UK sector file, I just found out that the package - at least the one which is available for me through ES download - contains only ese/sct file. So the source will be the sct file. For other advanced sector file packages, it also could be the isec file.
So I checked the fixes you mentioned and got:
for RETSI: COORD:N052.30.41.000:W002.52.33.000
for MAY: COORD:N051.01.02.000:E000.06.58.000

But I have to admit also that the zoom factor seems not detailed enough to precisely click on the spot. If I click slightly west or south, I can see that initially the seconds are reduced by one and only when going farer away, also the seconds decimal change from 000 to 999 and so on. Seems to be a rounding problem or at least an inconsistency between the seconds and the decimals.
By Harry Sugden 1237658
#526542 I get what you’re saying but it isn’t an issue using ES3.1 - get the exact coordinate as defined in the sector file every time...

Thanks for having a look - as long as it’s not just me then I guess I will have to keep correcting coordinates a little for the time being!
By Jonas Kuster 1158939
#526584 I still wonder what for you need the sline command in connection with waypoints. Maybe you can explain the use case. I think there are easier solutions than how you do it.
By Harry Sugden 1237658
#526586 The use of .sline with waypoints is simply to demonstrate the issue :)

The UK has a lot of CTAs being established at the moment which replace airspace previously encompassed by airways - when this happens, I need to use .sline to determine which of our old ‘AIRWAYS’ lines in Geo to remove since they were never labelled back in the day.

Another use - some of our sector lines (we have a huge amount considering both Scottish and London sectors!) are named in ways that don’t help identify them, so again .sline helps when trying to edit/adjust things.

Anyway, finding an alternative way to do something doesn’t solve the issue that’s occurring which is obviously something to do with EuroScope. So this thread is more of a way of pointing out that there is an issue to fix!
By Jonas Kuster 1158939
#526627 This tool might help you to get parts of your sct file analyzed visually quicker. The advantage is, that you can read the coordinates directly when hovering the points.
https://webtools.kusternet.ch/coordinatesimporter

Also consider using GNG in the future. It includes f.e. an updated airway structure according the current AIRAC and sector lines (also those to be displayed between active ATC) are calculated automatically once you provide a set of points and sector definitions with those points.
I'm using this to create sector file for the EuroCenter vACC. So I'm aware of the number of airspaces in Europe. And in my opinion, GNG is the only tool that allows the amount of work required for complex sector files to be done within a reasonable time.