Hi Peter, On Fri, Sep 10, 2010 at 5:52 PM, Peter Körner <osm-li...@mazdermind.de>wrote:
> Am 10.09.2010 09:15, schrieb Marco Lechner - FOSSGIS e.V.: > > Hi Peter, >> >> I'm always talking about the (or a) history-dump. >> > Okay, then we're talking about the same thing. > > > on >> the other way (importing into simple-history-schema) the visibility >> isn't availiable at all. >> > Please don't consider the simple-history-schema being final or sth. I might > add the visibility column on Sunday or maybe next week. > > > The reason for that is, that these schemas or >> their root didn't have the necessity to take care of the visibility, >> because they were focussing on dumps at a certain point in time and >> therefore contained only visible entities. >> > The simple-history-schema is targeted on holding all information including > history, and this includes the visibility flag. I just did not come to the > point of implementing handling of deleted elements. > > I focused on reading ways and building intermediate versions of them but > even this is not finally done and still buggy. > > > > the problem occurs at both schemas. > right now -- yes. But the history thing is quite young and pre-alpha with a > lot of missing features. > > > The main reason for it is, that osmosis doesn't take care of the >> visible-attribute anyhow. This can be shown easily by reading an osm.xml >> (including the visibility-attribute) and writing it without any >> filtering- or bounding-taks. The results differ, because the written xml >> is deprived of its visibility information. >> > Yes this is true because of the reasons mentioned at [1]. To solve this > we'll need to introduce a whole set of different tasks that extends the > functionality of the bounding-box and filter tasks to respect the > visibility-flag. As long as Brett doesn't give his go to it, I don't plan to > change the osmosis source to include the visibility flag but instead write > my own tasks for this. Unless there's something I'm missing I think Osmosis already has support for the visible flag, but in a different form to what you might be expecting. Can you send the data through as change entities instead of trying to add a "visible" attribute? visible=false is the same as a "create" or "modify" change, and visible=true is the same as a "delete" change. Most Osmosis "change" tasks treat the create and modify actions as much the same thing. For an example of this, check out the --write-apidb-change task. In the early days of Osmosis I went down the path of using change information instead of a visible attribute in order to keep Osmosis independent of the database implementation. Change/history information is added by means of wrapping an Entity (or EntityContainer) in a ChangeContainer object which holds the action. It has the benefit that the basic entity classes remain simple without optional attributes, instead they are augmented as necessary by aggregating them into other classes. If you can use the existing change stream support you'll avoid having to make any changes to Osmosis core. The pgsql schema will require many changes because it is only a snapshot schema at the moment. In fact that's why it was originally called the "simple" schema because I was planning on creating a "full" schema that could contain full history but never found the time. If you get this into a form where it's useful I think we'll need to fork the pgsql tasks into the current snapshot tasks and your new full history implementations. Brett
_______________________________________________ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
