[Talk-in] Border state | districts

Harshad RJ harshad.rj at gmail.com
Wed Dec 16 14:12:33 GMT 2009


On Wed, Dec 16, 2009 at 5:46 PM, michael lohr <micha.lohr at web.de> wrote:

> Am 16.12.2009 12:18, schrieb Harshad RJ:
> >
> > The Relation approach seems to be the new way of doing things, but
> > from what I could gather there isn't a complete consensus on it.
> i wasn't aware of that. link?
>

I can't find any now, so I will withdraw that statement.


> i disagree. working with relations is a lot easier for the editor (might
> not be true in our case though, cause the overlapping lines are there
> already and we would have to remove them). draw just one line, add it to
> the appropriate realtion with one click.
>

The problem is that it introduces one more level of hierarchy : nodes, ways
& relations. And now the ways have to be created intelligently by finding
out which part of the border is shared with other districts, states, or
national borders.

In my opinion, this intelligence is best programmed once and automatically
deduced rather than users having to do this for every admin border all over
the world.

Anyway, this is just my opinion. If OSM as a community is moving in this
direction, I either need to raise this issue with the whole OSM community or
accept the prevalent custom. For sheer lack of time I will choose the latter
:)



> besides, the mapping should represent the situation on the ground as
> exactly as possible. in case of borders: there's not 5 borders there,
> just one. but the meaning of this one border depends on the context
> you're viewing it in. that's much better represented by one line and a
> couple of relations.
>

Well, it is just a matter of abstraction. Note that, one level of hierarchy
already exists: nodes & ways. The nodes can be shared between borders and
the ways are defined for each admin area. By introducing relations, we are
just moving the problem one level up: the ways are shared and relations are
defined for each admin area.



> >
> > In the short term, if I understand correctly, the only hitch with the
> > current approach is that borders will overlap.
> that's a big hitch in my opinion. it might not be visible if rendered
> and you configure the renderer properly. but it will produce a lot of
> duplicate (and therefore useless) lines. just consider a a district on a
> national border. you'd have 6 lines on top of each other country a+b,
> state a+b, district a+b.
>

Err.. what I am proposing is that this can and should be handled
programatically in the renderer. And in fact, some logic for this would
already exists in there somewhere.

Take for example, two areas that touch each other (say a park and a
university campus). The renderer is able to handle that by drawing a single
border between the two, ain't it? We don't create a way between the park and
the university and then create two relations for them. The renderer manages
it for us!

Btw, I don't claim to know my stuff very well. And I am starved for time.
So, I will just rest my case here.

cheers,
-- 
Harshad RJ
http://hrj.wikidot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-in/attachments/20091216/914311a8/attachment.html>


More information about the Talk-in mailing list