Hi Peter, I'm always talking about the (or a) history-dump. My problem is, that it possible to use the latest osmosis to import the history-dump (or parts of it -> AOIs) into the api- or simple-schema. But in both versions the visible-attribute, which says if the entity is deleted or not is worthless. on one way it's just set to visible (importing into the api-schema without populating currrent tables), on the other way (importing into simple-history-schema) the visibility isn't availiable at all. 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. If I import the history dump (filename: full-planet-... that's why I was talking about the full-planet, may be that was confusing) or an filtered AOI the visibility information might be very important, because even if I work with the simple-history-schema, I might render some maps, showing a specific point in time but including at this time deleted points. How does it make sense to import an history-dump, if afterwards I can't say which points ahve been deleted at a certein point in time. the problem occurs at both schemas. 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.
I hope now you understand my thoughts a bit better Marco P.S. I already had forgotten about [2] - hope everything is fine. > Am 09.09.2010 16:18, schrieb Marco Lechner - FOSSGIS e.V.: >> I did some Java-hacking last night and my osmosis doesn't ignore the >> visibility anymore. I'll do some testing, because I guess I can import >> AOIs of the planetfile into the api-schema by filtering the full-planet >> using --bp and not populating the currenttables. This can be a basis for >> some analyses or a nice test-environment. > > I'm not sure I understand your intention. In order to import a part of > the planet, you don't need the history plugin. You can use the normal > postgres tasks for that. > > The history plugin is about reading a history dump and/or applying osc > files to either an history or a classic import in a way, that keeps > the history of all elements untouched. > >> I think it's a clean behaviour if --read-xml file =- write-xml file=- >> doesn't change anything, or is this nonsense? > It might work and it might not change anything, but as a plugin author > I don't want to change anything in the main osmosis code but only set > my plugin "on top". The very most operations performed with osmosis > don't need the visible flag and there's no task that is able to use > it, so I don't see any need in adding support for it in the main > osmosis tasks. > > Instead I'll go the oo-way and extend the existing classes (eg. create > a DeletedNode extends Node) and my own readers, that just overrides as > necessary. See [1] on this. > >> but I'm not sure if it's less work if Brett just implements it (if >> he likes to) without my dirty code. > I think Brett has currently other things in mind [2] ;) > >> The simple Schema is missing the visibility-column anyway - may be I'll >> do some (dirty) patch for this as well. > I'll add it to the history plugin, soon, as it belongs there. In every > normal planet dump, deleted items are simply missing. Only when it > comes to history dumps / excerpts, they become meaningful, so this > definitely is a task for the history plugin. > > Peter > > [1] > <http://lists.openstreetmap.org/pipermail/osmosis-dev/2010-August/000707.html> > > [2] > <http://lists.openstreetmap.org/pipermail/osmosis-dev/2010-August/000704.html> > _______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
