[ https://issues.apache.org/jira/browse/OFBIZ-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865338#comment-13865338 ]
Jacques Le Roux edited comment on OFBIZ-5453 at 1/8/14 12:30 PM: ----------------------------------------------------------------- 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 # rename GPT_ELEV_UOM the elevationUomId relation. # [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/] was (Author: jacques.le.roux): 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)