Open karbah-geodata opened 2 years ago
We have looked into this issue but still unable to fix it. Are there any obvious locale options we are missing here? Or pointer to which file needs to be patched?
You will have to look at the JS API for this: https://js.arcgis.com/3.36/esri/dijit/metadata/form/tools/geoExtentUtil.js:formatted
In the app, open the dev tools, open the source code and find the above file. then set a breakpoint on the first line in formatCoordinate() (you may need to format the minimized code, should be around line 26).
I'm expecting that replacing the comma with a period as decimal sign would resolve this. All of the metadata standards I see (including ISO, INSPIRE) have periods for decimal numbers. The comma turns the value into a string and that results in a validation rule in the geoportal editor.
You can get the JS API from the Esri developer site: https://developers.arcgis.com/downloads/#javascript
Once unpacked, you can put the JS API metadata files in your geoportal server install. Then recursively update the references in the gxe files from esri/dijit/metadata/form/iso/GeoExtentTool
to something like ../../../../form/iso/GeoExtentTool
(relative path). Get all the relative references also (../tools/ClickableTool, ../tools/GeoExtentDialog, ../tools/GeoExtentView, ../tools/geoExtentUtil
). Some more work to do on the .../kernel
references, as you need to remove those for locally hosted files. Same with a snippet like this that you will see in several files.
if(has("extend-esri")) {
lang.setObject("dijit.metadata.form.iso.GeoExtentTool", oThisClass, esriNS);
}
Thanks, will have a look at the file you described and try to override it with a local one.
However, I'm just wondering if there's some other option I'm missing such as number format locale? If what you describe is the only way to fix it, I would suggest that geoportal uses a patched local version of the GeoExtentTool that respects the decimal separator of the chosen locale out of the box, since this is not an edge case and I'm surprised the issue hasn't been raised previously. In fact, most non-English languages use comma decimal separators meaning that most non-English localized versions of GeoPortal would result in the same validation error when using the geographic extent tool.
I confirmed this by setting "locale: fr", after which setting the geographic extent resulted in the same comma separated coordinates and validation error:
Once unpacked, you can put the JS API metadata files in your geoportal server install.
Which exact folders/files do I unzip and where in geoportal do I put them in locally? My application is currently only focused on the iso standards, so I just copied the files from the esri "form/iso" folder to the existing (but incomplete) "webapp/app/gxe/form/iso" folder in geoportal, as well as "types/iso" into "webapp/app/gxe/types/iso".
Get all the relative references also (../tools/ClickableTool, ../tools/GeoExtentDialog, ../tools/GeoExtentView, ../tools/geoExtentUtil)
What do you mean by "get" them? There is exactly 1 reference for each that have references to those files as esri paths (eg define("esri/dijit/metadata/form/tools/ClickableTool"
), which I replaced with their relative path, ie define("../tools/ClickableTool"
. There are several places where the files are already references with their relative paths, do I just leave them?
Some more work to do on the .../kernel references, as you need to remove those for locally hosted files.
There are quite a few files inside "form/iso" that contain such references. For example, does that mean I should just change this:
define("esri/dijit/metadata/form/iso/AbstractObject",["dojo/_base/declare","dojo/_base/lang","dojo/has","../Element","../../../../kernel"])
to this:
define("esri/dijit/metadata/form/iso/AbstractObject",["dojo/_base/declare","dojo/_base/lang","dojo/has","../Element","../../../../kernel"])
Same with a snippet like this that you will see in several files.
When you say "same" you mean they also have to be removed? The code snippet you referenced was only found inside one file, and that was inside the dublin core folder which is not really used in my use case.
Describe the bug When configured with language/locale that uses comma as a decimal separator instead of period (e.g. Norwegian), the geographic extent selector sets the coordinate inputs with comma values. This in turn fails to validate when saving, since the validation presumably expects english numbers.
To Reproduce Steps to reproduce the behavior:
geoportal/src/main/webapp/index.html
turn on Norwegian language withlocale: "nb"
.Expected behavior The editor should recognize the decimal separator according to the locale. Alternatively it should convert it to a standard english numeric format.
Desktop (please complete the following information):
Additional context Is there a quick temporary solution for this problem? Maybe some way to configure the numeric format to be different than the locale language? Or some code I can hardcode/override?