Author: rullzer
[Added to the original trac issue at 2.43pm, Sunday, 1st November 2009]

Added a new patch.
This now also includes version information which is also a nice thing if you want to visualize activity etc.

Author: jburgess777[at]googlemail.com
[Added to the original trac issue at 3.07pm, Sunday, 1st November 2009]

It looks like a good new feature. I was wondering if you had considered the approach of turning the user/uid/version information into tags when reading the objects? This might be an easier way to pass the data through the existing code with less changes. Then user/uid/version can be added to the style to obtain the relevant columns in the DB.

Author: rullzer
[Added to the original trac issue at 12.25pm, Monday, 2nd November 2009]

very true!
Then it would not require an extra flag and the user can even choose to include this only for nodes for example.

I'll start working on a new patch :)

Author: rullzer
[Added to the original trac issue at 12.56pm, Monday, 2nd November 2009]

New patch attached. Does the same thing but now with the use of tags.

I named the field: osm_user, osm_uid and osm_version. This since it is unlikely they will be used but version=* is far more likely.

Author: rullzer
[Added to the original trac issue at 10.15pm, Thursday, 5th November 2009]

New patch to also include the timestamp. Simply add the following lines to your default.style file

node,way osm_user text linear
node,way osm_uid int linear
node,way osm_version int linear
node,way osm_timestamp timestamp linear

And enjoy the new features. I used native types since they take less space and are faster to query than strings.

Author: jonb
[Added to the original trac issue at 4.21pm, Saturday, 19th December 2009]

(In [19144]) Allow user,uid,version & timestamp attributes to be imported from osm objects. Fixes #2405.

Author: jburgess777[at]googlemail.com
[Added to the original trac issue at 4.28pm, Saturday, 19th December 2009]

I finally got around to adding this feature into osm2pgsql. In the end I thought it was better to make this extra information optional since it does increase the storage required to hold all the objects.

Thanks for your patches & patience!

Author: Ldp
[Added to the original trac issue at 9.15pm, Tuesday, 22nd December 2009]

One issue with the current way this is implemented: this new feature injects the osm_* tags into the tag list for each object. Because of this, suddenly every way/node is interesting enough to be included in the resulting db.

I could do with an intermediate way as well: do inject these extra attributes, but don't consider them important enough on their own to merit adding the object to the db. This way we do get the extra attributes for stuff that would render, but not the extra stuff that wouldn't render anyway.

Author: jburgess777[at]googlemail.com
[Added to the original trac issue at 10.15pm, Tuesday, 22nd December 2009]

Replying to [comment:9 Ldp]:

One issue with the current way this is implemented: this new feature injects the osm_* tags into the tag list for each object. Because of this, suddenly every way/node is interesting enough to be included in the resulting db.

I forgot about this. It sounds like we need to another flag for this kind of inconsequential data. How about 'minor'?

This will indicate that the data is included if present but will not in itself cause the object to get an entry into the DB. I can imagine that we could mark several other tags as minor since that make no sense to appear on their own, e.g. access, width etc.

Author: amm
[Added to the original trac issue at 5.54pm, Monday, 16th September 2013]

Closing, as the main points of the bug report have been implemented, and there hasn't been any activity in 4 years.