Silverlight build bug?

Jan 7, 2010 at 10:19 AM

Hi there

Seems to be a bug with the silverlight build when using "ProjNet.Converters.WellKnownText.CoordinateSystemWktReader.Parse()". The streamtokenizer class is producing differing results for the .NET and Silverlight builds. E.g. for this input wkt string:

string wkt = "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]";

The .NET streamtokenizer version outputs these tokens:

"GEOGCS", "[","\"", "WGS", "84"

But the Silverlight version outputs these tokens:

"G", "E", "O", "G", "C", "S", "[", etc..............

And thus generates an ArgumentException in the Parse() method. The ArgumentException is raised in the "default" case on the switch(){} block and reads "'G' is not recognized" (in the case of the above).

I've narrowed the source of bug down to these lines:

#if SILVERLIGHT
            Encoding AE = System.Text.Encoding.Unicode;
#else
            ASCIIEncoding AE = new ASCIIEncoding();
#endif

It would seem that these encodings don't behave the same way...! Any suggestions for a fix?

cheers

Alan

 

 

Jan 29, 2010 at 7:59 PM

 

Changing Unicode to UTF8 works for me since the default csv file is all single byte UTF8. If you have a custom SRID.csv with extended UTF8 (multibyte encoding) then you would have to go further.

SharpMap.CoordinateSystems\IO\CoordinateSystems\StreamTokenizer.cs

#if SILVERLIGHT
 //Encoding AE = System.Text.Encoding.Unicode;
 Encoding AE = System.Text.Encoding.UTF8;
#else
 ASCIIEncoding AE = new ASCIIEncoding();
#endif