French configuration
Windows XP Sp3
Configuration of PC is french, Comma instead of period as decimal
User without privilege or Administrator depending my login
DnrGps 6.0.0.4
Projection set to MTM 9 (32189)
I've download Waypoint (also track) from GPS and the projection of data worked well. Latitude, Longitude, X_proj and Y_proj but have all decimal with comma. The altitude have decimal with period. (first image)
When i save to file, i've receive an error message "mscorlib - Input string was not in a orrect format" except for GPX and TXT format. (second image)
Even with the error message, a second message appeard and say "Saved to File Successfully at..." (third image)
All file produced are not good because no data was really saved.
Result of the saved GPX file is not good to because comma is used as decimal for latitude, longitude and period is used for altitude, Unable to open it with other program. ( fourth image)
Result of the saved TXT with Comma, almost everything is delimited with comma, so, the same problem persist (Fifth image)
Result of the saved tXT with Tab, not good to because comma is used as decimal for latitude, longitude and period is used for altitude, Unable to open it with other program. ( sixth image)
So, even if configuration is french with comma for decimal, numeric data must be saved to file using period.
NEW INFORMATIONS.......
I've just load from a KML file from GOOGLE (My place).
Then, the KML file as period for decimal and once load in DnrGps, period as changed for comma as expected. When i saved it to shapefile, everything worked well, no error message. Load it in ArcMap 9.3.1 and it is OK. The DBF as all records with period as decimal.
So, the error message "mscorlib - Input string was not in correct format." is probably related with numerical field "Altitude" with period as decimal (as decribed before) and possibly others fields who are numerical.
Now, when i save it to GPX, TXT, etc... the problem is still there, the comma is not replaced with period as it is with DBF.
Configuration of PC is french, Comma instead of period as decimal
User without privilege or Administrator depending my login
DnrGps 6.0.0.4
Projection set to MTM 9 (32189)
I've download Waypoint (also track) from GPS and the projection of data worked well. Latitude, Longitude, X_proj and Y_proj but have all decimal with comma. The altitude have decimal with period. (first image)
When i save to file, i've receive an error message "mscorlib - Input string was not in a orrect format" except for GPX and TXT format. (second image)
Even with the error message, a second message appeard and say "Saved to File Successfully at..." (third image)
All file produced are not good because no data was really saved.
Result of the saved GPX file is not good to because comma is used as decimal for latitude, longitude and period is used for altitude, Unable to open it with other program. ( fourth image)
Result of the saved TXT with Comma, almost everything is delimited with comma, so, the same problem persist (Fifth image)
Result of the saved tXT with Tab, not good to because comma is used as decimal for latitude, longitude and period is used for altitude, Unable to open it with other program. ( sixth image)
So, even if configuration is french with comma for decimal, numeric data must be saved to file using period.
NEW INFORMATIONS.......
I've just load from a KML file from GOOGLE (My place).
Then, the KML file as period for decimal and once load in DnrGps, period as changed for comma as expected. When i saved it to shapefile, everything worked well, no error message. Load it in ArcMap 9.3.1 and it is OK. The DBF as all records with period as decimal.
So, the error message "mscorlib - Input string was not in correct format." is probably related with numerical field "Altitude" with period as decimal (as decribed before) and possibly others fields who are numerical.
Now, when i save it to GPX, TXT, etc... the problem is still there, the comma is not replaced with period as it is with DBF.
Leave a comment
Your diligence is appreciated. I've identified a larger problem that should resolve this issue in the next release.
BTW: Due to the comma as decimal points saving to a comma-delimited text file will always be trouble for you and I'd advise against it.
BTW: Due to the comma as decimal points saving to a comma-delimited text file will always be trouble for you and I'd advise against it.
I've been working with a person in Quebec with a similar issue (Ticket # 118 -- http://www.assembla.com/spaces/dnrgps/tickets/118). Could you please test out the version that is working for him -- http://www.assembla.com/spaces/dnrgps/documents/download/diE52Yv0ur4BSBacwqjQXA
This is just the dnrgps.exe file. It can be copied over your existing copy in the dnrgps folder.
Chris
This is just the dnrgps.exe file. It can be copied over your existing copy in the dnrgps folder.
Chris
Oups, the problem is still there, i had change my configuration for english to test something else, so that's why it was working.
So, with the french configuration, the problem with other numerical fields like "altitude" have information in it when downloading data from gps, but these have a period has delimiter instead of comma. If i manually change the period for a comma, it work. The process used for Latitude, Longitude, X_Proj and Y_Proj should be used for other numerical fields.
So, with the french configuration, the problem with other numerical fields like "altitude" have information in it when downloading data from gps, but these have a period has delimiter instead of comma. If i manually change the period for a comma, it work. The process used for Latitude, Longitude, X_Proj and Y_Proj should be used for other numerical fields.
The situation of numeric field other then coordinates is also present in all type of data waypoint, track, route and real time. Now, suppose you resolve it, here is the worse situation.
Imagine a user may use an alias for a field name, modify the type of that field from string to number with precision and finaly, populate that field with value. I did test and information is lost.
This must be mentionned somewhere to avoid to do that.
Hope this can help
Imagine a user may use an alias for a field name, modify the type of that field from string to number with precision and finaly, populate that field with value. I did test and information is lost.
This must be mentionned somewhere to avoid to do that.
Hope this can help