Building a street index

[MaciekB]

Hi All,

I am trying to create a street index for a series of map books that we produce in our organisation...

The map books contain many pages and each page contains several suburbs and many streets/roads. What we are trying to achieve is a street index which contains the following columns: a) Street name b) The suburb in which that street is c) Page number that it appears on d) the X,Y grid reference of the piece of annotation that identifies the street.

We can create an index that satisfies all of the above criteria but it gets a bit more complex than that as we want to list every suburb that the street goes through (not just the suburb, page number and X,Y co-ords of where the annotation sits) but have the grid reference referencing only the closest related annotation for the given street. e.g. Main Street runs through suburbs A and B on page 41 and Suburb C on page 42 but the annotation sits within Suburb B on page 41 at grid ref 257-945 and Suburb C on page 42 at grid ref 257-015. So we want Main Street to be listed as existing in Suburbs A and B on Page 41 and Suburb C on page 42 but the co-ordinates of each record to be referencing the location of the annotation on each page.

For example...

Name               |    Suburb    |    Page   |    Ref        

Main Street    |   A   |      41   |    257-945
Main Street    |   B   |      41   |    257-945
Main Street    |   C   |      42   |    257-015

We also want to list only the roads that are annotated/labelled and leave out the roads that weren't labelled. This rules out using the roads layer to generate the index as that would result in an index containing all the roads in the dataset whereas in reality not all the roads are labelled and we don't want to list a road that is not labelled as the user may not be able to determine which street it is due to a lack of a label.

So far, I have an annotation feature class which contains a text string field containing the road name in full, an X co-ordinate field populated with the X co-ordinate of the piece of text, and a Y co-ordinate field populated with the Y co-ordinate of the piece of text. Next I've got a roads feature class which has been dissolved so that all roads of the same name are merged into one, then the result was intersected with the page extents featureclass so each road record contains the page number it appears on (as a result, road lines are split at the page boundary), and then that result was intersected again against the suburbs featureclass so that each road also contains the suburb it appears in and is also split at the suburb boundary. This featureclass contains a Name field containing the road name in full, Suburb field containing the suburb name and Page Number field containing the page number.


If anybody would have any idea on how to generate such an index, I would appreciate any assistance. I have tried table joins and spatial joins to no avail.

Thanks...

[RobertBorchert]

In E911 we called what you are looking for as a MSAG.  Master Street Address Guide.  However, it was a lot more complex than what you want.

To make it the most accurate you may have to break all the streets at the boundaries of the suburbs and map pages.

Then create two new attributes in the streets for X,Y make them type as double

Use the calculate Geometry tool to create the X,Y for the street Midpoint.

use the resulting X,Y to create point events.  You can delete the X,Y locations that don't have a street name.

Export the point events to your database.

Create the appropriate attributes in your new point layer.

Transfer the attributes of the underlying polygons to the appropriate attributes in the x,y point layer.

you will now have a sortable feature from which you can create your index.

Other than the breaking of the streets at the polygon boundaries the rest of it is actually pretty quick. 

By using the midpoint of the street the break in the streets does not have to be perfect on the edge of the polygon.

You can also create the X,Y based on the centroid of the annotation.  I think the first method would be more accurate as the second would depend on the accuracy of your annotation placement.  Meaning IF the center line falls close to the boarder of a polygon the centroid of the annotation could be in an adjoining polygon.

Hi All,

I am trying to create a street index for a series of map books that we produce in our organisation...

The map books contain many pages and each page contains several suburbs and many streets/roads. What we are trying to achieve is a street index which contains the following columns: a) Street name b) The suburb in which that street is c) Page number that it appears on d) the X,Y grid reference of the piece of annotation that identifies the street.

We can create an index that satisfies all of the above criteria but it gets a bit more complex than that as we want to list every suburb that the street goes through (not just the suburb, page number and X,Y co-ords of where the annotation sits) but have the grid reference referencing only the closest related annotation for the given street. e.g. Main Street runs through suburbs A and B on page 41 and Suburb C on page 42 but the annotation sits within Suburb B on page 41 at grid ref 257-945 and Suburb C on page 42 at grid ref 257-015. So we want Main Street to be listed as existing in Suburbs A and B on Page 41 and Suburb C on page 42 but the co-ordinates of each record to be referencing the location of the annotation on each page.

For example...

Name               |    Suburb    |    Page   |    Ref        

Main Street    |   A   |      41   |    257-945
Main Street    |   B   |      41   |    257-945
Main Street    |   C   |      42   |    257-015

We also want to list only the roads that are annotated/labelled and leave out the roads that weren't labelled. This rules out using the roads layer to generate the index as that would result in an index containing all the roads in the dataset whereas in reality not all the roads are labelled and we don't want to list a road that is not labelled as the user may not be able to determine which street it is due to a lack of a label.

So far, I have an annotation feature class which contains a text string field containing the road name in full, an X co-ordinate field populated with the X co-ordinate of the piece of text, and a Y co-ordinate field populated with the Y co-ordinate of the piece of text. Next I've got a roads feature class which has been dissolved so that all roads of the same name are merged into one, then the result was intersected with the page extents featureclass so each road record contains the page number it appears on (as a result, road lines are split at the page boundary), and then that result was intersected again against the suburbs featureclass so that each road also contains the suburb it appears in and is also split at the suburb boundary. This featureclass contains a Name field containing the road name in full, Suburb field containing the suburb name and Page Number field containing the page number.


If anybody would have any idea on how to generate such an index, I would appreciate any assistance. I have tried table joins and spatial joins to no avail.

Thanks...

[MaciekB]

Thanks Robert,

The method you have provided would certainly work, however the resulting index would contain ALL the streets that have a name attribute. The map books we create are generally 1:100,000 or 1:50,000 so it is not feasible to label all the roads e.g. in the metropolitan area or in towns as the street density is too high and labels simply will not fit so as a result only some of the roads are annotated.

If we created an index containing all the streets with a name attribute and somebody looked up for example Clarence Street and then went to the page on which it is claimed to be and found the location of the grid reference, he/she may indeed find that there is no label for that street as it was too small to be annotated and therefore it could be ambiguous as to which street Clarence Street actually is as there could be several other streets in that general vicinity.

So we cannot use the road centreline or centroid data to create the index as such because it would list everything yet everything is not annotated. The index has to be based only on what exists in the annotation featureclass; creating centroids for the annotation, calculating the X,Y and then transferring suburb and page number data into a new field wouldn't work either as it would only list the suburb in which the annotation centroid sits in whereas in reality the road may run through several other suburbs which would need to be listed as well.

Take a look at the following example...

[ATTACH=CONFIG]23985[/ATTACH]

Using annotation centroids to generate an index would result in Springbank Road being listed only in Colonel Light Gardens whereas in reality it runs through Colonel Light Gardens, Panorama, Clapham and Torrens Park. So the problem is getting the index to list Springbank Road as existing in Colonel Light Gardens, Panorama, Clapham and Torrens Park BUT have the X,Y references pointing only to the annotation.

In E911 we called what you are looking for as a MSAG.  Master Street Address Guide.  However, it was a lot more complex than what you want.

To make it the most accurate you may have to break all the streets at the boundaries of the suburbs and map pages.

Then create two new attributes in the streets for X,Y make them type as double

Use the calculate Geometry tool to create the X,Y for the street Midpoint.

use the resulting X,Y to create point events.  You can delete the X,Y locations that don't have a street name.

Export the point events to your database.

Create the appropriate attributes in your new point layer.

Transfer the attributes of the underlying polygons to the appropriate attributes in the x,y point layer.

you will now have a sortable feature from which you can create your index.

Other than the breaking of the streets at the polygon boundaries the rest of it is actually pretty quick. 

By using the midpoint of the street the break in the streets does not have to be perfect on the edge of the polygon.

You can also create the X,Y based on the centroid of the annotation.  I think the first method would be more accurate as the second would depend on the accuracy of your annotation placement.  Meaning IF the center line falls close to the boarder of a polygon the centroid of the annotation could be in an adjoining polygon.

[RobertBorchert]

I am a little confused by your response.  One on hand you say basing the index on annotation would not work and you indicate you only want to do it with annotated roads.

If you do it based on the annotation center point you could snap the resulting point to the road center line before giving it the suburb attributes.

What I had done in the past was I had created an attribute for the roads indicating if I wanted it in the index.  Same issue not all the little roads are showing a label. It was someone labor intensive to set it up but nothing to maintain.  

If you had some sort of criteria set up to only annotate certain roads you could revisit those roads and break them at the suburb borders go from there.

Thanks Robert,

The method you have provided would certainly work, however the resulting index would contain ALL the streets that have a name attribute. The map books we create are generally 1:100,000 or 1:50,000 so it is not feasible to label all the roads e.g. in the metropolitan area or in towns as the street density is too high and labels simply will not fit so as a result only some of the roads are annotated.

If we created an index containing all the streets with a name attribute and somebody looked up for example Clarence Street and then went to the page on which it is claimed to be and found the location of the grid reference, he/she may indeed find that there is no label for that street as it was too small to be annotated and therefore it could be ambiguous as to which street Clarence Street actually is as there could be several other streets in that general vicinity.

So we cannot use the road centreline or centroid data to create the index as such because it would list everything yet everything is not annotated. The index has to be based only on what exists in the annotation featureclass; creating centroids for the annotation, calculating the X,Y and then transferring suburb and page number data into a new field wouldn't work either as it would only list the suburb in which the annotation centroid sits in whereas in reality the road may run through several other suburbs which would need to be listed as well.

Take a look at the following example...

[ATTACH=CONFIG]23985[/ATTACH]

Using annotation centroids to generate an index would result in Springbank Road being listed only in Colonel Light Gardens whereas in reality it runs through Colonel Light Gardens, Panorama, Clapham and Torrens Park. So the problem is getting the index to list Springbank Road as existing in Colonel Light Gardens, Panorama, Clapham and Torrens Park BUT have the X,Y references pointing only to the annotation.

[MaciekB]

Apologies for the confusion. I need to base the index on both the roads featureclass and the annotation. Each listing must be based on the road centre lines, suburbs and page numbers, whereas the grid reference must be based on the annotation. And if there is no annotation, there should be no listing.

Could you elaborate a bit on your idea of snapping the annotation centre point to the road centre line and then giving it the suburb (and page) attributes? This looks like a manual process which seems like a labour intensive task as this map book contains 100+ pages so going through and snapping every annotation centrepoint to the relevant road on each page and then duplicating it for each suburb and page combination, would take forever. The index process has to be as automated as possible as it would be repeated for other map books.

I am a little confused by your response.  One on hand you say basing the index on annotation would not work and you indicate you only want to do it with annotated roads.

If you do it based on the annotation center point you could snap the resulting point to the road center line before giving it the suburb attributes.

What I had done in the past was I had created an attribute for the roads indicating if I wanted it in the index.  Same issue not all the little roads are showing a label. It was someone labor intensive to set it up but nothing to maintain.  

If you had some sort of criteria set up to only annotate certain roads you could revisit those roads and break them at the suburb borders go from there.

[RobertBorchert]

First generate the X,Y of the annotation and create a point.  the point if created from the same table should contain the annotation text.

There is a command called Bulk Snap Command which you can download that will use classic snapping rules to snap selected features to what you have designated. 

Then do a spatial join of the point to the street layer and the various polygon layers.  You end resulting point feature will have the name attribute from each of the different layers joined together.

Apologies for the confusion. I need to base the index on both the roads featureclass and the annotation. Each listing must be based on the road centre lines, suburbs and page numbers, whereas the grid reference must be based on the annotation. And if there is no annotation, there should be no listing.

Could you elaborate a bit on your idea of snapping the annotation centre point to the road centre line and then giving it the suburb (and page) attributes? This looks like a manual process which seems like a labour intensive task as this map book contains 100+ pages so going through and snapping every annotation centrepoint to the relevant road on each page and then duplicating it for each suburb and page combination, would take forever. The index process has to be as automated as possible as it would be repeated for other map books.