Page 1 of 1

Latitude / Longitude

Posted: Thu Jun 30, 2005 1:58 am
by Thomas An.
Hi everyone,

Znouza from the Rhino section alerted me that the latitude/longitude data maybe inaccurate.

Longitude/Latitude is normally presented as DMS (e.g 41° 24' N 2° 9' E for Barcelona). However this is not the same as 41.24.

Can you check some of the data in your respective plugin (Max, Maya etc) ?
Do you have the same issue ?

In order to convert to decimal there needs to be a calculation:
http://jwocky.gsfc.nasa.gov/teacher/latlonarchive.html
http://stutzfamily.com/mrstutz/LatLong/latlonglist.htm

Posted: Thu Jun 30, 2005 7:41 am
by paxreid
I have the same problem with the rhino plug in thomas. It seems that some of the presets are incorrect. Madrid seems to work just fine :) but east coast USA (New York, Washington) are incorrect.

Posted: Thu Jun 30, 2005 8:13 am
by Kabe
Beside the calculation issue - which is normally not that important - you should be aware that there's a major bug in Cinemaxwell at least, but eventually in other M~R plugins or even the main program as well:
http://www.maxwellrender.com/forum/viewtopic.php?t=4229

The visual difference between 41.24° and 41°24' is not too much compared to being on the wrong hemisphere ;-)

Kabe

Posted: Thu Jun 30, 2005 8:27 am
by Thomas An.
Thank you Kabe, paxreid :)

@ Kabe, You are making some very good points in your bug report (znouza did too, if I remember right). Some time ago Oscar mentioning that the entire environment system will be revamped with a much more realistic sky (including night) and atmospheric effects. So, I suspect all this will be looked into... I just wanted to make sure that this small thing about degrees (which is a triviality) is not overlooked. It is not important (as you mentioned), but why leave it wrong .... :)

Posted: Thu Jun 30, 2005 8:53 am
by Kabe
Thomas An. wrote:It is not important (as you mentioned), but why leave it wrong .... :)
Oh, I am certainly the last who says it's not important! Maxwell will be used for lighting precalculations for shure - and it's pretty pointless to give away precision just out of carelessness.

Beside the floating point issue, it's also important to define which coordinate system to use - because contrary to public wisdon, this is far from clear.
In the times of GPS, I guess it's best to use WGS84 - which does give different values for longitude and exspecially latitude compared to the national grid systems like Gauss-Krüger in Germany or countless others in different countries.

Combine this with public available high precision C-source to calculate the sun position (SPA - 1000 lines of C that calculate sun pos up to 0.001°) you could create the best sun position simulation available in *any* renderer today.

Kabe

Posted: Thu Jun 30, 2005 9:11 am
by Thomas An.
Kabe wrote:...Beside the floating point issue, it's also important to define which coordinate system to use - because contrary to public wisdon, this is far from clear.
In the times of GPS, I guess it's best to use WGS84 - which does give different values for longitude and exspecially latitude compared to the national grid systems like Gauss-Krüger in Germany or countless others in different countries.
Good point again !
Thank you for bringing this up. I did notice discrepancies in the Longitude/Latitude tables that I have seen on the net, but it didn't occur to me at the time, that these might be due to different coordinate systems. I learned something new :)

Posted: Thu Jun 30, 2005 9:23 am
by Maya69
i have a probleme with maya

Posted: Thu Jun 30, 2005 9:32 am
by hdesbois
seems ok to me with Lightwave plugin, using decimal degrees. But it's difficult to check accuracy of minutes and seconds. I didn't tested western longitudes and southern latitudes. From my tests so far, error on sun position, if any, is small enough to have no practical consequence.
BTW, LW plugin hasn't any preset, but I like it that way.
HD

Posted: Thu Jun 30, 2005 10:21 am
by Mihai
I vote we put Kabe in charge of "Sun System Accuracy Testing Dept."

Would love to have a sun calculation within accuracy of a thousanth of a degree :D

Posted: Fri Jul 01, 2005 12:41 pm
by hdesbois
Kabe, you raised an interesting point about the choice of a geodetic datum, and I agree that many public routine libraries such as geolib can handle this with great accuracy. But then the error induced by datum mismatch may be of a few hundred meters, let's even suppose for the sake of the argument a dozen of kilometers. Since the time is precise only to the minute, and since you don't input any altitude (not very important in most case, except it can affect sunset/sunrise time) along with the long/lat settings (not to mention plugins where you have only presets cities), I think maybe we can live with sun calculation based on spherical earth (I fear it is the case now, in any case I vote for WGS84).
Of course, it would be cool to have advance GIS-like precision for localisation and sun position, but that's not the top of my wish list.
HD