<html>

At 2010-07-06 08:18, Pieren wrote:<br>

<blockquote type=cite class=cite cite>On Tue, Jul 6, 2010 at 4:07 PM,

M∡rtin Koppenhoefer

<<a href="mailto:dieterdreist@gmail.com">dieterdreist@gmail.com</a>>

wrote:

<dl>

<dd>Also it makes border far more complicated (and thus even false) 

when

<dd>glued to features: roads need to have more nodes than just for the

<dd>position (maxspeed, turnrestrictions, crossing streets, ...) while

<dd>borders are defined by a couple of border-points (usually less than

<dd>our roads have).<br><br>

</dl><br>

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. </blockquote><br>

It depends on what you mean by "glued" and "middle",

though.<br><br>

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.<br><br>

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.<br><br>

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.<br><br>

<blockquote type=cite class=cite cite>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.</blockquote><br>

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.<br>

<x-sigsep><p></x-sigsep>

--<br>

Alan Mintz <Alan_Mintz+OSM@Earthlink.net><br>

</html>