Well this question includes multiple points that I try to answer step by step:
1. Amount of data
A full planet dump is giant and will break every not well designed application. So I highly recommend to rely on existing solutions at least for filtering the full planet dump.
On the other hand I don't know your exact usecase, but I'm pretty sure that you will need updates from time to time. So maybe setup and syncing a local DB or calling an API like overpass is a wise design decision:
http://wiki.openstreetmap.org/wiki/Data
2. Parsing XML data
Parsing the data depends on fileformat as well. You can use XML of course, but most devs say it's slow compared to protobuf. You might recycle existing solutions from osmosis or JOSM:
http://wiki.openstreetmap.org/wiki/Frameworks
http://wiki.openstreetmap.org/wiki/Elements
Maybe it's easier to learn by example who already did the job, e.g. OSM2World:
https://github.com/tordanik/OSM2World
3. Undestanding XML tags
Beside the parsing, you will need to get an feeling about the use of certain tags.
Not all restaurants have a cuisine tag. Some nodes are only placed within building outlines so you might need to copy the address from shape to your POI. Also sometimes the restaurant is tagged at the building itself (here: a closed OSM way) and you might need to calculate the center (what about multipolygones? ;) for a virtual node. All in all this needs time to learn about how the community collects and tags data and you need to be patient till you will get clean results.
Your error message is explained in another answer (the merge task can merge only two pipes, so you need two merge tasks). But there's another way to address your problem, which is to avoid merging entirely: You're filtering one tag pattern in each of three parallel pipelines, then merging those pipelines. In fact, each tag-filter task can accept more than one tag pattern, and will accept/reject entities if they match any of those supplied tag patterns. Here is an alternative command creating a single pipeline that should produce exactly the same results as your three-pipeline approach:
osmosis \
--read-pbf switzerland.osm.pbf \
--tf accept-nodes sport=* amenity=* leisure=* \
--tf accept-ways sport=* amenity=* leisure=* \
--tf reject-relations \
--write-pgsql host=128.178.1.1 database=myDB user=myUsn password=myPwd
However, both your command and the one I proposed will probably not produce the output you are expecting. Both commands are retaining all nodes and ways that have a sport, amenity, or leisure tag, but they are not retaining any nodes referenced by these ways if the referenced nodes don't also have a sport, amenity, or leisure tag. This is the purpose of the used-node task: it will retain any nodes that are referenced by a retained way.
We can't just insert a used-node task into this single pipeline, because we want to retain both the nodes with certain tags and the nodes used by ways with those tags. So here you need two pipelines, but only one merge task:
osmosis \
--read-pbf switzerland.osm.pbf \
--tf accept-nodes sport=* amenity=* leisure=* \
--tf reject-ways \
--tf reject-relations \
--read-pbf switzerland.osm.pbf \
--tf accept-ways sport=* amenity=* leisure=* \
--tf reject-relations \
--used-node \
--merge \
--write-pgsql host=128.178.1.1 database=myDB user=myUsn password=myPwd
Best Answer
The OSM OSMOSIS page gives beginner examples under the section marked 'usage'. For further documentation try the detailed usage section.
For routing specifically, you may also like to investigate PgRouting (for which you will need to load your data into PostGIS using OSMOSIS or OSM2PGSQL) or have a look at OSM2PO. Both of these a common routing solutions for OSM data with plenty of tutorials on the web. and discussion in this forum.