[Talk-us] Admin limits

[Dale Puch]

Per Richard Weait's description I think the use of a relation to add the
road/river ect. segment to the admin boundary is the best method.

-- 
Dale Puch

On Mon, May 31, 2010 at 4:02 PM, Richard Weait <richard at weait.com> wrote:

> On Mon, May 31, 2010 at 3:49 PM, Richard Welty <rwelty at averillpark.net>
> wrote:
> > On 5/31/10 11:06 AM, Nakor wrote:
> >>     Hello,
> >>
> >> I just have a quick question on admin limits. I have seen various
> >> practices when they are overlapping another feature (road, river, ...)
> >> and I was wondering if there was a consensus on the way to do it as well
> >> as the pros and cons of each methods.
> >>
> >> * Two separate ways with separate nodes
> >> * Two separate ways with common nodes
> >> * One way holding both tags (e.g. highway=residentail and admin_level=8)
> >> * other?
> >>
> > most think it should be your first choice, two ways with separate nodes.
> > some argue for
> > choice 2 (generally GIS people who don't  like duplicate nodes), and
> > some bots and other
> > tools push that way.
> >
> > i've not heard of anyone advocating choice 3. me, i stick with 1, if it
> > were ever decided
> > that 2 was the thing to do, it'd be possible to get there with a bot.
>
> You will also hear folks suggest tag the highway as it exists, then
> add the highway to a boundary relation for the admin_level.
>
> When applied correctly, this makes corrections to the road geometry
> simple, makes the boundary follow the corrected road without a hassle,
> and is an excellent use of a relation.  This is not an argument to put
> the boundary on the road if the boundary does not belong on the road.
> The same benefits would apply for a boundary that follows a river or
> other exiting feature.
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20100601/0de53608/attachment.html>