Changes between Version 2 and Version 3 of FDORfc53


Ignore:
Timestamp:
Aug 31, 2010, 2:36:29 AM (14 years ago)
Author:
leodai
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc53

    v2 v3  
    3636== Proposed Solution ==
    3737
    38 The design solution is to handle it in WMS provider so that clients don’t have to worry about any of this. To handle it in WMS provider, we need to know which EPSG code needs to be reversed first while sending BBox parameter. Ideally, it would be good if the provider could get some sort of indication from the server. But I don’t expect the server will expose this information related in its capability file. Because it’s part of the EPSG’s definition and the name of the code name is already enough from the server’s view.[[BR]]
     38The design solution is to handle it in WMS provider so that clients don’t have to worry about any of this. To handle it in WMS provider, we need to know which EPSG code needs to be reversed first while sending BBox parameter. Ideally, it would be good if the provider could get some sort of indication from the server. But I don’t expect the server will expose this information related in its capability file. Because it’s part of the EPSG’s definition and the name of the code name is already enough from the server’s view.
    3939
    40 Similar with SQLServerSpatial provider, we are going to use a lookup file in WMS provider which indicates the axis order of specific EPSG codes. This file will have a reverse-order ESPG codes list. And before provider sending request to WMS server, it will decide whether to reverse the BBox value based on the two items:[[BR]]
     40By default we will have a hard-coded list containing the whole reverse-order EPSG codes. And in addition, we are going to define a lookup file which can be created by users and used to add missing EPSG codes if needed. When user meets the axis order issue with specific EPSG code, he/she can create this file and add the new EPSG code in it.
    4141
     42In our WMS provider, we look if in the same folder with the provider’s DLL we find this additional look up file and in case we do we load it and append the content to the internal list, otherwise we use the internal hard coded list. In this case, even if the file is missing or corrupted by users the provider can still work with the internal defined list.
     43
     44And before provider sending request to WMS server, provider will decide whether to reverse the BBox value based on the two items:
    42451.      WMS server’s version in current connection.
    4346
    44 2.      Check the file to determine the axis order if we got an EPSG code in the coordinate system parameter.
     472.      Check the list to determine the axis order if we got an EPSG code in the coordinate system parameter.
    4548
    46 The basic logic is that we reverse it only when current version is 1.3.0 and the EPSG code is found in the look up file.[[BR]]
     49The basic logic is that we reverse it only when current version is 1.3.0 and the EPSG code is found in the reverse-order EPSG list.
    4750
    48 For the look up file, it will be a txt file with reverse-order ESPG codes list, like:[[BR]]
     51For the defined additional look up file, it will be a txt file with reverse-order ESPG codes list, like:
    4952
    50 EPSG:4326
    51 
    52 EPSG:xxxx
    53 
    54 …[[BR]]
    55 
    56 And this file will be put into wms provider.
    57 
     53EPSG: 4326
     54EPSG: xxxx
     55…
     56And this file should be put into WMS provider if user needed.
    5857
    5958=== Implications ===
    6059
    61 This change will bring a new look up file with reverse-order EPSG codes list into WMS provider, and this file needs to be updated once new EPSG codes are created.
     60This change will have an internal hard-coded reverse-order EPSG codes list in WMS provider, and also expose a standard file name with missing EPSG codes to be added by users.
    6261
    6362=== Test Plan ===