# How may I introduce GPS coordinates as a waypoint in Prepar3D?

## Recommended Posts

Hi,

I'm having problems to introduce GPS coordinates, Latitude, Longitude, from Google Earth into my flight plan, in Prepar3D.

As you may know, you can introduce waypoints directly in your flight plan, just by click over the red line that describe your route.
For example, if you select a direct flight from airport to airpot via GPS, it will draw a straight line from your departure to your destination.
Then you have a tab called EDIT in which you can edit that straight line, just by clicking over it, you will be able to introduce waypoints. Just click with the left button of your mouse over the red line, hold the left button and move the mouse, you'll see you are moving a waypoint along the map. In this easy way you can draw literally a flight plan.
Okay the problem is when I am trying to introduce coordinates in the waypoints.
For example, let's imagine we have drawn a waypoint... and now we see it on the right side, in our flight plan.
If we click over it Waypoint WP1 and we press the button edit, we can enter coordinates.

As far as I know, P3D only accept decimal coordinates, right?
Okay.
I am trying to introduce the following GPS coordinates in the Waypoint WP1

GPS COORDINATES

LATITUDE: 41°55'54.00"N

LONGITUDE: 2°46'18.00"E

P3D don't accept these coordinates, so I must convert them to the decimal system.

I convert these coordinates to the decimal system with an online conversion tool and I get these results

LATITUDE: 41.931667

LONGITUDE: 2.771667

However, when I introduce the coordinates, the results I get are unpredictable and weird.
See it yourselft.
Gosh! what is this?

I've been reading a bit and seems to be the P3D coordinates systems it's complex and conversions from GPS coordinates to decimal coordinates don't work unless you apply some manipulations, but I don't know what kind of manipulations or corrections do I need to convert successfully GPS coordinates to the P3D system.

In Microsoft Flight simulator it was very easy, you were able to introduce GPS coordinates with degrees, Latitude, Longitude, but Lockheed Martin changed this system to other system I don't understand well?

I am converting from GPS coordinates to the WGS84 system and also don't work...

???

Observe more weird things, just by introducing some GPS coordinates, I get multiple routes with only 1 waypoint !!!

How may I convert GPS coordinates to the P3D coordinates system?
What coordinates systems use P3D ?
Do we have any conversion tool online that really works?

Cheers

 Help AVSIM continue to serve you!Please donate today!

Just to test it, I made a plan. Then I dragged a line in the plan and it created a new waypoint. I edited the waypoint and made changes to the coordinates. Each time, the changes in the plotted line made sense. I couldn't put an incorrect character in the edit boxes. So not sure what to make of it, it should work OK.

No, the problems is how to introduce GPS coordinates in Prepar3D. The problem is not Prepar3D cannot allow the entrance of new coordinates, the problem is how to introduce GPS coordinates from Google Earth into Prepar3D, because Google Earth gives you GPS coordinates system, and when you convert that to decimal system, you get weird results in P3D.

That is the problem and the subject to test.

P3D don't use GPS coordinates, it use, I guess decimal coordinates, so you cannot enter...

LATITUDE: 41°55'54.00"N

LONGITUDE: 2°46'18.00"E

You only can enter decimal numbers.

What I did is to convert those values, to decimal values, then I tried to introduce them in Prepar3D and don't work, I get those weirds results.

For testing purposes just create a flight plan, direct GPS from LEGE (Girona, Spain) ---> TO ---> LECO (La Coruña, Spain)

You will see a straight red line.

Create a waypoint just clicking over the red straight line thus dragging a new waypoint.

Once the waypoint is created, please, edit it, and try to change its position introducing the GPS coordinates I mentioned before.

How do you do that?

Do you convert those numbers to decimal?

What system is using Prepar3D?

If you could report back, I'd be grateful.

Cheers

Then get properties .

As you can see, even though we searched in decimal coordinates, choosing preferences, and degrees,min,sec, Apply,OK.... Pulling up properties shows the proper conversion to degrees minutes and seconds. Will do the same thing with a known might see him and Google earth place.

Let's choose an end corner of KBUR's Rwy 26, in google Earth in DD,MM,SS, Change preferences to Decimal degrees, hit APPLY,OK...right click the stick pin, and choose the properties tab. Copy the Decimal Degrees to your notepad...OR just leave Google earth open if you have the memory., and launch Prepar3d, go to world, maps, and copy the Decimal Lat/long into your coordinates. Accept the new position wit OK, AND ...

Once loaded go to View, Outside(with North Orientation chosen), Top Down. Where are you?

Chas

Hi,

there seems to be a localization issue in the dialog. Are you on an European PC? We use "," (comma) as decimal character, that is why "41.931667" isn't working (P3D is interpreting the "." as 1000s denominator). Try replacing the "." (point) in your numbers with "," (comma) and you will get a waypoint at the GIR VOR.

The input field however is always depicting the US-EN type of decimals with a "." (point) => output is showing different format than expected input => bug.

The conversion itself should be relatively straight forward: degrees + minutes/60 + seconds/3600.

As for the sim "using" this or that - internally a program will always work with a decimal representation of the coordinates, everything else would be very clunky and slow. Don't know if the P3D coordinate system is offset somehow though. And it is inconsistent, in the map the lat/lon input fields have the deg - min format...

btw. this localization issue existed/exists already in FSX and there in other places too, IIRC there were problems when the sim was reading AI or other flightplans using the "wrong" locale. Don't know if these still exist though. At some point I decided to always run an ESP based sim on a separate Windows installation with US-EN locale...

You can use VfrFlight (http://vfrflight.org) to make flight plan with custom GPS coordinates in a convinient way, and then you can export this as PLN file for P3D.

If you right click on the table, you can view/edit coordinates in decimal system:

Lukasz

AVSIM closed the edit window too early for me to finish this &\$))(;<#<;5!!!...so here's Part 2.

Let's choose an end corner of KBUR's Rwy 26, in Google Earth in DD,MM,SS, Change preferences to Decimal degrees, hit APPLY,OK...right click the stick pin, and choose the properties tab.

Copy the Decimal Degrees to your notepad...OR just leave Google earth open if you have the memory., THEN...

launch Prepar3d

1. Choose GOTO Airport

2. choose KBUR Rwy 26

3. Choose view, outside orientation, North up;

4. Choose View, Outside, TopDown and you should see below

5. Go to world, maps, and copy the Decimal OR the DDMMSS Lat/long from GOOGLE EARTH into your P3D Map coordinates. Accept the new position with OK, AND ...

Once loaded go to View, Outside(with North Orientation chosen), Top Down.

Where are you?

Hope this helps

Chas

And nice input there, Chas, as I've just re-installed the Google Earth Pro. Your screenshots will go a long way to help. although I do use PFPX or FSC9 to create my flightplans,and then if I'm so inclined, import them into the default GPS, when using aircraft that do not have the high-end FMCs.

Hi, thanks a lot to everyone for posting here and offering help. I really appreicate that.
I'll reply everyone by his name ok? So I don't forget anything...

nuitkati
SOLVED THE PROBLEM, HOWEVER I WILL EXPLAIN THIS IN DETAIL AND REPLY TO EVERYONE.

I did a video reply showing the bug and how to correct this. Also I am posting this video in the Lockheed Martin forum.

https://youtu.be/Xv09VfjWioQ

FIRST THING, THE PROBLEM EXACTLY IS: Summarizing, that you cannot enter in Prepar3D GPS coordinates in the fashion of North, South, East, West, degrees, minutes, seconds. Prepar3D allow only a kind of decimal coordinates, however I am not sure about what system is using Prepar3D exactly.

ALSO AND VERY IMPORTANT, when I convert these coordinates...

LATITUDE: 41°55'54.00"N   *****   LONGITUDE: 2°46'18.00"E

To the decimal system... I get this:

LATITUDE: 41.931667 ***** LONGITUDE: 2.771667

When I introduce those numbers in Prepar3D, it show crazy values.

NOW I REPLY EVERYONE AS FOLLOWS:

hesynergy

I am in Spain, Europe, so I am using Google Earth Pro in Spanish, however I've reviewed your settings and I have configured Google Earth Pro in the same way.

THE DECIMAL SYSTEM IN EUROPE, SPAIN IS: Miles are separated by a point, decimals by a comma.

One thousand = IN SPAIN 1.000 (I guess in US English is 1,000)

One thousand = IN SPAIN 1.000,25 (I guess in US English is 1,000.25)

I am not interested to go to any runway, I want exactly that point. It is a VOR/DME from Girona, I want to go particularly to that place.
The idea behind this is you can locate GPS coordinates and fly directly to them, so you can fly VOR/DME arcs and other maneuvers in a very easy way.

nuitkati

YOU ARE ABSOLUTELY RIGHT AND YOU SOLVED THE PROBLEM.

This is a bug dealing with the regional settings in Prepar3D.

*** BUG DESCRIPTION: ***

US users probably won't have this problem, but some countries in Europe for sure are having it.

The problem occur for European users separating thousands with a point "." and decimals with a comma "," in that case, Prepar3D present a bug dealing with the coordinates input system.

When Prepar3D show decimal coordinates, independently of the country and the locale settings from the PC in which the software is installed, Prepar3D present the coordinates in the following way:

Numbers and decimals are separated by a point. That is the way Prepar3D show the results.

Let's take for example a VOR/DME station. Girona, Spain, VOR/DME station.

Latitude: 41.931667
Longitude: 2.771667

This is the way Prepar3D show the coordinates and the way Google Earth gives you the coordinates.
If you introduce the coordinates in this way, using a point, and you are in the United States, I guess this works fine.

HOWEVER, if you are abroad the United States, in Spain for example, and you try to introduce the coordinates with a point to separate decimals and not a commma, which is what we use here in Spain to separate decimals, a comma, the results you get are unpredictable.

So, even if Prepar3D is showing the decimals separated by a point, when you introduce the decimals, if you are in Spain or other country that separate decimals using a comma, in that case, you must ignore that Prepar3D is showing you the results separating decimals with a point.
In that case, you must use your locale settings and introduce the coordinates, separating that decimals with your locale settings, that is, using a comma.

THE CONFUSION HERE COMES WHEN PREPAR3D IS SHOWING THE DECIMALS SEPARATED BY A POINT AND NOT BY A COMMA.

If you are in the United States, Prepar3D must show you the decimals, separated by a point, so when
you introduce decimal coordinates, you must introduce numbers and decimals separated by point.
HOWEVER IF PREPAR3D IS INSTALLED IN A COMPUTER ABROAD THE UNITED STATES, it must show the coordinates using the locale settings, so for example, if you are in Spain, Prepar3D must show you the coordinates separating numbers with a comma and not a point. In that way, when people abroad the United States introduce coordinates, they won't use points, they will use commas.

People is confused by this, because if you see Prepar3D is showing you the results with a point separating the decimal part, obviously, when you want to introduce a coordinate, you use a point. WRONG. ERROR. WRONG. If you are abroad the United States, and in a country like Spain, in which decimals are separated by a comma and not a point, you must ignore the way Prepar3D is showing you the results and you must use a comma and not a point.
To avoid this confussion, Prepar3D must show the coordinates using the locale settings of the PC, so when it corresponds, it will show a comma to separate decimals or a point, according the country the software is installed and the regional stettings.

hesynergy(Chas)

Where do you find that 'Then Get Properties' as in your screenshot for Google Earth? My Google Earth pro properties was greyed out.

vc10man please, see the video demonstration of the bug, in the video I show also how to edit the properties of the marks in Google Earth, however, it is very easy.

Just click on the mark you have placed in Google Earth and then, right click, with your mouse over the mark. You will see a menu and then select properties.

Also, in Tools, Options you can configure the way Google Earth is showing you the coordinates, and you can use the first option which is compatible with prepar3D, that is the decimal coordinate system.

twojastara

Amazing tool, hower, I guess you can plan also an IFR flight right? Because I see its name is VFR flight... but because we are creating a flight plan with GPS coordinates, we can do also an instrumental flight with this. Am I right?

Other doubt I have is I see this tool is dealing with METAR DATA, that is weather conditions.

Could we introduce the METAR DATA in P3D in some way?

Cheers

Gracias, wipeout01

Lockheed-Martin expressly states that the sim is designed to work with only the U.S. locale. They don't promise that anything other will work without issue.

It is not a bug, but rather an intent to not deal with the complexity of multi-language support.

No, the problems is how to introduce GPS coordinates in Prepar3D. The problem is not Prepar3D cannot allow the entrance of new coordinates, the problem is how to introduce GPS coordinates from Google Earth into Prepar3D, because Google Earth gives you GPS coordinates system, and when you convert that to decimal system, you get weird results in P3D.

That is the problem and the subject to test.

P3D don't use GPS coordinates, it use, I guess decimal coordinates, so you cannot enter...

LATITUDE: 41°55'54.00"N

LONGITUDE: 2°46'18.00"E

You only can enter decimal numbers.

What I did is to convert those values, to decimal values, then I tried to introduce them in Prepar3D and don't work, I get those weirds results.

For testing purposes just create a flight plan, direct GPS from LEGE (Girona, Spain) ---> TO ---> LECO (La Coruña, Spain)

You will see a straight red line.

Create a waypoint just clicking over the red straight line thus dragging a new waypoint.

Once the waypoint is created, please, edit it, and try to change its position introducing the GPS coordinates I mentioned before.

How do you do that?

Do you convert those numbers to decimal?

What system is using Prepar3D?

If you could report back, I'd be grateful.

Cheers

Works as I described. I couldn't input wrong characters as I stated.

Lockheed-Martin expressly states that the sim is designed to work with only the U.S. locale. They don't promise that anything other will work without issue.

It is not a bug, but rather an intent to not deal with the complexity of multi-language support.

The problem, and I guess you did not understand this, is, that when you input coordinates to Prepar3D it is not using US locale, it is using the systems settings locale, it's clearly a bug. The simulator shows the decimal coordinates using the US locale (that is right) but to input coordinates in the simulator it is not using the US locale, it is using the regional settings of the computer, and in this case it is expecting a comma (wrong) and not a point, as it should be using the US locale. So, I am sorry, it was demonstrated it is a bug.

SteveW to reproduce the bug you need a computer with Windows 7 or 8 or 10 installed in Spanish with the regional settings also configured to Spanish, Spain. In a computer from the UK you won't have this bug because you are using separators for thousands as a comma and for decimals as a point. You need a spanish computer dude. I am sorry.

Yes the problem with other than US English the edit boxes show a zero and cannot be used. The PC must be set to US English number formats to use the Edit Waypoint function.

Gracias, wipeout01

Gracias a ti amigo

Yes the problem with other than US English the edit boxes show a zero and cannot be used. The PC must be set to US English number formats to use the Edit Waypoint function.

No. World exist outside the United States and the United Kingdom, and of course normal users won't set their regional settings to the US settings in Windows, everytime they run the simulator. No that would be a very painful job to do, all the time, also unrealistic since a practical point of view. People install Windows, set the settings to the regional settings of their countries and the software adapt itself to the settings.

As I said, Lockheed Martin have two options to solve this bug.

1. Use the regional settings from the computer Prepar3D it's installed to show the coordinates and also to input the coordinates. In other words, if Prepar3D it's installed in Spain, you must show the coordinates with a comma to separate decimals. Also when inputting coordinates, you must accept you separate decimals with a comma.

OR...

2. Use always the US locale settings, displaying a point to separate decimals and accepting you input coordinates with a point when separating decimals.

What you cannnot do is: Using the US locale settings to display the coordinates and using the system regional locale settings to input the coordinates. It display the decimals separated by a point, when you introduce the decimals it expect a comma... ???

Since a programmer point of view (and I am also a computer programmer) solving this issue requieres just 1 or 2 lines of code. Perhaps, even less. It's a minor issue to solve since a programmer's point of view, and could give many headaches to many users.

The result is this conundrum. See the map.

In my best Emily Litella imitation.....

"NEVERMIND!"

wipeout01... doesn't really matter what you think. L-M has stated they will only support US locale settings... it is what it is.

WarpD the problem is you don't read the thread in full, then you are posting messages that have no sense. To understand this bug, you need watch the video in full and read the messages in full, describing the bug.

Seems to be you did not understood the error.

FIRST THING, YOU HAVE THE WATCH THE VIDEO IN FULL.

I will explain this easy.

In computers from Spain:

- Prepar3D show the coordinates with a "point" decimal separator (US Standard)

- When you introduce coordinates, Prepar3D don't accept the "point" as a decimal separator (US Standard), instead, Prepar3D need a comma as a decimal separator (it use the locale settings).

CONCLUSION: In computers from Spain, Spanish, Prepar3D is showing decimals separators with a point (US Standard) and when inputting coordinates to it, Prepar3D don't use the point as a decimal separator, it need the locale settings in this case a comma. If you introduce coordinates using the point, US Standard with a computer in Spain, you drive crazy to Prepar3D and get weird results in the map.

When showing results use a point (US Standard), when inputting results, need a comma (locale settings, Spain).

This evidently confuse the users and consequently it's a clear bug.

If Prepar3D use always the US Standard, it need to show the results with a point as a decimal separator, and also using a point when inputting the coordinates, AND NOT using the locale settings from Spain.

I can't explain this more easy. Please, read the post in full.

If Prepar3D show the results using a point (US Standard) it must use also a point (US Standard) when inputting results to it, and not a comma.

Cheers

Yeah... set your locale to US English like L-M says it needs to be... no bug. Doesn't get any easier than that.

Yeah... set your locale to US English like L-M says it needs to be... no bug. Doesn't get any easier than that.

I can't find this in the list of System Requirements on the Prepar3D site. Should IMHO be in there if it is a prerequisite.

Well WarpD I guess you want finish with the last message in the thread and you want "to be right", at any cost. In urban dictionary usage, I'd say this is "trolling". Never understood why trolls act this way, but it's the same. If you want to be the only one thinking this is not a bug, fine. For me it's perfect.

For me it's the same, however I consider necessary explaining why this is a bug. Not you, I know it will be completely impossible to have a reasoning with you, so I explain this to all the users (except you, of course)

The reply to you is: YOU ARE RIGHT. Okay? So we save time.

One thing is changing the regional parameters and other different thing is a software, let's say P3D or let's say other software confuse the user.

If the software present a number using a point as a decimal separator, then, when you input results to that software it must accept a point as a decimal separator, and not the locale settings. It show results with a point, it must accept results with a point too. As simple as that. End of the question. Finish. Kaput.

Softwares are intended for human beings and not to confuse the users. That's not an opinion, that's real.

The problem is: P3D is showing coordinates using a point as decimal separator, and then, when inputting the results, it ask for a comma (other different decimal separator).

So, it shows a point as decimal separator, and then, when you enter a value, it expect a comma as decimal separator.

Any people with a bit of "normal common sense" can see something is wrong here.

That is a bug.

Why?

Because when you create a computer program and you input a value, you can load that value in a temporary variable of the string type, and then, analyze character per character. With this information, you can locate decimal separators and correct them on the fly, changing a comma for a point or viceversa if necessary.

In this way, a computer program can work everywhere assuring always the results you input, will always works fine and be corrected properly. That would be a kind of autocorrection, like the one you find in Google when searching.

The problem here, is, many people doing these changes in Windows, accept this, as it is, because it is. End of the question.

No. To change a bulb you don't need to learn how to be a monkey and jump over the room until you finally get the bulb on the roof.

To change a bulb you only need a staircase. As simple as that.

Well, I am a computer programmer also, so I know very well when you input a result, it goes to a variable, and then you can work with that result. I know this is a bug (not all people have this knowledge) and also I know when you input a value, you can analyze the result character by character, also knowing what kind of decimal separator is being used, and correct it on-the-fly, to avoid this kind of problems.

When a computer program is correctly developed, the first thing it will do, is asking the system the locale settings and adapting itself to the locale settings for basic input / output operations.

However, if that involve to change a lot of code, that it doesn't, there are other solutions, like getting the results into a temporary variable of the string type, and then, reading character per character to find decimals separators and correct them on the fly in other temporary variable, until you finally provide to the code the right value.

In other words, that you can correct this kind of silly errors very easily.

Probably normal users don't accept this as a bug, because they simply think, this is the only way to make Prepar3D work, changing all the time the regional settings... but, no... I am sorry. This is clearly a bug. I am a programmer, and I know what I am talking about.

And if someone is telling this is not a bug, it's simply a lie. Perhaps for trolling, popularity reasons or who knows, everything else.

Well... I'm certainly not a programmer so...

• 1

As I programmer I am, I know this is a bug. Cheers

## Create an account

Register a new account

• Tom Allensworth,
Founder of AVSIM Online

• ### Hot Spots

• Flight Simulation's Premier Resource!

AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!