Interesting. I wish people would put up house numbers around here. It’s amazing how many houses are missing a house number or name.

Us Brits don’t really see the English language as a fixed language and as such we have a strong element of creeping Americanisms. I expect most people will not spot them - just a small proportion of people will. This is evident in the fact that the official English in the European Union is British English and even they get it wrong all too often.

My other concern is that OSM has traditionally been against automated edits of tags. As such, I feel that I should not change tags even when they only occur a few times in our data.

Finally it is often easier to accept these tags without challenging them at the risk of making OSM appear to be a “British only project”.

Good luck though :-D

Directions are coming. See the demo site at http://jsrouting.apis.dev.openstreetmap.org/

Gradually other things may get added, but as noted the OSM Foundation don’t want to put off third parties from doing this. I find that OpenStreetMap is becoming better known now through our data users (e.g. the many iOS and Android apps that use OSM data).

Ulamm,

No worries. I’m happy to help :-) Tagging is quite a complex thing to get right when you start to look at all the different things OpenStreetMap contributors want to add. The “restrictions” tags now follow a standard format:

1. Basic restrictions
These are the ones most people are used to. For example:

access = no
maxspeed = 60
oneway = yes

2. Intermediate restrictions
These are of the format <restriction>:<transport mode>:<direction>=<restriction value> with the tag including either <transport mode>, or <direction>, or both. For example:

maxspeed:hgv = 40
oneway:bicycle = no
maxspeed:forward = 50 (in the case of different maxspeeds for each direction of travel - forward meaning in the same direction that the way is drawn on OSM)

Note that this means that when someone tags bicycle=no they actually mean access:bicyle=no. However due to the long-standing use of <transport mode>=* these shorter versions are more common (new tagging schemas aim to be backward compatible).

3. Advanced conditional restrictions
These are used when there are conditions set on the restriction (e.g. the restriction only applies during certain hours / when the road is wet / etc).

They build upon the format in 2 above. You can read more at: osm.wiki/Key:conditional

Hmm, what’s going on with my formatting. Lets try again:

If it’s not clear, how to tag a oneway street that is bidirectional for cyclists, let me just recap:

• You draw a way (line) representing the street.
• To this line you add both tags “oneway=yes” and “oneway:bicycle=no” (plus the highway=* tag to identify what type of road it is.

Hi Ulamm,

It’s it’s not clear, how to tag a oneway street that is bidirectional for cyclists, let me just recap: * You draw a way (line) representing the street. * To this line you add both tags “oneway=yes” and “oneway:bicycle=no” (plus the highway=* tag to identify what type of road it is.

The way it works is that there is a transport hierarchy [1]. The first tag (oneway=yes) marks the road as oneway for all traffic, and the second tag (oneway:bicylce=no) in effect removes the oneway obligation for bicycles.

I hope that helps.

Oh and just to clarify, OpenStreetMap is not a Californian project. Legally it is registered in the UK, but it has no office, no paid employees. It’s a community project run by ordinary folks. The tags we use have been decided through open community involvement. Using something other than these tags makes it harder for our data consumers to use. For example, Richard who first replied to you has built a cycle website that uses OpenStreetMap data to build a cycle routing map [2]. Richard would not have been able to do this if everyone used different tags.

[1] See the diagram for the transport hierarchy - osm.wiki/DE:Key:access [2] http://cycle.travel/map

I get the impression that Google only map the bus stops and not the full route (that’s why the public transport routing shows straight lines between places rather than following the route of the road). On the other had where we have a mapper who is able and willing to keep route data up to date, then I see no reason not to include it in OSM.

Anyway, thanks for your thoughts - in OSM it can be quite tricky to get an experts opinion at short notice when tagging schemes are being developed.

Ah that’s how you do it. With the old ?lat… style rather than the # style.

Thanks Simon.

Will aim to add it to the Mappa Mercia site.

Obviously that should read “bus routes are quite a complex thing to map”. Long day.

Looks great. Welcome to the OpenStreetMap community. Bus routes are quick a complex thing to map in OpenStreetMap and trying to keep track of changes to the route is equally difficult. Perhaps that’s one way in which you could feed back into the data??

The other way is to provide some thoughts on how you think bus stops should be mapped. We currently have two alternate schemes. The first simply recommends mapping the bus stop beside the road, the other is a bit more complex as it recommends mapping the bus stop beside the road and as a point on the road where the bus actually stops (then joining the 2 into a relation/grouping). The idea behind this is essentially that public transport routing has a point to route to that is on a road (rather than just next to it). As a potential user of this data, which approach works best for you, or are they both just as good?

Openstreetmap decided to supply its maps in this way as they can be put on screen faster than calculating and drawing each screen individually.

That may change at some point in the future with the introduction of something called “Vector tiles” but acknowledging that would just over complicate your basic description without adding much to it.

Rob

@imagico: I wouldn’t say that it’s “clearly in violation”. It really comes down to how you interpret “reasonably calculated”. Alex has also set out in this post why they don’t link to the OSM copyright page (they need to show that the map is made up of several sources each with their own copyright).

I do tend to agree with you that https://www.mapbox.com/about/maps/ could be improved to focus more on the copyright (and OSM’s story), rather than being overly flashy.

On the other hand the Improve the Map page is really good. It get straight to the point: >This map is powered by Mapbox and based on data from OpenStreetMap, a community driven dataset.

https://www.mapbox.com/map-feedback/#lxbarth.i48g0o0p/-53.635/-4.872/5

Perhaps Mapbox’s copyright/about page could be more similar to the Improve the Map page.

Do any of the editors warn you if you try to upload a change that includes a lot of deletions?

Also, we have experienced mappers coming to the local mailing list to ask for a revert. It’s actually very easy to do with JOSM’s revert plugin.

Good work. I’ve got so used to having aerial imagery available, but if that’s not well aligned then the OSM data may be entered with a misalignment.

Lots of places could do with more GPS traces (particularly on side streets). There’s not much you can do about that - perhaps we could look at using OpenData as a reliable source calculate the imagery offset?

Regards, Rob

p.s. I think the wiki page could do with being a lot shorter. I’ve found that short quick reference pages with the detail available on sub-pages is best. Let me know if you want me to have a go at doing this (on my User page until you’re happy with it).

Start by cleaning up the public transport pages (leaving highway=bus_stop).

The public transport page on the wiki is an overview of the tags, yes, buts its data overload. It’s trying to do all things for all users. In my opinion it would help if it was written as a quick reference guide:

• here’s how to map a bus stop (no more than 3 simple steps).
• and for those folk who are interested, here’s a link to the full public transport schema.

One for buses, one for trains, etc..

Write the doc for the people you are trying to target (the mappers).

Here in the West Midlands of UK, the highway=bus_stop is used in the same way by all mappers - the position of the bus shelter/pole.

I get the problem that the public transport schema is trying to solve, but if after 3 years the tag is not well adopted, then you have a problem. Personally I would start by making the wiki pages a lot easier to read (shorter, basic example, separate pages for buses, trams, etc).

I’ve often thought “wouldn’t it be great if we could standardise X”, but I’ve now come to realise a few things:

• OSM is a big community. Getting everyone to change is near impossible.
• Tagging schemas are only as good as the people who get involved in writing them.
• Not many people read the wiki, the tagging mailing list, etc.
• Change that is not well communicated risks damaging the community.

This isn’t to say don’t attempt it. I’m just saying, it needs to be with the community.

Again are bus stops really something where you need a lot of beginners to contribute?

Yes. And I find it a bit rude that you think otherwise. Not everywhere has the level of detail of Germany and in my opinion we need all the mappers we can get.

How is highway=bus_stop better?

It’s simpler. It’s gives people the information they want (i.e. where is the bus stop for this side of the road). You only have to add one thing. When do you get a bus stopping somewhere other than right next to where the passengers are waiting?!

If I have a bus stop at X in the road, and the opposite bus stop is 10-20m further along the road then should I be adding 2 public_transport=stop_position tags? And how do we know which one relates to which direction of travel? You need to create a relation and add the appropriate stop_position for the direction of travel, right? If yes, then why not just do the same with highway=bus_stop and assume the stopping place is on the road adjacent to the bus stop?

Why is the stopping point even relevant to OSM? Only the bus driver needs to know this, so why tag for a single end user? Also, the stopping point for us bus is often marked as a rectangle on the road, so why only map as a node?

How should public transport be converted into a simple interface for iD?

If you search for Bus it could show you Bus Stop and Bus Platform

Fine, that gives you the options in iD but you still have to find a way to ensure they get used properly. For a new user (or infrequent bus stop mapper) they won’t know that “platform” gets mapped to the side of the road, whist “stop” is as a node in the road. Add to this the language barrier that many of our mappers will experience then the chance of success will fall even lower. You’ll end up with bad data in the public_transport tag. Perhaps then someone will create a new tagging system!!

Rant over!

Oh and one of the things that has always concerned me about the tagging system is that the people proposing new tags (and this includes me) might not be experts and often we assume the changes we make are for the better. But has anyone ever bothered to stop and ask our current and future end data users?? Telenav? Bus companies?

There is a balance you have to strike when trying to develop a tagging schema.

If you make it so simple that it’s obvious without having to look in the wiki then it many more people will help contribute data (and the map editors will be more likely to adopt it). Make it difficult, and you will reduce the number of people who are able to add the feature to the map. Worst still you end up splintering the way we map something.

Remember in iD tags are hidden. You mention the Opening Hours tag which is complex, but it could easily be added to iD (and other editors) via a really simple user interface. With such an interface, mappers will not need to know about the opening_hours tag. How should public transport be converted into a simple interface for iD? Stops as nodes on the way, platforms next to the way makes this task more challenging.

Rob

In my above comment, the line “If however this combination constitutes a Collective Databae then point applies” should read:

“If however this combination constitutes a Collective Databae then point 3 applies.” (note the missing “3”)