[OSM-talk] relations

[Jo]

Hi list,

I'm adding relations for bus routes and now I'm going to start using 
them for cycle routes and signed walking paths. I have a few questions 
about them and their implementation in the editors though. I find that 
I'm splitting up roads a lot to indicate that a specific part of it is 
part of a route. Say somebody comes after me and uses Potlatch or JOSM 
to combine these streets again. Would this be possible? Or is it somehow 
prevented? I should probably try it out sometime.

The other way around is that I say that a chunk of a primary road is 
part of my bus route. Then somebody comes by and splits this in two. I 
tried this in josm and all of a sudden only the first part of the 
primary road remained part of the relation. (I think this was before 
committing it to the DB). Ideally when a road that is part of a relation 
is split, both parts should become parts of the relation(s).

And when somebody tries to combine two parts of a road, where one part 
belongs to a relation, this should be prevented. Preferably with a 
message like: 'part of a relation' or something of the kind.

Polyglot

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] relations

[Richard Fairhurst]

Jo wrote:

> I'm adding relations for bus routes and now I'm going to start using
> them for cycle routes and signed walking paths. I have a few questions
> about them and their implementation in the editors though. I find that
> I'm splitting up roads a lot to indicate that a specific part of it is
> part of a route. Say somebody comes after me and uses Potlatch or JOSM
> to combine these streets again. Would this be possible? Or is it somehow
> prevented?

Right now, the only relations support in Potlatch is that if you  
delete an object (be it way or node), it is also removed from any  
relations that it might be in. In other words, the bare minimum  
required not to break relations (though it may on occasion break their  
meaning!).

Proper relations handling is something that Potlatch will need in due  
course but isn't a priority for me at the moment - though I think Dave  
Stubbs has started work on implementing it.

cheers
Richard


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] relations

[Dave Stubbs]

On 02/01/2008, Richard Fairhurst <[EMAIL PROTECTED]> wrote:
> Jo wrote:
>
> > I'm adding relations for bus routes and now I'm going to start using
> > them for cycle routes and signed walking paths. I have a few questions
> > about them and their implementation in the editors though. I find that
> > I'm splitting up roads a lot to indicate that a specific part of it is
> > part of a route. Say somebody comes after me and uses Potlatch or JOSM
> > to combine these streets again. Would this be possible? Or is it somehow
> > prevented?
>
> Right now, the only relations support in Potlatch is that if you
> delete an object (be it way or node), it is also removed from any
> relations that it might be in. In other words, the bare minimum
> required not to break relations (though it may on occasion break their
> meaning!).
>
> Proper relations handling is something that Potlatch will need in due
> course but isn't a priority for me at the moment - though I think Dave
> Stubbs has started work on implementing it.
>

Yep, started on it.
But got distracted a bit though... I'll probably get back working on it soonish.

The implementation will only handle route type relations, which is
what you want here. Relations are funny old things -- you have to
handle different relation types in very different ways, the results of
splitting, merging, deleting will have different requirements.
Can I suggest everybody is careful to talk about "routes" or
"route-relations" rather than just "relations" to stop everybody
getting really confused at some point?!

Dave

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Relations are a super-powerful tool and permit all kinds of  
whizziness (cycle routes, bus routes, areas with holes, dual  
carriageways, etc.). This much we know.

On looking through the latest UK planet excerpt, though, I note a  
handful of cases where they're being used for simple road refs. So  
there are route relations which have simply been set up to convey  
ref=A813, etc.

Could I 'umbly suggest not doing this unless there's very good reason?

In the UK, road numbers are unique (apart from about three cases  
where local councils have cocked up, e.g. the B4027) and no road can  
have more than one ref. The relation doesn't give any info over and  
above that in the standard 'ref' tags - it just increases complexity  
for both editing and processing.

cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Relations on Irish islands

[Joseph Reeves]

Hi all,

Inspired by this morning's Falkland Isles question, could someone explain
Irish counties / islands to me? Apologies in advance for not signing up to
talk-ie...

I've been tidying up some islands off the Cork coast, which are tagged as
outers in the county relation [0]. Cork county itself is part of the
province of Munster [1], but the Munster boundary tagging on the islands
I'm dealing with ([2] for example) doesn't seem right - they're all tagged
as ""

What does "" mean? This should be "outer"?

thinking further on... Could the Cork County relation just be tagged as a
member of the Munster relation? This would then see the Munster relation
removed from individual ways.

Thanks, Joseph


[0] http://www.openstreetmap.org/browse/relation/332631
[1] http://www.openstreetmap.org/browse/relation/278750
[2] http://www.openstreetmap.org/browse/way/4554557
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Relations are not Categories

[Frederik Ramm]

Hi,

bit of a rant here but I've tried to remain polite:

http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

Feel free to style this differently to better fit the general Wiki 
style, I was just in the mood to write it that way.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Karl Newman]

On Sun, Apr 6, 2008 at 11:08 AM, Richard Fairhurst <[EMAIL PROTECTED]>
wrote:

> Relations are a super-powerful tool and permit all kinds of
> whizziness (cycle routes, bus routes, areas with holes, dual
> carriageways, etc.). This much we know.
>
> On looking through the latest UK planet excerpt, though, I note a
> handful of cases where they're being used for simple road refs. So
> there are route relations which have simply been set up to convey
> ref=A813, etc.
>
> Could I 'umbly suggest not doing this unless there's very good reason?
>
> In the UK, road numbers are unique (apart from about three cases
> where local councils have cocked up, e.g. the B4027) and no road can
> have more than one ref. The relation doesn't give any info over and
> above that in the standard 'ref' tags - it just increases complexity
> for both editing and processing.
>
> cheers
> Richard
>

In the US, it's common for multiple numbered highways to run on the same
pavement. Just thinking of a few examples around the San Francisco Bay area,
you could have several interstates running together for a while (I-580 and
I-80), or a state highway together with an interstate (CA 12 and I-80) or
two or more state highways (CA 12, CA 29, CA 121). For these cases, I've
been putting them all in the "ref" tag directly on the way but separating
them by semicolons.

Karl
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[David Earl]

On 06/04/2008 20:19, Karl Newman wrote:
> In the UK, road numbers are unique (apart from about three cases
> where local councils have cocked up, e.g. the B4027) and no road can
> have more than one ref. 

Not true - the A11 and A14 share about 10 miles of dual carriageway 
around the north of Newmarket, for example.

> The relation doesn't give any info over and
> above that in the standard 'ref' tags - it just increases complexity
> for both editing and processing.

It links the pieces together, which you would have to infer otherwise 
from the ref. That's not to say the ref shouldn't be on the highway as well.

David


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

David Earl wrote:

>> In the UK, road numbers are unique (apart from about three cases
>> where local councils have cocked up, e.g. the B4027) and no  
>> road can
>> have more than one ref.
>
> Not true - the A11 and A14 share about 10 miles of dual carriageway  
> around the north of Newmarket, for example.

It's absolutely true. That bit's the A14. This Highways Agency  
document, for example, refers to the stretch of road in question as  
solely the A14:

 http://www.highways.gov.uk/roads/15200.aspx

The fact that traffic "following the A11" needs to use it is pretty  
much immaterial - traffic following the A34 from Winchester to  
Manchester, for example, has to use the M40 from Bicester to the M42,  
and no-one's suggesting that the M40 is also the A34 (if it is, I can  
cycle on it ;) ). No, it's the A14 leading to the A11, and will  
almost certainly be signposted as such - "A14 (A11)", or on more  
recent signs, on separate lines like this:

A14
Bury St Edmunds 15
Felixstowe 87
(A11)
Norwich 98

There are thousands of stretches of road like this across Britain,  
but in all cases they only have one official number (very occasional  
signage errors notwithstanding).

>> The relation doesn't give any info over and
>> above that in the standard 'ref' tags - it just increases  
>> complexity
>> for both editing and processing.
>
> It links the pieces together, which you would have to infer  
> otherwise from the ref. That's not to say the ref shouldn't be on  
> the highway as well.

But if you can unambiguously infer it, you shouldn't need to  
explicitly tag it.

Having duplication also makes it too easy for discrepancies to arise  
- what if a newbie changes the ref in the way tag (obvious), but  
doesn't update the relation membership (less obvious)?

cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Frederik Ramm]

Hi,

> In the UK, road numbers are unique (apart from about three cases  
> where local councils have cocked up, e.g. the B4027) and no road can  
> have more than one ref. The relation doesn't give any info over and  
> above that in the standard 'ref' tags - it just increases complexity  
> for both editing and processing.

If you simply use the "ref" tag to specify the road number, how would
you then use the API to access all ways making up B4027?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09" E008°23'33"


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Frederik Ramm wrote:

>> In the UK, road numbers are unique (apart from about three cases
>> where local councils have cocked up, e.g. the B4027) and no road can
>> have more than one ref. The relation doesn't give any info over and
>> above that in the standard 'ref' tags - it just increases complexity
>> for both editing and processing.
>
> If you simply use the "ref" tag to specify the road number, how would
> you then use the API to access all ways making up B4027?

By using OSMXAPI: http://www.informationfreeway.org/api/0.5/way 
[ref=B4027]

That the mainstream API doesn't do it is (if it's deemed useful) a  
deficiency in the API, not a reason to add duplicate data.

cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard Fairhurst wrote:
| David Earl wrote:
|
|>> In the UK, road numbers are unique (apart from about three cases
|>> where local councils have cocked up, e.g. the B4027) and no
|>> road can
|>> have more than one ref.
|> Not true - the A11 and A14 share about 10 miles of dual carriageway
|> around the north of Newmarket, for example.
|
| It's absolutely true. That bit's the A14. This Highways Agency
| document, for example, refers to the stretch of road in question as
| solely the A14:
|
|  http://www.highways.gov.uk/roads/15200.aspx
|
| The fact that traffic "following the A11" needs to use it is pretty
| much immaterial - traffic following the A34 from Winchester to
| Manchester, for example, has to use the M40 from Bicester to the M42,
| and no-one's suggesting that the M40 is also the A34 (if it is, I can
| cycle on it ;) ). No, it's the A14 leading to the A11, and will
| almost certainly be signposted as such - "A14 (A11)", or on more
| recent signs, on separate lines like this:

If that is the case, then the relationship is essential to convey the
route of the A11 information. If the road just has 2 numbers, then it
isn't - just a semi-colon in the ref would do.

Robert (Jamie) Munro
(who thinks that relationships are so brilliant that long term we
shouldn't tag ways at all - only relationships)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+WFIz+aYVHdncI0RAqmSAJ93U5F7F5K0lcnrfXKdDWzhNmdjqQCg92v2
h4SW72Wx7EwsBdLtbufpd30=
=lzzc
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Robert (Jamie) Munro wrote:

> If that is the case, then the relationship is essential to convey the
> route of the A11 information. If the road just has 2 numbers, then it
> isn't - just a semi-colon in the ref would do.

But bearing in mind that this section _isn't_ the A11 and to tag it  
as such is therefore wrong, then we map the facts on the ground - and  
that's "signage=A14 (A11)". Of course, if you want to go round  
tagging every single sign then good luck to you, but...

> Robert (Jamie) Munro
> (who thinks that relationships are so brilliant that long term we
> shouldn't tag ways at all - only relationships)

Yeees... that was what I was afraid of. :|

cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Alex S.]

Richard Fairhurst wrote:
> There are thousands of stretches of road like this across Britain,  
> but in all cases they only have one official number (very occasional  
> signage errors notwithstanding).

In the US, there are many highways which carry more than one official 
"ref" number across long stretches.  For example, US-12 shares roadway 
with sections of I-5, I-82 and I-182 in Washington State, but both signs 
are on the side of the roadway in these sections.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Alex S. wrote:

> In the US, there are many highways which carry more than one official
> "ref" number across long stretches.  For example, US-12 shares roadway
> with sections of I-5, I-82 and I-182 in Washington State, but both  
> signs
> are on the side of the roadway in these sections.

Sure, and in that case it makes sense to use a relation or to tag  
with semicolon-separated values, because that's something that can't  
be expressed with simple "key=single value".

cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Frederik Ramm]

Hi,

> > If you simply use the "ref" tag to specify the road number, how would
> > you then use the API to access all ways making up B4027?
> 
> By using OSMXAPI: http://www.informationfreeway.org/api/0.5/way 
> [ref=B4027]

Which will omit anything tagged "ref=B4027;B4028" or some such. Ok you
said there shouldn't be any of those in the UK anyway so I guess
you're fine...

> That the mainstream API doesn't do it is (if it's deemed useful) a  
> deficiency in the API, not a reason to add duplicate data.

I think it is a good idea to group objects that belong together in a
relation. Ultimately I'd expect the relation to carry the "ref=B4027"
tag and to drop that tag from the ways contained therein. Makes a lot
of sense from a data modelling viewpoint I think.

Agreed that we're not there yet but it is a good thing to aim at. I
fully expect most ways to be part of one or more relations some time in
the future so why not get used to it.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09" E008°23'33"


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Andy Robinson (blackadder)]

Frederik Ramm wrote:
>Sent: 07 April 2008 1:52 AM
>To: Richard Fairhurst
>Cc: Talk Openstreetmap
>Subject: Re: [OSM-talk] Relations not always brilliant
>
>Hi,
>
>> > If you simply use the "ref" tag to specify the road number, how would
>> > you then use the API to access all ways making up B4027?
>>
>> By using OSMXAPI: http://www.informationfreeway.org/api/0.5/way
>> [ref=B4027]
>
>Which will omit anything tagged "ref=B4027;B4028" or some such. Ok you
>said there shouldn't be any of those in the UK anyway so I guess
>you're fine...
>
>> That the mainstream API doesn't do it is (if it's deemed useful) a
>> deficiency in the API, not a reason to add duplicate data.
>
>I think it is a good idea to group objects that belong together in a
>relation. Ultimately I'd expect the relation to carry the "ref=B4027"
>tag and to drop that tag from the ways contained therein. Makes a lot
>of sense from a data modelling viewpoint I think.

I think it’s a leap of faith to think that we will even get to the position
were the relationship alone holds the grouped data, such as ref. I see that
there will always likely be duplication in this regard with the same
information being held on the component parts as well as the relationship. I
don’t see this as a bad thing, the components may have equal applicability
and use as the overall object, especially in different applications.

Cheers

Andy

>
>Agreed that we're not there yet but it is a good thing to aim at. I
>fully expect most ways to be part of one or more relations some time in
>the future so why not get used to it.
>
>Bye
>Frederik
>
>--
>Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09" E008°23'33"
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Sun, 6 Apr 2008, Richard Fairhurst wrote:

> In the UK, road numbers are unique (apart from about three cases
> where local councils have cocked up, e.g. the B4027)

This isn't entirely true - take, for example, the A31, which goes from 
Guildford to Winchester and then vanishes as it joins the M3.  It then 
reappears on the Westerly end of the M27 and continues to the West (the 
A35 does a similar thing, as do quite a lot of other A roads).

C roads, of course, are not unique (but their reference numbers tend not 
to be published).

> and no road can have more than one ref.

I believe that might also be untrue.  It doesn't excuse the use of 
relations though - multiple refs should be specified like: ref=Bfoo;Bbar

> The relation doesn't give any info over and
> above that in the standard 'ref' tags - it just increases complexity
> for both editing and processing.

I agree entirely.  Presumably the idea of the relation is to allow 
routing algorithms to rejoin ways which have been split, but this isn't 
necessary - if the end of 2 ways share the same node and they have the 
same ref then they can be rejoined.  The existence of multiple 
non-adjacent roads with the same ref doesn't change this and the existence 
of multiple refs for the same road only adds a minor complication.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, Frederik Ramm wrote:

> Which will omit anything tagged "ref=B4027;B4028" or some such. Ok you
> said there shouldn't be any of those in the UK anyway so I guess
> you're fine...

Then the API needs to be improved - we shouldn't be adding unnecessary 
data to work around deficiencies in the API.

> I think it is a good idea to group objects that belong together in a
> relation. Ultimately I'd expect the relation to carry the "ref=B4027"
> tag and to drop that tag from the ways contained therein. Makes a lot
> of sense from a data modelling viewpoint I think.

I am concerned that it adds complexity (which means there is more chance 
of human error).  Complexity in some cases is unavoidable, but in this 
case I can't see a significant advantage over just tagging the ways and 
improving the API to allow searching for single values in multi-value 
tags.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Frederik Ramm]

Hi,

> But this is kind of the point - if you are able to automatically  
> create the relations (and presumably automatically fix them if  
> someone makes the way tags inconsistent with the relation tags)  
> with very little effort, is there a good reason to create them in  
> the first place rather than deriving that data as and when you need  
> it?

I assume it will usually be easier to check a machine-readable  
relation than to compare tags. A grouping relation is a more abstract  
thing and can be used for other purposes (i.e. many ways might  
together make up the "city bypass", but this might not depend on the  
road "ref" but on the road name). I assume that anyone working with  
the data in earnest will have to support relations anyway, so it  
seems unnecessary to ask them to also group by tags which involves  
finding out which tags to group by, which bounding box so search in,  
splitting tag values at semicolons etc.

Rather than have one million systems implement their own ways of  
guessing what was meant, I'd like to put this explicitly in the  
database (or at least have *one* central system do the grouping  
consinstently).

But this discussion is becoming much too theoretical. Let's just do  
what works. You use the ref tags on individual objects, and if at any  
point in time I see the need for relations generated on the basis of  
these then I can generate them.

My original point "why not get used to it now" is perhaps the more  
important one; we're still very much at the beginning concerning  
relations and the more people get exposed to relations, the better  
we'll be able to work with them and use them productively.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09" E008°23'33"




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, David Earl wrote:

> And to take the A11/A14 example again, if the A11 in effect disappears
> where it is coincident with the A14, the A11 is discontinuous.

I'm not sure why we need to treat the whole discontinuous A11 as a single 
road.

In this example, as far as I can tell we have 2 roads called the A11 and 
a road joining them called the A14 - route planners can deal with this 
just the same as they can deal with A11 -> A14 -> A134.

Route planners shouldn't be directing you along the A14 just because it 
happens to also be part of the A11 - they should be directing you down it 
because it is the best road to get you from A to B.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, Frederik Ramm wrote:

> If it's done consistently, one can still create relations automatically later 
> if desired.

But this is kind of the point - if you are able to automatically create 
the relations (and presumably automatically fix them if someone makes the 
way tags inconsistent with the relation tags) with very little effort, is 
there a good reason to create them in the first place rather than deriving 
that data as and when you need it?

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Stephen Gower]

On Mon, Apr 07, 2008 at 11:46:10AM +0100, Steve Hill wrote:
> 
> In this example, as far as I can tell we have 2 roads called the A11 and 
> a road joining them called the A14 - route planners can deal with this 
> just the same as they can deal with A11 -> A14 -> A134.
> 
> Route planners shouldn't be directing you along the A14 just because it 
> happens to also be part of the A11 - they should be directing you down it 
> because it is the best road to get you from A to B.

  Our data's only for route planners?
  
  Suppose I wanted to walk the whole of the A34 while I was 34 as a
  charity gig?  OK, that's contrived, but beware of arguments that
  apply to just one use-case (for what its worth, I'm undecided about
  if relations in this situation are brilliant or not brilliant).
  
  s

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[David Earl]

On 07/04/2008 11:11, Frederik Ramm wrote:
> Hi,
> 
>> But this is kind of the point - if you are able to automatically  
>> create the relations (and presumably automatically fix them if  
>> someone makes the way tags inconsistent with the relation tags)  
>> with very little effort, is there a good reason to create them in  
>> the first place rather than deriving that data as and when you need  
>> it?
> 
> I assume it will usually be easier to check a machine-readable  
> relation than to compare tags. 

And to take the A11/A14 example again, if the A11 in effect disappears 
where it is coincident with the A14, the A11 is discontinuous. How do 
you therefore distinguish from the ref alone that the pieces of the A11 
in the UK are different from the A11 autobahn in Germany. Determining 
which country they are in is hard (even harder when there is no water 
between them). And the European E route numbers cross national 
boundaries (actually there's an example where UK roads really do have 
more than one ref, though it's unlikely we'd tag them because there is 
no evidence of this on road signs).

David

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, Frederik Ramm wrote:

> I assume it will usually be easier to check a machine-readable relation than 
> to compare tags.

Possibly.  There may be cause for having machine generated relations which 
are kept up to date by the server when data is committed so the people 
editing the data don't need to care about them (such relations would need 
to be read-only and tagged in a way to make it clear they aren't normal 
editable relations).  I think that'd be easier for people submitting the 
data than having to deal with these relations directly (which as you say, 
are only there for efficency reasons)

In the end, moving *all* tags into relations might be the best thing to 
do, but I think the editors need a lot of work before that is a viable 
option.  At the moment we have a rather confusing mix.

> it seems unnecessary to ask them to also group by tags which 
> involves finding out which tags to group by, which bounding box so search in, 
> splitting tag values at semicolons etc.

Unless you can ensure that the relations exist on *all* appropriate 
objects, they will have to group by tags anyway.  (And I don't believe you 
can ensure this without some automatic daemon fixing up the relations on 
all the data as it is submitted).

> Rather than have one million systems implement their own ways of guessing 
> what was meant, I'd like to put this explicitly in the database (or at least 
> have *one* central system do the grouping consinstently).

This sounds sensible.  But as mentioned, I think for it to be achieveable 
we either need a lot of improvement on the editors to make relations more 
obvious and intuitive, or we need some automatic stuff to generate the 
relations that can be unambiguously derived from other data.  (Or both)

I'm concerned that the data structure might be outpacing the editors too 
much and this could be raising the bar to entry for mappers.

> But this discussion is becoming much too theoretical.

Well yeah, but sometimes it's good to bash theoretical ideas around to see 
what works. :)

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Frederik Ramm wrote:

> I assume it will usually be easier to check a machine-readable  
> relation than to compare tags. A grouping relation is a more  
> abstract thing and can be used for other purposes (i.e. many ways  
> might together make up the "city bypass", but this might not depend  
> on the road "ref" but on the road name). I assume that anyone  
> working with the data in earnest will have to support relations  
> anyway, so it seems unnecessary to ask them to also group by tags  
> which involves finding out which tags to group by, which bounding  
> box so search in, splitting tag values at semicolons etc.

IMO it's _always_ better to optimise for ease of editing and  
maintenance, than for ease of use by developers.

Any non-trivial use of OSM data is going to require postprocessing  
anyway. One of our failures, as a project, is that we don't provide  
enough widely used/actively developed libraries in common languages  
for working with OSM data - libraries that would do exactly what you  
suggest (grouping by tags, etc.). Much better to work on these than  
to raise the (already too high) editing barriers for new mappers.

> My original point "why not get used to it now" is perhaps the more  
> important one; we're still very much at the beginning concerning  
> relations and the more people get exposed to relations, the better  
> we'll be able to work with them and use them productively.

You could start by making JOSM's relations UI as good as Potlatch's.  


cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Frederik Ramm]

Hi,

> I am concerned that it adds complexity (which means there is more  
> chance of human error).  Complexity in some cases is unavoidable,  
> but in this case I can't see a significant advantage over just  
> tagging the ways and improving the API to allow searching for  
> single values in multi-value tags.

If it's done consistently, one can still create relations  
automatically later if desired.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09" E008°23'33"




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard Fairhurst wrote:
| Robert (Jamie) Munro wrote:
|
|> If that is the case, then the relationship is essential to convey the
|> route of the A11 information. If the road just has 2 numbers, then it
|> isn't - just a semi-colon in the ref would do.
|
| But bearing in mind that this section _isn't_ the A11 and to tag it
| as such is therefore wrong, then we map the facts on the ground - and
| that's "signage=A14 (A11)". Of course, if you want to go round
| tagging every single sign then good luck to you, but...

It might not be the A11 from the point of view of who is in charge of
maintaining it, but it is the A11 from the point of view of someone
following the route of the A11 to get somewhere. Therefore it should be
in a relationship as part of the A11, but should not be tagged "ref=A11".

If you tag it ref=A14 (A11), which may not be wrong, then when you ask
OSMXAPI for ref=A14 or ref=A11, neither route will be complete. It just
has to be a relationship. You can even tag the shared section's
membership of the relationship as "shared" or something.

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+gd0z+aYVHdncI0RAnUfAJ0Q7BbXpNUJ6bsadnYsWQXx0fW4IgCffbDU
OEThxkdqgxx/hrnjqEtCwds=
=q0te
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, Stephen Gower wrote:

>  Suppose I wanted to walk the whole of the A34 while I was 34 as a
>  charity gig?

Ok, either:
1. You have lots of ways tagged with ref=A34
2. You have lots of relations tagged with ref=A34, one for each 
discontinuous section of the road (which may be multiple ways)
3. You have a single relation tagged with ref=A34, containing all of the 
ways making up the A34, but with gaps where there are discontinuities.

In the case of (1) the API needs some work to make it possible to search 
for single values in multivalue tags.  You can then search for ref=A34 and 
get a list of ways back.

For (2) you can search for ref=A34 and get a list of relations (and 
therefore a list of ways).

For (3) you can search for ref=A34 and get a single relation (and 
therefore a list of ways).

In all of these cases, there is nothing especially non-trivial.  You might 
get a performance improvement from (2) and (3) since you don't have to 
parse so many tags (and the parsing isn't as complex since they only have 
a single value in the tag).  But (3) doesn't seem to be better than (2).

Whichever method you have taken, you end up with the same data - a list of 
ways with gaps in them where there are discontinuities.  You must fill in 
those gaps yourself (e.g. using a routing algorithm) and OSM can't do this 
for you.  Different people will have different preferences for how to fill 
in those gaps - car drivers may prefer motorways whilst you, on your walk, 
probably want a shortest-distance non-motorway route.  You may even choose 
to reference third party data, such as land elevations to allow you to go 
around large hills instead of over them.

>  OK, that's contrived, but beware of arguments that
>  apply to just one use-case (for what its worth, I'm undecided about
>  if relations in this situation are brilliant or not brilliant).

Noted.  But I still haven't seen any good explanation as to why we need 
the whole of a discontinuous road in a single relation.

The only good reasoning I've seen for using relations at all is for 
performance and consistency reasons (which are good points, but I don't 
think that requires a discontinuous road in a single relation - if we 
stick to continuous roads in each relation then the relation generation 
can be automated, which would ensure consistency, reduce the scope for 
human error and make data submition easier.)

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Andy Allan]

On Mon, Apr 7, 2008 at 11:30 AM, Steve Hill <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Apr 2008, Frederik Ramm wrote:

>  In the end, moving *all* tags into relations might be the best thing to
>  do, but I think the editors need a lot of work before that is a viable
>  option.  At the moment we have a rather confusing mix.

If I peer into my crystal ball, I can see physical attributes (width,
surface, lanes) being on ways, and non-physical attributes
(references, routes, even street names) moving to relations. Ways will
end up being a connected series of nodes, ending where the properties
change. That's just my hunch.

But there's no hurry. We're short on developers, and documentation
writers, and have a huge community to think about. There's no point in
forcing the pace on this issue - our efforts would be better focussed
on forcing the pace on actual mapping - there's still a staggering
amount of streets to be mapped (even just considering Europe),
regardless of how we tag them.

Cheers,
Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, Andy Allan wrote:

> If I peer into my crystal ball, I can see physical attributes (width,
> surface, lanes) being on ways, and non-physical attributes
> (references, routes, even street names) moving to relations. Ways will
> end up being a connected series of nodes, ending where the properties
> change. That's just my hunch.

I'd agree with that.

> But there's no hurry. We're short on developers, and documentation
> writers, and have a huge community to think about. There's no point in
> forcing the pace on this issue - our efforts would be better focussed
> on forcing the pace on actual mapping - there's still a staggering
> amount of streets to be mapped (even just considering Europe),
> regardless of how we tag them.

Indeed - this is why I'm very dubious about putting too much stock into 
relations until things like the editors and documentation have caught up a 
bit more.  Far better to get the data into the database in a simplistic 
form and make it better later rather than confusing people too much 
(confused people will make more mistakes, reducing the quality of the 
data).

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Dave Stubbs]

On Mon, Apr 7, 2008 at 12:37 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  Richard Fairhurst wrote:
>
> | Robert (Jamie) Munro wrote:
>  |
>  |> If that is the case, then the relationship is essential to convey the
>  |> route of the A11 information. If the road just has 2 numbers, then it
>  |> isn't - just a semi-colon in the ref would do.
>  |
>  | But bearing in mind that this section _isn't_ the A11 and to tag it
>  | as such is therefore wrong, then we map the facts on the ground - and
>  | that's "signage=A14 (A11)". Of course, if you want to go round
>  | tagging every single sign then good luck to you, but...
>
>  It might not be the A11 from the point of view of who is in charge of
>  maintaining it, but it is the A11 from the point of view of someone
>  following the route of the A11 to get somewhere. Therefore it should be
>  in a relationship as part of the A11, but should not be tagged "ref=A11".

I hate to say it, but if it's not the A11 from the point of view of
who is in charge of it, then it isn't the A11, and any route you
generate will likely be fairly subjective.
I think the failure here is in the assumption UK road refs represent
routes, when it seems they don't, even if they sometimes look like
they do. Other countries clearly have a different approach where use
of a route relation is much more applicable.

The difference probably isn't worth worrying about much, except to
point out that relations aren't really necessary to model the UK's
road refs even if they are desirable for other reasons.

Dave

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, Robert (Jamie) Munro wrote:

> It might not be the A11 from the point of view of who is in charge of
> maintaining it, but it is the A11 from the point of view of someone
> following the route of the A11 to get somewhere. Therefore it should be
> in a relationship as part of the A11, but should not be tagged "ref=A11".

I'm not at all convinced that OSM should be making decisions as to what 
roads should be considered part of the A11 despite not *really* being part 
of it.  However, if you want to do that, isn't this what the route= tag is 
for?  ref= tags a physical entity, route= tags a logical route.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dave Stubbs wrote:
| On Mon, Apr 7, 2008 at 12:37 PM, Robert (Jamie) Munro
<[EMAIL PROTECTED]> wrote:
|> -BEGIN PGP SIGNED MESSAGE-
|>  Hash: SHA1
|>
|>  Richard Fairhurst wrote:
|>
|> | Robert (Jamie) Munro wrote:
|>  |
|>  |> If that is the case, then the relationship is essential to convey the
|>  |> route of the A11 information. If the road just has 2 numbers, then it
|>  |> isn't - just a semi-colon in the ref would do.
|>  |
|>  | But bearing in mind that this section _isn't_ the A11 and to tag it
|>  | as such is therefore wrong, then we map the facts on the ground - and
|>  | that's "signage=A14 (A11)". Of course, if you want to go round
|>  | tagging every single sign then good luck to you, but...
|>
|>  It might not be the A11 from the point of view of who is in charge of
|>  maintaining it, but it is the A11 from the point of view of someone
|>  following the route of the A11 to get somewhere. Therefore it should be
|>  in a relationship as part of the A11, but should not be tagged
"ref=A11".
|
| I hate to say it, but if it's not the A11 from the point of view of
| who is in charge of it, then it isn't the A11, and any route you
| generate will likely be fairly subjective.

It's not subjective, it is officially signed - the signs say "A14
(A11)". This happens all over the place in the UK A roads network.

Going back on topic, fundamentally, I can't see how you can argue that
it is wrong to connect all the ways forming a large numbered road with a
relationship, which seems to be what Richard is arguing. It seems to me
that it is exactly what relationships are for.

Robert (Jamie) Munro

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+ibsz+aYVHdncI0RAiAxAKCAhocz62EgTHZCKF3Z/6EF6D2yjgCg29c2
ngicRCABnBM0n6gh6FPuA4g=
=+owL
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Nick]

In article <[EMAIL PROTECTED]>,
Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote:
>It's not subjective, it is officially signed - the signs say "A14
>(A11)". This happens all over the place in the UK A roads network.

I can see why this is confusing. But the identification number A11 is
shown in that case because it is indicating the direction you would go
to get to the A11, but you have to turn off the A14 to get to it.

For instance, near me there are signs showing how to get to the M27 on
the A36 - but no-one could say that the road is also the M27.

If you look at the documentation for this it makes clear the distinction
- for instance

http://www.opsi.gov.uk/si/si2002/20023113.htm 

"Identification numbers of routes to which a particular route leads
shall be shown in brackets."

So in this case, the sign to which you are referring is saying this is
the A14 leading to the A11. It is not also the A11 as you imply.

HTH

Nick


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Mon, 7 Apr 2008, Robert (Jamie) Munro wrote:

> It's not subjective, it is officially signed - the signs say "A14
> (A11)". This happens all over the place in the UK A roads network.

Don't road numbers in brackets generally mean "leads to" rather than "part 
of"?

> I can't see how you can argue that
> it is wrong to connect all the ways forming a large numbered road with a
> relationship, which seems to be what Richard is arguing. It seems to me
> that it is exactly what relationships are for.

I'm not sure anyone is saying it is wrong, merely unnecessary and prone to 
causing confusion/errors.

The fact that there is some disagreement here about _what_ should be 
part of a relation shows that this stuff isn't really clear cut.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Steve Hill wrote:

Don't road numbers in brackets generally mean "leads to" rather  
than "part

of"?
[...]
I'm not sure anyone is saying it is wrong, merely unnecessary and  
prone to

causing confusion/errors.


+1.

Relations are for doing things that can't otherwise be done, or done  
well. But where there's something that already works well (ref tags),  
let's not confuse newcomers by requiring them to learn yet another  
thing.


cheers
Richard___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[David Ebling]

I'm firmly with Richard so far on this discussion.

On one of the issues, Robert, your understanding of
what "A14 (A11)" means seems very different to mine.
If I understand you correctly, you're arguing the road
should be tagged A11 because it has signs saying (A11)
on it, meaning that it's part of at A11 route.

As I understand it the sign says (A11) only because
the road leads to the A11. Thus many other roads that
lead to the A11 will have (A11) marked on signs, which
do not fill a gap between two roads that are
*actually* the A11, but just lead to a junction with
the A11.

eg:
A14
 |
 |
A11--+
 |
 |
 ++---A11
 ||
 ||
A14 B(A11)

This B road is not in any sense part of the A11, but
could have signs saying (A11).

The "direction signs" link at
http://www.direct.gov.uk/en/TravelAndTransport/Highwaycode/Signsandmarkings/index.htm
states the following:

"Motorways shown in brackets can also be reached along
the route indicated."

Thus a slip road onto the M23 northbound could have a
sign with "M23 (M25)" on it. In no sense is the M23
part of the M25, nor should it ever be tagged as such,
nor included in a relation as such.

Signs next to the carriageway away from junctions are
just confirmation signs of which route you are on, and
road references in brackets are still merely
indicating that the route you are on leads to that
road.

I still don't understand the need to have a single
contiguous relation for the A11. The A11 isn't
contiguous. You could make a route relation, but I'm
unsure of it's value.

Dave


> 
> Message: 6
> Date: Mon, 07 Apr 2008 14:51:43 +0100
> From: "Robert (Jamie) Munro" <[EMAIL PROTECTED]>
> Subject: Re: [OSM-talk] Relations not always
> brilliant

> 
> It's not subjective, it is officially signed - the
> signs say "A14
> (A11)". This happens all over the place in the UK A
> roads network.
> 
> Going back on topic, fundamentally, I can't see how
> you can argue that
> it is wrong to connect all the ways forming a large
> numbered road with a
> relationship, which seems to be what Richard is
> arguing. It seems to me
> that it is exactly what relationships are for.
> 
> Robert (Jamie) Munro
> 



  ___ 
Yahoo! For Good helps you make a difference  

http://uk.promotions.yahoo.com/forgood/


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andy Robinson (blackadder) wrote:
| Frederik Ramm wrote:
|> Sent: 07 April 2008 1:52 AM
|> To: Richard Fairhurst
|> Cc: Talk Openstreetmap
|> Subject: Re: [OSM-talk] Relations not always brilliant
|>
|> Hi,
|>
|>>> If you simply use the "ref" tag to specify the road number, how would
|>>> you then use the API to access all ways making up B4027?
|>> By using OSMXAPI: http://www.informationfreeway.org/api/0.5/way
|>> [ref=B4027]
|> Which will omit anything tagged "ref=B4027;B4028" or some such. Ok you
|> said there shouldn't be any of those in the UK anyway so I guess
|> you're fine...
|>
|>> That the mainstream API doesn't do it is (if it's deemed useful) a
|>> deficiency in the API, not a reason to add duplicate data.
|> I think it is a good idea to group objects that belong together in a
|> relation. Ultimately I'd expect the relation to carry the "ref=B4027"
|> tag and to drop that tag from the ways contained therein. Makes a lot
|> of sense from a data modelling viewpoint I think.
|
| I think it’s a leap of faith to think that we will even get to the
position
| were the relationship alone holds the grouped data, such as ref. I see
that
| there will always likely be duplication in this regard with the same
| information being held on the component parts as well as the
relationship. I
| don’t see this as a bad thing, the components may have equal applicability
| and use as the overall object, especially in different applications.

IMHO Data duplication is a really bad idea. It will get out of sync, and
some renderings will show one version, others will show others. Use of
relations allows us to reduce duplication.

Robert (Jamie) Munro

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+q7fz+aYVHdncI0RAqUDAJ9FN90vbUPb6z94JN4EfrAgYI/mNgCcCP+F
aZVjVTsX3mqEgdm0OeORZhA=
=hQce
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Lester Caine]

Steve Hill wrote:
> On Mon, 7 Apr 2008, Frederik Ramm wrote:
> 
>> If it's done consistently, one can still create relations automatically 
>> later 
>> if desired.
> 
> But this is kind of the point - if you are able to automatically create 
> the relations (and presumably automatically fix them if someone makes the 
> way tags inconsistent with the relation tags) with very little effort, is 
> there a good reason to create them in the first place rather than deriving 
> that data as and when you need it?

I harp back to *MY* original request. That there is a mechanism created for 
managing hierarchical data properly. Looking for ref=M11 is no use what so 
ever if there are M11's in several countries?

Until there is some UNIQUE way of tagging high level relationships 
consistently, then there seems little point trying to fix fine detail at the 
lower level. It brings back up the simple problem of producing a unique list 
of objects in the data. How DO we currently identify all roads in the UK, so 
that we don't end up with some of the simply silly links that the likes of 
Autoroute returns when asking for a location.

We need a consistent UNIQUE index method that will allow all 'ref=M11' 
elements in the UK to be identified as that one element. This may need the 
is_in to be correctly flagged, but what is actually missing is some HASH 
method whereby M11,UK is identified as #12345 while M11,NZ is #12346. This may 
well need some automated methods to manage it, but until there is some 
agreement on HOW the problem should be solved is there any point discussing 
how you combine disjointed bits of some road and flag the direction 
information needed to direct people through them? If I am searching for UK 
information I need some means of identifying it without having to do polygon 
transforms on 100s of thousands of elements when the boundary surrounding them 
is not even complete yet :(

Please can we at least start with a set of objects that define the countries 
of the world and consistently uses them to define those elements that are 
within each country?

-- 
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Ian Sergeant]

Lester Caine <[EMAIL PROTECTED]> wrote:

> until there is some UNIQUE way of tagging high level relationships
> consistently, then there seems little point trying to fix fine detail at
the
> lower level. It brings back up the simple problem of producing a unique
list
> of objects in the data. How DO we currently identify all roads in the UK,
so
> that we don't end up with some of the simply silly links that the likes
of
> Autoroute returns when asking for a location.

This doesn't solve your uniqueness problem, with routes, roads, or possibly
anything else.  Route references within a country certainly aren't always
unique.  Ensuring the reference is in the same country doesn't mean you
still won't get silly results.

A relation provides a unique relation id which distinguishes the M1 in
London, from the M1 in Sydney, from the M1 in Melbourne, from the M1 in
Auckland, etc.  This makes each road reference unique, without trying to
predict the way road references work in different places.

The alternative to using a relation is developing a set of heuristics,
using country, location, reference name, connection nodes, etc.  The
question is whether the complexity of the set that would have to be
developed, and handling the exceptions is better than the complexity of
implementing the required relations.

Ian.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Tue, 8 Apr 2008, Lester Caine wrote:

> How DO we currently identify all roads in the UK, so
> that we don't end up with some of the simply silly links that the likes of
> Autoroute returns when asking for a location.
>
> We need a consistent UNIQUE index method that will allow all 'ref=M11'
> elements in the UK to be identified as that one element.

Why do we need them all to be identified with a single element?  You cite 
route planning as a reason but I really don't see why it is applicable - 
your route planner doesn't need to know that two bits of road with a gap 
between them are (administratively) the same road.

In fact, there are only 2 times a route planner needs to know about the 
road's ref or name:
1. When producing instructions ("Take the 3rd exit onto the M11")
2. As you cross from one way to another in order to determine if it is 
really a junction or just a continuation of the same way (you don't want 
it to tell you to "continue along the M11" at arbitrary points just 
because the way has been split there, and you might want to impose some 
kind of penalty for turning off the road to prevent the route from 
containing too many small turns).

Putting all of the separate bits of the UK's M11 in a single relation 
sounds about as silly as putting all the roads in the UK called "Station 
Road" in a single relation - they are separate roads and there is no good 
reason to treat them in any other way.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Lester Caine wrote:

> I harp back to *MY* original request.

I thought you might. ;)

> That there is a mechanism created for
> managing hierarchical data properly.

You can superimpose a "structure" on OSM two ways: either through  
forcing the data to be entered and tagged in a certain way, or  
through post-processing.

Imposing it simply via data entry will not work for our community. It  
requires either strict rules on what data is entered (can't work with  
a user-base growing at the rate ours is), or for the editing software  
to provide a greater level of abstraction, and experience shows that  
many of our users _resent_ abstraction - they want to control exactly  
what's going into the database.

So it has to be via post-processing - and this has the advantage that  
two people can derive a completely different structure from the same  
database. And, again, let's work on the libraries to make this as  
easy as possible.

I agree with your later point that it would be good to have a  
mechanism of finding out what's in each country (and, ultimately,  
county/département/länd/whatever) - but rather than requiring  
everyone to tag with some new hierarchical equivalent of is_in, let's  
use the boundaries that people are already drawing to set up a  
"painted" image of the world, coastline-style, with a lookup service.  
Would be a great GSoC project sometime... next year!

cheers
Richard
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Lars Aronsson]

Robert (Jamie) Munro wrote:

> It might not be the A11 from the point of view of who is in 
> charge of maintaining it, but it is the A11 from the point of 
> view of someone following the route

Have you talked to the people who are in charge of the road?  
Maybe they are friends of OSM, as opposed to the Ordnance Survey.  
Maybe we have a common enemy in the OS?



In Sweden, the parenthesis is not used on road signs but instead a 
dotted line around the road number.  This is national road 58,
http://commons.wikimedia.org/wiki/Image:1_5_4_2.svg
And this is a road leading towards road 58,
http://commons.wikimedia.org/wiki/Image:1_5_4_4.svg



Still, there is at least near Kvarntorp some confusion of whether 
road 51 goes north to Örebro or east towards E20 south of Kumla.  
Both roads carry signs 51 without any dotted line.  But according 
to Wikipedia, the road north is a branch named 51.01,
http://sv.wikipedia.org/wiki/Riksv%C3%A4g_51

Eniro, a popular Swedish map site, shows all three roads as 51, 
http://kartor.eniro.se/query?&what=map_adr&mop=aq&mapstate=6;15.282434534059728;59.133863881839446;s;15.248667763412294;59.14890027267818;15.316133905963355;59.118827491000715;1001;842&mapcomp=;;0;00&stq=0

Google Maps says 51 goes east-west only, not north,
http://maps.google.com/?ie=UTF8&ll=59.13421,15.289536&spn=0.033025,0.090637&z=14

Multimap agrees with Google,
http://www.multimap.com/maps/#t=l&map=59.13084,15.28539|14|4&loc=SE:58.66117:15.18308

Point in case is that Örebro (north) is the major city, and people 
from there "know" that road 51 starts in their town.


-- 
  Lars Aronsson ([EMAIL PROTECTED])
  Aronsson Datateknik - http://aronsson.se

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Hill wrote:
| Putting all of the separate bits of the UK's M11 in a single relation
| sounds about as silly as putting all the roads in the UK called "Station
| Road" in a single relation - they are separate roads and there is no good
| reason to treat them in any other way.

Seriously, you can't see a difference between the M11, and the
collection of roads called "High Street", all over the UK and even the
world? You don't think that the second is just a bit more "silly" than
the first?

You don't think that searching for "M11" should produce one result for a
road that covers the whole country, and searching for high street should
produce hundreds of separate results?

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+19Pz+aYVHdncI0RAoc1AJ9vX75VAC/nZUzNufhkOskGtfveuwCfWmq3
mZTNAoBfxFkrW80j5yQ8U9c=
=hvZO
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Dave Stubbs]

On Tue, Apr 8, 2008 at 1:04 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>
> Steve Hill wrote:
>  | Putting all of the separate bits of the UK's M11 in a single relation
>  | sounds about as silly as putting all the roads in the UK called "Station
>  | Road" in a single relation - they are separate roads and there is no good
>  | reason to treat them in any other way.
>
>  Seriously, you can't see a difference between the M11, and the
>  collection of roads called "High Street", all over the UK and even the
>  world? You don't think that the second is just a bit more "silly" than
>  the first?
>
>  You don't think that searching for "M11" should produce one result for a
>  road that covers the whole country, and searching for high street should
>  produce hundreds of separate results?
>

He was talking about disconnected bits, although it does depend to
some extent just how disconnected the bits are as to how silly it is.
I'm sure you can find some nice extreme examples to prove both
arguments.

I've no idea whether there are actually any disconnected parts of the
M11 - as far as I was aware it's just about 50 miles in the SE of
England - but anyway, that's completely irrelevant to the point.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Andy Allan]

On Tue, Apr 8, 2008 at 1:04 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote:

>  You don't think that searching for "M11" should

You seem to be discussing a hypothetical search engine - how it works
is dependent on the implementation of the search engine, not the
structure of the database, and so this is not relevant to the
conversation at hand.

Cheers,
Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Andy Allan]

On Tue, Apr 8, 2008 at 1:33 PM, Steve Hill <[EMAIL PROTECTED]> wrote:
>  But a motorway which is not a continuous road (i.e. has gaps in it) is
>  _not_ a single road - I see no reason why it should be treated as one.
>  Maybe you could cite some examples of why you need to treat it as a single
>  road, even though it has gaps in it?

...or more importantly, examples where not using relations makes the
task impossible, as opposed to just tricky...

Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Ebling wrote:
| I'm firmly with Richard so far on this discussion.
|
| On one of the issues, Robert, your understanding of
| what "A14 (A11)" means seems very different to mine.
| If I understand you correctly, you're arguing the road
| should be tagged A11 because it has signs saying (A11)
| on it, meaning that it's part of at A11 route.

We're getting way distracted here. I merely suggested that if it were
part of both roads (which legally it seems not to be in the UK, but
according to comments legally is in similar situations in the USA), then
you'd need to put it in a relationship to make the road as an entity
make sense - just using ref's doesn't work well.

Richard seemed to be arguing that putting the whole A11 (with or without
the connecting parts from other roads) in a single relationship was "not
brilliant". Surely that's what relationships are for?

I still don't think it's wrong to relate the stretch of the A14 that
connects the disjointed parts of the A11 together in some way, no matter
what the law says, but either way, the parts of a long route should be
related to each other for database tidiness and consistency reasons. It
just makes sense.

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+2n1z+aYVHdncI0RAoTHAJ4z5w2EMqidGE35QRPA+/RrqAU4TgCbBafK
YD48YNWofcgIc6cmmcRPVCI=
=JauA
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Robert (Jamie) Munro wrote:

> Richard seemed to be arguing that putting the whole A11 (with or  
> without
> the connecting parts from other roads) in a single relationship was  
> "not
> brilliant". Surely that's what relationships are for?

No... because the information is already in there (in the ref tag)  
and, for the nth time, you are adding more and more and more  
complexity that can only serve to increase the entry barrier.

I repeat: "Relations are for doing things that can't otherwise be  
done, or done well."

cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Tue, 8 Apr 2008, Robert (Jamie) Munro wrote:

> You don't think that searching for "M11" should produce one result for a
> road that covers the whole country, and searching for high street should
> produce hundreds of separate results?

But a motorway which is not a continuous road (i.e. has gaps in it) is 
_not_ a single road - I see no reason why it should be treated as one. 
Maybe you could cite some examples of why you need to treat it as a single 
road, even though it has gaps in it?

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Sven Grüner]

Lester Caine schrieb:
> Until there is some UNIQUE way of tagging high level relationships 
> consistently, then there seems little point trying to fix fine detail at the 
> lower level. It brings back up the simple problem of producing a unique list 
> of objects in the data. How DO we currently identify all roads in the UK, so 
> that we don't end up with some of the simply silly links that the likes of 
> Autoroute returns when asking for a location.

I'm thinking along those lines as well for a while now. I don't believe 
it suffices to map all boundaries to determine which roads belong to 
which country/city/suburb. Leave alone the fact that many boundaries are 
pretty hard to find or even map. When I've mapped a village with, say, 
20 roads it takes me less than five clicks to group those in a relation 
and adding that relation to the relation of the municipality, town, etc. 
Even with the lowlevel relations support our editors currently have. I 
believe this is far more practical than to require mappers to map all 
relevant boundaries.

I've recently created a sandbox going the whole way from "Planet Earth" 
to "Some Road" all in nested relations. You can browse it here:
http://osm.schunterscouts.de/relation-browser.php
(the URL accepts other relations as well, comments welcome)

regards, Sven

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Tue, 8 Apr 2008, Robert (Jamie) Munro wrote:

[ Roads with multiple designations ]
> just using ref's doesn't work well.

Why don't they work well?  Put multiple values in the tag separated by 
semicolons - what's wrong with that?  I understand that currently you 
can't search on a single value within that tag, but that is a (fixable) 
API problem and doesn't require this extra complexity.

Don't get me wrong - I do agree that in the end this stuff wants to go 
into relations, but I think doing it now is going to be a bad idea because 
the tools haven't yet made this easy and intuitive.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dave Stubbs wrote:
| On Tue, Apr 8, 2008 at 1:04 PM, Robert (Jamie) Munro
<[EMAIL PROTECTED]> wrote:
|> -BEGIN PGP SIGNED MESSAGE-
|>  Hash: SHA1
|>
|>
|> Steve Hill wrote:
|>  | Putting all of the separate bits of the UK's M11 in a single relation
|>  | sounds about as silly as putting all the roads in the UK called
"Station
|>  | Road" in a single relation - they are separate roads and there is
no good
|>  | reason to treat them in any other way.
|>
|>  Seriously, you can't see a difference between the M11, and the
|>  collection of roads called "High Street", all over the UK and even the
|>  world? You don't think that the second is just a bit more "silly" than
|>  the first?
|>
|>  You don't think that searching for "M11" should produce one result for a
|>  road that covers the whole country, and searching for high street should
|>  produce hundreds of separate results?
|>
|
| He was talking about disconnected bits, although it does depend to
| some extent just how disconnected the bits are as to how silly it is.
| I'm sure you can find some nice extreme examples to prove both
| arguments.
|
| I've no idea whether there are actually any disconnected parts of the
| M11 - as far as I was aware it's just about 50 miles in the SE of
| England - but anyway, that's completely irrelevant to the point.

I live about 200m from the A44 in Oxfordshire. I've always belived that
this is the road from the middle of Oxford to Aberystwyth, but you're
arguing that this is untrue. It's simply the road from Oxford to Moreton
in Marsh. It just happens to have the same ref as the road from Moreton
in Marsh to Evesham that starts about 60m along the A429 from the road
that passes me. Then there just happens to be another separate road with
the same ref in Evesham that goes to Worcester and so on until you reach
Aberystwyth. These roads have nothing to do with each other, and they
shouldn't form a relationship in the database, and I shouldn't expect to
~  get home from Aberystwyth by following them.

Robert (Jamie) Munro


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+3F6z+aYVHdncI0RAkmyAKCLFb/Se+g0xCFyZ/X8LUtgH5VlXACg9XZ/
MRBqBJdFTRCXBIp0okeuoxk=
=PzhM
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Tue, 8 Apr 2008, Andrew McCarthy wrote:

> (2) A relation for that road's notional "route", that contains the
> relation above *plus* the (usually obvious) connecting bits that give
> you a single, long distance route from A to B.

Which bits you use to connect the disjointed sections are a rather 
arbitrary decision - should OSM be making such decisions?  I mean, there 
is no officially documented "this is how you get between these sections" 
route so we would be making a route up arbitrarilly.

Sure, for some stuff it might be obvious, but for a lot of stuff it 
isn't.  Take the A31, for example - it joins the M3 near Winchester but 
then reappears on the westerly end of the M27.  You might say that the M3 
and M27 is "obviously" the missing link and add that to the A31 relation, 
but that would be completely unsuitable for cyclists.  This really isn't 
the job for submitters, this is the job for a route planner program - 
submitters are supposed to be recording data, not making relatively 
arbitrary decisions about which routes people should take.

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Richard Fairhurst]

Robert (Jamie) Munro wrote:

> [A44]
> These roads have nothing to do with each other

No;

> and they shouldn't form a relationship in the database

they already do (with a small 'r'), it's the set of those ways within  
the UK where ref=A44;

> and I shouldn't expect to get home from Aberystwyth by following them.

personally I'd change at Shrewsbury and Hereford, but each to their own.

cheers
Richard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Andrew McCarthy]

On Tue, Apr 08, 2008 at 01:33:31PM +0100, Steve Hill wrote:
> But a motorway which is not a continuous road (i.e. has gaps in it) is 
> _not_ a single road - I see no reason why it should be treated as one. 
> Maybe you could cite some examples of why you need to treat it as a single 
> road, even though it has gaps in it?

Can we not have both?

(1) A relation which contains all the ways that define a road according
to its official designation, whether a single road, or several disjoint
pieces.

and 

(2) A relation for that road's notional "route", that contains the
relation above *plus* the (usually obvious) connecting bits that give
you a single, long distance route from A to B.

Different people will find the two options useful. Or am I missing
something here?

Andrew


signature.asc
Description: Digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Sebastian Spaeth]

Sven Grüner wrote:
> I've recently created a sandbox going the whole way from "Planet Earth" 
> to "Some Road" all in nested relations. You can browse it here:
> http://osm.schunterscouts.de/relation-browser.php
> (the URL accepts other relations as well, comments welcome)

You do know that sometimes people need to download all entities of a
relation when they download an area with a single node in it? I wouldn't
want to download all elements of "earth" when I download my
neighbourhood block. :-) How do you handle this problem?

spaetz

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Andrew McCarthy]

On Tue, Apr 08, 2008 at 02:25:11PM +0100, Steve Hill wrote:
> Which bits you use to connect the disjointed sections are a rather 
> arbitrary decision - should OSM be making such decisions?  I mean, there is 
> no officially documented "this is how you get between these sections" route 
> so we would be making a route up arbitrarilly.
>
> Sure, for some stuff it might be obvious, but for a lot of stuff it isn't.  
> Take the A31, for example - it joins the M3 near Winchester but then 
> reappears on the westerly end of the M27.  You might say that the M3 and 
> M27 is "obviously" the missing link and add that to the A31 relation, but 
> that would be completely unsuitable for cyclists.  This really isn't the 
> job for submitters, this is the job for a route planner program - 
> submitters are supposed to be recording data, not making relatively 
> arbitrary decisions about which routes people should take.

Okay, I take your point. In Ireland I'm not aware of any such extreme
examples (except the N3), with most disjoins being only a few hundred
metres at most.

In that case, would the use of highway relations be restricted to such
cases where there is one *official* route, with differing refs? For
example, National Primary Road 7 in Ireland is the entire road from
Dublin to Limerick. It's called the N7, but for those portions where
it's a motorway, it's the M7. In this case ref=M7;N7 would only be
appropriate for the motorway if N7 was guaranteed not to appear.

:)

Andrew


signature.asc
Description: Digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Tue, 8 Apr 2008, Robert (Jamie) Munro wrote:

> But Richard seems to be arguing that relating parts of A roads together in a 
> single relationship is by itself a bad idea, because refs are simpler.

I agree with him here though - I think it is a bad idea with the current 
state of the tools, because I think the data will become inaccurate as 
people edit the ways.  (I also still dislike the idea of putting lots of 
disjointed bits of a road in a relation because I fundamentally don't see 
why you wouldn't want to treat them as independent roads).

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Tue, 8 Apr 2008, Andrew McCarthy wrote:

> In that case, would the use of highway relations be restricted to such
> cases where there is one *official* route, with differing refs?

"Official" by whose authority?  I am not aware of the UK highways agency 
publishing official routes for these gaps (although for other countries 
there may be some kind of official route - a relation with the route= 
tag may be a reasonable approach if there really is something official).

> For example, National Primary Road 7 in Ireland is the entire road from
> Dublin to Limerick. It's called the N7, but for those portions where
> it's a motorway, it's the M7. In this case ref=M7;N7 would only be
> appropriate for the motorway if N7 was guaranteed not to appear.

Is the M7 officially also the N7 though, or are you just making a decision 
based on a subjective "obviousness" criteria?

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Sven Grüner]

Sebastian Spaeth schrieb:
> You do know that sometimes people need to download all entities of a
> relation when they download an area with a single node in it? I wouldn't
> want to download all elements of "earth" when I download my
> neighbourhood block. :-) How do you handle this problem?

Well, currently the API only returns direct members, so do our editors 
as well as my script. For "Earth" that would only be the few continents 
and a couple of oceans, totally bearable.

When you start to put all Autobahnen in the Germany-relation (since they 
are run and owned by the national governemnt) you will obviously run 
into trouble just when downloading direct members.
But this could be solved by only making the way-relation as proposed in:
http://wiki.openstreetmap.org/index.php/Relations/Proposed/Collected_Ways

That would result in about 100-200 direct members (instead of thousands 
of ways with millions of nodes), which is okay again. Alternatively one 
could request special member-groups of a relation by their role. I.e. 
"give me all states of Germany and the capital but not the Autobahnen, 
national buildings, etc."

This is of course still an issue but I believe that solutions will occur 
shortly after we run into serious trouble like always in OSM. And it 
will be a while till relations are so well used to cause  bandwith-problems.

regards, Sven

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Steve Hill]

On Tue, 8 Apr 2008, Andrew McCarthy wrote:

> It's specified in the "Statutory Instrument" issued by the Government.
> I've no idea if we're unique on this, but it's a big planet :)

Sounds like ref=M7;N7 is the correct thing to do in this case then.  As 
for what the renderers should do, that's another question (there could be 
arguments for showing an "M7" label with "N7" under it in smaller type, 
etc. but so long as the data is in the database in a useful form, that can 
all be worked out later).

  - Steve
xmpp:[EMAIL PROTECTED]   sip:[EMAIL PROTECTED]   http://www.nexusuk.org/

  Servatis a periculum, servatis a maleficum - Whisper, Evanescence


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew McCarthy wrote:
| On Tue, Apr 08, 2008 at 01:33:31PM +0100, Steve Hill wrote:
|> But a motorway which is not a continuous road (i.e. has gaps in it) is
|> _not_ a single road - I see no reason why it should be treated as one.
|> Maybe you could cite some examples of why you need to treat it as a
single
|> road, even though it has gaps in it?
|
| Can we not have both?
|
| (1) A relation which contains all the ways that define a road according
| to its official designation, whether a single road, or several disjoint
| pieces.
|
|   and
|
| (2) A relation for that road's notional "route", that contains the
| relation above *plus* the (usually obvious) connecting bits that give
| you a single, long distance route from A to B.
|
| Different people will find the two options useful. Or am I missing
| something here?

That's my point of view, but this thread started with Richard saying we
can't have /either/.

The second option was really me saying "look, if a road was a
relationship, that would open other great things, like we could link in
these other bits with a special role - relationships /are/ brilliant!"
But to my surprise, rather than people thinking that linking those bits
of road might be a nice added feature, they started quoting highway
regulations back at me insisting that the roads must be kept separate.
It's not my opinion that we /must/ link in the connecting parts, just
that it might be a nice feature.

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+4fiz+aYVHdncI0RAsGMAJ4z+jJovvCgMWIW5ce8hqw9jwkBvQCfUMFx
3uOeVAl9D230qOWKkgjPG5E=
=AjW7
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[Lester Caine]

Robert (Jamie) Munro wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Steve Hill wrote:
> | Putting all of the separate bits of the UK's M11 in a single relation
> | sounds about as silly as putting all the roads in the UK called "Station
> | Road" in a single relation - they are separate roads and there is no good
> | reason to treat them in any other way.
> 
> Seriously, you can't see a difference between the M11, and the
> collection of roads called "High Street", all over the UK and even the
> world? You don't think that the second is just a bit more "silly" than
> the first?
> 
> You don't think that searching for "M11" should produce one result for a
> road that covers the whole country, and searching for high street should
> produce hundreds of separate results?

This is EXACTLY the problem I'm trying to highlight!
The CURRENT data produces hundreds of High Street's and a large quantity of 
them are duplicates. You can not produce a single set of 'High Street' 
objects, ADDED to which identifying the LOCATION of each 'High Street' is an 
even sillier exercise.
This is why we need to agree a method of identifying unique versions of an 
object such as 'High Street', 'Evesham', 'Worcestershire', 'England'. And then 
we can find High Street, Evesham from all of the other High Streets, and 
HOPEFULLY identify all of the segments that make it up.
The missing piece of the jigsaw is a means if linking all of the High Street, 
Evesham segments into one object, so that a search only produces ONE result.

Problems like the A11 using part of the A14 as it's route North of Cambridge 
are just a matter of deciding if the A11-South is a separate road to the 
A11-North. Directions would have to say - Turn onto A14 - Take slip road 
signposted A11 - So in this instance they are two separate roads, but other 
uses of the road data MAY require that just a single record of A11 is 
returned. It is THAT relationship management that is missing. Although the A11 
passes through Cambridgeshire, Suffolk and Norfolk, and sensibly each section 
should be able to provide that information so that 'Pass into Suffolk or 
Norfolk' could be identified. The hierarchy is never going to be simple, but 
some means of adding sensible data IS required?

-- 
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations not always brilliant

[David Earl]

On 08/04/2008 19:02, Lester Caine wrote:
>> You don't think that searching for "M11" should produce one result for a
>> road that covers the whole country, and searching for high street should
>> produce hundreds of separate results?
> 
> This is EXACTLY the problem I'm trying to highlight!
> The CURRENT data produces hundreds of High Street's and a large quantity of 
> them are duplicates. You can not produce a single set of 'High Street' 
> objects, ADDED to which identifying the LOCATION of each 'High Street' is an 
> even sillier exercise.
> This is why we need to agree a method of identifying unique versions of an 
> object such as 'High Street', 'Evesham', 'Worcestershire', 'England'. And 
> then 
> we can find High Street, Evesham from all of the other High Streets, and 
> HOPEFULLY identify all of the segments that make it up.
> The missing piece of the jigsaw is a means if linking all of the High Street, 
> Evesham segments into one object, so that a search only produces ONE result.

Well, this is partly the problem the Name Finder sets out to solve. You 
will notice that if you search for "High Street, Ely" (the one in 
Evesham, if there is one, isn't mapped, so I've changed the example) you 
don't get several results which are the component ways of that 
particular High Street (assuming there is more than one - I've not 
looked), but you do get other nearby High Streets.

It would be easier to do this if the components were related, but it 
isn't an insoluble problem if they aren't. You don't get duplicates with 
the name finder for this kind of street.

However, you *do* get *useful* duplicates for the M11. Not every single 
little piece, but at useful intervals along it. So if you say "M11 near 
Bishops Stortford" you get one bit, the nearest to the town (and then a 
few more successively further away), and "M11 near Saffron Walden" gets 
you a different bit.

Because it is such a long road, as you say pointing at one point only on 
it is not helpful. So I don't. But pointing at every artificially 
divided up part of a road isn't helpful either. So I don't.


David

(PS I notice something's gone wrong with the sorting in the name finder 
- I'll look into that).


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] relations within relations - walking trails

[Robin Paulson]

i am mapping walking tracks in new zealand, and have recently added
'te araroa' - the walking track from the top of the north island to
the bottom of the south.

it is made up at parts of the way of other walking tracks, such as the
'coast to coast' walking track in the auckland region.

problem is, i can't get my head round how to relate the two in a relation

any suggestions? i'm using potlatch to do my editing, so examples
using that would be good

cheers

-- 
robin

http://bumblepuppy.org/blog/?p=237 - government bill to remove basic
human rights in NZ

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Relations and the license change

[Nathan Edgars II]

Has there been any information as to how the OSMF will handle relations 
when deleting or reverting tainted objects? It is much easier for a 
relation to be tainted than a way; all that needs to be done is the 
splitting of a single member to ruin the entire relation. For example, 
31 of the (non-super non-business) relations for U.S. Interstate 
Highways (network=US:I) were created by a red user and 63 were modified 
by one, which is 18% tainted out of a total of 517.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Relations on Irish islands

[Richard Fairhurst]

Joseph Reeves wrote:
> What does "" mean? This should be "outer"?

I'd hazard a guess that's a Potlatch 2 bug resulting from some edge case
when editing the role with multiple items selected. I'll have a look but
feel free to add a trac ticket to remind me.

cheers
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/Relations-on-Irish-islands-tp5736825p5736842.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations in order not to

[David Ebling]

> As far as I understand it, the idea is simply to
> qualify a tag with
> start and end node. I.e. you have a way that goes
> from node A, B, C to
> Z, but from B to D and from M to P it is a
> pedestrian road. So,
> 
> old scheme:
> 
> split way into 5 parts (3 non-pedestrian, 2
> pedestrian) and tag
> accordingly.
> 
> scheme with "superway" relation:
> 
> split way into 5 parts and create one relation to
> contain them all;
> add all common tags to relation; add pedestrian tag
> to 2 ways.
> 
> scheme with "qualified tag" relations:
> 
> do not split way. create two relations that each
> contain the way, plus
> the start and end node (B/D for relation 1 and M/P
> for relation 2),
> plus the special tag (pedestrian).

Am I the only one reading this discussion thinking
that editing on OSM is going to get so complicated
that we'll have very few new contributors, and
certainly not many non-techies?

I agree that segmenting roads is not ideal, but I'm
just trying to think about the way that relation data
will be presented to users for editing with either of
these two models. Perhaps that's cart before horse,
but it worries me.

I started playing with OSM just after segments had
been done away with, and sometimes I wonder why that
happened, not having ever used them. It seems to me
that the current proposals regarding ways/relations
are somewhat similar to segments/ways. The "qualified
tag" approach seems like ways become what was
segments, except they cover more than one node, and
the relations become what was ways... or am I
misunderstanding somewhat? I feel that the term
"relation" for something that is basically a
meta-data-carrying way will be confusing for
newcomers. The use of "relation" for saying that two
ways are related makes more sense.

Sorry for the rambling stream-of-conciousness, anyway!

Dave


  __
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Relations without members: Lists and wikipage

[Werner Hoch]

Hi there,

in the latest planet there are 768632 relations. 
25094 of them don't have any relation member.
That means more than 3% of all relations are affected.

I've created a wikipage about empty relations:
http://wiki.openstreetmap.org/wiki/Empty_relations
I wrote down my guesses why the empty relations 
exist and how they can be fixed or cleaned up.

I've created a list of all empty relations and a statistic 
about the users who have created them (last editor):
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/empty_relations.html

I'm going to contact the users that have created lots of empty relations.
I'd like to find out more about the reasons and ask if the relations can
be wiped out or if they are still needed.

Comments and improvements of the wikipage are welcome.

Any help in cleaning up those relations would be great.

Regards
Werner (werner2101)

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations within relations - walking trails

[Frederik Ramm]

Hi,

On 05/24/11 03:18, Robin Paulson wrote:

it is made up at parts of the way of other walking tracks, such as the
'coast to coast' walking track in the auckland region.

problem is, i can't get my head round how to relate the two in a relation


Example:

Trans-European hiking route E1

http://www.openstreetmap.org/browse/relation/371743

consists, among other relations, of the "E1 German Part"

http://www.openstreetmap.org/browse/relation/36367

which in turn consists of smaller relations like "E1 Hamburg", "E1 
Schleswig-Holstein", etc.


http://www.openstreetmap.org/browse/relation/69471
http://www.openstreetmap.org/browse/relation/71770

and these, finally, contain way members.

Bye
Frederik


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations within relations - walking trails

[Hermann Peifer]

On 24/05/2011 08:41, Frederik Ramm wrote:

Hi,

On 05/24/11 03:18, Robin Paulson wrote:

it is made up at parts of the way of other walking tracks, such as the
'coast to coast' walking track in the auckland region.

problem is, i can't get my head round how to relate the two in a relation


Example:

Trans-European hiking route E1

http://www.openstreetmap.org/browse/relation/371743

consists, among other relations, of the "E1 German Part"

http://www.openstreetmap.org/browse/relation/36367

which in turn consists of smaller relations like "E1 Hamburg", "E1
Schleswig-Holstein", etc.

http://www.openstreetmap.org/browse/relation/69471
http://www.openstreetmap.org/browse/relation/71770



I have a similar issue with the nesting of international > national > 
regional > local bike routes where relations on the lower levels already 
exists. The problem (at least mine) is not to relate the existing 
relation objects conceptually, but to do this practically, in Potlatch.


Hermann

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations within relations - walking trails

[Vincent Pottier]

Le 24/05/2011 03:18, Robin Paulson a écrit :

i am mapping walking tracks in new zealand, and have recently added
'te araroa' - the walking track from the top of the north island to
the bottom of the south.

it is made up at parts of the way of other walking tracks, such as the
'coast to coast' walking track in the auckland region.

problem is, i can't get my head round how to relate the two in a relation

any suggestions? i'm using potlatch to do my editing, so examples
using that would be good

cheers
I don't know if it is possible with Potlatch to put relations as members 
of a relation. It is quite easy on JOSM.


The schema of a relation type=route including relations type=route is 
widely used on this program :

http://wiki.openstreetmap.org/wiki/WikiProject_Europe/Long-distance_paths
It is a way to split a very long route into several parts as for
http://www.openstreetmap.org/browse/relation/138227

If only parts of other routes must be included, the ways can be members 
of several relations.


Some use a type=superroute for the main relations, but it is not an 
existing type and it is not necessary for the route is simply a route 
even if members are relations.


There is a good map showing the routes and rendering the osmc:symbol :
http://osm.lonvia.de/hiking.html?lat=44.33868&lon=2.14782&zoom=8&layers=FFBT0
--
FrViPofm

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations within relations - walking trails

[Frederik Ramm]

Hi,

On 05/24/11 09:24, Hermann Peifer wrote:

The problem (at least mine) is not to relate the existing
relation objects conceptually, but to do this practically, in Potlatch.


Someone has recently claimed that Potlatch was a full-featured editor so 
I'm sure it must be possible ;)


Say you see a way in Potlatch which is a member of relation X (in 
Robin's example, the Auckland coast to coast trail), and you want to add 
this relation X to another relation, Y, which already exists (in Robin's 
example, the 'te araroa' trail).


* Select the way
* use "Advanced" mode to see relation X of wich way is a member
* double click relation X to open relation editor
* use "Advanced" mode to see relations of which X is member (currently 
empty)

* click "Add to" to add X to another relation
* since Y is unlikely to be already loaded, and thus will not appear in 
the list, click "Load Relation" and enter Y's relation ID

* Y is loaded, and X is made a child of Y.

In cases where Y doesn't already exist, use the "New Relation" button 
instead of "New Relation".


If you don't know the relation ID of Y, and don't even know an area that 
you could load to find it, then it is possible that you can use Google 
for that, searching for something like


site:www.openstreetmap.org  relation type=route route=hiking e6

Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations within relations - walking trails

[Hermann Peifer]

On 24/05/2011 10:10, Frederik Ramm wrote:

Hi,

On 05/24/11 09:24, Hermann Peifer wrote:

The problem (at least mine) is not to relate the existing
relation objects conceptually, but to do this practically, in Potlatch.



* Select the way
* use "Advanced" mode to see relation X of wich way is a member
* double click relation X to open relation editor
* use "Advanced" mode to see relations of which X is member (currently
empty)
* click "Add to" to add X to another relation
* since Y is unlikely to be already loaded, and thus will not appear in
the list, click "Load Relation" and enter Y's relation ID
* Y is loaded, and X is made a child of Y.



Thanks for the hints. I managed to redefine our regional bike route 51 
as a relation of 2 relations (local bike routes) and 5 Ways which are 
needed for filling the gaps in between the local routes: 
http://www.openstreetmap.org/browse/relation/1588406


It looks to me that some of the web tools for checking relations are 
only able to present the relation's way members. They do not resolve the 
"sub-relations" into their way members, e.g. 
http://www.openstreetmap.org/?relation=1588406 and 
http://ra.osmsurround.org/analyze.jsp?relationId=1588406


Am I perhaps doing something wrong? In any case, the same relation looks 
OK here:


http://osmrm.openstreetmap.de/relation.jsp?id=1588406#lon=12.52484215;lat=55.69023765;zoom=13;layer=Mpnk

Hermann

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations within relations - walking trails

[Robin Paulson]

On 24 May 2011 20:10, Frederik Ramm  wrote:
> Say you see a way in Potlatch which is a member of relation X (in Robin's
> example, the Auckland coast to coast trail), and you want to add this
> relation X to another relation, Y, which already exists (in Robin's example,
> the 'te araroa' trail).
>
> * Select the way
> * use "Advanced" mode to see relation X of wich way is a member
> * double click relation X to open relation editor
> * use "Advanced" mode to see relations of which X is member (currently
> empty)
> * click "Add to" to add X to another relation
> * since Y is unlikely to be already loaded, and thus will not appear in the
> list, click "Load Relation" and enter Y's relation ID
> * Y is loaded, and X is made a child of Y.

excellent, thanks. exactly what i was after

> In cases where Y doesn't already exist, use the "New Relation" button
> instead of "New Relation".
>
> If you don't know the relation ID of Y, and don't even know an area that you
> could load to find it, then it is possible that you can use Google for that,
> searching for something like
>
> site:www.openstreetmap.org  relation type=route route=hiking e6

ah, that's a good idea.

i wonder - is there a way in osm to search for relations, other than
using google/some other external search engine?

if i know the number it's easy enough, but as you say, that's not
always the case.

also, if i have accidentally created a relation by mistake, how do i delete it?

cheers for the help

-- 
robin

http://bumblepuppy.org/blog/?p=237 - government bill to remove basic
human rights in NZ

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] relations within relations - walking trails

[colliar]

Am 24.05.2011 21:21, schrieb Hermann Peifer:
> Thanks for the hints. I managed to redefine our regional bike route 51
> as a relation of 2 relations (local bike routes) and 5 Ways which are
> needed for filling the gaps in between the local routes:
> http://www.openstreetmap.org/browse/relation/1588406
> 
> It looks to me that some of the web tools for checking relations are
> only able to present the relation's way members. They do not resolve the
> "sub-relations" into their way members, e.g.
> http://www.openstreetmap.org/?relation=1588406 and
> http://ra.osmsurround.org/analyze.jsp?relationId=1588406
> 
> Am I perhaps doing something wrong? In any case, the same relation looks
> OK here:
>
> http://osmrm.openstreetmap.de/relation.jsp?id=1588406#lon=12.52484215;lat=55.69023765;zoom=13;layer=Mpnk

No everything alright!
Sadly, much software does not work for these cases so far.

cu fly

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Relations and the license change

[Frederik Ramm]

Hi,

On 12/18/2011 04:34 AM, Nathan Edgars II wrote:

Has there been any information as to how the OSMF will handle relations
when deleting or reverting tainted objects?


No.

I'll write something on legal-talk.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Relations and the license change

[Nathan Edgars II]

On 12/18/2011 8:45 AM, Frederik Ramm wrote:

Hi,

On 12/18/2011 04:34 AM, Nathan Edgars II wrote:

Has there been any information as to how the OSMF will handle relations
when deleting or reverting tainted objects?


No.

I'll write something on legal-talk.


I'll reply here because (a) I'm not subscribed to legal-talk and (b) 
this is not a legal issue but one of what the OSMF will choose to do.


"Do the Interstate relations you mention contain information that can 
*not* simply be read from the planet file? I mean - if I removed all the 
bits that a non-agreeing user has added to the relation, would it then 
be trivial to put it back together by e.g. simply doing routing between 
the now dangling segment endpoints?"


Because of redundancy with ref tags, it would be simple to search for 
ref:"I 4" to find everything that belongs in the Interstate 4 relation. 
The only other aspects to the relation are with the choice of roles 
(east/west vs. forward) and tags on the relation.


(By the way, routing probably won't work after the OSMF reverts.)

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Relations Proposals for boundary, country and is_in

[Raphael Studer]

Hi,

I've founde three relation proposals with nearly the seam aims.

http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries
http://wiki.openstreetmap.org/index.php/Relations/Proposed/Country
http://wiki.openstreetmap.org/index.php/Relations/Proposed/Is_In

I've also seen relations with type=nation meaning nearly the same as country.

What's about having only two of them:

_Boundaries_
Relation:
 * type=boundary
 * name=?
 * admin_level=?
Members:
 * way or relation with role border.

_Territory (you may choose a better word that for)_
Relation:
 * type=relam
 * name[:de|:en|:it|:fr]=?
 * level=[country|state|county|district]
 * population, language, founded 
Members:
 * territoy-relation with role is_in
 * boundary-relation with role border
 * node with role capital

What do you think of this?

Regards
Raphael

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Relations (Re: Critical Mass for license change-over)

[Nathan Edgars II]

On 1/28/2012 4:26 PM, Toby Murray wrote:

The other major thing that no existing tools take into consideration
is relations. They are mentioned on the "What is clean?" page but they
aren't being factored into any existing algorithms. Not the easiest
thing to show since some of them aren't even rendered on most maps...


Here there are two issues - membership and tags. Membership should be 
easy enough to verify due to redundancy (e.g. the I-70 relation should 
have all ways with ref:"I 70"), and tags are rather standardized. So it 
should be fine to mark odbl=clean after verifying that it's a complete 
route (easy to do if it's all dual carriageway or uses forward/backward 
roles) and checking for nonstandard tags added by ungood mappers.


Relations such as bus routes that are not marked on their children are 
more complicated.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Relations Proposals for boundary, country and is_in

[Knut Arne Bjørndal]

"Raphael Studer" <[EMAIL PROTECTED]> writes:
> I've founde three relation proposals with nearly the seam aims.
>
> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries
> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Country
> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Is_In
>
> I've also seen relations with type=nation meaning nearly the same as country.
>
> What's about having only two of them:

I was thinking along these lines when I wrote the Country proposal,
please remove it as an obsolete suggestion and suggest this instead as
it looks much cleaner to me.

Btw: is there a clear procedure on how we make relation usages
standard?

-- 
Knut Arne Bjørndal
aka Bob Kåre
[EMAIL PROTECTED]
[EMAIL PROTECTED]

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations Proposals for boundary, country and is_in

[Frederik Ramm]

Hi,

> Btw: is there a clear procedure on how we make relation usages
> standard?

I believe the route relation has become standard by being used, and I'd 
suggest the same for others ;-)

Bye
Frederik


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations Proposals for boundary, country and is_in

[Stefan Baebler]

Knut Arne Bjørndal wrote:
> "Raphael Studer" <[EMAIL PROTECTED]> writes:
>> I've founde three relation proposals with nearly the seam aims.
>>
>> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries
>> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Country
>> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Is_In
>>
>> I've also seen relations with type=nation meaning nearly the same as country.
Seeing some use of undocumented nation relation I beg to differ.
nation is not a country.

Countries are administratively (or by force) defined geographical 
entities. Countries generally don't overlap, have precise (although 
sometimes disputed) borders, can have exclaves, enclaves...can be mapped 
precisely
http://en.wikipedia.org/wiki/Country

Nation are people with common culture. Nations can overlap, can have 
minorities in other countries, borders between nations are generally 
blurring with globalisation...can be mapped only vaguely.
http://en.wikipedia.org/wiki/Nation

Sure, some countries might represent a nation
http://en.wikipedia.org/wiki/Nation-state
but this certainly cannot be applied globally.

http://en.wikipedia.org/wiki/State#Usage

So, I'm voting for country relation by using it in our parts of the wood. :)

Stefan

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)

[Martin Trautmann]

Karl Newman wrote:
> To me, the nodes and ways
> should follow the physical world as much as possible--the road didn't change
> just because the speed limit changed, so why chop it up?

I changed the subject now - and I agree, roads should be kept as roads. 
The more details you add, the more fragments you would get. When a 
proprety of the road at its full length does change, you have to adjust 
every single piece.

There are occasions where a certain split has to be done. Take e.g. a 
national route which passes several cities. It could be called e.g. "B3" 
(which would be the German Bundesstraße 3) which is several hundred 
kilometers long and passes through dozens of towns and villages. 
Whenever the town boarder is reached, the B3 may follow a line of 
residential roads. I feel that a split is required here - the full 
length of the road can be found by the ref tag.

BTW: I learned recently that those national roads no longer have 
kilometer markings for the full length. When this road is changed e.g. 
to a bypass, the kilometers would have to be repositioned. Thus nowadays 
those roads are split to segments and (kilo)meters are measured relative 
to the border of the segment:



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)

[Frederik Ramm]

Hi,

> If we add a thing like segment relations as is proposed, we'll 
> effectively end up with another level next to points, segments and 
> relations (since things like route relations will again have these 
> segment relations contained in them), which will likely increase 
> complexity a lot in my eyes.

Has anyone actually proposed such a thing? That would indeed be
unnecessarily complex.

As far as I understand it, the idea is simply to qualify a tag with
start and end node. I.e. you have a way that goes from node A, B, C to
Z, but from B to D and from M to P it is a pedestrian road. So,

old scheme:

split way into 5 parts (3 non-pedestrian, 2 pedestrian) and tag
accordingly.

scheme with "superway" relation:

split way into 5 parts and create one relation to contain them all;
add all common tags to relation; add pedestrian tag to 2 ways.

scheme with "qualified tag" relations:

do not split way. create two relations that each contain the way, plus
the start and end node (B/D for relation 1 and M/P for relation 2),
plus the special tag (pedestrian).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)

[Ben Laenen]

On Monday 11 February 2008, Karl Newman wrote:
> That seems like a reasonable approach--see my reply to Bernd's email
> in another forked thread. The way should be long, but not
> unreasonably so, and if the name or highway type changes, that seems
> like a logical place to split it.

I thought with the addition of relations we would go towards moving all 
information up from ways to segments. So instead of putting for example 
the street name in the way, put it in a relation (and that would 
immediately solve things like dual carriage ways or cul-de-sacs with 
the same street name, which need different ways anyway). If a road has 
a reference number, put it also in a relation together with all other 
roads with that reference, etc.

So, in my eyes it would be something like splitting ways up at all 
junctions (to my knowledge that also simplifies things for route 
planners), or on metadata changes like speed, and move info up if more 
than one way belongs to the same property.

If we add a thing like segment relations as is proposed, we'll 
effectively end up with another level next to points, segments and 
relations (since things like route relations will again have these 
segment relations contained in them), which will likely increase 
complexity a lot in my eyes.

Greetings
Ben

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)

[Karl Newman]

On Feb 11, 2008 10:36 AM, Martin Trautmann <[EMAIL PROTECTED]> wrote:

> Karl Newman wrote:
> > To me, the nodes and ways
> > should follow the physical world as much as possible--the road didn't
> change
> > just because the speed limit changed, so why chop it up?
>
> I changed the subject now - and I agree, roads should be kept as roads.
> The more details you add, the more fragments you would get. When a
> proprety of the road at its full length does change, you have to adjust
> every single piece.
>
> There are occasions where a certain split has to be done. Take e.g. a
> national route which passes several cities. It could be called e.g. "B3"
> (which would be the German Bundesstraße 3) which is several hundred
> kilometers long and passes through dozens of towns and villages.
> Whenever the town boarder is reached, the B3 may follow a line of
> residential roads. I feel that a split is required here - the full
> length of the road can be found by the ref tag.
>

That seems like a reasonable approach--see my reply to Bernd's email in
another forked thread. The way should be long, but not unreasonably so, and
if the name or highway type changes, that seems like a logical place to
split it.

Karl
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)

[Frederik Ramm]

Hi,

> The point is that for when part of a road belongs to a route, you'll
> either need to:

[...]

Ah, now I understand.

The main thing that was proposed is using relations for TAGS that are  
not valid for the whole length of a way. This would be modelled using  
a relation but that relation would not become member of anything;  
there would just be a relation saying "for this part of the way, the  
following tag is valid".

You're talking about qualifying not a tag, but a membership - you  
want to say "this way is part of that relation, but only from node A  
to node B". This could indeed lead to the creation of what you call a  
"segment relation". That would itself be a member of the route relation.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] relations in order not to fragment roads (was: correctly mapping avenues)

[Ben Laenen]

On Monday 11 February 2008, Frederik Ramm wrote:
> Hi,
>
> > If we add a thing like segment relations as is proposed, we'll
> > effectively end up with another level next to points, segments and
> > relations (since things like route relations will again have these
> > segment relations contained in them), which will likely increase
> > complexity a lot in my eyes.
>
> Has anyone actually proposed such a thing? That would indeed be
> unnecessarily complex.

The point is that for when part of a road belongs to a route, you'll 
either need to:

* split the ways at the start and end point of that route for the road 
and at the ways in between to the relation

* or we'll have to make a new segment relation with that part, and add 
that one to the route relation.

So that's what I mean with the extra layer of segment relations.

Greetings
Ben

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Relations + splitting ways on JOSM (was Re: Ways on bus route relations)

[Eduardo Habkost]

On Mon, Jun 16, 2008 at 03:04:33PM +0200, Ben Laenen wrote:
> On Monday 16 June 2008, Jo wrote:
> > What is a bit problematic with how it is done now, is that when one
> > splits a road that is already part of a relation. This other relation
> > becomes broken, so one should be careful to fix it/them as well.
> 
> If you split a way which is a member of a relation in Potlatch, both 
> parts will be part of that relation after the split. That's exactly how 
> I'd expect it...

This is what I would expect to happen, too. But I have just tested it
and it didn't happen on JOSM (Version 645). Can we say this is a bug?

-- 
Eduardo

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Relations + splitting ways on JOSM (was Re: Ways on bus route relations)

[Eduardo Habkost]

On Mon, Jun 16, 2008 at 10:15:14AM -0300, Eduardo Habkost wrote:
> On Mon, Jun 16, 2008 at 03:04:33PM +0200, Ben Laenen wrote:
> > On Monday 16 June 2008, Jo wrote:
> > > What is a bit problematic with how it is done now, is that when one
> > > splits a road that is already part of a relation. This other relation
> > > becomes broken, so one should be careful to fix it/them as well.
> > 
> > If you split a way which is a member of a relation in Potlatch, both 
> > parts will be part of that relation after the split. That's exactly how 
> > I'd expect it...
> 
> This is what I would expect to happen, too. But I have just tested it
> and it didn't happen on JOSM (Version 645). Can we say this is a bug?

Oh, it is a bug: http://josm.openstreetmap.de/ticket/701

-- 
Eduardo

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk