Query and Identify on AGS REST endpoint returns different results. - Double Fields
~~Subject: Enhancement: Query on REST-endpoint returns values from Database. Regional Settings wanted Double
Dear GeoCortex support team
This is the first, out of 3 very related support-cases/enhancement requests that deals with the way that a Query parses information to the end-user.
We recently discovered that there is a difference in the way that Find/Identify (on a REST-endpoint) returns data to the user and the way that a Query (on a REST-endpoint) returns data to the user.
We have been working with Esri to get them to acknowledge this difference, and that resulted in the below BUG report from ESRI:
---
ESRI BUG
BUG-000086125 - Using Identify on the REST endpoint of a European OS returns a string value for double and float attribute fields with a comma decimal separator while Query at the REST endpoint returns standard JSON numbers (period as the decimal separator). This causes an error when the results of one are used as input to the other.
---
But this BUG was soon to be rejected and stipulated 'Works as designed'. Esri stipulates that on a query they parse the information exactly as it stored in the database. This seems like a fair statement, but it creates problems because it seems that on MS SQL 2012 all double values are stored with '.' as the decimal-separator! Regardless off the regional settings on the system.
At least we have not yet been able to find a setting on the databases that will allow us to store data using ',' a the decimal separator. It seems to us that this is something new at MS SQL-server 2012 (- but we may be wrong)
So now we will try to work with you guys at Latitude to hear if this is something that you would want to handle.
PROBLEM:
Our GeoCortex customers in Denmark employ 'Danish Regional Setting' on their systems. On these systems ',' is the decimal separator. But since they use MS SQL Server 2012 the databases use '.' As the decimal separator!
Our customers create HTML5 viewers including WFS that can be edited in the field.
As an example: the end-users enters a double number indicating Max Voltage Capacity level of a cable, and this number is given as a double (ex: 120,5 Volts) But because of the way that the REST end-point can only handle '.' as the decimal separator then the value that gets stored in the database will be (ex: 1205 Volts).
DESIRED SOLUTION:
We believe that the application layer (the GeoCortex viewers) should adapt the regional settings of the end-users device /cpu etc. and use/honor these regional settings when parsing data from queries on an ArcGIS for Server REST-endpoint.
Kind Regards
Kristoffer Waage Beck
Informi GIS A/S - Denmark
-
Hi GeoCortex Support.
We have done some further testing on our side, and we can provide som URL's that you can use for testing purposes.
We are using an older version of SIlverLight Viewer. The purpose is more to understand if this was a new problem in the 'newest' viewer versions. But apparently the problem has been there for some time (or always)
First some important basics:
- The server is acting as both Database, AGS and GeoCortex server. The server uses Danish as regional setting, hence "," is the decimal separator.
- The database does however store Double (number) formats with "." as the decimal separator.
- The Database is running on SQL Server 2008 R2
- The ArcGIS Server is 10.2.1
PROBLEM:
The GeoCortex application does not fully interpret Date and Number fields when retrieving Queries from the database. The Date fields are interpreted from epoch-date into a meaningfull date format, but the Number fields are not respecting the regional settings, hence a value of 5.4 from the database is not translated into 5,4 (and thereby respecting the regional settings)
Esri clearly stipulates that a Query on the REST-endpoint, will return, the values stored in the database, and an Identity or Find on the REST-endpoint will be interpreted to the user.
STEP TO REPRODUCE:
We have an accessible URL with some data for testing..
Using the FIND on a REST-endpoint:
Notice that both on HTML and on JSON the [last_edited_date] is given as a date format. Also notice that the field [Number] show a value 5,4 (the correct interpretation of the stored value "5.4", when using Danish Regional Settings)
If you try to use Identify or Global Search in the GeoCortex viewer below you will get the same result:
(Use the Point Identify tool) and point to (Denmark & Europe), then you can catch the below URL:
Again we notice that the result is interpreted correctly, and honoring the Regional Settings of the Server.
Alternatively you enter "Ipad" in the Global Search, and find the data.
Using the Qeury a REST-endpoint:
But what happens when using Queries? - Try this URL:
Notice that both on HTML and on JSON the [last_edited_date] is given as a stored date format (epoch-date). Also notice that the field [Number] show a value 5.4, exactly as it is stored in the database.
Now try to retrieve the same data from a query in a workflow in GeoCortex:
use the "I want to.." menu (" Jeg vil gerne.. ") -> Finde OID 1206 -> enter value 1206 in the entry text box -> Click OK to perform the Query.
Now examine the data that are retrieved. The date format is interpreted into a meaningfull format, but the field [Number] is given as "54" .
So the "." is omitted and the user gets something that is completely wrong!
If needed I can send you the XAML, but it is the simplest XAML you may ever have come across! - And again the problem is not the workflow, but rather how you guys at Latitude have implemented the interpretation of queried data.
DESIRED SOLUTION
We have more than 5 customers struglling with this problem right now. We will gladly help and maybe even provide you access to our test-server (Portugal) used to explain the case.
But we need a solution or a workaround rather sooner than later.
Kind regards
Kristoffer Waage Beck
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
1 Kommentar