You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just came across this bug (Geoda 1.12.1.239 on Moac OSX).
Steps:
Merge table to shapefile
Problem:
when table has integers with commas, e.g. 153,084 or 44,263 (see right side of table in image below), GeoDa imports them as 153 and 44 (see left image below), i.e. it truncates the integer at the comma.
The text was updated successfully, but these errors were encountered:
note: the merge process cant recognize the field type, and user need to manually change the filed type after merge.With this fix, GeoDa should recognize thr thousand separator and decimal separator, which can be setup manually using OS's system setting dialog, or change GeoDa's language (e.g. Spanish -- using comma as decimal separator).
ready to build
lixun910
added a commit
to lixun910/geoda
that referenced
this issue
Jun 17, 2019
Also fix another bug that when edit cell in table (only when using sqlite data source), the double precision value will be rounded to an integer number in the editing box.
Using menu item: table->Setup Number Formatting, one can specify the thousand separator and decimal separator manually. For example, if you set “,” to be the decimal separator. Then, the case: 45,128 will be converted to 45.128 (double type) or 45 (integer type).
Just came across this bug (Geoda 1.12.1.239 on Moac OSX).
Steps:
Problem:
when table has integers with commas, e.g. 153,084 or 44,263 (see right side of table in image below), GeoDa imports them as 153 and 44 (see left image below), i.e. it truncates the integer at the comma.
The text was updated successfully, but these errors were encountered: