Accepted Solutions
Hi Maarten,
Found your 1 meter segment.
This is what i did.
- Created another feature class with M Tolerance 0.0001
- Appended your features to my new feature class
- Created a route event layer.
- There it is your 1 meter segment.
Check your route feature class M Resolution possibly, it's >= 1.
Also please make sure you are posting your questions to correct forum, Geonet Help forum is for the general form related topic, Best place for your question would be Managing Data. This will help you in getting better help.
The first table has the lines (from_KP_km - to_KP_km) and it connects with the featureclass GDF (2nd picture) with FUGRO_CODE. With the tool make route event layer i want to put the lines from the table on the line in the feature class. The problelm is that only the lines with a length of 2 meter are showing (and not the lines of 1 meter).
Below are my trouble shooting suggestion.
- One thing that stands out to me is your map unit is meters, chainage column values looks like kilometers. Generally route feature class M values are in meters (technically M values has no units), may be you should convert your KM to M and try creating your route event layer.
- Use Locating error field to check if there are any error when event layer was created.
- Use Identify Route measure tool to inspect your route feature class chainages. Customize -> Toolbars -> Customize. Commands tab, search for "Identify route locations", drag the command and drop it on any toolbar (I prefer next to identify in commands toolbar)
If your route feature class and event table chainage are consistent and correct and there are no locating errors, your event should be located along the route feature class.
As Ted mentioned, for both of your examples, the sets of line segments have overlapping measures that will cause the 1 meter line to fall inside of a 2 meter line. Since all your lines are the same color and thickness and no end markers, there is no way you will ever see the overlapping lines as separate features, but they are actually there, whether you see them or not. It appears you have select both segments so that again only the longer one is visibly highlighted. To demonstrate that you actually have a real problem you need to filter out the 2 meter long segments by using a definition query like:
to_KP_km - from_KP_km < .0015
If the 1 meter lines still don't show then the problem is real. But if they do show up after applying the filter then this is simply due to the fact that you are obscuring the 1 meter lines by overlapping the segments.
To use symbology to show that there are actually 2 lines of different lengths that share a segment without using a filter, you would have to add end cap markers to the lines, and use a categorized or proportional symbol that varied the line colors and thicknesses according to the line lengths. I would change the values in the Length_M field to be correct (since they are not correctly reflecting the measure lengths for the 2 meter long lines) and use that to vary the symbols. Additionally, to ensure the lines draw in an order where thinner lines draw on top of thicker lines you would have to do a decreasing length sort of the event table so that the shorter events draw last on top of the longer events, or use separate layers with different definition queries to make shorter lines draw last in the top most layer.
I am not clear what this data is showing or why you would want to create overlapping segments. Most event tables do not contain overlapping events for one attribute type, like speed zones or lanes, unless there is a right and left hand offset to separate the overapping line types. If a left and right hand offset applies then there is a setting to use a numeric field with positive/negative values that will offset the lines left and right so that they do not overlap. Below is an example where I use different symbol categories from two fields to separate overlapping line types using color. Another field is used in the event layer set up to control the left and right hand offsets. These lines represent house number address range data patterns for each side of the road. The side offsets were determined by the position of the actual address point relative to the central lines (the Centerlines are not being shown in this example, only the offset lines). The thicker lines are highlighting unexpected addressing patterns between house pairs with the same types of Orientation and Parity and the events were actually sorted according to their category and measure values to display them in a specific order. The order of the Symbol Categories in the layer symbology list also affects the order in which the lines are drawn, so technically I should move the thicker lines below the thinner lines in the symbol list to get the thin lines to always draw on top of the thicker lines wherever an actual overlap occurs between two different categories.
