ThinkGeo.com    |     Documentation    |     Premium Support

Alternative to rtg as file?

I have loaded my roads to a postgres table and routing works fine.
Is there any alternative to having the rtgroutingsource as a file?
 
 
                FeatureLayer dkRoadsLayer = Layers.Road.RoadLayer.GetDkRoadsLayer();
                dkRoadsLayer.DrawingExceptionMode = DrawingExceptionMode.ThrowException;
                dkRoadsLayer.Open();
 
                RtgRoutingSource rtg = new RtgRoutingSource(@"C:\GisData\Export\merged.routable.rtg");
                RoutingSource routingSource = rtg;                
                routingSource.Open();
 
                //var algorithm = new DijkstraRoutingAlgorithm();
                var algorithm = new AStarRoutingAlgorithm();                
                RoutingEngine routingEngine = new RoutingEngine(routingSource, algorithm, dkRoadsLayer.FeatureSource);
                
                routingEngine.RoutingResultsType = RoutingResultsType.RouteSegmentsAndFeatures;
                routingResult = routingEngine.GetRoute(startPoint, endPoint);
                routingSource.Close();
                dkRoadsLayer.Close();
 
- Niels
 

Hello Niels, 
  
 What do you mean as a file? For now the RoutingSource file is set as rtg format. 
  
 Sorry if I misunderstanding. 
  
 Regards, 
  
 Gary

Niels, it sounds like you’re asking if the contents that go into the RTG file can be stored elsewhere.  While it’s probably not perfect and seems to perform a bit slower than the standard RTG file, a month or so ago I created a “SqlRoutingSource” class which is derived from “RoutingSource” but stores the contents in a SQL Server table.  I had to be creative and build a table structure to hold the same items you’d find in a RouteSegment and I had to override some methods and created a few new ones for internally dealing with a different data source and structure in the SQL table.  For the adjacent nodes  I put them in comma-separated strings in columns for the start and end node lists.  The input is still shapefiles, but once you get to the “FeatureSource” it doesn’t seem to matter much where the data comes from.  Once I created the “SqlRoutingSource” class I believe I just plugged it into every place where I previously used “RoutingSource” and it all worked once I worked through any errors.  Eventually we might move the original data to SQL Server, much like you moved yours to PostGres.  The one thing I wasn’t clear about and didn’t see anything in the documentation or samples was the RTX file, so right now my SQL version of the RTG file doesn’t have any such beast.  I did not encounter any methods I needed to implement or override that dealt with the RTX file.  I don’t know what would go in it and how to create it, or perhaps the equivalent would be some to build sort of SQL Server index. 
  
 Allen

Hello Allen, 
  
 Thanks for sharing your experience. 
  
 Regards, 
  
 Gary

 Hi Allen.


My idea was a table in a database so i didn't have to maintain and push a +100 Mb rtg file to the users, and using a network share ends with a file lock, the file is open by other.... and so on.. (All .shp and .tab files are now converted and lives in a database) so  the rtg is the last file that is giving lock & distribution problems.


Right now I'm in another part of my application, but your idea looks nice, something I'll must look at later, thanks for sharing.


- Niels


 


 



Niels, 
  
 The current version of our application eliminated shapefiles (except for user-supplied data) and is storing all the mapping data in SQL Server.  This opens up all sorts of potential when it comes to data replication.  Right now the app looks for the .RTG file but some day that stuff might be moved into the database itself, depending upon customer demand.  What I did was more of a “could it be done?” experiment rather than a polished implementation.  We maintain all of our data in a single nationwide database, so we’d have to carve out chunks of roads (eh, once the data actually has the items needed to do the routing–we must handle one-way streets and overpasses) and process the routing information for several dozen geographical areas, then generate update scripts to get the data to the customers.  The whole ritual might be weeks of processing time. 
  
 Allen

Thanks for sharing.