On Thu, Nov 18, 2010 at 4:47 PM, Lennard <l...@xs4all.nl> wrote: > On 16-10-2010 9:55, Lennard wrote: > >> On 16-10-2010 8:39, Brett Henderson wrote: >> >> If anybody sees any issues with the binary support, please let Scott and >>> I know. I'm now building Osmosis via an automated Hudson process so >>> pushing out new builds should be fairly quick once a fix is identified. >>> >> >> Scott already knows about this, but 23580[1] will emit a warning for >> every occurence of an object without user/uid parameters. These objects, >> the result of anonymous edits which were possible in the past, do exist >> in the planet, and could cause some flooding on the console output. In >> my eyes, this change should be reverted. >> > > Just built the current trunk, and this output[1] is still present. Could > you please consider removing this notice, or only output it once instead of > for every anonymous element? >
I think that the notice should exist. There's an edge case where someone feeds a file with stripped metadata into osmosis, but, on the output, forgets to tell the pbf writer to strip metadata. I could invisibly have the serializer happily write the junk timestamps, version numbers and other metadata fields, but I thought that the user probably didn't intend to do that. The problem is that there are some entities in the database that do have junk metadata (??), so the warning false positives. I didn't encounter this case in my testing. I won't object to different text, if you have want to propose a patch: "Attention, some entities in the file appear to lack metadata. Did you intend to use omitmetadata=true?" Scott > In fact, the suggestion being given is plain incorrect for some uses. For > instance, when you're cutting out a piece of the planet, you're probably > intending to distribute that extract as-is, i.e. with all metadata intact. > The suggestion in that respect is too bold. > > [1] "Attention: Data being output lacks metadata. Please use > omitmetadata=true" > > >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
