[Genma Saotome]

dmrick44, on 11 November 2016 - 04:35 PM, said:

If you are like many of us who create routes, you'll find yourself using Google Maps or Google Earth to determine where things are in the real world... and then transfer those coordinates from Google into the Route Editor. Google Earth works great when it comes to transferring sets of data (locations) from Google Earth into a *.mkr file for the Route Editor.

What about the goode-homosoline skew?

dmrick44, on 11 November 2016 - 04:35 PM, said:

Mike and I created a utility for doing just that.

What about the goode-homosoline skew?

If you don't skew the google data it won't conform to the same location as anything else in MSTS RE.

[jasonattorney]

I use GE to make markers (and toporoute.com which is unbeatable for tracing lines, btw) and i just realized that the OR compass code needs to check to see if a route has been 'Ortho'd' in Demex and then compensate for the 'correction' from Demex 'Offset markers' to give coordinates along the the route the proper lat/long... i think?

[m61]

Program Geocontext-Profiler allows you to make topographic profiles anywhere on Earth

http://www.geocontex...04/profiler/en/

[Coonskin]

The same issue exists in other venues as well. For example, the lat/lons I receive on my Iphone compass are NOT where they should be when using a digital topographical map such as Caltopo or USAPhotoMaps. Different data, I suppose. That makes my Iphone useless for plotting coordinates/etc when in the field and comparing them to a digital topographical map.

[Lindsayts]

Coonskin, on 20 November 2016 - 07:06 AM, said:

The same issue exists in other venues as well. For example, the lat/lons I receive on my Iphone compass are NOT where they should be when using a digital topographical map such as Caltopo or USAPhotoMaps. Different data, I suppose. That makes my Iphone useless for plotting coordinates/etc when in the field and comparing them to a digital topographical map.

As far s I am aware (I do not have any kind of mobie phone) from talking to others about this issue the problem is that these phones do not display the position to enough precison, only displaying the position to within 1 sec, this leaves an ambiguity of between 1000 to 1600 metres. To display a position to within 10 metre accuracy requires better than 2 decimal places for the seconds, ie long -135d 35m 55.091sec lat -35d 26m 59.975s

For geo tagging positions I use 2 different devices, on my camera a Nikon D700 I have a GPS attachment the Nikon GP1, for handheld use I have a Garmin GPSmap 76CSx. Both of these devices will plot positions to within 10 to 15 metres on a consistent basis.

Lindsay

[James Ross]

Lindsayts, on 11 November 2016 - 10:38 PM, said:

Sorry to bother you James, if the existing code is inaccuarte enough that its essentially unusable (as it appears to be) what would be wrong with at least trying the new code. A problem I am finding is the position as reported in OR differs not only from MSTS but from Goku's route editor as well. It would be LOVELY if all these agreed it would help much as it would enable Goku's editor to be much more used. I believe its CRITICAL for new content to be able to be done for OR, for instance in Australia all the old MSTS content developers have left MSTS for other trainsims that do have decent content developing tools.

An obvious way of testing is to have two independent systems side by side viewing the same route one on MSTS the other on OR, this is something I CAN do.

disc, on 12 November 2016 - 07:21 AM, said:

Then why don't you commit it, if it's better?

Nothing wrong with trying the new code, but it's a less-significant problem (compared to others I deal with) and more-complex code (to check) that it's way down my priority list. And it's not like I'm the only one that can do it, the code is out there (I believe Goku incorporated it or at least referenced it for his work) so there's no real reason others couldn't do it.