I've fixed the CommonEntityData class which is contained within all Entity classes (eg. Node, Way Relation) to de-serialise the OsmUser.NONE case correctly. Serialisation is used within the sort implementation because it is a disk based sort. This *should* fix the problems with PBF.
Previously it was just creating a new OsmUser with an id of -1. Existing tasks such as XmlWriter were comparing each OsmUser to OsmUser.NONE using code like "OsmUser.NONE.equals(myUser)" which allowed them to be detected as the NONE case correctly, but anything that just does a "user == OsmUser.NONE" style check would have failed. On Tue, Nov 30, 2010 at 8:40 AM, Brett Henderson <[email protected]> wrote: > I'll need to take a closer look. My guess is that the entity > de-serializer doesn't create the user as OsmUser.NONE, but instead a > normal OsmUser with an id of -1. The XML writer might deal with it > okay, but the binary writer might be getting confused. If that's the > case it should be fixable, just need all parties to agree on a > representation of missing user. > > On 30/11/2010, at 7:39, Frederik Ramm <[email protected]> wrote: > > > Hi, > > > > whenever relations without userid are temporarily stored by Osmosis, > they end up changed somehow. > > > > If I take this file: > > > > <osm version="0.6"> > > <relation id="1" version="9" timestamp="2010-06-25T11:33:43Z" > changeset="1" /> > > </osm> > > > > and convert it to PBF: > > > > osmosis --rx test.osm --write-bin test.osm.pbf > > > > I end up with a 58 byte file that can be converted back to the above with > either osmosis or pbf2osm. > > > > But when I run > > > > osmosis --rx test.osm --sort --write-bin test.osm.pbf > > > > then the resulting file has 65 bytes. It can still be converted back to > the above with osmosis, but if I run pbf2osm on it I get: > > > > <osm version="0.6" generator="pbf2osm"> > > <relation id="1" version="9" changeset="1" user="" uid="-1" > timestamp="2010-06-25T11:33:43Z"/> > > </osm> > > > > Somehow the information that user ID and user name were unset has been > lost when the relation was temporarily stored. > > > > Can it be fixed? > > > > Bye > > Frederik > > > > -- > > Frederik Ramm ## eMail [email protected] ## N49°00'09" E008°23'33" > > > > _______________________________________________ > > osmosis-dev mailing list > > [email protected] > > http://lists.openstreetmap.org/listinfo/osmosis-dev >
_______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
