Changes between Version 2 and Version 3 of FDORfc53
- Timestamp:
- 08/31/10 02:36:29 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FDORfc53
v2 v3 36 36 == Proposed Solution == 37 37 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]]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. 39 39 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]] 40 By 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. 41 41 42 In 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 44 And before provider sending request to WMS server, provider will decide whether to reverse the BBox value based on the two items: 42 45 1. WMS server’s version in current connection. 43 46 44 2. Check the fileto determine the axis order if we got an EPSG code in the coordinate system parameter.47 2. Check the list to determine the axis order if we got an EPSG code in the coordinate system parameter. 45 48 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]]49 The 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. 47 50 48 For the look up file, it will be a txt file with reverse-order ESPG codes list, like:[[BR]]51 For the defined additional look up file, it will be a txt file with reverse-order ESPG codes list, like: 49 52 50 EPSG:4326 51 52 EPSG:xxxx 53 54 …[[BR]] 55 56 And this file will be put into wms provider. 57 53 EPSG: 4326 54 EPSG: xxxx 55 … 56 And this file should be put into WMS provider if user needed. 58 57 59 58 === Implications === 60 59 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.60 This 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. 62 61 63 62 === Test Plan ===
