Recent diary entries
An action was started to promote uploading of tracks and POIs by overlanders as well as to extend the definition of campings as needed by overlanders. See for the discussion
In some rare streets, the driving side of the street can be inverted (usually to help the flow of traffic of adjacent streets). For example, in a country where right is the normal driving side, there may be some exceptional streets where left is the driving side.
This kind of exception can be mapped in OSM with the tag
Defines which side of the road vehicles must legally use.
As we draw close to 100% on the Rural Lesotho Task in the #MapLesotho initiative I find myself filled with very strong reaffirmation of the power of community and the many implicit and explicit benefits and values of crowdsourced engagement.
On the 16th of January at Fingal County Hall I participated in my third marathon for the #MapLesotho project. There was a full house for this event with the organiser working his usual magic to get involvement from a collection of fifth year students from a number of schools in the area as well as publicly minded volunteers who have been involved in this specific project or associated ones around Open Street Map. We were joined by volunteers participating from around the world: Canada, the US, Germany and of course stalwarts in Lesotho itself, to name a few identifiable ones. As we were closing in on having a publicly available, robust, complete basemap for the eastern half of Lesotho this day witnessed not just the completion of nearly 10% of the task but more importantly the infectious sharing of enthusiasm for the project and its ethos amongst all attending. As we all shared our own reasons for why and how we do what we do and what we have learned from the project, I watched those newly engaged lightening up with their own enthusiasm for the project, imagining what else might be accomplished with the raw mapping materials and being positive about what they themselves can contribute. It was truly striking and wonderfully energising to feel the positive energy in the room, on interaction through twitter and demonstrated most concretely by the placing of nodes and progress towards tasks.
I was privileged to work with some new converts to the cause and help them get them started with OpenStreetMap - what was involved, what tools were available and then to let them take it for themselves. They embraced the challenge with vigour and I was particularly impressed by how they helped one another as they got going and shared their own newly acquired skills with others. As the students around me moved along they gained in confidence and shared their experience helping each other along the way.
I had a number of thoughtful conversation with a particular student beside me who was helping his own colleague move from using IDEditor to JOSM aided by his own infectious enthusiasm for what the tool afforded him. He shared with me his reason for doing what he does and it cannot be expressed any more clearly: he gives of his time to help others help themselves. As he said this is not charity, this is enablement - it is starting a process that grows with its own generated synergy.
This is #MapLesotho. The achievements continue build and to speak for themselves.
Marina full, a happening place. People and staff friendly. Don't be fooled, there is no high speed internet as advertised. Nice facilities close to two working boat yards.
Today I put template route relations for itineraries of De Lijn and TEC on Dropbox. Generating them takes 2 hours. And then another 2 hours when I noticed Python hadn't actually compressed them. I'll update them as fresh data from De Lijn and TEC comes in.
I also worked on a script which you can run after opening such a file in OSM.
(no sound was recorded and I still have to add subtitles to them, some day)
The script will download all the stops. They are not included in the files. Once the stops are downloaded the view zooms to their extent.
Then the script will use an Overpass Query to download all route relations with the same ref as identifier. At the moment all over Flanders. I hope I'll find a way to limit it to the bbox you just zoomed to.
For all the nodes on the way, Overpass will download all the nodes which are within 30 meters (and all the ways and relations they belong to).
Now you'll have to run the compare script again. I didn't figure out yet, how to make the script wait until the download completes, so it'll give an error message saying it didn't find the master_routes it was looking for.
When run again, after the download is complete with not objects selected, it'll compare the template routes with the already existing routes. It uses the master_route relations to match them. If the existing routes don't belong to a master_route yet, you'll have to use the template and add the matching existing routes manually. You can leave the template routes, they'll be removed from the master as we progress. Select all the existing and the template routes and close the master route. Now run the compare script again.
You'll end up with a relation which has some funny looking roles. Each letter-number (a0w1i3) combination represents as stop. Now it becomes easier to see which template belongs to which existing route.
Select 2 routes which belong together and press the button to select them in the general window.
Move the window with all the routes out of the way.
Use the other script, which will add ways to the route. At first this script only added the ways adjacent to the stops. At some point I was thinking: why not try to look at the other route relations. Buses tend to all use the same itineraries to get from one stop to the next.
In the mean time the script also copies tags and stops from the template to the existing route relation and it odbl=new. This has the effect that it's shown more prominently with help of MapCSS. Nothing to do with the license. That tag is only used, as it won't 'survive' during upload.
Also the template routes came in tagged with odbl=tttttt. This is what the script uses to identify them as templates.
I'll have to write some posts about how to set up JOSM to enable everybody to use those scripts, the MapCSS and add handy buttons for search and one click presets to the toolbar. One of these days...
I am exploring OSM and the rendering toolchain in particular. I want to contribute in the project and start from addressing a less critical issue or bug. Could you give a pointer for this. Are there meet-ups happening in Bangalore (India) or anybody here from OSM or mapnik/mod_tile team. Thanks -Rajeev
I'm writing this entry because what began as typing a comment on this diary entry started getting a bit long.
Addressing is a lot of work. Not just the initial collection, but then you get into the whole "map gardening" discussion - maintaining what has already been mapped as opposed to (or perhaps as well as) mapping new stuff. Locally we've started watching local authority planning decisions and using the relatively new notes feature to record where needs surveying to see if and when things change. But we've been collecting addresses for about 5 years, and weren't doing this at the start. Only today in a discussion about non-shop laundrys (for hotels and restaurants) I checked a couple I had mapped and found one got planning permission a year or two back to be replaced by a block of flats (we missed that one). So another re-survey needed. And only this morning I was adding some new builds I finally got around to re-surveying at the weekend that had been previously added as construction areas a couple of years ago.
I now use OsmAnd and always love it when it can direct me to an address rather than a road, which is why I want to get local addresses as complete as I can, though I started collecting addresses before I could use the data. Initially it was when collecting my step-daughters from my friends' houses in the dark I wanted to be able to check OSM before setting out to see what end of, and which side of, the street to find them. It took a long time to join all those little random patches of addresses together.
Addresses are the places people want to go; roads are the way they get there. OSM needs both. I think it will take time, but as tools evolve and we continue to grow hopefully the pace will also increase. I think Robert Barr said during his 2013 State of the Map presentation that at the then level of address coverage it would take another 200 years to finish collecting UK addresses. I hope it is quicker than that.
People sometimes ask me: why add all these route relations to Openstreetmap, when De Lijn already has them as shape files?
For one thing, De Lijn cannot share them with us. A good example is the following:
If you click through to one of the other lines, change the url so it has &style=wuppertal once again at the end. Also keep in mind not each and every line is already mapped, although we're doing quite well in Oost-Vlaanderen.
Another example is a map I rendered where I'm combining the PT network (pink on the background), the walking nodes network (orange) and the route I wanted to talk about:
Only, say 10 years ago, creating such a map would have been an impossible endeavour. It's important for the explanation on this site:
To be able to show where the bus stops are and the walking node numbers are used in the directions, but not exactly used the way they were meant to be used... only to help point people in the right direction, instead of following them from node to node.
Incidentally you'll have to have a look at the Dutch version of the article to see the map used. The English version uses Openstreetmap too, but in a more dynamic way.
Two weeks ago Steve Coast held an AmA (Ask Me Anything) on Reddit. I've selected and rearranged some of his answers for this post, since he rarely expresses his point of view on lists or anywhere else.
Also, he agreed to participate in next week's Russian OSM Radio (in English, of course). You can submit your questions during the broadcast (22nd of January, 20:00-21:00 UTC) on #osm-ru IRC channel.
mr_gila: What inspired you to start up OSM?
There's a few different answers to that question. On one level, it was just kind of obvious. Back then, in 2004, Wikipedia was hot new technology and the wiki idea in general was spreading. Why not apply it to maps?
On another level, I had an old laptop with Debian Linux on it and a USB GPS device. I tried to use some mapping software but there were no maps. So why not make them?
On another level, the maps that were available in the UK and Europe tended to be very proprietary and expensive. So why not open them up?
On another level, I was young and naive.
Let's not forget though that OSM is now many, many people from all over the world. It wouldn't have worked if I hadn't convinced a lot of people to join in and help.
mapsandmapsandmaps: How did you find your time studying at UCL, and how much of an impact do you think this lead into you founding OSM? Does it feel strange that it has become a big topic of academic research with people like Muki Haklay writing papers about it?
UCL. I was working in a couple of PhD research labs and not paying much attention to studies. That mean I had the time and resources (computers with direct access to the internet, no NAT!) to go do OSM and other things.
Muki was in one of those research labs (as was Paul Torrens, Martin Dodge, Sean Gorman and others), so it's not entirely strange.
ManAboutCouch: Half-jokingly, how has OSM managed to get this far without a properly defined Polygon feature type?
OSM has succeeded, I think and in part, precisely because the data model (and other things) are/is so simple. When I started it, there were various calls for OSM to use all kinds of complicated schemas (like WFS). You'd blow your brains out just reading the specification. OSM to me in many ways was a people problem not a technology problem, and it's easier to fit the technology to the people (e.g. OSMs simple models) than it is to convince people to go use WFS.
NorbitGorbit: If you had to redo the map project from scratch, what sort of system would you use or design to handle crowdsourcing map data?
I think I'd pretty much do it the same with some tweaks.
I'm trying to be careful to assign credit. The addition of change sets and relations for example. I had similar ideas but I didn't implement those, and they're critical.
I think exploring tags beyond just keys and values, since we hack in third values by doing things like "addr:housenumber=42" for example.
Beyond the data model itself, waze really nailed some aspects of crowd sourcing. The human element of getting people to contribute certain things.
dv7d: Do you map? What do you like to map the most?
Yes I still map under a variety of usernames. I've been attacking addressing to get a feel for the complexity of it. I used to spend a lot of time cleaning up TIGER data. Map roulette is a good way to find random things to fix in the map: http://maproulette.org
GregZorz: What would you say to someone responding that your use of multiple accounts waters down ability to check authenticity/reliability of edits?
i'd say in the general case you're right but as the founder I've had satirical fake blogs set up about me, people follow me and other internet weirdness. So I take a degree of anonymity.
ManAboutCouch: Hi Steve, you're on record saying that you think the next big challenge for OSM is address data. Given the myriad of address systems in use across the globe, and how this is often perceived as 'less fun' than adding other features to the map, how do you see this challenge being met?
Frankly it's hard to see it happen within OSM any time soon. Addressing requires some bold moves. For example, only show roads on the OSM website which have addresses. That would instantly make the world go blank, and create a lot of pressure to add address data, similar to how OSM was 5-7 years ago but with more people and resources. That kind of bold move is unfortunately hard to make happen these days.
edparsons: Looking forward to the book, but to preempt it - Are there any decisions you made in the early days you now regret ?
I'll split this in to two. Mistakes and regrets.
Mistakes abound. OSM could have had an exit like waze. Segments (a data model we had prior to ways) diverted energy away. Trying to run mapping parties by telling people where or what to map rather than letting them self-select. Calling it OpenStreetMap when it's much more than streets.
Defining "mistake" would take too long, but we should note that many of these things are only mistakes when viewed under a certain light. Mistakes of some kind are inevitable when doing something new. I'm happy making mistakes because it means I'm learning something. What I discovered is that this doesn't apply to most people, for whom mistakes or even trying something which has a chance of becoming a mistake is... not something you do.
Which brings me to my only regret: Giving up too much power. I thought that everyone in the world thinks like I do, and would also give up power and try new things like I did. That for the most part simply didn't happen. It's worked out very well, and the people are great, and OSM hums along... but the days of taking big bets and risks is over. That drives me nuts, since there's so much more out there to do with open mapping than just making the map slightly better every year and running another conference. For example, addressing.
We've done very well, as you know. We blazed a trail for others to follow too. I just have a much higher set of ambitions, including OSM being "done" by now (which would include addressing, of course).
dalek2point3: Steve -- are you saying that you wished that OSM had gone down the route of for-profit crowd sourcing a la Waze, rather than non profit a la Wikipedia? Have you thought about these two modes and pros and cons of each?
That's why I mentioned "certain light" above, there are tradeoffs here. Being able to monetize would speed things up. It doesn't have to be all or nothing, open or closed. You can make data open after two years, or something.
The downside is you don't get the same unexpected use cases like the Humanitarian OSM Team going and saving the day in Haiti.
GregZorz: Forget mental regrets... looking back 10 years, is there a physical item(s), or data from a specific trip, you wish you you kept/saved/rescued?
I tend to throw things away. I remember the anecdote that when Jobs went back to Apple in '97 they had an Apple Museum with all the old computers and stuff in it. He closed it down. Or as I think Gates said, he doesn't spend a lot of time looking in the rear-view mirror.
I find those items like mapping t-shirts, paper maps, conference pens, old GPS units tie me to a past that is gone anyway. I'm much more interested in the future.
smellsliketuna: Do you get a lot of people pitching you on ways to leverage your previous mapping project, for for-profit ventures? It would seem to be a logical choice, given your knowledge and experience.
Yes - I'm on a few different advisory boards now for example. Notably Auth0 and ParkNav, the others are stealth.
mapsandmapsandmaps: What's your opinion on the open/proprietary software situation in the mapping/GIS industry and do you think open tools and data will eventually take over?
I don't think open software will take over because it's always playing catch up and very rarely customer-focused or original. As an example, select a group of numbers in Excel and it takes two clicks to color the cells by value. That is, green for low numbers through orange and red. A simple visualization that's very valuable that I use all the time.
Go try that in libre/open office, apple numbers or google docs. It's essentially impossible by comparison. Everyone tries to copy Excel (and ESRI and so on) but they always end up copying the wrong thing. See my talk and the part about Dubai copying New York: https://www.youtube.com/watch?v=v2UqGUa2Tgk
alexandreleroux: Do you see Google ever moving to OSM for Google Maps/Earth data? Other major players have done it -- at least partially (Microsoft, Apple, MapQuest, Esri).
Google people have been super supportive of OSM including funding our conference and so on. I think OSM just moves too slowly for what they're trying to achieve, and that's fine. The world can support more than one map or one ideology.
I think it would be hard for Google for a couple of reasons. First is the investment. Who wants to be the guy to write off billions of dollars? Second, the map isn't actually good enough yet for them, and they're not done yet. They're trying to get cars to drive themselves which in part requires great maps, and they're not there yet.
Will it ever happen? Eventually. I think it depends how long Google (and OSM) lasts, which depends on them (G) finding more than one business model, which enters in to the realm of speculation.
Think about it like this: Would you bet people wouldn't use wikipedia? In the end, if OSM is good enough at zero price, why wouldn't you use it?
alexandreleroux: I heard lots of folk in the geospatial community claiming that it's OSM's ODbL license that reduces OSM data reuses.
The ODbL is a convenient thing to blame for not using OSM. I haven't found a use case yet where it wasn't really about something else, like a business decision. For example, some don't want to contribute addressing back to OSM and so "the license is bad". It's like saying wikipedia's license is "bad" because I have to credit wikipedia when I use it.
Is the license perfect? Absolutely not. But we're breaking new ground here. There isn't another large open data project close to the scope and size. Could we go public domain? Yes, but then it's an open question as to whether it would succeed without incentives to contribute anything to the pot. Hence discussion of Linux vs. BSD.
smellsliketuna: What future projects are you looking to get involved in?
I think there's a lot out there in the world that can be fixed. Search can be a lot better as an example. There are a lot of closed databases in the world that could be freed up. It feels like local businesses should have better services to help them with their online presence.
Then there are simple things. I'm noodling with this: http://www.my-evangelist.com
(Ed.) A pitch from another reddit post:
It feels like companies and startups need evangelists more than ever, but they're hard to find and retain. Why not contract that?
I've been an evangelist and hired them in the past. It's hard and expensive. Then when you have an evangelist, you have to pay a bunch of money to fly them around to conferences. They burn out. And then, when you go to a conference, most of the people manning booths aren't super excited or inviting.
So I figured, why not offer evangelism as a service? Help man your booth, plan great talks, run and attend meetups, help with online evangelism. Maybe you just want to know what's going on at conferences.
It's not a replacement if you want a full-time person who truly believes in your product, but it's a way to fill out your team or hire someone to do a conference for you here or there, far cheaper than hiring someone.
dv7d: How does the future of OSM look like?
Every day that goes by makes it harder to justify not using OSM in some way, because the map keeps getting better and the price is staying the same. I've said enough about addressing elsewhere here already, but it's the missing piece.
2014 is one of hectic year for me with HOT. Things are going well in Indonesia with Scenario Development and Contingency Planning (SD4CP) and University Roadshow with Australia-Indonesia Facility for Disaster Reduction (AIFDR). Within this year, there are more than thousand people exposed with OpenStreetMap, QGIS, and InaSAFE
These are just some highlights for the project I've done:
- Updates about HOT in Indonesia
- OSM Training fro Flood risk mapping in Malawi
- Fieldwork in Nsanje District Malawi
- MissingMaps Jakarta
- OSM Training of Trainers in Philippines
I also involved with some training group within HOT, mostly for Training Working Group as I've done a lot of training, module creation, including translation of training materials. For people who wants or interested about OSM training, I encourage you to join this working group.
I would've never done so much things without the help of HOT community, including my co-workers in Indonesia. So I would like to thank them :)
Now 2015 is here. There are things I would like to see more with HOT community as it's getting better in terms of numbers of volunteers, governance, support, and also recognition. I would like to see more activation, more activities, growing more network and partnership with other organizations, and improving more tools to make humanitarian mapping easier.
My contribution for this year maybe won't be huge as the past three years. Some people might already know that I'm going back to school. My work experiences within HOT in Indonesia and some part of the world has brought me to a full scholarships program from New Zealand Aid for Master of Geographic Information Science (MGIS) in University of Canterbury, Christchurch.
I'm so excited and a bit nervous for going back to school, and I'll live in Christchurch for 2 years. I hope I can meet HOT and OSM community there so maybe I could share some of experiences or maybe ideas. Without my presence, however, HOT still continuing the project in Indonesia with the rest of the team that I fully trusted. And I hope, I still can give support remotely, not just for Indonesia, but also rest of the world.
No Rio de Janeiro (e talvez noutras cidades do mundo), existem lanchonetes especificamente voltadas para sucos, as chamadas casas de sucos. Me pergunto como seria a melhor forma de marcar no OSM estabelecimentos deste tipo. Talvez amenity=fast_food e cuisine=juice?
Alguém tem alguma ideia a respeito?
In Rio de Janeiro (and perhaps other cities worldwide), there are snack bars specifically focused on juices, known as "casas de sucos" (lit.: juice houses). I wonder what would be the best way to tag such establishments on OSM. Perhaps amenity=fast_food and cuisine=juice?
Anyone has thoughts on this?
I attended a meeting of the Peruvian community on Saturday. Somebody showed us the capabilities of Mapillary. Of course, I'm hooked already.
Soon the parts of the city and surroudings I frequently visit will be visible on Mapillary.
I've been waiting for a long time for a way to link back to pictures I took during my surveys. Wikimedia Commons is no good for this, all the worthwhile pictures I uploaded there got nominated for deletion. So I gave up on them.
Mapillary looks promising. If it were up to me they'd get a dedicated tag all for themselves:
But I also gave up on the voting process on the wiki. Even if a vote's result are positive, that doesn't mean or guarantee that that scheme will be rendered by the powers that be (yes, I'm talking about the 'new' public transport scheme).
So I'll probably simply start using that tag and be done with it.
The Battlegrid had been down for a while and I have had no time to look at it really. Until today! The Battlegrid is back up. And it now compares with the latest TIGER 2014 data, so bright cells should more often be a treasure trove for real problems.
If this is the first you hear about the Battlegrid, read much more about it in the original announcement blog post.
What are you waiting for!? Fix some cells, head over to battlegrid.us!
I'm a bit confused by the highest level tags... what is the thinking behind them? Probably this has grown without too much coordination, but it is leading to a mess.
Should there not be some order/thinking/philosophy to them?
highway= .. is tagging a thing.
amenity= is tagging a function/service.
Would it not be best to adopt one order/thinking/philosophy/system and stick to it? I think the present tags have evolved from different points of view and would be best reorganized, but before that happens some guide lines need to be established as to the order/thinking/philosophy/system that should be used. That would help people proposing new tags .. that would fit in with the system, rather than confuse it further.
If highway= were to be tagged as a service then it would be transportation=motorway, primary_highway, railway, ferry etc.
If amenity=drinking_water were to be tagged as a thing then it could be tagged as water=blubber(,sea, river, pipe, tap, )
Thoughts? I've raised the issue on the tagging talk group too.
i've started working on adding Auto Racing venues in the US & Canada to the map, and improving those that are already in the map.
this exercise is in two parts; for those tracks that are still clearly visible (active or inactive) i will add the tracks to OSM. For those which are more doubtful, or which will never return to service, i am adding them to OHM. Examples of the latter include tracks like the first and second circuits at Watkins Glen. hopefully, when the site of an inactive track is redeveloped, we'll reach a state where instead of deleting tracks, they get moved to OHM.
for tagging, i am mostly using ways with highway=raceway. if a direction is discernible (ovals are usually counter clockwise), i set oneway as well. I try to identify the bounding area for the facility and create a landuse=recreation_ground poly with the name and address of the site.
I have largely completed Alaska, am currently nearly done with Arizona, and have also done several examples of historic tracks in upstate New York. i will be working on the south and southwest for the time being, as that is where people are racing at this time of year.
in Arizona i have seen a couple of examples where the race track was done as a multi polygon relation tagged as leisure=track. this tag is for non-motorized racing, not for auto racing. although in the 20s and 30s there were some dual purpose tracks (horses and cars), this practice was abandoned before WWII. i am changing the tags to highway=raceway, but the current mapnik style sheet doesn't render highway=raceway on relations, so as a temporary expedient i am adding ways in the center, which i will go back and remove when the style sheet is updates (and yes, there is a tracker on this in the mapnik queue).
i have a leaflet example of an OHM/OSM mashup here showing the modern Watkins Glen circuit (the 4th circuit) overlaid with the OHM representation of the 2nd Watkins Glen circuit (the first Glen circuit is up and to the right): http://www.na-motorsports.com/test/test.html
A lot of mappers in Taiwan including me are noticed that OSM tiles are down in JOSM, but it look OK in the website.
After some investigation, I found out that HTTP tiles are working but not HTTPS. Accessing https://a.tile.openstreetmap.org/ from my network in Taiwan will hang until timeout.
Is this a known issue and is there any workaround?
Vote for this data so the New Zealand Fire Service opens up some gis data to the public: https://diadata.cwp.govt.nz/datasetrequest/show/226
I have tried quite a few of the various maps available for use on my Garmin device, as of yet I have been unable to find one that looks exactly the same as the basemap! is there one available for the uk?
Recently in Brazil, a number of cities started adding outdoor fitness stations in public parks.
In my city only, there are around 20 of these.
After looking for a tag to describe this feature, I found
Adapted from the wiki page:
A fitness station is an outdoor facility with one or more exercise equipment. This is typically operated by a local government, and free to use for everyone. Often inside a fitness route or a park.
It has a good number of uses right now (1877), but my gut feeling tells me it's not known as much as it could be.
This article is inspired by http://blog.openstreetmap.de/blog/2014/12/wochenaufgabe-kw-5152-oepnvfahrplanwechsel/ but adapted to how public transport is mapped in Belgium at the moment.
I also recorded an editing session in JOSM:
Apparently public transport companies do all the major changes to their time tables towards year's end. At least this seems the case for both Germany and Belgium. So we have some changes to process in Belgium as well.
In Germany they have weekly assignments. I guess that, over here, cleaning up the mapping of public transport, will become a task, that takes somewhat longer than a week to accomplish.
We also still have quite a large amount of lines that are mapped in the now deprecated way, using just one route in a futile attempt to describe all its variations. If all you wanted to do, is render on a map where the buses pass, this may be sufficient, but in case you want to describe actual itineraries, that is severely lacking. Those older routes take the longest to convert, but at least there is an approximate indication of the itinerary when they are present.
We have, however, many routes which are already on 'version 2'. The problem with those is that they are prone to change to the timetables/itineraries and they get broken by edits with inferior editors, which don't process relations properly.
This got me thinking about a way to:
keep them up-to-date in a practical way?
I've been working on scripts to automate the boring parts of this arduous task. The source code can be found here:
Incidentally those scripts also help when creating routes for bus and tram lines which aren't in OSM yet.
They depend heavily on the availability of PT data from De Lijn and TEC though. So their performance is optimal when such data is available, which isn't the case for the Brussels' operator MIVB/STIB, unfortunately. Those can be added in more traditional ways, but instead of starting from the stops to add an itinerary afterwards, it may make more sense to work the other way around.
On to the translation/adaptation of the German week assignment
Mapping public transport in OSM is a subject which is often poorly understood. The consequence is a multitude broken route relations, which don't get updated. For users of the data this is rather worthless. At the time of writing, it seems like 3, and possibly a few other, mapping schemes are in use (I found out recently that we deviate from what the wiki proscribes in Belgium as well, this article was started to describe at which points in detail).
Before starting to edit, some research might be needed. Does the route_master relation still describe an existing bus/tram line? Do the route relations still describe actual variations accurately?
Sometimes lines get new identifiers (line numbers). This occurred in Beringen recently:
I worked on updating those over the past week (Jan 2015). The changes happened in July 2014 though, I'm working on a way to detect such changes in a more timely way and to present to the community at large through a web interface.
To map public transport, you'll need an editor which can work correctly with relations, iD is not up to that task, as it's not possible to influence the order of the members with iD. And the order of relation members is crucially important in public transport route relations. (It is important in our cycle/walking node relations as well, if you want to do automatic validation on them, but that's another story).
JOSM is the only suitable editor to accomplish this task and not only because of the relation editor, but also because it's the only editor which supports the MapCSS to properly visualise the data and a scripting environment to use the scripts I created to help with the task.
New routes and all the ones we bring up-to-date, should be mapped according to the 'new' Scheme. For Belgium it's described here:
In the new scheme a separation is made between where the passengers wait and where the (front of the) bus/tram/train halts on the way. The latter is mapped as a node which is part of the way. Although all stops of De Lijn and TEC are now in OSM, these stop_positions were not always added. Please add them if you are already editing/splitting the way for other purposes.
public_transport=stop_position for bus stops add bus=yes for tram stops add tram=yes for train add train=yes
These nodes don't get extra information like name, ref, route_ref or zone. (at least in Belgium they don't)
When this serves as a terminal/initial stop for some of the served line variations, split the way at this point.
In case a platform is present, this can be entered as a way or an area.
To get them rendered add:
highway=platform for bus stops
railway=platform for tram stops
In case of a closed way for an area add
At the moment I haven't found a reason to use multipolygon relations for these.
In Belgium, these platforms don't get any extra tags, except for tactile_paving=yes/no if a way was used to map it and those foot massagers are present.
In case of an area was used for mapping the platform, it's probably better to add a highway=footway with tactile_paving=yes. The imagery of AGIV is good enough to determine where their extremities are. They look like white T's
To keep things simple and manageable all bus and tram stops in Belgium are mapped on nodes. I never considered moving the details like name, ref, route_ref and zone to platform ways, as that would result in them not being shown anymore by the MapCSS style I created for that purpose.
These nodes can designate the position of the pole, a corner on the shelter where the 'flag' is mounted, or if this is unknown, the position of the B of the word B U S, if visible on the aerial imagery.
In Belgium all bus and tram stops of De Lijn and TEC are now mapped, most of them by yours truly. (Click on the links if you want to download files converted to OSM format for verification). In case the position could not be determined from the aerial imagery these positions are approximate until somebody surveys and moves them.
TEC also provides shapefiles, which I converted to GPX. This is mostly interesting to know which streets the buses are likely to follow and to exclude the streets where they most certainly don't go.
In Brussels we can't seem to get permission to access to the data of MIVB/STIB, but the exact positions of the poles are in the dataset of UrbIS, which we are allowed to use. So we should be able to map the PT network in Brussels the (mostly) traditional way. UrbIS contains the tram rails as well. It's quite an undertaking to integrate them in OSM, but once they're in, it becomes trivial to add the tram lines. If you provide me with GPX files of your bus rides on lines in Brussels, I might even add/update them for you.
Some stops of De Lijn and TEC extend into the Brussels Region, The Netherlands, Germany, Luxembourg and France. All these were added to OSM as well. In fact, I did those first, to find out which was the best way to do so. At first I used dedicated nodes per operator, but that's not the proper way, after all (I was never entirely happy with doing it that way, but it had a few advantages as well in case some fields didn't happen to agree). Now each operator got their own 'namespace' and those nodes should all be merged by now.,
public_transport=platform for bus stops add bus=yes for tram stops add tram=yes for train add train=yes
For backward compatibility and to get them rendered:
add highway=bus_stop or railway=tram_stop
All bus/tram stop nodes have a unique ref to identify them. To make it possible to use a single node for multiple operators, these are mapped as:
ref:De_Lijn ref:TECB ref:TECC ref:TECH ref:TECN ref:TECL ref:TECX
Indeed, each entity of TEC assigned their own identifiers and for buses which wander into another provinces the stops have more than one.
For Veolia, Connexxion, MIVB/STIB, etc we can safely use:
But mostly we don't have identifiers for these.
Sometimes it's necessary to use separate namespaces for name as well:
When 2 entities of TEC don't happen to agree on the name to use, I just picked 1, mostly arbitrarily.
At some point we decided to include the name of the municipality as part of the name:
Making an exception for the larger cities like Antwerp, Brussels and Ghent. In retrospect I would prefer to start prepending Gent as well. For Charleroi and Liège, I simply included them as part of the name. For stops outside of Belgium this is not customary. For bilingual areas, I also dropped the village/city names, as they become rather long otherwise.
The same applies to route_ref. This tag includes all the lines which serve this bus stop.
For QC purposes one could also include not_served_by for those stops skipped by express buses, or when it's not possible to serve them as the bus makes a left turn across 2 lanes soon after where the halt is located.
It's possible to include
* shelter=yes/no * covered=yes/no * bench=yes/no * bin=yes/no
Or it's possible to map these as separate elements:
* amenity=shelter * shelter_type=public_transport * amenity=bench * amenity=waste_basket * building=roof
for bus stations you can add a node or an area tagged as * amenity=bus_station
All of the above can be collected in a stop_area relation. One stop_area relation for each highway=platform node. So in simple cases one for each side of the road.
All stop_area relations can be collected in stop_area_group relations. JOSM will complain about these. Let it. The validator may catch up some day, or not. They were in the initial 'new' PT scheme, and then they were dropped for some inexplicable reason.
Once the stops are mapped according to 'PTv2' - we can start adding route relations for all the variations. The good news is that in Belgium almost all stops have been added by now. The exception are those stops in Brussels which don't get served by De Lijn or TEC. Add OSM notes to the map with all their details and send me a link to the note for those, if you don't feel comfortable adding them directly.
In PTv2 there is one route relation per variant. So the simplest lines will have 2 variants, one for each direction (The exceptions confirming the rule are the Ringbus 600 and 601 in Leuven and some school buses like 586). The good news is that we can compile route relations for each of these variants automatically for lines run by De Lijn and TEC.
To keep the number of variants (and the work to keep them up-to-date) limited we only have a variant for the longest sequence of stops for telescopic routes. I believe it makes sense to save contributors' precious time and to limit the number of route relations, ways need to be members of. For rendering there is no difference (except that it means less processing) and for routing, it's relatively easy to cut out the ways sequence which is needed for a shorter sequence of stops. (I know it can be done, as I've scripted exactly that to assist contributors when creating new route relations)
Each route relation has all the stops at the end. These are the platform NODES mentioned higher up. These are the only nodes the conversion scripts know about, so these are the nodes which can be added automatically to the template routes it creates. Their order matters, of course. At some point I made the arbitrary decision to have the ways first, followed by the stops, as that's the way JOSM would sort them (if you were foolish enough to let it do that on all the members of the relation at once. JOSM can sort the ways fine, but it's smarter to give it a subset of just ways. It doesn't cope very well if ways are used more than once (loops, spoons)).
Apparently the wiki contradicts this and proscribes stops first, then ways. Ultimately I don't think it matters much, unless it would cause 'edit wars'. I prefer to have the ways first, as that is what contributors work on. The stops are added by a script, at least in our case.
If the bus uses a way more than once, it will be in the route more than once. The same goes for the stops, which get served more than once by the same variant. This is less common than ways being used more than once.
All variant routes belonging to the same line are collected in a master route relation.
Challenge: keep it all up-to-date
I will come up with a script which can make an overview of which routes are in need of attention. Hopefully I can get an account on a dev server to do so.