Re: [OSM-talk] Relations not always brilliant
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
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
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
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
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_adrmop=aqmapstate=6;15.282434534059728;59.133863881839446;s;15.248667763412294;59.14890027267818;15.316133905963355;59.118827491000715;1001;842mapcomp=;;0;00stq=0 Google Maps says 51 goes east-west only, not north, http://maps.google.com/?ie=UTF8ll=59.13421,15.289536spn=0.033025,0.090637z=14 Multimap agrees with Google, http://www.multimap.com/maps/#t=lmap=59.13084,15.28539|14|4loc=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
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
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
-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
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
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
-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
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
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
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
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
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
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
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 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
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
Re: [OSM-talk] Relations not always brilliant
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 its 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 dont 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
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
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
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
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
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
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
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
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
-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
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
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
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
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
-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
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
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
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
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
-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
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
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
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
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
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
-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
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
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
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
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
