When decimal seperator is no dot, geometry construction crashes


In the latest version of msSQLSpatial, locales where instead of a dot a comma is used as decimal seperator cause geometry construction to fail
The trick is to enhance the geometry construction functions with a temporary change of the culture in use: (Here is an example)
'First, store the CurrentCulture so it can be reset after the routine is done
Dim originalCulture As System.Globalization.CultureInfo
originalCulture = CultureInfo.CurrentCulture
'msSQLSpatial needs the locale to be set to US so the . and , are interpreted correctly
Thread.CurrentThread.CurrentCulture = New CultureInfo("en-US", True)
'Do the things you have to do here..................................
'Reset the CurrentCulture
Thread.CurrentThread.CurrentCulture = originalCulture
Closed Sep 22, 2007 at 1:45 AM by rstuven
Thanks. Article "How to load data from non-spatial sources" corrected.


SharpGIS wrote Sep 21, 2007 at 7:07 AM

Changing the thread culture is not a recommended way to go. Instead all string parsing to numeric values should use System.Globalization.CultureInfo.InvariantCulture :double myValue = double.Parse(myStringValue, CultureInfo.InvariantCulture);More or less the same goes for parsing doubles into strings.

milovanderlinden wrote Sep 21, 2007 at 10:32 PM

This sounds good. If this is implemented correct it is ok. I found out my issue had nothing to do with culture, but with a wrong sample in the wiki on constructing geometry from X and Y columns. I added comment on the solution on the wiki.

wrote Sep 22, 2007 at 1:45 AM

wrote Feb 14, 2013 at 5:56 PM

wrote May 16, 2013 at 8:43 AM