decimal separator identify/query

[HugoAhlenius]

Hi, I am working on a web application, and the server is ArcGIS 10.1.

Now I just noticed something very funny - when I do query tasks everything works as it should, but for an identify task, the server returns comma as the decimal separator. The server is located in Norway, and I haven't investigated it further (and experimented) but it is likely that the user account that the server is running under is set to Norwegian regional settings. Setting the user to en-us probably fixes this...

I did some troubleshooting, and I could see the comma-decimal separator in the requests - see the json returned from this query for instance: http://bit.ly/Sxbynh. Note the shape.area attribute/field for instance.

[HugoAhlenius]

To me it seems like a bug!

[__Rich_]

...I could see the comma-decimal separator in the requests...

Do you mean in the responses?

If the server processes are running under Bokmål then I'd expect dates, numbers etc in attributes to be expressed in that locale e.g. do you know how the underlying data store is configured?  Do you know who else uses the data?  (probably people in Norway for a start!)

ESRI may have chosen to 'normalise' 'system' values for functional purposes into a chosen locale (probably en-us) but it'd be dangerous for them to start messing with proprietary values that they do not 'own'.

Having said all that....I think all the tasks should be consistent in what they do to values - this isn't the only thing that is done differently between the task types e.g. date format.

[HugoAhlenius]

The responses, of course... The data store (in SQL Server / enterprise geodatabase), stores numbers in binary format anyways. I can inspect the attributes in the data store (using ArcCatalog, or SQL Server tools), and see that decimal separator work as expected.

The data should be queried and communicated behind the scenes in a common format (e.g. en-us) and presented to the user according  to overrides (i.e. dojo.locale).

What leads me to call this a bug is that a queryTask work as expected, while an identifyTask doesn't...

[__Rich_]

The data store (in SQL Server / enterprise geodatabase), stores numbers in binary format anyways.

But you don't directly read the internal value representations of the DBMS and neither do the tools you mentioned.

Anyway, yes there should be consistency across the responses from the REST methods, that is an issue
---------------
On a separate matter, I'm not sure I agree with ESRI forcing your data values into any locale, it could be argued that since you're the custodian of those data values, you should ensure a consistent locale.  Aside from the REST bug (and I agree it's a bug) they are effectively delegating responsibility for locale selection to the people who are based place to chose i.e. the owners of the data.

[HugoAhlenius]

🙂

Thanks for the response by the way! Think thing with JSON and the REST api - since it doesn't specify the format of values (strings, double etc) and it is human readable - it is a bit deceiving. But for it to work with a variety of clients, it either needs to specify the format, or hold it in a predictable format (e.g. en-us).

The json response shouldn't be for human consumption anyways, and the values should be cast to a suitable locale in the presentation layer!

[__Rich_]

Conversion to a universally acceptable (!) locale initially seems an attractive option, but I think the service stating the locale is probably (possibly?) a more robust approach based on approx 15 seconds of thinking!  (no doubt I haven't thought this through and someone will tell me it's a terrible idea!)

...and on top of locale you've also got format e.g. date.  (a locale may not guarantee a single format for the type)

[HugoAhlenius]

Another aspect that tells me that this is a bug - the key here seems to be the locale the user account on the server runs under, not anything related to by data store/repository...

[__Rich_]

Another aspect that tells me that this is a bug - the key here seems to be the locale the user account on the server runs under, not anything related to by data store/repository...

What locale is SQL Server using?

Which do you think is behaving correctly?

Identify i.e. locale-aware)
Query i.e. forced to (probably) en-US

I know which you prefer, but that's not the same question 😉

The biggest issue I have is that they behave differently!  (must be considered a bug)

[HugoAhlenius]

What locale is SQL Server using?

It is irrelevant, SQL Server is not sensitive to the regional settings. One can set the collation per database/table/field, but that is primarily the sort order. Dates and numerical values are stored in binary format.

Which do you think is behaving correctly?

The query, since dojo/the javascript API does not apply the browser/locale settings in the identify case, and the attribute is interpreted as a string.