ThinkGeo.com    |     Documentation    |     Premium Support

Numeric values and Culture Info

#1

 Hi,


 
I have some questions about the culture info used for the numeric values:
 
1) In which culture info, is the string (representing numeric values) obtained from the ColumnValues
of a feature contained in a shapefile ?
 
2) For the custom numeric values passed through the callback CustomColumnFetch to thinkgeo, what culture info
should be used ?
 
3) For user created features in an InMemoryFeatureLayer, what culture info should be used for the numeric values ?
 
 
Regards,
P.OM
Reportive
 
PS: I first assumed that it was always the Invariant Culture but it's not always the case.
 
PS: Is there a way to provide numeric values as double and not string ?

#2

Hello Puthirak, 
  
 Thank you for your post. 
  
 There are two cultures, Invariant Culture and Current Culture, and which one should be use is depend on your data. 
  
 For example: 
             double data = 123456789.1234;  
             data .ToString("N", CultureInfo.InvariantCulture);   //output is 123,456,789.12 
             data.ToString("N", CultureInfo.GetCultureInfo("de-de"));   //output is 123.456.789.12 
  
 InvariantCulture will always use the same format ignore your local machine culture. 
  
 Regards, 
  
 Gary

#3

 Hi Gary,


 
I don't know if you understood my questions or not.
I will try to be more clear.
 
Let's say I have a shapefile containing polygons.
I apply a ClassBreakStyle style using a custom column, i.e. the value is given
by me through the callback CustomColumnFetch.
This value must be of type string. So I have to convert my double value to a string.
That's one conversion.
 
Also I can safely state that when the thinkgeo style engine will try to apply the style, it will
convert the string given by me to a double.
That's the second conversion.
 
My question is: what Culture Info did the thinkgeo style engine use to make the second conversion?
 
Let's assume that the thinkgeo engine use the Current Culture. So I just have to use the Current Culture
to make the first conversion. Everythings fine right?
 
But wait, what if something changed the Current Culture between the moment the engine gets the string value
and the moment it makes the conversion. You'll potentially get an exception.
 
That's my main concern. For me, the string given by the users should always be in the Invariant Culture and
the engine should always use the Invariant Culture to make the conversion.
 
Regards,
P.OM
Reportive
 

#4

Hi Puthirak, 
  
 For the second conversion, you are exactly right we are using CurrentCulture to convert the string in case we can compare the numeric value to apply the class break style. Also you are right again we need use the InvalidCulture for both directions in all the cases you mentioned. Please allow me to report it to our manager for this issue and make it right soon. Just let you know we are on it now and we will review our other similar cases. 
  
 Thanks, 
 Howard