On Tue, Jul 6, 2010 at 4:07 PM, Mâ¡rtin Koppenhoefer <[email protected]> wrote:
- Also it makes border far more complicated (and thus even false) when
- glued to features: roads need to have more nodes than just for the
- position (maxspeed, turnrestrictions, crossing streets, ...) while
- borders are defined by a couple of border-points (usually less than
- our roads have).
Again, this depends on the region you are contributing. In my region, most of the municipality borders are in fact glued to the middle of features like roads, tracks or rivers.
It depends on what you mean by "glued" and "middle", though.
Borders are usually defined legally by a survey. The centerlines of roads and other features are usually defined by a different (and probably more frequent) survey. If a road is widened asymmetrically, such that the centerline moves, it does not necessarily follow that the border moves, too. It might move eventually, but it is likely a separate issue from the road construction, requiring legislative change.
Even the apparent centerline from satellite imagery may be in a different place than that considered as the centerline for boundary purposes. In particular, asymmetrical sidewalk, horse trail, turn lanes, etc. can all cause an OSM mapper to move a road centerline - something that is entirely reasonable. It should, however, not result in moving a boundary that is legally defined.
Also, considering imports, for the reasons above, it is likely that boundaries are updated from sources that are different than those used to update road features (TIGER being a notable exception, and one that is not likely to be used again). If you import an accurate, legally defined shapefile for a city boundary, and it does not follow a street centerline exactly, it is only correct to have the street centerline and the boundary be two separate ways, not to merge the two into the position of the boundary, the position of the centerline, or somewhere in between.
Those features can be added in OSM from different sources (imagery, GPS, land registry). So adjusting the border with a more accurate source requires to adjust two ways and many duplicated nodes when it is far easier if the nodes are shared. This is IMHO also a good reason to glue the boundary with the feature.
It's exactly because they are added from different sources that it is incorrect to merge them. If you adjust a border from a "more accurate" source, you should adjust that border, not everything else that is glued to it (other than that of it's neighbor siblings). The source you use for the border is correct for the border alone. It may happen to coincide in places with the physical centerline of a feature, but that doesn't necessarily mean they are the same thing.
Alan Mintz <[email protected]>
_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
