osm2pgsql: patch to include extrainfo (username, uid, version) #2405
Comments
Author: rullzer Added a new patch. |
Author: jburgess777[at]googlemail.com 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 very true! I'll start working on a new patch :) |
Author: rullzer 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 New patch to also include the timestamp. Simply add the following lines to your default.style file node,way osm_user text linear And enjoy the new features. I used native types since they take less space and are faster to query than strings. |
Author: jonb (In [19144]) Allow user,uid,version & timestamp attributes to be imported from osm objects. Fixes #2405. |
Author: jburgess777[at]googlemail.com 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 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 Replying to [comment:9 Ldp]:
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 Closing, as the main points of the bug report have been implemented, and there hasn't been any activity in 4 years. |
Reporter: rullzer
[Submitted to the original trac issue database at 4.00pm, Wednesday, 28th October 2009]
I wanted to do some rendering which included user information (who touched this way the latest etc). But in order to do that I needed to modify osm2pgsql to include this data in the database. Attached is a patch (svn diff) to get the desired result.
Since it is a flag it does not affect people that do not want this. So I think it is ready to go into the code :) But feel free of course to first check my changes :)
The text was updated successfully, but these errors were encountered: