Facade Classification #1
Replies: 44 comments 117 replies
-
|
Before we discuss possible implementations (I will propose many of them later), I like to discuss definitions first, so that we get some kind of clear base. Mainly the definition of facade classes is not yet clear to me. Ways
In general, OSM ways are not polygons. What do you mean by polygon chain?
What is the difference between a way-segment line and a way? Facade classes
There exists only extremely few literature on this subject. Most ideas come from the search for positions, where POIs could be placed. One paper proposes some weighting of building edges using similar features as we currently discuss, an idea we could eventually adapt to our problem. |
Beta Was this translation helpful? Give feedback.
-
Sorry it was a typo. I meant the Polygonal chain (a connected series of line segments).
Way is a polygonal chain, Way-segment line is the line for the way segment, i.e. a segment extended to infinity on both sides.
The facade class depends on the angle between the normals to the way-segment and to the facade and how the angle borders are defined, for example:
Yes. No left and right class in that case. Only front and side classes are assigned.
That range is assumed implicitly, since all way segments are located in the close vicinity to the building. The initial implementation and subsequent tests will show if the range is really need.
The facade class still depends on the angle between the normals provided that the facade isn't hidden by another building from the way segment. |
Beta Was this translation helpful? Give feedback.
-
Just to be sure that I understand correctly, assuming that the black line is a way-segment, are the following classifications correct?
If we allow multiple front facades, what is the reason to not to do the same for back facades too? Would this lead to ambiguities? |
Beta Was this translation helpful? Give feedback.
-
Yes.
Multiple back facades also possible, for example:
Can you post an example for a possible ambiguity? |
Beta Was this translation helpful? Give feedback.
-
|
I like to propose an idea of an implementation that could be very effective to find facades looking towards a way-segment and to determine the visibility of facades. In contrast to your proposition I would start with way-segments and find buildings with centers in a given range around them. Maybe this could also be solved using a kd-tree, I don't know. An arbitrary endpoint (the green point in my example image) of the way-segment is then defined as origin of a new coordinate system. All the vertices of the buildings are then rotated around this origin, so that the way-segemnt defines a new horizontal x-axis:
verts = [Vector((x0,y0)), ... , Vector((xn,yn))] # 2D-vertices of buildings
p0 = Vector((xs0,ys0)) # first vertex of way-segment
p1 = Vector((xs1,ys1)) # second vertex of way-segment
u = np.array( [(p1-p0).normalized()]) # unit vector of way-segment
p = np.stack( (-u[:,1],u[:,0]), axis=1 ) # perpendicular to unit vector
v = np.array(verts) # vertices to numpy array
v = v - np.array(p0) # shift origin to p0 (origin of segment)
vx = np.matmul( v, np.transpose(u) ) # x-coords in rotated system
vy = np.matmul( v, np.transpose(p) ) # y-coords in rotated system
verts_rot = [Vector((x,y)) for x,y in zip(mx,my)] # rotated verticesWhat is the advantage of this rotation? First, distances to the way-segment no more need projections, they are simply the absolute values of the y-coordinate of the rotated vertice. When I assume that the vertices of the buildings are ordered counter-clockwise, it is very simple to find the facade edges, that are visible to the way-segment. Just compute the difference of the x-values of two consecutive vertices and compare their sign with the sign of the y-coordinate of one of their vertices. If these signs are equal, the facade is visible:
The problem of visibility of facades then becomes 1-dimensional. There are no projections required, one can just use the x-coordinates of the facade edges of the building:
Using this approach, the influence of a way-segment could be computed for a multitude of buildings at once. Naturally, these "votes" have to be stored somehow, so that at the end, the final class of a facade can be determined. |
Beta Was this translation helpful? Give feedback.
-
But what to do with the case when a segment line crossing the building footprint? |
Beta Was this translation helpful? Give feedback.
-
|
Isn't that a special case anyway? How can this happen, by a tunnel? |
Beta Was this translation helpful? Give feedback.
-
|
It happens quite often even if it's a special case. Examples:
|
Beta Was this translation helpful? Give feedback.
-
|
I see. But however, it remains a special case. In the coordinate system I propose it would at least be simple to detect such cases, just by the fact that the y-coordinates of the vertices have both, positive and negative signs in this case. As you already proposed, we will have to define a special classification for this case. |
Beta Was this translation helpful? Give feedback.
-
|
Added a section about an existent implementaton for the facade classification (in the beginning of the document). |
Beta Was this translation helpful? Give feedback.
-
|
One more note to your proposal. Buildings without any way in their neighborhood must be identified. A fallback facade classification should be applied to those buildings. |
Beta Was this translation helpful? Give feedback.
-
|
Your proposal seems to be appropriate also for the task of the way clasterization I mentioned in one of my previous message. Let's consider an example in Rotterdam:
1e Middellandstraat is divided into two separate road ways by two tram tracks. There are two designated cycleways and two designated pedestrian ways (only one is marked in OpenStreetMap) on each side of the street, The idea is to cluster them together to find the borders of the street. Front building facades, fences, rivers, water channels, areas with grass on a street can also be added to the cluster to estimate the borders of the whole street. After the cluster is formed, an appropriate street texture is selected and/or geometry for the ways that form the street cluster is created. |
Beta Was this translation helpful? Give feedback.
-
|
Wanted to add additional comments about the facade classification. A facade facing a street gets more decorations than a facade not visible from a street. Entrances to shops, cafes are typically located in the facades facing the street. If two different facades face two different streets, both facades get the same level of decorations. |
Beta Was this translation helpful? Give feedback.
-
|
Will such facades facing a street get a separate class, like main_front? They will have more decorations if situated in a town, but not in rural regions. Could this difference be handled by PML styles? |
Beta Was this translation helpful? Give feedback.
-
|
I thought those facades jsut get the front class. What would be the difference between the classes main_front and front? |
Beta Was this translation helpful? Give feedback.
-
|
I thought on buildings that are not directly facing a street, but maybe can also have a front facade: |
Beta Was this translation helpful? Give feedback.
-
The method of facade classification would fail to detect facade classes for those buildings since the facades are hidden from the streets by the other buildings. A default method of facade classification should be applied to those buildings. For example, the facade with the largest width can be classified as the front one. An additional attribute is probably required to distinguish a building without a visible street from the building with a visible street. Perhaps something like this for a PML condition: facade[item.hasVisibleRoad] {
...
}That's my proposal. |
Beta Was this translation helpful? Give feedback.
-
|
A question to your proposal. How to detect the case A facade hides other facades from a way segment? In the examples below:
|
Beta Was this translation helpful? Give feedback.
-
I thought the task can be solved by analyzing a sequence V - V - H - V -V - V - H - H. But it seemingly won't work. |
Beta Was this translation helpful? Give feedback.
-
|
I did not yet elaborate an algorithm. It depends on the definition of the visibility of facades. When I assume that the visibility classification of your example of the concave building is the desired one, then my proposition using the signs will hold:
But this would not yet solve the visibility of buildings that are (ev. partly) covered by a building closer to the way-segment. Another approach is to use a simplified scan-line algorithm well known from hidden line removal in computer graphics. Partly invisible edges should then not get splitted, but be classified as invisible. Do you have a (desired/practical) definition? |
Beta Was this translation helpful? Give feedback.
-
Let's consider a facade. If the facade is opposite to any way, it's classified as the back one. All in-between facades are classified as the side ones. The exact class is defined by the angle between the facade and the way and how the border angles are defined. Special cases are not considered by this definition. |
Beta Was this translation helpful? Give feedback.
-
|
I started to experiment with real data and have some first results and observations. I will post them each in a different post so that we may discuss them separately. Preprocessing of Way-SegementsOften I observed that streets have been drawn using a lot of small segments, as shown in the image a) below. Using my proposition with coordinate transformation, processing of each short segment is very inefficient. I propose to simplify the streets, for instance using a Douglas–Peucker algorithm. For my experiments I used this implementation from GitHub. Image b) shows the result for the same street as a). a) Simplifiying streets could maybe also be helpful for your way clusterization. The simplification does not help, where streets have sharp curves, as shown in the next image. Another observation I made (donwloading all streets tagged highway) are very short (~5m long) streets of only one segment. Maybe it would help to demand at least one segment to have a minimal length. To select only streets, that can be used to find front facades, should also be considered. Maybe by selecting a group of keys for highway, should also be considered.
|
Beta Was this translation helpful? Give feedback.
-
So far I remove vertices forming a straight angle from building footprints. The removed vertices may have some useful OSM tags, for example a building entrance. Similarly a removed vertex for a way may also have some useful tags, for example a pedestrian crossing or a street lamp or a bus stop. Tests should be undertaken to find out which method of the way simplification (including no way simplification) is the most effective. |
Beta Was this translation helpful? Give feedback.
-
Selection of Buildings from Way-SegmentThe selection of buildings that have to be investigated from a transformed way-segment is a very complex task. I do not yet have a reliable solution. For my experiments, I transformed the centers of the buildings to the coordinate system of the way segment. Building centers are available from OSM-data and seem to correspond to the center of gravity of the building's shape. The advantage of using them is that there is only one center per building, which reduces the load to transform all of them. Centers within a rectangle around the way-segment have been accepted for further investigation. For instance the following selection in image a) used a range of 50 m above and below the way-segment and 10 m on both sides (green rectangle): a) The configuration of this range is very delicate. The center of large building, like a supermarket, easily does not get selected, because its center is too far away (see example in image b)). Once I had an example (unfortunately I can't find it anymore), where a long building along a street didn't get detected, because its center was to far to the right. Therefore, a building placed behind it got a front facade, because it was not more hidden. Eventually it would be better to find building vertices within such a range and then include all the affiliated buildings. But then, all building vertices would have to be transformed and the vertices would need a link back to the building. Maybe your idea using a kd-tree and the original untransformed coordinates for the selection could help. |
Beta Was this translation helpful? Give feedback.
-
|
Would do you mean by the affiliated buildings? |
Beta Was this translation helpful? Give feedback.
-
|
The search may find for instance two vertices of one building. The affiliated building is the complete buidling, these vertices belong to. If there are vertices of multiple buildings, all these buildings have to be included in the range. Belonging to would maybe the better word than affiliated. |
Beta Was this translation helpful? Give feedback.
-
|
Here an example of what can get wrong using the selection of building centers:
The center of the building, pointed to by the green arrow, is just outside of the selection range (dotted, green). Because it is not selected, the building behind gets a visible front facade, although this would be hidden by the missing building. The blue arrow points to another issue, but not one by the algorithm. Because the facade is partly hidden by the building in front of it, it should not get a front facade. But the contributor to OSM drawed it in two parts, so that there is a facade segment, that is completely visible. |
Beta Was this translation helpful? Give feedback.
-
Visibility TestingA first attempt for visibility testing is encouraging. The algorithm starts with the edges of all buildings from a selection and using their transformed coordinates, aligned to way-segment, as described above. Here a description in pseudo-code: There exist sometimes small issues, but I did not yet find whether they are produced already by the selection process. Here a first example of visible facades (in green), showing some issues:
EDIT: Ther was a line missing in the pseudo-code. |
Beta Was this translation helpful? Give feedback.
-
|
Is it a rural area? Does the red circle mark the beginning of a segment? How is it defined? |
Beta Was this translation helpful? Give feedback.
-
|
It's the selection 13.54972,52.49592,13.55541,52.49824 in Berlin. Yes, the red dot marks the beginning of a way-segment. I used the query to get all streets fro Overpass API. The nodes for every street in the order given by the API define the segments. Always the first node of a node pair got a red dot. |
Beta Was this translation helpful? Give feedback.
-
|
I just found that I didn't download the last way-segment of the streets. The corrected result looks like this:
I used a range of 100 m above and below the way-segments and 10 m on both sides. |
Beta Was this translation helpful? Give feedback.
-
|
The preliminary test looks encouraging! |
Beta Was this translation helpful? Give feedback.
-
Selection of Buildings from Way-Segment, IIAs already discussed, the selection of buildings to find the visibility of their facades relative to a way segment is not yet solved. Although I do not yet have an implementation, I like to propose another approach. Let me first repeat the actual algorithm to highlight then the difference: For every way-segment do:
The following image illustrates this process in the state of the transformed coordinate system:
This algorithm has two main disadvantages:
Therefore let me describe another approach:
For every way-segment do:
The following image illustrates this process in the state of the original coordinate system:
The advantages of this approach are:
and there is one (small) disadvatage:
Unsolved until nowI was not yet able to implement this proposition. The main reasons are the following:
As always, it's a balance between algorithms and data structures. Maybe you have some hints? |
Beta Was this translation helpful? Give feedback.
-
Instead of the surrounding rectangle we can use a surrounding circle with the radius 0.5 * sqrt(aa + bb), where a and b are the sides of the search rectangle. Then the kd-tree supplied with Blender can be used. The amount of excessive vertices located within the surrounding circle is comparable to the ones located within the surrounding rectangle. However Blender's kd-tree won't be available in the pure command line mode. SciPy's kd-tree can be used for tests in the command line mode. |
Beta Was this translation helpful? Give feedback.
-
Buildings are store in a list in the addon. Each building has a reference to its vertices. An additional list would be required for mapping between a vertex and its building. Each element of the list would store the index of the building in the list of buildings. |
Beta Was this translation helpful? Give feedback.
-
Good idea. The process should still be much faster than the current one. |
Beta Was this translation helpful? Give feedback.
-
|
I have now a working implementation with this new algorithm, which is faster than the old (just a feeling, no measurements yet). Here some impressions of the selection of buildings within the surrounding circle (blue). On the left: original coordinate system, on the right: selection in the rotated system:
I stop now with this part of implementation, until I see how it could be integrated in the blender-osm addon. I will try now to find solution for the special cases, like ways crossing the building footprint, ways ending in front of a building, buildings at way corners, aso. |
Beta Was this translation helpful? Give feedback.
-
I am refactoring the code of the blender-osm addon to allow command line operation and to prepare the addon code for facade classification and way clasterization. I expect to have something ready this week. |
Beta Was this translation helpful? Give feedback.
-
|
Finally, we will have similar issues as we had with bpypolyskel. Here an example, where a facade (orange arrow in left image) was not accepted as front facade, although it should in my opinion. On the right we see, that a small part of the building is hidden (orange arrow), because the building edges are not recatangular. This may be true or be an effect of imprecise drawing by the user. We will have to accept some tolerance, for instance of half a meter.
|
Beta Was this translation helpful? Give feedback.
-
|
The solution would be to calculate the ratio of the facade width hidden be other buildings. For example if it's greater than 0.5, than the facade is considere as hidden from the street. Otherwise it's visible. |
Beta Was this translation helpful? Give feedback.
-
|
Another issue is building parts. Some buildings have a detailed 3D mapping. Specifically, there may be additional footprints that represent building parts in 3D. The problem is how to process the building parts. Should they be classified like all building footprints? An alternative would be to classify a footprint for the whole building first and the use that facade classification to assign facade visibility for the building parts. |
Beta Was this translation helpful? Give feedback.
-
|
Blender's KD-tree isn't available in the command line mode. What would be the replacement for the command line mode? Have you already tried scipy.spatial.KDTree? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I used scipy's KDTree. It works fine to search for vertices within a circle around a way-segment. It even accepted a numpy array with the coordinates of the vertices of all buildings. |
Beta Was this translation helpful? Give feedback.
-
|
Can you post your code snippet for scipy.spatial.KDTree? I'll insert it into the blender-osm code base. |
Beta Was this translation helpful? Give feedback.
-
|
OK, but I have to explain the KDTree code by some additional code I used to start the detection, so that you can understand how I use this tree. I started with my own implementation of getting OSM data from Overpass. From there I get the buildings in a dictionary buildingsOSM, where the key is the OSM-ID of the building and the content is a list of tuples with the coordinates (Spherical Mercator) of the vertices of the building. In a first step, a numpy array vertsB has to be initialized with a size to store all vertices of all buildings. I liked to create the array at once instead of stacking it, so that a compact memory block is created. Unfortunaltely I don't know the number of vertices in advance, so they have to be counted: N = 0 # number of vertices in buildings
for _,b in buildingsOSM.items():
N += len(b)
vertsB = np.zeros((N,2))Then, this array is filled with the vertices and a dictionary buildings is created, that holds the index of the first vertice and the one of the last+1: nextIndx = 0
buildings = {}
for key,b in buildingsOSM.items():
n = len(b)
vertsB[nextIndx:nextIndx+n,:] = np.array(b)
buildings[key] = [nextIndx, nextIndx+n]
nextIndx += nThen, back associations are constructed, so that later the corresponding building for a vertice index can be found. This could naturally be integrated into the previous code, but I have put it separately into one of my functions: buildingForIndex = []
for key, building in buildings.items():
buildingForIndex.extend( [key for i in range(*building)] )Then, the KDTree is constructed: tree = KDTree(vertsB)Later in the code, the tree is used several times to find all vertice indices within a circle: idxs_in_circle = tree.query_ball_point(searchCenter, searchRadius)But at the border of the circle, only a part of the buildongs vertices are found. Therefore, the back associations are used now to find the building IDs (removing duplicates): buildIds_in_circle = list(dict.fromkeys([buildingForIndex[i] for i in idxs_in_circle]))From these, the complete vertices of all buildings within the circle can be computed. So when you embed the KDTree into the blender-osm code base, I would additionally need the back associations (or some other solution) and the numpy array of the vertices. |
Beta Was this translation helpful? Give feedback.
-
Just a note. The Python list isn't need in .extend(..). A Python generator is enough: buildingForIndex.extend( key for i in range(*building) ) |
Beta Was this translation helpful? Give feedback.
-
|
I created an issue #4 to discuss the integration of the code that calculates the facade visibility. |
Beta Was this translation helpful? Give feedback.
-
|
My another concern are T-crossings leading to false visibilty values. Note the marked visible edges in the vicinity of the T-crossings.
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, setting self.searchWidthMargin to 0. solves the problem at least for that particular case. |
Beta Was this translation helpful? Give feedback.
-
I studied solutions to implement this idea correctly. The easiest way I see is to give the crossed edges a special class (self.cl in BldgEdge). This would also help the facade classifier to treat these edges, as they are special cases (I already mentioned this above). Do you already have an idea on how you wanted to use self.cl? Maybe something like 0: Unknown If you agree with such a solution, I will correct the issue and commit a solution. |
Beta Was this translation helpful? Give feedback.
-
|
The attribute self.cl takes a value defined in the newly added class FacadeClass . A building facade is created out of a polygon edge. Based on self.cl an appropriated texture or meshes will be assigned to the facade. Yes, I agree with the solution. |
Beta Was this translation helpful? Give feedback.
-
Done and committed. Test result see below. Note that this is a temporary solution that will be refactored when the "winner" algorithm is implemented, which should be the next step.
|
Beta Was this translation helpful? Give feedback.
-
|
I replaced the value 5 for |
Beta Was this translation helpful? Give feedback.
-
|
In our discussion until here, the following parameters have been defined to be stored in the "winning" edge: visibility For the way-segment, I am not yet clear about what data you like to have, the category of the way it belongs to, or a reference to the segment itself (which is not yet available from the current code). The above parameters are computed for every way-segment and every way, one after the other in the loop that starts at line 107 in facade_visibility.py. The task is now to replace the method updateVisibility() of the class BldgEdge, which is called for every way-segment and every edge at line 270 in facade_visibility.py, if the edge is within the given range around the way-segment. The replacement of this method has to determine the "winning" edge and to store the data mentioned above for this edge, so that finally the data required to classify the edge according to your proposition can be processed. Every call to this method for the same edge is a vote for the winning edge. But what is the "winning" edge? As long as dx < dy, the maximum visibility can be used as criteria, as it is done currently. When the visibilities are equal for that case, the smaller distance should be relevant, because there could be for instance two parallel way-segments, which both see the edge. Then the nearer one should be stored. But what if dy > dx? Even an edge with an angle of 89° relative to the way-segment can have 100% visibility. Should such a way-segment be preferred to another, that has an angle of 50° and that is much nearer to the same edge? Could you please try to explain, what criteria you like to use, this is not yet clear to me? |
Beta Was this translation helpful? Give feedback.
-
|
What if we allow the visibility for dy>dx. Can you please still provide an example? |
Beta Was this translation helpful? Give feedback.
-
Note that dx and dy depend on the coordinate systems of the way-segments.
For the green edge: |
Beta Was this translation helpful? Give feedback.
-
|
A great example. Thanks. Still not sure if a more complicated rule for the winning way-segment is needed. And if the rule is needed, in what form. |
Beta Was this translation helpful? Give feedback.
-
I am implementing it right now having in mind the data structures for way crossings. |
Beta Was this translation helpful? Give feedback.
-
I am going to introduce the class VisibilityInfo to store the above attributes |
Beta Was this translation helpful? Give feedback.
-
|
I renamed the script setup/mpl_base.py to setup/mpl_facade_visibility.py |
Beta Was this translation helpful? Give feedback.
-
|
In berlin_karl_marx_allee.osm: The edges of the outline of the building at the red arrow are all classified as shared edges, but they shouldn't.
|
Beta Was this translation helpful? Give feedback.
-
|
I'll check it out. |
Beta Was this translation helpful? Give feedback.
-
It was a mapping error: overlapping buildings. I fixed it in both OSM database and the osm_extracts repo. |
Beta Was this translation helpful? Give feedback.
-
Yes it should. This isuue is the result of setting the margin of the search range to zero. The current condition to accept an edge is to have at least one end of the edge within the search range, which is not the case for this edge (see image below, blue is a part of the search range with margin zero). A new condition should require the edge to intersect the search range rectangle et least once. I will see how this can be realized efficiently.
|
Beta Was this translation helpful? Give feedback.
-
|
I committed a first version of facade classification. It is not yet completed and is thought to enable experiments for further improvements of this feature. The version includes a renderer (BuildingClassificationRender) for facade classes, which currently replaces the visibility renderer (BuildingVisibilityRender) in the setup file. After a lot of experiments, I changed several ideas of the original concept and the given code of the last commit. Below, I describe and discuss these changes.
As already said, it's a first attempt, but it produces already quite acceptable results. Please feel free to improve the code wherever you like. |
Beta Was this translation helpful? Give feedback.
-
I'll try to explain why ways should be processed at least in two passes. The service road is typically an auxiliary road that shouldn't contribute to the facade classification. The service roads are marked with the blue color on the image below. The service roads cause the wrong facade class (the front one on the image below) if they are processed with the major roads (primary, secodary, tertiary, residential). However there are cases when only a service road is present in the vicinity of a building. In that case we should check if the building has an edge with a major street as the winning way-segment. If the building doesn't have one, the service road is taken into account for the facade classification.
|
Beta Was this translation helpful? Give feedback.
-
|
OK, now I understand. This makes sense to me. Shall I adapt the code or do you like to do it? |
Beta Was this translation helpful? Give feedback.
-
The simpler the better. The side facades as the result of the current facade classification look ok for me. |
Beta Was this translation helpful? Give feedback.
-
Please adapt the code. I'd like to fix the old-standing bugs and release the asset package editor till the end of the week. Note that there were three groups of way categories in the original proposal: |
Beta Was this translation helpful? Give feedback.
-
This strategy has maybe to be complemented by a change in the selection of the winning segment (in the method __gt__() of VisibilityInfo). It may happen that for a single visible edge, a service road provides a visibility of 100% (and wins), while a major street looses with 90% visibility, but would maybe be more important for this building. But I do not yet have an idea on how to handle such cases. |
Beta Was this translation helpful? Give feedback.
-
|
As always in computational geometry, there are decisions that need some tolerances. To decide whether an intersection is within a way-segment, the limit had to be increased a little bit. This change is committed. |
Beta Was this translation helpful? Give feedback.
-
Fixed and committed. |
Beta Was this translation helpful? Give feedback.
-
|
I added a new command line option --classification. If it's given, the facade classification is displayed. The facade visibility is displayed otherwise. |
Beta Was this translation helpful? Give feedback.
-
|
I think it would look more natural if the edges marked with the blue color were classified as the front ones. manhattan_01.osm bern_old_town.osm |
Beta Was this translation helpful? Give feedback.
-
|
I just found that we have a very old bug, probably in event processing, that I didn't recognize until today. Many edges get a visibility that is larger than 1.0. I try first to fix it, maybe other issues are related to it. |
Beta Was this translation helpful? Give feedback.
-
|
A new experimental version of facade classification is committed and ready for further experiments. The main changes are the following:
From discussion "Facade Classification #1":
This step was really important. See for instance the rightmost facade of the u-shaped building in the left image below (btw. I changed the color of side facades locally to blue, because my sick eye can't see yellow on white, it dazzles too much):
The nearer low category ways produced a visibility of 100%, so that the major road (thicker line width) couldn't win. The right image shows the result after the correction. In many cases, the new strategy using the loops of way-categories works fine. However, in my opinion it produces severe misclassifications that fall into the eye immediately. I don't know whether it is really a progress. See for instance two kinds of misclassifications, both from bern_old_town.osm (thicker brown line means more important way-category):
This bug is fixed. I continue now with the development of a distance vs. building size restriction. |
Beta Was this translation helpful? Give feedback.
-
I moved living_street to the group C1. The Bern example now looks better. |
Beta Was this translation helpful? Give feedback.
-
This is the last criteria reamining for facade classification. As a preparation I did some investigations to get a feeling on how this could be realized. The distance of the way-segment to an edge is already transferred in VisibilityInfo as the sum of the y-distances Y1+Y2 in the way-segment coodinate system. To compute the fraction, a measure of the building size is required. The proposed maximum distance in x- and y-coordinates depends on the coordinate system and on the angle of the building in this system. Therefore this measure is not precise, but can be a good indicator. To minimize the computation load, I propose to compute this measure in the geographic coordinate system. In the way-segment coordinate system, this size would have to be computed every time, a building appears in the search range of a way-segment, which may happen several times for the same building. Therefore, in the following investigations I used this proposition. A next question to answer is: Where to set the threshold for this fraction to filter out visible building edges located too far away from the related way-segment? To get more insight, I measured the distribution (normalized by its peak value) of this fraction for edges classified as front edges in the maps we have stored in our osm_extracts repository. Here are the results (click on the images to magnify them): beijing_center, berlin_karl_marx_allee, bern_old_town, bratislava_old_town husum_altstadt, krasnaya_polyana, manhattan_01, moscow_leningradski_prospekt All look very similar, except krasnaya_polyana, which has a much broader distribution (reason see below). As a threshold, I selected for further tests a threshold value of 7.5, all edges that have a fraction larger than this threshold are plotted in red in the following images. For instance for husum_altstadt, the following edges are classified as too far away (left: whole map, right: NE-part magnified):
In my opinion, this is near to what we want to have. The solution for the broad distribution in the case of krasnaya_polyana is simple: There the roads are far away from each other (100-200m). Many buildings between them are small and their fraction value becomes large. On the Mapbox satellite image we can also see that there is much green between the streets (must be a nice place!), which confirms the result:
My proposition is to use this fraction and a threshold of about 7.5 and set the visibility for all edges beyond it to zero, so that the front facades get set by the longest edge of the building. |
Beta Was this translation helpful? Give feedback.
-
What was the exact formula used to estimate the building size? |
Beta Was this translation helpful? Give feedback.
-
|
Your approach seems reasonable for me. |
Beta Was this translation helpful? Give feedback.
-
It is the maximum of the maximum extents in x- and y-direction of the building. In my examples computed in the geographic coordinate system, as proposed.
I will commit an implementation of this proposition today. |
Beta Was this translation helpful? Give feedback.
-
New version using ratio of edge distance (Y1+Y2) and building size as limit of visibility at 7.5 is committed. I also collected all parameters of the process (visibility and classification) in the file facade_classification.py. |
Beta Was this translation helpful? Give feedback.
-
|
I added the file mckinney.osm to osm_extracts to have an example of a typical US town. |
Beta Was this translation helpful? Give feedback.
-
|
I found a case in krasnya_polyana.osm that doesn't work as I would expect.
|
Beta Was this translation helpful? Give feedback.
-
|
In this case, a large building decreases the ratio of distance/buildingDimension, which keeps this edge visible, although most of the building is invisible from this way-segment. Could it eventually make more sense to use a ratio distance/edgeLength or even the projection of the edge onto the way-segment as distance/dx? Should I maybe redo my investigation for these ratios? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, let's do more experiments. |
Beta Was this translation helpful? Give feedback.
-
|
Found another classification case which doesn't look natural for me (file mckinney.osm). I don't have an idea at the moment what to do with it.
|
Beta Was this translation helpful? Give feedback.
-
It's a difficult task. The propositions I made above do not work at all. After a lot of experiments I found a number that comes closer to what we like to have. I tried to combine normalized numbers to a number, that could be used instead of the visibility limit of 0.75, used in the first part of the current algorithm for classification. This number is the product of visibility, pseudo-angle (explained here) and the searchHeight (currently 100m), divided by the distance (Y1+Y2). In the examples below, the magenta arrows show the edges, where this product is > 1., while the blue arrows show the edges where it is <= 1. These edges marked by the blue arrows should not get front edges. mckinney.osm: krasnya_polyana.osm |
Beta Was this translation helpful? Give feedback.
-
That was another loser. It works well for the above examples. However, for scenes with wide streets, such as in berlin_karl_marx_allee.osm, the distance to the buildings becomes too large, so their facades are all not classified as front. An indicator is required for the distance to the first buildings, maybe on a per way-segment base. Experimenting continues. |
Beta Was this translation helpful? Give feedback.
-
I implemented and committed a solution that uses this idea. First, the distance of an edge to the way-segment has to be a relative value. For instance for berlin_karl_marx_allee.osm, many buildings are far away from the street and we need a measure that indicates the distance to the main facades, seen from a way-segment. For other ways beside the Karl-Marx-Allee, this distance is smaller. To map this fact I introduced a weighted distance favgDist or every way-segment, that represents an average of the distances of all edges in the search range, weighted by their visibilities. SUM() means the sum over all edges in the search range: This number is computed and the end of the visibility computation for a way-segment and stored in the class WaySegment. Then I defined a new number replacing the edge visibility in the first step of the classification algorithm. I called it sight, and it shall represent somehow, how good this edge is seen from the way-segment, but including more criteria than only visibility. It includes the following parameters
The final sight parameter is then defined as: I found that instead of visibility > 0.75, as in the current version, the new criteria should be sight > 0.5. But this limit requires maybe some screwing, when we do more experiments. Here the results for the now already well known maps (klick on them to see them larger)
|
Beta Was this translation helpful? Give feedback.
-
|
I wanted to solve the problem of the side facade in manhattan_01.osm My idea was to count the number of mostly perpendicular way segments to the building edge in def update(self, other):
self.value,\
self.waySegment,\
self.distance,\
self.dx,\
self.dy \
= \
other.value,\
other.waySegment,\
other.distance,\
other.dx,\
other.dy
if not self.mostlyParallelToWaySegment():
self.numMostlyPerpWaySegments += 1Then the building edge is classified as the front one if It solved that case of the corner facade before your latest commit. Now it doesn't solve it after your latest commit. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe it's related to #9 I extacted the building with the corner facade and simlified it for testing. The building is attached. The corner facade is classified as the side one for me: |
Beta Was this translation helpful? Give feedback.
-
Actually, my commit was after yours. Git merged them seamlessly because the commits were related to different lines. |
Beta Was this translation helpful? Give feedback.
-
I have adapted your idea in the newest commit. Seems to work for this facet, but not for others. We urgently need to solve #9, it's difficult to do development, with different results for each run. |
Beta Was this translation helpful? Give feedback.
-
Why is it classified as a passage? |
Beta Was this translation helpful? Give feedback.
-
Sorry, was too fast. For debugging I classified it as passage to get a separate color. Like this I could see, where this special case applies. Should be front. Bug fixed and committed. |
Beta Was this translation helpful? Give feedback.
-
Introduction
This is a proposal for facade classification. A facade class (front, back, side, left, right) is assigned to each edge of a building footprint depending on the relative position of the footprint edge and the neighboring streets. The streets are represented by their centerlines. A plot of land and eventually other entities represented by a polygon can be classified in the similar way.
Existed implementations
Facade classification is implemented in the ESRI City Engine (see the section Street selectors in the linked page). The two images below are from the documentation for ESRI City Engine:
Definitions
A way is a polygon chain. A way can represent a street, a path, a road, etc.
A way segment is bounded by two distinct end points.
A way segment line is a line to which the way segment belongs.
Assignment of facade classes
If a facade touches a facade of another building or a building part and is completely hidden, there is no need to classify it. Actually that facade should be skipped for further processing.
Let's consider the simplest case:
A way consisting of a single segment is on the left, a building is on the right. The facade class depends on the angle between the normal to the way and the normal to the facade. The front facade is marked with the green color, the back one is marked with the red color, the side facades are marked with the yellow color.
The problem is how to orient the normal to the way: is it pointing leftwards or rightwards on the image above?
It's assumed that the way segment line does not cross any edge of the building footprint. Pick up a point on the way. The cross product <vector between the point on the way and any footprint's vertex and> x <a unit vector along the way> should point upwards. If it points downwards, then change the direction of the unit vector along the way. Then the normal to the way can be calculated as the cross product <unit vector along the way> x <the basis vector for the z-axis>.
A more complex example:
The facade class still depends on the angle between the normal to the way segment and the one to the facade.
Even more complex example:
There are two way segments in this example: A and B. Each facade is considered against each segment. Suppose a facade is classified as the back one for a way segment and as the side one for another way segment. The resulting class would be side. Suppose a facade is classified as the side one for a way segment and as front one for another way segment. The resulting class would be front.
Even more complex example:
There are two crossing ways in this example. All concepts described above are also applied to this example.
Getting the nearest ways for a building
It's important to have a robust method of getting the nearest ways for a building to assign facade classes according to the procedure above.
Blender provides a generic 3-dimensional kd-tree to perform spatial searches.
All way segments can be placed into a kd-tree. Then a call of the find_range(..) function can be made for the center of a building to find way segments located in the vicinity of the building. If a way segment is too long, it can be divided into a number of parts.
An appropriate radius must be chosen for the call of the find_range(..).
Advanced cases
Some advanced cases are described in this section. The code to process them may be provided later.
(1) A facade is hidden from a way by other buildings
The facade A of the building (2) is hidden from the upper way segment by the building (1).
If facade F1 is classified as either front or side one for a specific way segment, then the projection of the facade's edge on the way segment should be stored. Also the distance (for example the shortest distance from the facade's edge to the way segment line) from the facade to the the way segment line should be stored. If another building is processed against the same way segment and
then the way segment is not processed for the facade F1. If there is a way segment against which the facade F1 was processed before, then the facade F1 is processed against it again to find the facade class.
(2) A facade hides other facades from a way segment
This case is applicable only to concave building footprints. The facade A hides the facades B, C, D from the way segment. The method described in the previous section can be used here as well to find out if a facade is hidden by another facade.
There must be a proposal how to classify a facade hidden by another facade. Perhaps it can be classified as side one. Or an additional facade class can be introduced for that case.
(3) A way segment line intersects a facade's edge
A unit vector along the way segment and pointing towards the building should be used to detemine a facade class instead of the normal to the way segment line.
Beta Was this translation helpful? Give feedback.
All reactions