|
Let me give two personal examples, and then I'll ask my question: 1) I was trying to correct the border of large park area but ran into a ton of problems because most of the points (nodes?) in that section were joined to that of a street, which was also joined together with the border of a jurisdiction. It wasn't possible to simply adjust the park boundary without incorrectly changing the street or the jurisdiction border too. I was able to accomplish my goal by using the scissors tool to unlink the items, which became very tricky to separate what I wanted but leave the other two joined. 2) I want to adjust the boundaries of an airport apron. Right now the apron encircles the entire airport terminal, which is kind of ridiculous since planes can't taxi through the gift shop. So I may opt to correct the shape to go loosely around the terminal, but another (more precise) method could be to retrace the entire airport terminal (building) border whereas I would join all those points (nodes?). That would be nice and precise but I really worry about the situation I described above, in that it would be a nightmare if for some reason anybody ever needed to separate the two. So my question is this: What is the recommended standard procedure for properly "drawing" two or more adjacent areas? Should they share the same points so they fit nice and snuggly, or should they remain independent (even if the nodes overlap)? Thanks. |
|
In Potlatch 2, if a node is shared by several ways, you can separate it into a separate node for each way, by selecting the node and pressing 'shift-J'. You can then select the way that you want to change, and move the node for just that way. If a node is shared by more than two ways, and you want to edit only one of the ways, you can separate the shared node into one node for each way using 'shift-J', move the node in one of the ways, and then select one of the unmoved nodes and press 'J' to re-combine them. So one possible answer is: If the same nodes define two ways (e.g. if a stream forms the boundary of a wood, or a road forms the boundary of a residential area), use shared nodes. If two ways just happen to run very close to each other, use different nodes for the two ways. |
|
In the case of the airport apron, a cleaner option is to use a multypolygon relation. Leave the builing ways as-is, but remove the tags fron the apron way (except maybe source=Bing for example) and put them in a relation. So that you do not have extra ways, yet the data is semantically correct. If two nodes are conceptually at the same location, then they should be a single node. Having "overlaping nodes" is dirty and unnecessary. Overlaping ways are more subjective : They are arguably dirty too but they can be oh-so-pratical. Using relations for the same purpose often sound like too much work. I use relations for complicated stuff, and overlaping ways for simpler ones. YMMV. In any case, overlaps/relations should only be used if the real-life objects actually "touch". A forest alongside a lake or an administrative boundary following a road/river are good examples, but a park alongside a road most certainly isn't (unless the road is mapped as an area). Said differently, only glue ways together if they are both areas/2D or both lines/1D, but not if you have a mix. |
