osmconvert csv-output available column names

Hi all,

I would like to analyse some bits of OSM data and therefore filtered OSM data from the OSM history splitter with osmconvert and osmfilter, which are great tools.

Now, I would like to convert the .osm-file into a .csv-file by using osmconvert and the --csv= parameter. I succeed with @lat @lon @id @uid @user @oname and all tags, e.g.

osmconvert by_hist.osm --csv="@id @lat @lon @oname @uid @user amenity name note" --csv-headline -o=by_hist.csv

However, I fail to extract the timestamp, version and changeset. I tried to use both timestamp or @timestamp.

Does anyone know how to access these three variables?


have you looked already whether the osm file you are using contains still these information?

Have a look with a text editor that can load big osm xml files, like notepad++ or ultraedit

As far as I remember: these three columns are not supported by osmconvert when generating CSV files.
Maybe the program can be expanded accordingly… For what purpose do you need these columns? There might be another way to get these data.

I checked the xml-file beforehand. these data are contained in the node tag. thanks anyway, as sometimes you miss the obvious.

Thanks for the info. I just wanted to make sure not to miss something.
I found a work-around: I used ArcGIS OSM Editor (that was at hand, I am sure that there is a QGIS equivalent) to get the timestamp and version data - however, the ArcGIS OSM Editor does not supply all tag information. So, I combined this in R with the csv-output from osmconvert.
What do I do with the data? I am interested in what was mapped when to feed into a scientific study on representation of certain phenomena in different kind of maps (OSM is just one of them).

Thanks for the explanation; I was just curious, because I did not expect these data to be needed in a CSV list.

Some minutes ago I uploaded osmconvert version 0.7R. The missing header tags @version, @timestamp and @changeset have been added. This might ease your toolchain a bit and perhaps could help other users as well.


That’s great, Markus! Thanks a lot!

It makes my analysis (and hopefully all the other’s) much more easy, especially, as I had trouble to match my two outputs due to missing unambigious IDs.