[
https://issues.apache.org/jira/browse/OFBIZ-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865338#comment-13865338
]
Jacques Le Roux commented on OFBIZ-5453:
----------------------------------------
To conclude on this, here is an abstract.
I agree that storing strings (short-varchar, like if they were numbers in
English format) would be easier than storing numbers (floating-point in DB): no
i18n conversion annoyances.
So what we need to do is (ready, tested locally):
# revert (in reverse order) revisions 1554681, 1554685, 1554706, 1554764,
1554787, 1554706
# remove type="Float" from ExampleScreens.xml
# remove ?c from geolocation.ftl, just passing a string in JS is OK
# [remove the change I put for locale in the wiki
page...|https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+%28minilang%29+Reference#Mini-language(minilang)Reference-Attributes.28]
# create an entry in [data migration wiki
page|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045166]
Then we should be ok
Notes:
* I agree we should add the Geographic Coordinate Uom. But, despites knowing
that GPS, Google Maps and Openlayer use
[WGS84***|https://en.wikipedia.org/wiki/World_Geodetic_System] (and Spherical
Mercator Projection, at least for Openlayer), we still need to know which maps
renderer to use. So the GEOPOINT_DTSRC relation is still needed (we must keep
the data source).
* The UOM conversion routines to convert from one coordinate system to another
is a good idea. Though I don't know when or why it will be used...
* I agree that GPT_ELEV_UOM is a better name for the elevationUomId relation.
* I have still to understand some points, but I also don't want to know much
more about this. OFBiz does not need to be too specific on this subject...
\*** Not quite sure at the moment if its what Adrian called GEO_WGS84or
GEO_WGS84_DMS, I still need to investigate more:
* [Google "WGS84 vs EPSG
3785"|https://www.google.fr/search?q=WGS84%20vs%20EPSG%203785]
* [Java code for WGS84 to Google map position and
back|https://stackoverflow.com/questions/7661/java-code-for-wgs84-to-google-map-position-and-back]
* [convert wgs84 coordinate to Google Map coordinate system(EPSG 3785) with
geotools and
java|http://gis.stackexchange.com/questions/28018/convert-wgs84-coordinate-to-google-map-coordinate-systemepsg-3785-with-geotool]
Here are also some interesting references
* [JTS Utility
Class|http://docs.geotools.org/latest/userguide/library/api/jts.html]
* [The Google Maps / Bing Maps Spherical Mercator
Projection|https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/]
> Set field in (at least) widget screen does not take into account a locale for
> (at least) the Float type
> -------------------------------------------------------------------------------------------------------
>
> Key: OFBIZ-5453
> URL: https://issues.apache.org/jira/browse/OFBIZ-5453
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04,
> Release Branch 13.07
> Reporter: Jacques Le Roux
> Assignee: Jacques Le Roux
> Fix For: SVN trunk, Release Branch 12.04, Release Branch 13.07
>
> Attachments: OFBIZ-5453.patch
>
>
> While working on Google Maps API migration from V2 to V3 I discovered an
> issue which is reflected by those 2 commits
> * http://svn.apache.org/viewvc?view=revision&revision=892579
> * http://svn.apache.org/viewvc?view=revision&revision=895950
> In other words if you pass something like
> <set field="geoPoints[+0].lat" value="37.4419" type="Float"/>
> in a French OS or browser context you will get 37.0 in OFBiz context
> But if you pass
> <set field="geoPoints[+0].lat" value="37,4419" type="Float"/>
> in an English OS or browser context you will get 37.0 in OFBiz context
> So we need either to fix this in code (ModelWidgetAction.java[132,171]) or to
> add a way to pass a locale to force/fix the Float(others?) value in OFBiz
> context (this is needed for instance for geolocation)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
