Sector file tools for conversion of coordinates

[Jonas Kuster]

Happy new year to you all!

I'd like to start this year with some news to share regarding some tools for sector files I've developed a few years back. I've finally had the time to bring a major update online. Some of you have maybe used these (and some of my other) tools already in the past.
Please don't mind the non-existence of any style/design features. I'm not so much into web design. And my priority is just to ensure the functionality.

You find an overview here: https://kilojuliett.ch/webtools/.

Mostly interesting for sector file managers is the coordinates converter (earlier called coordinates importer). It accepts a large number of coordinate formats, including some AIP description formats of airspaces. Just enter what you have on the left and see immediately the result (both in text and a drawing on Google Maps). In some cases, adjustments of the input text might be necessary to create the desired output.
https://kilojuliett.ch/webtools/geo/coordinatesconverter

Also updated is a tool to easily draw runway extended centerlines. The threshold coordinate can be of any value accepted by the coordinates converter. The runway direction and the ticks can then be easily configured.
https://kilojuliett.ch/webtools/geo/rdrawer

Both pages got addtional options to tailor the output, feature now cookies (so your last used settings will be used when you return) and the individual elements got updated with tooltips providing additional information regarding the use or accepted formats. New formats were added for the output.

Please feel free to share any feedback, bugs (there still might be some despite extended tests) or proposals for improvement.

[Chris Gutierrez]

Hello Jonas,

 

Thank you very much for those tool, they are very helpful to us in the Nav Departments 🙂

I would like to add a few futures/improvements.

In the previous Coordinate Converter, I was able to directly copy and past coordinates from the German AIP and convert them. Unfortunately, this is no longer available.

Here is an example out of the AIP:

 

Would it be possible to add the coordinate format?

 

My second future request has to do with the Runway centerlines.

It would be great to create Dashed Centerlines like in this picture.

 

Thank you for you effort Jonas and i would like to hear back from you

 

Kind Regards

Chris Gutierrez

RG Bremen Nav Department

[Jonas Kuster]

Hello Chris

Thanks for your kind words. There was indeed an issue with AIP coordinates from the German AIP compared to the previous version, mainly because the algorithm used (which is just a very complex regex) was completely changed in order to capture more types of coordinate formats. Jannik made me aware of this issue already and I implemented a fix a few days ago. Could you check if the AIP coordinates now work for you as well?

I'll let you know when I've implement a dashed version of the centreline.

Regards

Jonas

[Chris Gutierrez]

Works perfectly now!

Thank you

[Itay Fishman]

Hello, how do I run the the tool, cant find any button does executes the program?

[Jonas Kuster]

@Itay Fishman The output does update automatically via javascript. There was a small issue preventing some formats, which I fixed upon receiving another feedback. Can you check if it works now for you as well?

[Jonas Kuster]

Today a added improvements and new options for both tools mentioned in the initial post.

The coordinates converter is now accepting even more formats. I've added more details about them in the placeholder text of the input box. I've also added details there how to use the tool to draw circles (it was possible already before, but not properly documented). Any coordinate format can be followed by a dash and numerical value, which represents the radius in nautical miles, to draw a circle. If only a specific radial or an arc should be drawn, use another slash followed by the numbers for the radial and optionally either > (to draw clockwise), < (to draw counter-clockwise) or - (to draw the shortest way) plus the radial where the arc should end again.

Remember that a large number of syntaxes used in AIP can be used directly, including descriptions of arcs and even tangents around two center coordinates. If you find a format or text example that doesn't work, reply to this thread. Maybe I can add support for even more formats.

The coordinates converter now also interprets 5LNC (5 letter name codes of waypoints) and navaid identifiers. This was already an option earlier, but required some improvement and re-coding due to different changes to the code in the meantime. Waypoints and navaids need to be written in upper case. Their names can be used like any other coordinate format, and even combinations are possible. If a waypoint or navaid is the first coordinate of a group and multiple matches are found, all results are added in individual groups. If a waypoint or navaid follows any other coordinate and multiple matches are found, the closest only is taken.

Additional formats have been added for download.

 

The tool to draw runway extended centerlines features now an additional option to draw dashed centerlines. @Chris Gutierrez let me know if this fits your needs.

Edited January 22, 2022 at 05:21 PM by Jonas Kuster

[Paul McDyer]

Hi Jonas,

This tool will come in very handy in the future. However, I do have one question. The value "new lines between polygons" suggest that if that is set to one and I enter two polygons shown in the attached picture that the output would remain two separate polygons. It obviously doesn't do this as the two polygons are still showing as if they are one so am curious...I am complete misinterpreting what this value means or should it in fact create two separate polygons?

 

[Jonas Kuster]

@Paul McDyer To indicate the end of a polygon in the input box, you need to use "//" (see last part of the placeholder text in the input box).

Depending on the use case, this may be helpful or not. Iim considering adding an option to accept also empty lines as polygon separators in a future update.

Edited January 25, 2022 at 09:00 PM by Jonas Kuster

[Paul McDyer]

Ahh yes, my fault for not reading the whole body of text. Appreciate it! I really like the tool by the way.

[Chris Gutierrez]

Hello Jonas,

 

very nice Job. I have one more request. Could you add this format?

54°35.00'N 009°02.72'E

 

Best regards

[Adrian Bjerke]

Hi Jonas.

 

I have noticed that when I input decimal coordinates it does not correctly "translate" them, making them very offset.
The error seems to occur on the latitude, however the longitude seems to match. Have tried with several coordinates in different regions of the world and all has the same effect.

 

Examples:

 

 

However, if I take coordinates with negative longitude, it handles them correctly:

 

[Hongye Rudi Zhang]

Hi, thanks for the amazing work! I just found a small issue. 

This format is written in the readme and AIP, is it not available to use?

[Chris Gutierrez]

@Jonas Kuster 

I have one more Idea for the Coordinator Importer. It would be nice to generate Dashed Lines with a simple command or setting between two points.

Kind regards

Chris Gutierrez

[Jonas Kuster]

I pushed an update to the server just a few minutes ago. Most changes are fixes (thanks for all the reports!), but also some features have been done.

• Improving the detection of different formats, including the issues reported by @Chris Gutierrez, @Adrian Bjerke and @Hongye Rudi Zhang. I hope I didn't break any others (since the algorithm is intended to cope with all sorts and variants of formats and doesn't require strict patterns, this may happen), but if so, please let me know by answering this post.
• Reading of the default decimal format has been improved as well for different use cases.
• Empty lines (including any whitespace characters) are now considered to directly initate a new polygon, as @Paul McDyer expected. This option can be deactivated, but is enabled by default.

Also the RWY drawer got an upgrade, which allows now a higher level of detail for tick frequencies. "Large" ticks have now priority over "small" ticks, resulting in the values of the "large" ticks being considered for distances that match both tick frequencies, even if the specs/values (width) for the "large" ticks are smaller. It's just a first-come-first-serve principle now, where it was a value-based sorted (larger tick, higher prio) list before. Ticks can now also be specified to be drawn on either side of the REC only, thus supporting more setups, which may be common especially for parallel runways.

@Chris Gutierrez For now, dashed lines are only supported by the RWY drawing tool. For other lines, I suggest to use the symbology options of the controller client where applicable, thus also compensating for scale effects. Maybe you can illustrate your use case for me to better understand your issue, then I might consider a change in the future.

Edited April 30, 2022 at 08:19 PM by Jonas Kuster

[Jonas Kuster]

Last but not least, I've worked on some rounding issues resulting in DMS outputs displaying "60" for seconds or minutes. They should at least be much less frequent now. If you still find them, please post your data from your input field as a text answer to this topic. Thanks!

[Hongye Rudi Zhang]

@Jonas Kuster Maybe add a holding pattern calculation with arrow? like name/coordinate/inbound course/inbound length

holding one/N038.35.41.974 E120.17.51.400/288/12 export as

holding one NXXX.XX.XX.XXX EXXX.XX.XX.XXX NXXX.XX.XX.XXX EXXX.XX.XX.XXX

basically it is 4 leg calculation

[Jonas Kuster]

20 hours ago, Hongye Rudi Zhang said:

Maybe add a holding pattern calculation with arrow? like name/coordinate/inbound course/inbound length

Thanks for your proposal. I do currently not plan to implement this.

[Hongye Rudi Zhang]

On 5/11/2022 at 10:29 PM, Jonas Kuster said:

Thanks for your proposal. I do currently not plan to implement this.

all right some regrets😟

[Hongye Rudi Zhang]

found another bug, E1190000 exported as E119000000001.00.00.000

[Jonas Kuster]

2 hours ago, Hongye Rudi Zhang said:

found another bug, E1190000 exported as E119000000001.00.00.000

Please let me know the entire data entry you made.

[Hongye Rudi Zhang]

3 hours ago, Jonas Kuster said:

Please let me know the entire data entry you made.

[Andreas Fuchs]

Would it be possible to add "Qutescoop" as output format? To implement new or changed airspace, it is usually a lot of work to extract and prepare ESE sector lines for conversion with another tool.

Should you consider this, the format is the following:

dd.mm:dd.mm
Before the colon it is latitude, where positive values are NORTH and negative values are SOUTH.
After the colon it is longitude, where positive values are EAST and negative values are WEST.

Examples:

• 49.44:10.97 = 49.44N, 10.97E
• -19.12:08.22 = 19.12S, 08.22E
• -44.91:-70.00 = 44.91S, 70.00W

Thanks for considering!

[Jannes van Gestel]

Bug

When trying to draw a circle or arc with coordinates in the Southern Hemisphere the system returns the "correct" coordinates but for the Northern Hemisphere.

Input used:

S033.21.22.680 W056.29.45.964

circle(radius 30nm, S033.21.22.680 W056.29.45.964)

Edited May 16, 2022 at 08:36 PM by Jannes van Gestel

[Chris Gutierrez]

@Jonas Kuster 

Dashed Lines would be very helpful to draw realistic Sectors.

Euroscope has only limited futures drawing dashed lines.

It would be nice to set a Start and End coordinate and say I would like 3nm spacing between those lines.

DFS in RL uses custom dashed lines for Sector boundaries some smaller some bigger gaps it depends on Airspace type.