ThinkGeo.com    |     Documentation    |     Premium Support

WFS Feature Layer - Incorrect bounding box format

Hello,


when I add a WfsFeatureLayer to my map, the URL composed by the client to send to "tile_GeoResource.axd" contains the BBOX parameters.When those parameters are used by the ASP.NET server to compose the request to submit to the WFS Server, the BBOX parameters are wrote using a comma as decimal separator. This results in an incorrect http request and a wrong number of parameters for the BBOX.


I'm using a local IIS7 server, and my OS is a Windows 7 x64 FRENCH.


Trying to set the Culture of the ASP.NET application to en-US, the problem is still the same.


Do you know another setting to set on the server, to have double parameters formated with a point as decimal separator?


Thank you


Nicolas 



Hi, Nicolas


 I think this problem is related with your “Region And Language” setting in the Control Panel. That’s because your computer is in French environment, by default, and it uses comma as the Decimal symbol. Please see the red heighted region in the attached screenshot. Please have a try to modify the Formats or Location information.

You mean that the BBOX sent to “tile_GeoResource.axd” had been wrong? The BBOX had used the comma as a decimal separator?
If that’s true, can you attach one screenshot for that?
In fact, on the server-side and we will split the BBOX string from client-side using comma and then convert it into right BoundBox.
 
Thanks,
 
Khalil

 



Hi Khalil,

thank you for your response. To illustrate my issue, I'm using your CSharp VS2008 samples. Below is the code-behind of the LoadWfsFeatureLayer. I ran your solution in many situation and the results are :



        
  • when the solution is ran using the VS integrated Web Server, there is no problem, even if my Windows is a french version, and if the decimal separator is set to comma,

  •     
  • when the solution is ran using the local IIS 7 (using a dedicated website and a dedicated application pool), BBOX in the URL is write using comma as decimal seperator :



        
  1. If I set the decimal separator to point in the Windows regional settings, the problem is still the same,

  2.     
  3. If I set the globalization parameters of the Web application to en-US, the problem is still the same,

  4.     
  5. If I set the CurrentThread.CurrentCulture and the CurrentThread.CurrentUICulture to "en-US" in the page load, the problem is still the same.


Finally, I think that there are more than one MapSuite problem. First, IIS seems to have some difficulties to take in care the globalization parameters. Also, MapSuite doesn't force de format of the doubles wrote in the URL. This format should not be dependant on the culture of the system. Comma may be prohibited, simply because she's allready used as a parameter seperator.


Here is the modified code-begind . I use the FeatureSource.RequestingData event to track the URL :


    public partial class LoadWfsFeatureLayer : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");
            System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US");

            if (!Page.IsPostBack)
            {
                Map1.MapUnit = GeographyUnit.Meter;
                Map1.CurrentExtent = new RectangleShape(455417.2, 4992437.4, 485795.9, 4960950.6);
                Map1.MapBackground.BackgroundBrush = new GeoSolidBrush(GeoColor.FromHtml("#E5E3DF"));

                WfsFeatureLayer wfsFeatureLayer = new WfsFeatureLayer(@"datafinder.org/wfsconnector/com.esri.wfs.Esrimap/MN_MetroGIS_DataFinder_WFS_Water_Resources", "Watersheds-watersheds_2_a");
                wfsFeatureLayer.ZoomLevelSet.ZoomLevel01.DefaultAreaStyle = AreaStyles.Country1;
                wfsFeatureLayer.ZoomLevelSet.ZoomLevel01.ApplyUntilZoomLevel = ApplyUntilZoomLevel.Level20;

                (wfsFeatureLayer.FeatureSource as WfsFeatureSource).RequestingData += new EventHandler<RequestingDataWfsFeatureSourceEventArgs>(wfsSource_RequestingData);
                (wfsFeatureLayer.FeatureSource as WfsFeatureSource).RequestedData += new EventHandler<RequestedDataWfsFeatureSourceEventArgs>(wfsSource_RequestedData);

                Map1.StaticOverlay.Layers.Add("WfsFeatureLayer", wfsFeatureLayer);
            }
        }

        void wfsSource_RequestingData(object sender, RequestingDataWfsFeatureSourceEventArgs e)
        {
            Debug.WriteLine(String.Format("ServiceUrl = {0}", e.ServiceUrl));
        }

        void wfsSource_RequestedData(object sender, RequestedDataWfsFeatureSourceEventArgs e)
        {
            Debug.WriteLine(String.Format("XmlResponse = {0}", e.XmlResponse));
        }
    }


 


Here is the URL used by the WebServer to request the WFS server:



datafinder.org/wfsconnector/com.esri.wfs.Esrimap/MN_MetroGIS_DataFinder_WFS_Water_Resources?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=Watersheds-watersheds_2_a&BBOX=496964,549189485,4950393,36080664,518450,389947285,4971879,20156445&propertyname=



 


 


 



Hi, Nicolas


Thanks for your information about this problem.
Yes, this is a bug for WfsFeatureSource. We don’t consider the CultureInfo when composing the BBOX parameter. We have fixed this issue and it should be available in the latest Daily Build (4.0.134.0 or later). Please get it through helpdesk.thinkgeo.com/helpdesk/login.aspx.
 
The auto build might be completed tomorrow; I don't know when it will be available for you to download.
Let me know if you still have issues then.
 
Thanks,
 
Khalil