I'm going to build my routing index (.rte) file from an original source of an SQL Table (uploading the OpenStreetMapData). How do I identify a street as one-way when building the index, where I'm loading individual features manually?
Also, how do I identify a street as a Freeway (65MPH) vs. a regular street(25MPH) vs. arterial(45MPH) so that the shortest distance is calculated correctly (Including Time)? The examples again show shape files and I'm using SQL Tables.
bob
Hello Bob,
Thanks for your post, I’m afraid I have misunderstanding here, when you say “identify”, you mean you don’t know if that road it one way road, and you need a way to know or you know that road is one way road but need a method to define it when you build the index, then it will working when routing?
If it’s the first way, sorry we don’t have any way to know that, you need your own logic to find out what’s the type of that road, if it’s the second way, we do have a build event can make this, please refer routing HowDoISamples—>Building Routing Data, in this sample, it shows you how to define a road as one way, how to define it as high way or normal way.
Please feel free to let us know your queries.
Regards,
Gary
Maybe I am clueless (all things are possible), but the example you give does not seem to give me any idea on how the logic is working (under the covers). All I see is that you are using two different shape files to do the routing for one-way streets.
I guess the real question I have is, if I attempt to route someone through a city that has one-way streets, will your tool route someone down the wrong direction because that street “seems” to be the shortest. If all we are talking about is arrows showing the one-way street, then at this time I don’t need the arrows. I just don’t want to get someone killed. :)
If not, then how do you take a set of features, (where the original data imported into SQL Server from OpenStreetMapData has a field indicating one-way – true/false) and make sure you don’t send someone down the wrong way?
Thanks. bob
Bob,
This is an excellent question!
First let me begin by saying that you are welcome to retrieve data from SQLServer to create your RTG file and that you only really need ALL of the necessary column data to be able to create an RTG. As you will see a bit later this shapefile column data is what is necessary to build a really useful RTG.
Back to your data question, I am not sure how you are querying this data? If you
are using a MSSQL2008FeatureLayer then you should be able to easily pass this in as a FeatureSource to the
RtgRoutingSource.GenerateRoutingData() method.
You are correct that in our sample we only have two shapefiles, one designed to create an RTG that is aware of one-way streets, and the other that will create an RTG that is not aware of one way streets.
The differences in these two shapefiles are some column values that we added to the basic AustinStreets.shp. The original AustinStreets.shp did not have columns for One_way or Indicator values, we edited this shapefile and added these Columns and ColumnValues to create the new AustinWithOneWayRoad.shp.
It would seem that the OpenStreetMapData you are using already has the data needed to determine if a road is one-way road but there is some additional information needed for the one-way logic to work really well that I will discuss a bit later (Indicator Values).
You will see in the BuildingRoutingData Sample Application we have an option that creates the AustinWithOneWayRoad.rtg. We have an BuildingRoutingData event that gets fired while the RTG is being built that can allow us to modify each RouteSegment before it is added to the RTG.
To build a ‘One-way enabled RTG’ the BuildingRoutingData Event calls the OneWayRoad() Method. Here we look at the values of the 'One_way' and 'Indicator' columns (from the AustinWithOneWayRoad.shp) to see if we need to modify the StartPointAdjacentIds or the EndPointAdjacentIds for each individual RouteSegment that is eventually stored in the RTG.
If it is one-way then we either clear out the StartPointAdjacentIds or the EndPointAdjacentIds as these are the elements the
RoutingEngine uses to determine what direction the route can travel along this RouteSegment.
The Indicator value used in the sample and manually added to our AustinWithOneWayRoad.shp helps to inform the Routing Engine as to the direction that the line was digitized. So if the line was digitized from left to right, but the direction of travel for that one-way road is actually from right to left we need to know this as it changes whether we clear StartPointAdjacentIds or the EndPointAdjacentIds.
Once all of the above is taken into consideration we then create the RTG index that 'knows' about one-way streets. This index should provide routes that respect the one-way values you provided in your shapefile.
So to round out this answer to get the RoutingEngine to respect One-Way streets your base dataset needs to have some indicators for one-way streets and the direction that they were digitized so that you can modify your StartPointAdjacentIds or EndPointAdjacentIds for your RouteSegments before the RouteSegments are added to the RTG. If you have this data in your dataset you then just need to setup your code that creates your RTG file to read from whatever columns your data has, just as we did in the OneWayRoad() method.
Your next question about the weighting of each street type is resolved in a similar manner.
We simply intercept each RouteSegment as the RTG is being built (remember our Building event) and modify the Weight parameter based on the type of road that is passed in. In our AustinStreets.shp the value in "CFCC" column that tells what type of road this is and so we can modify RoadSegment.Weight to make the RouteSegment appear shorter(faster) or longer(slower) to the Routing Engine. You will need to check what value in your OpenStreetMap data has the best identifier for the road type and try out different weights to see what works best for your scenario. One idea for this might be to use a speed limit column and divide the weight by that value.
I hope this information is helpful!
Thank you. That was a lot of helpful information. And only leaves me a couple in return for now. As you can see below, this is the schema provided from the OpenStreetMapData files after they are imported into SQL Server (see picture)
There is a oneway field that is true/false. But I don't readily see the other field that defines which direction...do you? And, we can't go through the entire database (over 1M records) and set that manually...
BTW, I don't use your MSSQL2008Feature because it is not flexible with our existing database authentication, etc. model. But I build the an InMemoryFeatureLayer manually by adding individual features to the InternalFeatures of that class. Is there a problem with this method?
So how do I deal with the One-Way streets from the data in OpenStreetMapData?
bob
Hi Bob!
According to the Open Street Map Wiki, one-way streets SHOULD be drawn in the direction of travel: wiki.openstreetmap.org/wiki/One_way
So it would seem an direction 'Indicator' column is not necessary, provided that everyone adding data to Open Street Map follows the convention of drawing the streets in the direction they travel.
There may be some OSM review process to verify that one-way streets are properly entered, but I can neither confirm or deny that this action takes place. You may want to conduct your own review of some one-way streets to see if they route properly or contact the Open Street Map Community to see if they have information on their data review processes.
For the creation of your One-Way street aware RTG file I again refer to the BuildingRoutingData sample application where we are checking for the Indicator value. As the features in the OpenStreetMap data SHOULD be in the direction of travel you would want to set the following for each RouteSegment that is One-Way:
e.RouteSegment.StartPointAdjacentIds.Clear();
On the surface using an InMemoryFeatureLayer for your Features sounds like a fine idea, however I know you are encountering some exceptions with this so we should investigate these further in the other thread: gis.thinkgeo.com/Support/Dis...fault.aspx