Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
Frederik Ramm wrote: On 01/24/2012 04:27 PM, Jukka Rahkonen wrote: We will see much more proprietary keys in the future because people are importing huge amounts of spatial data from external sources. Maybe we should simply stop them from doing that? Much of that data is hard or impossible to update by OSM contributors but new updates will be offered from the original sources. That sounds like a perfect reason to not import. Topological data and landuse data are some examples. Corine land cover will be updated this year, 9 gigabytes of topological vector data from the National Land Survey of Finland will be free under attribution-only license in May and so on. All that should not be in OSM. Actually this is probably a perfect example of the sort of stuff that SHOULD be available as secondary layers? Like the contour information on freemap would be nice as a selectable layer. But what we have always been missing is a clean way of cross referencing objects which UUID was intended to provide. While the page has been marked for deletion, much of the detail IS still documented such as http://wiki.openstreetmap.org/wiki/Key:uuid/Proof_of_Concept and the other uses of uuid's with other datasets. Using node and way numbers are not stable enough as cross-references? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://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/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
On Tue, Jan 24, 2012 at 9:38 AM, Jochen Topf wrote: > On Tue, Jan 24, 2012 at 03:27:00PM +, Jukka Rahkonen wrote: >> We will see much more proprietary keys in the future because people are >> importing huge amounts of spatial data from external sources. Much of that >> data is hard or impossible to update by OSM contributors but new updates >> will be offered from the original sources. Topological data and landuse >> data are some examples. Corine land cover will be updated this year, 9 >> gigabytes of topological vector data from the National Land Survey of >> Finland will be free under attribution-only license in May and so on. In such >> situation people start thinking about adding source-IDs as OSM tags in a hope >> that some part of the data could be more or less automatically updated on >> the OSM side later. > > I don't know of any case where people have actually done that, ie. imported > data and then later checked and updated it from a new version of the import > source. > > Importing is difficult enough to do properly and I think updating that data is > even more difficult to do. I hope somebody actually tries this in some corner > so that we get some idea how useful this actually is and how well it can be > done. When we have some experience we can decide whether it actually makes > sense to dump huge amounts of source IDs and other data related to the sources > in OSM. I think people keep assuming that "someone will figure this out at some point" and completely skip over considering the issue of updates when they import. And it's not just a matter of having source IDs. What about data that has been updated by a human? It is entirely possible that the edit was accidental or mistaken. But then again maybe not. So now you have data you don't want to touch for fear of overwriting someone's edit. But then that might break things in the rest of the external data you are trying to update. So it's a mess. But people are sticking their heads in the sand and ignoring it. Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
On Tue, Jan 24, 2012 at 3:38 PM, Jochen Topf wrote: > Importing is difficult enough to do properly and I think updating that data is > even more difficult to do. I think it would make more sense for some kinds of data (particularly, the more "volatile" ones) to have map servers that can gather data from multiple data servers (i.e. OSM and whatever the imports would otherwise have been from) and combine it to present it as a single data stream (probably in an OSM-defined format). Similar ideas have been in use in bioinformatics for some time now; for example, see http://www.biodas.org/wiki/Main_Page (DAS is Distributed Annotation Server). Perhaps we could get ideas from them. __John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
On Tue, Jan 24, 2012 at 03:27:00PM +, Jukka Rahkonen wrote: > We will see much more proprietary keys in the future because people are > importing huge amounts of spatial data from external sources. Much of that > data is hard or impossible to update by OSM contributors but new updates > will be offered from the original sources. Topological data and landuse > data are some examples. Corine land cover will be updated this year, 9 > gigabytes of topological vector data from the National Land Survey of > Finland will be free under attribution-only license in May and so on. In such > situation people start thinking about adding source-IDs as OSM tags in a hope > that some part of the data could be more or less automatically updated on > the OSM side later. I don't know of any case where people have actually done that, ie. imported data and then later checked and updated it from a new version of the import source. Importing is difficult enough to do properly and I think updating that data is even more difficult to do. I hope somebody actually tries this in some corner so that we get some idea how useful this actually is and how well it can be done. When we have some experience we can decide whether it actually makes sense to dump huge amounts of source IDs and other data related to the sources in OSM. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
On Tue, Jan 24, 2012 at 03:59:51PM +0100, Janko Mihelić wrote: > 2012/1/24 Pieren > > > > > I could add another one : "delete what is beyond understanding". > > Because your principle is against another one : "verifiability". > > Because your principle - if it is tolerated - might end up with > > elements tagged with dozen references to external applications and the > > readable tags will disappear in the number. > > > > Pieren > > > > > Let us add another one: "Delete only after trying to contact the author for > a period of time no shorter than xy". > Community is the most important thing here. Someone in the community knows > what those tags should mean. Find them and argue your points. If the author made no effort to document their special tags and the tags look non-sensical to me, I don't see why I have to spent the time finding those people and argue with them. In most cases it will probably been an error or some trial anyway and people will not care about those tags. OSM is not a dumping ground for everybodies personal data. OSM is a community effort so if you add unusual data you should discuss it beforehand with the community and document it for the community. I am not talking about somebody inventing a new kind of amenity=something tags. Thats fine and people don't have to discuss this kind of thing to death before using it. But if somebody wants to add lots of XZ:ID:BLUB=1235656 tags to the database they should discuss that. We trust users to decide what is useful for OSM and add and change anything in OSM. We trust them to take proper care. We should also trust them to remove things entirely that make no sense having. With the proper care, of course. So I suggest the rules to be: * If you care for your tags, you should document them. That way they will look useful to more people. It also allows the community to have a discussion based on facts to decide whether some data is useful for OSM. * If you care for OSM you are encouraged to clean up the database whenever you encounter rubbish. We trust the users to differentiate rubbish from useful stuff and do the right thing. The question what happens with document tags that are still rubbish is another one, that I will not address here. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
Hi, On 01/24/2012 04:27 PM, Jukka Rahkonen wrote: We will see much more proprietary keys in the future because people are importing huge amounts of spatial data from external sources. Maybe we should simply stop them from doing that? Much of that data is hard or impossible to update by OSM contributors but new updates will be offered from the original sources. That sounds like a perfect reason to not import. Topological data and landuse data are some examples. Corine land cover will be updated this year, 9 gigabytes of topological vector data from the National Land Survey of Finland will be free under attribution-only license in May and so on. All that should not be in OSM. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
Pieren gmail.com> writes: > > On Tue, Jan 24, 2012 at 12:42 PM, Jonathan Bennett > jonno.cix.co.uk> wrote: > > We have (or at least, should have) a simple principle in OSM: Ignore what you don't understand. > > I could add another one : "delete what is beyond understanding". > Because your principle is against another one : "verifiability". > Because your principle - if it is tolerated - might end up with > elements tagged with dozen references to external applications and the > readable tags will disappear in the number. We will see much more proprietary keys in the future because people are importing huge amounts of spatial data from external sources. Much of that data is hard or impossible to update by OSM contributors but new updates will be offered from the original sources. Topological data and landuse data are some examples. Corine land cover will be updated this year, 9 gigabytes of topological vector data from the National Land Survey of Finland will be free under attribution-only license in May and so on. In such situation people start thinking about adding source-IDs as OSM tags in a hope that some part of the data could be more or less automatically updated on the OSM side later. -Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Big Blue Something in Colombia
David Groom wrote: >I thought I'd wait till the next set of the coastline error checker >files [1] which should be next week, check if there are no major >problems, and then suggest to the sys admins that the coastline >shapefiles be updated. Looking (e.g.) at http://www.openstreetmap.org/?lat=6.749&lon=-73.928&zoom=10 and http://www.openstreetmap.org/?lat=41.145&lon=66.528&zoom=9&layers=M it seems someone has done so last night. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
2012/1/24 Pieren > > I could add another one : "delete what is beyond understanding". > Because your principle is against another one : "verifiability". > Because your principle - if it is tolerated - might end up with > elements tagged with dozen references to external applications and the > readable tags will disappear in the number. > > Pieren > > Let us add another one: "Delete only after trying to contact the author for a period of time no shorter than xy". Community is the most important thing here. Someone in the community knows what those tags should mean. Find them and argue your points. Janko ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
On Tue, Jan 24, 2012 at 12:42 PM, Jonathan Bennett wrote: > We have (or at least, should have) a simple principle in OSM: Ignore what you > don't understand. I could add another one : "delete what is beyond understanding". Because your principle is against another one : "verifiability". Because your principle - if it is tolerated - might end up with elements tagged with dozen references to external applications and the readable tags will disappear in the number. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Check my junctions - looking for someone to review my plates of spaghetti -- responding to feedback
On 1/24/2012 9:20 AM, Anthony wrote: On Tue, Jan 24, 2012 at 8:45 AM, Nathan Edgars II wrote: On 1/24/2012 8:33 AM, Anthony wrote: On Tue, Jan 24, 2012 at 7:31 AM, Nathan Edgars II wrote: I don't know about Pennsylvania, but here in Florida a single white line does not legally prevent crossing. But even if it did, we don't map a double yellow as a median. *You* don't map a "double yellow" (I assume you mean a double double yellow) as a median. No, I mean a double yellow. As in do not pass. That doesn't legally prevent crossing either. It does if there are no intersections nearby. (Any other exceptions, such as passing an obstruction, would also apply to crossing a double white.) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
On Tue, Jan 24, 2012 at 11:22 AM, Martin Koppenhoefer wrote: > the concept seems to be documented here: > http://wiki.openstreetmap.org/wiki/Proposed_Features/UUID I don't see any mention of what should happen to UUIDs attached to ways, when ways are split or merged. Should this be coded explicitly in editors? In which case, it makes sense to push all such "external linking" tags to use UUIDs, so that they are handled consistently when the map is edited, without editors having to make special provision for all known external linking tags. __John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Check my junctions - looking for someone to review my plates of spaghetti
On 1/24/2012 8:45 AM, Anthony wrote: On Mon, Jan 23, 2012 at 11:20 PM, Nathan Edgars II wrote: On 1/23/2012 9:52 PM, dies38...@mypacks.net wrote: Yuck. A separate way should not be used for a turn lane (unless that lane is separated by barriers or maybe a wide striped-off area). Corollary: a separated right-turn lane begins and ends approximately where the traffic island begins and ends, not where the separate lane begins and ends. Better fix this: http://www.openstreetmap.org/?lat=27.987056&lon=-82.5464&zoom=18&layers=M Yawn. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
Martin Koppenhoefer wrote: > 2012/1/24 Jonathan Bennett : > > On 24/01/2012 11:22, Martin Koppenhoefer wrote: > >> I wonder if this kind of tagging should be tolerated. In the wiki I > >> found no documentation regarding this tag, and therefore this data > >> seems unusable for most mappers. > > > > Perhaps not, but systematically removing it won't improve anything > > (since most apps will just ignore the tags), and will actually > increase > > the amount of storage needed (since a new version of the objects in > > question will be created). > > > > We have (or at least, should have) a simple principle in OSM: Ignore > > what you don't understand. That applies to mappers and to > applications > > using the data. The alternative is edit wars where one mapper things > a > > particular tag -- that otherwise does them no harm -- is "wrong" and > > starts removing them and their creator puts them back. > > > While I understand the idea behind (deletions also occupy space/need > computing power, at least if performed via the API), I still feel that > we should have a policy to request tags and values to be human > readable. > > How would you improve / modify (say split) an object where you don't > understand part of the tags applied to it? > > Imagine that this tendency grows stronger and a few imports later our > db would have more crypted keys then "readable" ones. If osm is about > open data, it should be really open, not only freely available but > unusable because crypted. Why should we use free and open ressources > to distribute free-but-not-open content? > > cheers, > Martin > In cases where data is arranged in multiple tables, and the purpose of a particular field is to link two tables together, rather than directly describing an attribute, it is best to use an otherwise-arbitrary numeric value as the link value. That way, updating the descriptive fields doesn't break the link. Also, it is best to have an attribute described in just one of a group of associated records; otherwise, it is easy to get contradictions. -- John F. Eldredge -- j...@jfeldredge.com "Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
Hi,
On 01/24/12 14:35, Martin Koppenhoefer wrote:
How would you improve / modify (say split) an object where you don't
understand part of the tags applied to it?
I agree but would like to point out that this problem applies to
properly documented tags as well - there are quite a few interesting
proposals about tagging e.g. turn lanes at large intersections which
would lead to these junctions being un-understandable for the average
mapper. It is not sufficient to say "oh well the documentation is all
here" ;)
Imagine that this tendency grows stronger and a few imports later our
db would have more crypted keys then "readable" ones. If osm is about
open data, it should be really open, not only freely available but
unusable because crypted.
Crypted is perhaps not the right word here because even if the tag says
clearly what it is ("freds_internal_place_database_id=1736253") it might
still be of little use for anyone who has no access to Fred's internal
place database.
Bye
Frederik
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Check my junctions - looking for someone to review my plates of spaghetti -- responding to feedback
On 1/24/2012 8:33 AM, Anthony wrote: On Tue, Jan 24, 2012 at 7:31 AM, Nathan Edgars II wrote: I don't know about Pennsylvania, but here in Florida a single white line does not legally prevent crossing. But even if it did, we don't map a double yellow as a median. *You* don't map a "double yellow" (I assume you mean a double double yellow) as a median. No, I mean a double yellow. As in do not pass. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
2012/1/24 Jonathan Bennett : > On 24/01/2012 11:22, Martin Koppenhoefer wrote: >> I wonder if this kind of tagging should be tolerated. In the wiki I >> found no documentation regarding this tag, and therefore this data >> seems unusable for most mappers. > > Perhaps not, but systematically removing it won't improve anything > (since most apps will just ignore the tags), and will actually increase > the amount of storage needed (since a new version of the objects in > question will be created). > > We have (or at least, should have) a simple principle in OSM: Ignore > what you don't understand. That applies to mappers and to applications > using the data. The alternative is edit wars where one mapper things a > particular tag -- that otherwise does them no harm -- is "wrong" and > starts removing them and their creator puts them back. While I understand the idea behind (deletions also occupy space/need computing power, at least if performed via the API), I still feel that we should have a policy to request tags and values to be human readable. How would you improve / modify (say split) an object where you don't understand part of the tags applied to it? Imagine that this tendency grows stronger and a few imports later our db would have more crypted keys then "readable" ones. If osm is about open data, it should be really open, not only freely available but unusable because crypted. Why should we use free and open ressources to distribute free-but-not-open content? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Big Blue Something in Colombia
- Original Message - From: malenki To: talk@openstreetmap.org Sent: Monday, January 23, 2012 6:43 PM Subject: Re: [OSM-talk] Big Blue Something in Colombia bastien wrote: Have a little look in talk-co, Thanks for the hint, but my knowledge of Spanish consists of three to five words. ;) Someone call David repair the error, a way with costline attibute. That would be me :) Maybe thats why I couldn't find a possibly guilty coastlines at the region underwater. We need to wait now. One more¹ reason to reprocess the coastline shapefile. I've been doing a lot of tidying up coastline data throughout the world in the last month, and although I'm pretty sure that I have not created any further errors, some of the areas which needed tidying were quite complex, and an error or two may have crept in. I thought I'd wait till the next set of the coastline error checker files [1] which should be next week, check if there are no major problems, and then suggest to the sys admins that the coastline shapefiles be updated. It would be a pity to update the shapefiles now to fix the issue in Colombia, only for issues to appear elsewhere on the map. If I had the bandwidth I'd download the planet file and produce the error checker files myself, but I'm afraid its not really practical for me to do that. Regards David [1] http://metro.teczno.com/#coastline Regards malenki ¹ http://www.openstreetmap.org/?lat=41.145&lon=66.528&zoom=9&layers=M ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti -- responding to feedback
On 1/24/2012 7:07 AM, dies38...@mypacks.net wrote: Thanks for your feedback, both positive and negative. The reason for the complexity and seeming overuse of ways and restrictions is that I am mapping legally binding pavement markings along with the actual travel ways. It is my understanding that pavement markings are as enforceable as stop signs and traffic lights and, therefore, are subject to key:access type treatment, such as through use of turn restriction relations. I don't know about Pennsylvania, but here in Florida a single white line does not legally prevent crossing. But even if it did, we don't map a double yellow as a median. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti -- responding to feedback
(my e-mail provider does not support threading) Thanks for your feedback, both positive and negative. The reason for the complexity and seeming overuse of ways and restrictions is that I am mapping legally binding pavement markings along with the actual travel ways. It is my understanding that pavement markings are as enforceable as stop signs and traffic lights and, therefore, are subject to key:access type treatment, such as through use of turn restriction relations. Could you consider my request for feedback along with this additional information? Thanks for your (continuing) help. --user ceyockey ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "proprietary" keys and values, machine readable vs. humans
On 24/01/2012 11:22, Martin Koppenhoefer wrote: > I wonder if this kind of tagging should be tolerated. In the wiki I > found no documentation regarding this tag, and therefore this data > seems unusable for most mappers. Perhaps not, but systematically removing it won't improve anything (since most apps will just ignore the tags), and will actually increase the amount of storage needed (since a new version of the objects in question will be created). We have (or at least, should have) a simple principle in OSM: Ignore what you don't understand. That applies to mappers and to applications using the data. The alternative is edit wars where one mapper things a particular tag -- that otherwise does them no harm -- is "wrong" and starts removing them and their creator puts them back. -- Jonathan (Jonobennett) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] "proprietary" keys and values, machine readable vs. humans
Looking at the fantastic taginfo reports [1] I noticed some tags that
link presumably proprietary databases to OSM from inside the OSM-db:
e.g. this one: http://taginfo.openstreetmap.org/keys/%25kml%3Aguid#values
with values like:
{a2ec06ed-792a-4495-9218-8b2a394c4163}
I wonder if this kind of tagging should be tolerated. In the wiki I
found no documentation regarding this tag, and therefore this data
seems unusable for most mappers.
There are other tags with similar values which are much more in use already:
http://taginfo.openstreetmap.org/keys/import_uuid#values
http://taginfo.openstreetmap.org/keys/uuid%3Abuilding#values
...
the concept seems to be documented here:
http://wiki.openstreetmap.org/wiki/Proposed_Features/UUID
cheers,
Martin
[1] http://taginfo.openstreetmap.org/reports/characters_in_keys#problematic
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti
Hi, On Tue, Jan 24, 2012 at 3:52 AM, wrote: > Over the past couple of months, I have armchair-mapped several highway > junctions in the United States which are "commonly complex" in that they > involve multiple turn restrictions, street name changes and pedestrian > crossing placements. > > I would like to have some critique from someone experienced in mapping such > junctions so that I ensure I am following current best practice and am not > just creating a bunch of plates of unpalatable spaghetti. > > Two recent junctions are found in the following permalink views > * http://www.openstreetmap.org/?lat=40.095879&lon=-75.296179&zoom=18&layers=M > * http://www.openstreetmap.org/?lat=39.128273&lon=-77.237731&zoom=18&layers=M > Although the effort to map these intersections in detail is commendable, I have to go with the previous responses in terms of mapping practices. But instead of just reverting stuff as was also suggested, I prefer to have a discussion here so we all learn something. So definitely bring your questions here or to the tagging list. On turn restrictions: the turn restriction relation indicates, as the name implies, restrictions on the directions you are allowed to turn. You seem to want to indicate the direction of a turn lane with them, which is not the appropriate use. In my view, there is a case to make for appropriately using turn restrictions in this type of situation: where connector lanes (_link) cross at level or join the main road, if and only if a turn restriction is not implied (because of one_way restrictions). See http://www.openstreetmap.org/?lat=40.782409&lon=-111.910731&zoom=18&layers=M for examples. Used like that, http://www.openstreetmap.org/browse/node/728096876 could do with a few. -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Road cores and casings on standard Mapnik rendering
On 1/21/2012 6:03 AM, Richard Mann wrote: The current tagging rules for links don't make life at all easy for the renderer, but I got flamed when I suggested that the "link" road should take the status of the lower classification (unless it's a motorway_link). I agree that taking the status of the lower makes sense if it's a typical intersection bypass (right turn in the US, left turn in the UK). But if e.g. a trunk has a full motorway-style interchange with a lower-classification road, I'll use trunk_link. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Road cores and casings on standard Mapnik rendering
On 1/21/2012 12:05 AM, Ben Robbins wrote: http://wiki.openstreetmap.org/w/images/2/21/Comparison_-_Junction1.png Just a minor issue - shouldn't the primary_link and unclassified near the upper right corner be motorway_links, since you can only access them from the motorway? Otherwise, this is basically how I tag (though (a) I don't name links and (b) I'd probably change the northwest-southeast road to secondary where the ramps come off). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
