Thursday, September 25, 2008

Creating a Feature Class of Pairs of Intersecting streets .. Part 2 Limitations

The results are the points at which streets with different names connect to one another. In most cases, this satisfies the obvious meaning of the term cross street. But it could give rise to some strange special cases.

1) Does a T - junction constitute a cross street?
2) Does the point at which a minor street merges into a major street constitute a cross street?
3) Does a single street which changes names constitute a cross street? What if the difference is only the direction, but the name remains the same?
3a) Does a street that takes a sharp bend constitute a cross street?
4) Does a traffic circle with multiple spokes on it constitute a cross street? If so, is it the center point of the circle, or is each junction of the spoke intersecting the circumference of the circle a separate cross street? What is the name of the circumference street of the circle? If it does have a formal name, how do you distinguish the two points generated when a street enters and leaves the circle?
5) How do we handle loops when the street loops upon itself? The above procedure returns as a cross street the point where a street changes name with no other street crossing it. This requires us to have a more formal discussion of the term cross street.
6) How do we define the beginning or ending points of a street? One way is to call the beginning point as the point at which the street number is lowest, and the ending point at which the street number is highest. Another would be to avoid the problem completely by not distinguishing the ends (like a piece of rope that has two ends and no beginnings).
7) What if one road goes over another road (e.g. as at an overpass)? This could show up as a cross street, but would definitely would not meet the vernacular definition.

Monday, September 15, 2008

Creating a Feature Class of Pairs of Intersecting streets from a street centerline network

Step 1: We start with a set of features of Feature Class STREET_SEGMENTS (total 3793 features)

  • Each street segment consists of one continuous line feature and has the street segment name and a polarity (a way of showing that one end is the start and the other end the end of the line).
  • Different segments could have the same segment name
    * The segment name is actually the street name and has the following components
    a. Direction (N, S, W, E or Null)
    b. Street_Name
    c. Street_Type
  • Use Functional Attribute to generate a single string out of the three components. One such Functional Attribute would be to CONCATENATE the three fields together with a space and treated the Null direction as the empty string ‘’.

Step 2: Apply Analytic Merge to STREET_SEGMENTS to merge by attribute Segment Name to get STREETS. This will ensure that each Street Feature has a unique name (843 Features)

Step 3: Output Feature Class of the results of the STREETS query to a Geomedia Warehouse calling it MILPITAS_STREETS. While we could/should work with the query STREETS, at some point we will need to have an ID for referring to the streets, and writing out the Feature assigns an ID field.

Step 4: Apply Spatial Intersection of MILPITAS_STREETS that touch MILPITAS_STREETS to get intersections of all the Streets. (3565 features). The result will be a set of point and line features.

Step 5: Apply Attribute Query to the result from Step 4 with the Filter being ID – ID1 <> 0. This will remove features which consist of streets that are spatially equal to themselves. Details on why ID <>ID1 as a filter does not work is given in Identifying duplicate Spatial Features in GeoMedia (There are 2722 features which is 3565-843 as expected)

Step 5 is a query that produces a feature class where the every intersection appears at least twice, in different orders of the street names creating the intersection. In the case of junctions where 3 streets meet, there will be 6 features with the same intersection point, and in the case of 4 streets, there will be 12 features with the same intersection point. A illustrative example is the intersection of N and S Main Street and E and W Calaveras Blvd.


Step 5 produces a feature class that may then be modified for other purposes.

Suggested Modification 1: Eliminate duplicate combinations of cross streets so that each intersecting pair of streets appears once. One way of doing this may be to apply an Attribute Query to the Step 5 results with ID - ID1 > 0

Suggested Modification 2: By applying an Analytical Merge of the results of 5, and counting how many intersection point create each result, it may be possible to rename the results where the count is greater than 2. For instance, the case of N and S Main St intersecting E and W Calaveras Blvd may be considered Calaveras Blvd crossing Main St.

Application and Business Requirements:

The choice of modifications is in the realm of business requirements that determine how the data is to be used, and how cross streets should be defined. One application is to describe traffic accidents, and in that case if the order in which the street names are stated is not important, Modification 1 may be adequate for the purpose.

A second application is to create a street index of all streets cross each street. In this case, the data from Step 5 may be exported to an EXCEL spreadsheet and then manipulated.

Monday, September 8, 2008

Identifying duplicate Spatial Features in GeoMedia

Many times we have a feature class that has the same feature duplicated, and we want to identify which they are, so we can delete them.

Here is one method that works that has been applied in City of Milpitas GIS.

Let us have a feature class F which is a simple geometry class with an ID.

Step 1. Create a Spatial Intersection query between F and F (yes, with itself) for the geometries that are "Spatially equal"; We will call this Query 1

Step 2. Look at the results of Query 1 in a Data table. You will see ID and ID1 Columns. The number of entries in the table should be equal to or greater than the number of features in F

Step 3. Create an Attribute Query of Query 1 such that ID - ID1 < 0. We will call this Query 2. (This step is not obvious: What we want is ID < ID1, but GeoMedia does not accept that a valid expression, but ID-ID1 < 0 serves the same purpose.)

Step 4. Look at the result of Query 2 in a Data Table. If there are 0 entries, it means that there are no duplicate geometries in the Feature Class F. Each line in the Data Table of Query 2 shows a pair of features in F that are Spatially equal, where ID is the feature with the lower value ID, and ID1 is the feature with higher value ID.

Note that these are pairwise comparisons. So 2 features Spatially Equal show in 1 record, 3 features Spatially Equal will show 3 records, 4 features spatially equal will show 6 records, and so on.

The result is that we have now identified features that are Spatially Equal. The next step may be to keep one of the features, and delete the rest of the features that are spatially equal. This will be described in an upcoming post if there is enough interest.

Wednesday, September 3, 2008

Analysis of Results

Fig 1 Layout of PIPES and VALVES at full extent

Fig 1 shows the PIPES and VALVES feature in full display. The lines represent PIPES and the dots represent VALVES.

Fig 2. A single pipe segment with associated valves

Fig 2-a. Details showing the number of valves and STOP_VALVES_IDS for the given segment.

On picking a fairly complicated section, we note that there are 10 valves, 7 of which are at the ends of the segment, and 3 of them lie on the segment linework. The detailed results show that in fact there are 7 valves, so it appears that either our methodology does not work, or that valves are not on the pipes as expected.

Fig 3.

Fig 3 shows the 3 interior Valves.

Fig 4

Fig 4-a

Fig 4-b

Fig 4-c

Fig 4-d

Fig 4-e

Fig 4, Fig 4-a through Fig 4-e show various zoom levels. It is not until Fig 4-e, where there is a 1 to 1 zoom level that we see that the valve is not located on the pipe.

Fig 5

Fig 5 shows an analysis of all the valves that do not touch PIPES. There are 11 of them.

The recommended action is to investigate the existence of the valves, and if they in fact connect pipe segments, to correct the underlying GIS. Since the GIS linework is obtained from Engineering CAD drawings, corrections would have to be made there.

Authors Opinion:

This exercise demonstrates that merely converting paper drawings into digital form may not immediately create correct results. When a system is in a computer, there is expectation of a higher level of automation and correctness than paper documentation. As GIS analysts and professionals, we appreciate the limitations of the system and with an understanding of what is going on, can provide reasonable explanations for apparently unexpected results. Emergency maintenance personnel, working under the pressure of thousands of gallons of water leaking, under cover of darkness, and in flooded conditions cannot be expected to do the same deep level of analysis. It is possible that without proper training, and correcting the pipe network diagram, maintenance personnel would quickly lose faith in the digital maps since it does not appear to pick up valves on a pipe segment that exists on the ground. Since the purpose of the map is to identify shutoff valves in an emergency, relying on it in the current form may give incorrect results in the height of activity and confusion of a pipe break, where human reasoning may not be able to determine that it is the linework that is not fully correct.