ThinkGeo.com    |     Documentation    |     Premium Support

Generate Grid with Spherical Mercator System

Hi,


I've been gridding data on a map with spherical mercator and have noticed an odd problem.


Typically, I have a grid of points that fills a specific area and then I define a GridDefinition with drawing extent that is about 20 kms bigger in all directions.  The idea being that when I'm done interpolating I fill the GridDefinition completely with data and no -9999 values.


I then give this GridDefinition coordinates and points in spherical mercator.


If I grid data in extreme north or south latitudes, I end up with a grid that has a lot of -9999 values.  In moderate latitudes, the same grid of points fills the GridDefinition with valid data as I expect.


Essentially, I believe the area skew of the spherical mercator projection in extreme latitudes is not being accounted for correctly in the grid interpolation model particularly for the search radius parameter.


I am using the InverseDistanceWeightedGridInterpolationModel.


Please advice a way to get the data processed as expected. 


Regards,


Damian A. Hite


 



Hi Damian, 
  
 Sorry that we are unable to reproduce the issue mentioned, I wonder it’s caused by some specified source cell data, so can you provide your source data file or a simple sample? I will check it again. 
  
 Thanks, 
 Johnny

Hi Johnny,


Okay, attached is a project with a text input dataset in the data directory.  These 2 dataset are the exact same grid spacing, value and number of items with the notable exception that one was created ~74N and the other ~33N.


If you run the test app, you will find 2 buttons.  Button 1 loads the Northern dataset and button 2 loads the southern dataset.


Because both datasets use a static 500m depth value, immediately, you will be able to tell that the northern datasets good data covers much less area than the central dataset.  If you examine the .grd files you will see that there are many more cells in the Northern dataset than the southern, but yet both grids are supposedly covering the same space.  In fact, the Northern grid file is much larger size than the southern.  My first indication that something is wrong.


If you then go into the code to the procedure called GetBathyPoints, you will see a block of code with my comments.  Disable the code that converts the input coordinates to spherical mercator and run the analysis again.  You will see that the grids now cover an identical area and the file sizes are equivalent; however, my environment doesn't put them where they should be because I want to use spherical mercator as the base grid.


So, the problem I have is that the coordinate locations of the grid are only correct in my spherical mercator environment when I convert the UTM point coordinates to spherical mercator.  But, the interpolation is incorrect and doesn't show 500m depths over the required area.  If I process the grid in UTM, the interpolation is correct, but the coordinates are not showing where they should because I have setup my environment in spherical mercator.  Since GridFeatureLayers write their data to disk, I would guess the solution would be to have a Projection property for GridFeatureLayer and IsolineLayer that can handle reprojecting this, but so far my attempts at doing this have caused hangups in the software.


Best Regards,


Damian



SphericalMercatorGridTest.zip (87.5 KB)

 Hi Damian,


 


Thanks for your sample, in fact, the north part should cover more areas under Mercator projection, and in fact the north does cover a larger area in your sample, I guess the problem is that you may didn’t check them under the same scale, Here is result image of two grid under the same “ruler”.


Center:                                                                                                     



North:



As you can see north’s area is larger than center’s area. This is correct because in Mercator projection the north is much more stretched than center. 


 


If any question, feel free to ask!


 


Johnny. 



Johnny,


My problem is with the interpolation not the grid area. I supply a distance to interpolate into the gridding function. But, when the data are projected into SM first, the interpolation distance does not hold true.


Look at the points in the input file. They are UTM 35N projected. Would you agree that they are spaced 3km apart? Now look at the interpolation distance I've supplied. It's 21km. In the northern example, the valid data do not exist 21km away from any point.


In fact, I've just realized I made an error in my code which may be misleading and causing the problem to be ill-defined. Essentially, when I was drawing the box that represents the area I want to grid, I did not use UTM points, add my areaBuffer and then convert the final values to SM.  Attached is an updated project. As you can see, the required area to fill versus valid depth values changes with latitude.  This is the problem I am trying to solve. Why doesn't the interpolation work out to the distance that I define when I supply SM coordinates?


Regards,


Damian



SphericalMercatorGridTest_v2.zip (87.9 KB)

 Hi Damian,


I'm not sure whether I understand you clearly, the attached is the modified demo following my understanding.  The changes what we did are:


1. Remove the global proj4Projection field and move them into different methods, to make sure we are always use UTM for the data, but Sphere Mercator for display. In this way, we can avoid the data projected several times and bring some problems.


2. Apply the projection information to GridFeatureLayer to make sure the grid data created in UTM display in SpherMercator projection.


Following is the screenshot we got, please check it, if there is anything we misunderstand, please let us know:



Thanks,


Johnny


 



Hi Johnny, 
  
 Great!  That looks like what I’m expecting now.  But, I don’t see the code attachment.  Can you please upload? 
  
 Re. point 2, I have tried to apply a projection to a grid previously and it always stalled out.  However, I always tried to apply it after it was generated.  Perhaps the correct method is to initialize the layer with the correct projection first, but I guess I will see when I can look at your update. 
  
 Thanks, 
 Damian

 Hi Damian,



Sorry that I missed the attachment in last post, please check it now.


Actually, I think you are correct, but doing the projection conversion for several times, and thus runs into error. Also applying projection to the layer is much easier than doing conversion for each feature. 


Thanks,


Johnny



Post11090Sample.zip (15.8 KB)