Ryosuke Mizuno
The most useful map-scale of the urban planning base-maps in Japan is 1:2,500. However, sometimes the map needs to be reduced to show all of the cities or districts.
If we do MAP-REDUCTION with ArcInfo, we must edit annotations such as house, road or river names. If we simply minimize the annotations, no one can read them. But if the size of annotations is equal to the original map, some of them are overwritten by others.
This paper describes an approach to solve the problem through automatic editing.
As provided by Japanese city planning low, many cities have urban planning base-maps which are scaled 1:2,500. Those maps are fundamental materials of urban planning, though this scale shows less than 2 Km width (East-West) and 1.5 Km height (North-South).
Even if Japan is a small country, this map seems rather small for showing the cities in one map. For that reason, we receive some orders like "Show the city in one map" frequently.
Some problems occur during MAP-REDUCTION when done by hand. ArcInfo settles many problems. For example, we can change the scale easily, can unit a lot of map pieces, and all ArcInfo functions make few errors.
But there is a problematic feature, it's a quite difficult matter.
It is ANNOTATION. The problem with Annotation is quite difficult to solve without human interaction.
When this paper says the word "ANNOTATION", it means, "the characters indicating objects on the map".
There are many annotations on a map. Probably, there are a great deal of annotations in a series of urban planning base-maps. A common case, those annotations explain important buildings, roads, rivers, railroads, and places.
Map-Reduction means, "down the scale and unit the maps in one", Originally, maps are reduced by photograph. Whenever it needs annotations, someone, who is called the tracer in Japan, sticks some printed characters on the reduced map, at the proper position, at a size that is easy to see. In short, Annotation's editing is dependent upon human hand.
In Japan, "Digital Mapping" has a more narrow meaning than in other countries. It is a series of spatial databases only digitized with aerophotographs. Also it is limited by various ways of database definition.
When we received the map-reduction operation of one of the largest cities in Japan, we had to use the Digital Mapping Data of the city. It isn't ArcInfo's Database basically, but we could convert it. We converted its annotation data as point coverages because the annotation data has the information about position of start to writing, and no more information about location.
If we use ArcInfo for map-reduction, two problems occur with the reduced map's annotations.
One of the problems is overwriting. Those annotations are disposed in order to the scale 1:2,500. It has some attributes about how to write the characters. If the annotations are written according to the attributes, some annotations will be written upon another annotation. Then we have to change the attributes or edit the location of annotation's point.
The second problem is duplication. The Digital Mapping Data was divided up as following the division of the former paper map. Of course annotation data was divided. Many roads, rivers or railroads cross over some maps. They have an annotation in each map at least. If a road crosses over 3 maps, it may have more than 3 annotations. But we should choose one of the annotations which is located in the most effective place, or the reduced map will be poor looking.
For this reason, we sometimes had to edit the annotation data. Though we solved the above-mentioned problems, more problems exist. The database will be renewed every 3 or 4 years, and the reduced annotation data must be renewed at the same time, over and over again. Nobody needs such a complicated way that database maintenance will become troubling.
A way remains to clear the problems. We have to edit the data automatically. We have to develop the routine for automatic editing.
In the first instance, we should have recognized the problem of duplicate or overwrite annotations for ArcInfo. This is the most difficult for us, in spite of the human ability to recognize it at a glance.
Original annotation data's point attribute table has several items as follows.
Please pay attention to the attribute "Vertical or horizontal". Strangely, Japanese can be written both vertically and horizontally. This is one of the characteristics of Japanese language.
The attribute "Type of expression" has several distinctive codes as follows.
Below lists the requests of our clients.
They want to make another edition which shows the boundary of administration. Place names will be indicated on the edition.
Parking area, Others 1 and Others 2 are not important objects in the map. Station name is important, but it doesn't have its own distinctive code. Thus, we had to find all the station names from the annotations. We assumed the attribute "Characters" will be effective, because all the station names must include the character "STATION".
The time has come when we must start to create the logic. To begin with the operation, we chose the necessary annotations according to previous requests. As we assumed, we could pick up the station names. And we divided the annotation data as "necessary" and "unnecessary".
Multiple line annotation is one of the causes of overwriting. Some of the large buildings, especially schools or public establishments, have long names. Occasionally, the names were divided on several lines. These locations can be quite near each other. When this happens, the names will be overwritten. We have to move those annotations.
The logic to extract multiple-lined annotations is very simple. We assumed that those annotations have the same "Type of expression" code. We got those points' coordinates by ADDXY command. If those points are horizontal annotations, those points' X coordinates might have approximate value. And the distance between each point's Y coordinate might be as long as the attribute "Text-size".
When we extract them, all we have to do is set the annotations at 2mm intervals from the first line. Of course, the first line is fixed.
For the most part, the overwrite problem is solved in this way unexpectedly.
We have to extract the rest of overwrite annotations. But how? This is the most difficult subject for us. We, mankind, can distinguish them at a glance, but our computers can't glance at the map, they don't have any sense of sight. We must distinguish it for our computers without the sense of sight.
We racked our brains. But we had no idea, because we didn't think about why computers can't distinguish it. We realized the reason, finally. "There is no FIGURE." As mentioned above, the annotation data is point coverage. The point coverage has no figure about the annotations' occupational places. We have to figure the annotation.
We can figure it by using the attribute's value. X and Y coordinates are already recognizable. If the annotation is horizontal, characters must be written from the point as a low-left. The height and width of it can be calculated by the attributes "Type of expression" and "Text number". The size of the characters depends on the attribute "Type of expression". The attribute "Text angle" points out the direction of the annotation. We figure the annotations as line coverages. It figures the outline of the each annotation as a rectangle.
The input of the annotation's rectangle can be done automatically by using ARCEDIT or GENERATE. And the logic of extraction of the overwrite annotations is as below.
1. Execute CLEAN command to the line coverage to make intersection.
2. Execute UNSPLIT command in ARCEDIT with NONE option.
3. Delete the ARC which has the same FNODE# and TNODE#.
4. Execute RENODE and NODEPOINT command.
The points are located at annotations' intersection. If overwrite annotation exists, we count the number of overwriting each annotation.
If some annotations have the same attribute "Type of expression" and "Characters", they mention the same object on the map. The reason for this is already mentioned. We can extract them by the research for the attributes.
We chose the most effective one from the duplicate annotations in the logic order below.
1. Detect the minimum overwriting number.
2. Delete the annotation which has a larger overwriting number than the minimum.
3. Delete all the rest of overlapping annotations except the one nearest to the center of the map.
The duplication problem is solved by this method, and the number of overwrite annotions decreased.
We have to move the rest of the overwrite annotations. Fortunately, Japanese can be written in two ways. Most of the buildings' annotations are written vertically or horizontally, with no angle. This allows us to change the direction of the annotations' writing. We created the last revision logic keeping this in mind, as below.
1. Find out if the annotation can be written in another way with no overwrite.
2. Find out if the annotation's start writing point can be positioned in the center of the object with no overwrite.
3. Find out if the annotation can be moved to one line (2.0mm or 2.5mm) with no overwrite.
The logic No. 1 and No. 2 are executed only for the building annotations because most of route annotations have angled text, which is not suitable for revision. The route annotations must be fixed. But if overwrite remains, then logic No. 3 is executed.
The result of this operation, for the most part, is that the duplicate and overwrite problem is solved automatically. However we had to edit a few annotations by human interaction. There are so many annotations that the above steps cannot clear all the overwriting in the heart of the city. But it seems they cannot be cleared by human interaction either. There are some similar annotations that indicate the same object. Similar is not the same. We could not have made the computers recognize it. We solved some problems, some new problems appeared, as usual.