I am looking over the code, but it looks like your routes already exist and are not being created in this code. So to begin I need to know if you have verified whether or not the route measures actually start at 0. Have you done the Python calculation into a double field in your route feature class with an expression of !Shape.FirstPoint.M! ?
Are the lines that are being overlaid derivatives of these road lines? In other words, are you certain there is little or no variance in the shared geometry between the routes and the line events you are creating?
No you do not have to do the calculation I suggested in your script, it was just to verify the assumptions about the inputs to the script that are not part of the code.
The general cause I have seen where the MDomain prevents the beginning measure from being 0 while running the Create Route tool occurs when the measure range allows negative numbers and the spatial reference of the route is not metric (like mine).
I have had to expressly include the MDomain environment setting in every script that uses the Create Route tool to ensure that the domain values that avoid that behavior is replicated.
It took some experimentation to find the range that worked. Something like -1000 was OK, but -100 was not. Anyway, it was just trial and error to figure out what I needed.
First of all, are these complete duplicates in every field including the measures?
Well, any difference means that the tool did not duplicate the records, it retained distinct records, which it is supposed to do. If there is overlap of the input events within an event table that have slightly different values then it is supposed to retain each of those separate records and divide not only against the other table records, but within the table records that overlap.
Most likely the Locate Features Along Routes is applying your M Tolerance and M Resolution settings in the background and making the end to end measures slightly different between adjoining segments. That creates overlaps with distinct records that cut up the events internally in that input table.
I think the code is clear enough and should being doing what you need. You could gain a lot of speed by using a single pass of an update cursor to do all of the field calculations on a record at once, rather than doing the update to each record one field at a time.
If al of the fields are in a single table you only need a single update cursor. If your are doing a transfer between tables, rather than joining them and using the field calculator, you can read the source table into a dictionary and then use an update cursor to do the transfer out of the dictionary. With the da cursors that should give you about a 50 fold gain in speed.
So I just want to summarize what the code is doing to see if I understand it and can isolate the point where the problem has to be fixed.
Basically it looks like you are connecting to a database and transferring a subset of the data from it into a new feature class. Then you add and calculate fields. Then you convert that data to route line events. And then you overlay it with another preexisting event layer and make an event layer from that output.
You also do a few calculations on that output, presumably because now you have the data merged together.
we have a software that takes in a shape file as input to do some linear programming and markov chains modelling. The input layer comes from the road data provider as a geodatabase. Another Event table comes in that indicates which roads will be worked on over the next few years. I combine the shape file with event table to create one shape file to be used in teh software
So, on the event table not being created by this code and only being overlaid, are you sure that no measure overlaps exist between any segments, even by fractional amounts?
I just mean pick a single route with problems out of all of the data you are working with and select the set of input events and features that create the final events.
Just sent you an e-mail showing examples of a single table update and more importantly how to do data transfers between tables where there is a common join field (one-to-one or many-to-one). The transfer between tables is where the real speed gain is incredible.
Arcpy loading and geoprocessing has a lot going on behind the scenes to manage errors and memory and read environments and set up, so there is overhead using them.
The data transfer code I sent replaces a geoprocessing operation where you would do a standard join and then use the field calculator to move data from the table added by the join to the editable table.
