ThinkGeo.com    |     Documentation    |     Premium Support

Absolute Path for ImageCache

 We need to port our website to AppHarbor, a cloud ISP.  But we cannot use any absolute path references in our code.  Once such reference is the ImageCache directory, for which the path is C:\ImageCache.  Everything works fine with this path.


However we cannot use it in the cloud.  Instead, we must use a relative path.


But when a relative path is ignored.  No tiles are cached.  Has anyone out there solved this problem?  How do we define a relative path that works with image caching?


 


Thanks,


 


Al Vigil



Al, 



I looked at the code and I can see how we would have some problems with relative paths.  We will have a developer look at this on Monday and put a fix in for you through the daily build hopefully the day after.  Sorry for the inconvenience, we didn't have this as a test case or scenario. 



David



Thanks, David 
  
 Al Vigil

Hi Al, 
  
 In your application, let’s assume we have a scenario that displays a shapefile on the map; also cache it after rendering. For this case we have two places where need set physical path. One indicates where the shapefile is; while another one indicates where to save the cache files. 
  
 As we tested, AppHarbor supports write access to file system. Make sure the checkbox for “Allow write-access to file system” is checked in the setting tab of your application. So I think the cache is not a problem with this server. Your question is how to use virtual path for setting cache path. Let’s say, in web, we have several ways to converting from virtual path to server path. For example, we can use Server.MapPath("~/[Virtual Path]") or MapPath("~/[Virtual Path]") or using Request.PhysicalApplicationPath to combine the physical path. So I say it’s not a problem for the cache system.  
  
 I used to successfully save an image to the disk on server and display it. But the problem is how to indicate the physical path for the shapefile. As I tested, when we commit and push our project to the server, AppHarbor compiles it automatically, and publish it into their server, I think it’s not the place where we upload the project. So when the application is deployed, the data is not published to the publish server; I tried several ways to convert the virtual path to physical path, but I still cannot find the shapefile neither, so that the map cannot load correctly. 
  
 The cache is generated dynamically, so it saves and loads in the same way; it’s different from looking for a specific file path on the server. We are not expert of AppHarbor, if we misunderstanding or dong something wrong, please feel free to let us know. 
  
 Thanks for reporting. 
 Howard

Howard, 
  
 It seems to me that we need to have a relative path defined for the ImageCache.  Not having a relative path defeats the purpose of having storage on multiple machines.  If we do not have a relative path and do not know the location where the image tiles are stored, how can we clear the contents when the street network changes? 
  
 I am not sure if you are telling me there is no problem porting our website to AppHarbor or that there is.  Your comment, below, leads me to believe there is a problem.  If that is the case, can you provide a fix? 
  
  
 "I used to successfully save an image to the disk on server and display it. But the problem is how to indicate the physical path for the shapefile. As I tested, when we commit and push our project to the server, AppHarbor compiles it automatically, and publish it into their server, I think it’s not the place where we upload the project. So when the application is deployed, the data is not published to the publish server; I tried several ways to convert the virtual path to physical path, but I still cannot find the shapefile neither, so that the map cannot load correctly. " 
  
 Thanks, 
  
 Al Vigil

AI,


Sorry that I didn't represent my word clearly. 

1, the cache can be used in AppHarbor server, we can convert the relative path to physical path by the following ways. 

Map1.StaticOverlay.ServerCache = new ServerCache(MapPath("[VirtualPath]"));
Map1.StaticOverlay.ServerCache = new ServerCache(Page.MapPath("[VirtualPath]"));
Map1.StaticOverlay.ServerCache = new ServerCache(Request.PhysicalApplicationPath + "[VirtualPath]");


With this ways, the app dynamically saves the caches into the disk and loads them back. If you want to clean them, just delete the cache directory you indicated. The conversions above are still available.


2, I still have a problem loading a shapefile. If you have any suggestions, please let me know. You know after compiling, the shapefile might not transfer to the publish server, I cannot find it anymore when I run the application. It's different from the first case. I will write to the company and see if they have any suggestions.


So my point is that cache is not the point prevent you from transferring your application to AppHarbor while finding a specific shapefile is as I tested. Just let you know when they have a feedback.


Thanks,

Howard


 



Hi AI,


Today, we research it more and found it supports cache and it works fine with my sample. So the following list you need be aware of when you deploy your application.


1, put your data (Shapefiles) in the application domain. Such as the App_Data.

2, change the data build action to "Content" so that your data will be deployed into publish server. (This is the reason that I cannot find the shapefile in my previous reply)

3, set your application to allow write access. Because we need generate some resource and save cache files into the server disk.

4, use the conversion the way below to convert from virtual path to physical path. 

Map1.StaticOverlay.ServerCache = new ServerCache(Server.MapPath("~/app_data/caches"));

5, we also have a bug when the server cache is on. We have corrected it, please download the latest version and test out.


Here is a sample I tested, please try it.


Thanks,

Howard



WebMapApp2.zip (325 KB)

 Thank you for the suggestions, Howard.  We are making progress.  I have downloaded the latest version of the Web Edition dlls (for now only the Development version; I don't want to change anything on the production server until I am sure everything works on development computer).


 
However I have two problems with the latest download: 1) I get messages that the evaluation period has expired.  See attached.  How do I get rid of these?  I have a current license.  2) I get a compilation error on the line of code
 
MainMap.SyncClientZoomLevels(ZoomLevelHelper.getInstance().GetCustomZoomLevelSet());
 
 
When I hover over this line using the present dlls (not the latest, but version 5.0) I see the warning,
 
'ThinkGeo.MapSuite.WebEdition.MapSyncClientZoomLevels(ThinkGeo.MapSuite.Core.ZoomLevelSet)' is obsolete: 'This method is obsolete and may be removed on or after November 1st 2011, please use ZoomLevelSet instead.'  See attached.
 
How do I modify the line of code to use the suggested method?
 
I'd appreciate any help you can give me to resolve these two problems,
 
Al Vigil
 

Pictures.zip (112 KB)

 Hi AI, 


 
For the first issue, it seems the evaluation is expired. Please contact support@thinkgeo.com to extend the trial period. Please refer to this post in detail:gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/2/aft/1586/afv/topic/Default.aspx
 
For the obsoleted method, as the warning message, we added a new property called "ZoomLevelSet" in map. I'm not sure which overload is using as your code attached. If the "ZoomLevelHelper.getInstance().GetCustomZoomLevelSet()" returns a ZoomLevelSet object, you can directly set this value to the new property. While if it returns an IEnumerable<ZoomLevel>, please create a new ZoomLevelSet object, add all the ZoomLevels into the new ZoomLevelSet's CustomZoomLevels property; then set it to the Map.ZoomLevelSet property.
Map1.ZoomLevelSet = ZoomLevelHelper.getInstance().GetCustomZoomLevelSet();
//// if your code returns IEnumerable<ZoomLevel>, please use this one.
//ZoomLevelSet customZoomLevelSet = new ZoomLevelSet();
//foreach(var level in ZoomLevelHelper.getInstance().GetCustomZoomLevelSet())
//{
//    customZoomLevelSet.CustomZoomLevels.Add(level);
//}
//Map1.ZoomLevelSet = customZoomLevelSet;

 
Hope it helps, 
 
Thanks,
Howard

Hi Al,  
 Most likely you downloaded and have referenced a Evaluation Web Edition Dll from the ‘My Product Download - Daily Builds’ section of the Customer Portal. The ‘Evaluation Daily Builds’ section of the Customer Portal only contains evaluation dlls. If you have the Full Web Edition development license installed you need to be sure you are referencing the Full Edition dlls in your application. A way to check the Edition of your dlls is to right-click on the WebEdition.dll and/or MapSuiteCore.dll and navigate to the Details tab. Here you will find a description stating ‘Full Edition’ or ‘Evaluation Edition’. 
  
 Hope this is helpful but do not hesistate to contact us if you continue to encounter issues.

 Howard,


I just sent you a reply, but it appears it did not 'take'.  So I am repeating the message,


We have solved both problems.  I downloaded the correct dlls and I no longer get the Evaluation Expired message.  The change of code to the SetZoom level that you suggested also worked.  I am able to compile with no errors now.


However we have a new problem: The image tiles are scrambled when zooming in.  Attached are two images.  4.jpg is the home default display.  3.jpg shows the map when the user zooms in once (using the + icon on the zoom bar).  This behaviour does not exist when I use the old dlls (version 5.0).


I deleted the contents of ImageCache before running the program.  This behavior only exists when I use the latest build.  The two versions differ only in the dlls.  Both have the change to ZoomLevelSet you suggested.


Any idea what is causing this? 


 



001_zommingBug.zip (250 KB)

Hello Al, 
  
 Sorry to delay and thanks for your attached images, I can see the problem, but I can’t recreate it with our sample, could you please provide a small sample that help us to recreate the problem? 
  
 I appreciated your help. 
  
 Regards, 
  
 Gary