[OSM-dev] Release candidate for OSM binary format is in osmosis trunk.
scrosby at cs.rice.edu
Sun Sep 5 21:05:52 BST 2010
On Sun, Sep 5, 2010 at 7:02 AM, Peter Körner <osm-lists at mazdermind.de> wrote:
> Am 05.09.2010 05:51, schrieb Scott Crosby:
>> This schema is more expressive than the current XML which only
>> includes a 'source' field in the<bounds> tag. Should I alter my
>> schema to have just one field, 'source'? Or define a mapping between
>> this schema and current XML? If I define a mapping, any suggestions as
>> to what mapping to define?
> I'd suggest to keep your schema, because it's easy to add those new tags to
> the xml schema but not the other way round. And in general more meta data is
> always better, if it's not too expensive (which it isnÄt in your schema).
> The only thing I could imagine to be even better is a key/value list instead
> of those fixed fields. This way we could gather the same flexibility as we
> currently have with the xml.
However, I'm not sure if it is wise having having an arbitrary
key-value dictionary for the metadata schema. Metadata should have a
carefully considered schema that is well-defined, because the schema
nominally has to be understood by all software manipulating the data.
Adding fields to the protocol buffer is cheap and easy. It is also
explicit to all implementors; the metadata schema is visible in the
protobuf definition file.
Can you think of a use-case where we need the full generality of
including a dictionary? Or, is it likely that we'd want dozens of
metadata fields in the future?
>> My format allows non-geographic metadata, such as username, version
>> numbers, and last-modified datestamps to be omitted when generating a
>> binary file. This results in significant space savings. However, when
>> parsing, Osmosis expects these fields to be supplied. When the
>> metadata is omitted, I use '-1' and 'now' as as the default. Other
>> suggested defaults?
> I'd set the username to an empty string and the ints (version, userid) to
> zero. That would be the natural default. now for the datestamp is okay, but
> as far as I remember osmosis can handle entities without parsing the date,
> so you could supply any string in this case.
For users, I'm using OsmUser.NONE, which defines the username and
userid. I have to supply a java.util.Date object for the date, which
precludes picking an arbitrary string.
>> Finally, anyone have any suggestions or comments on the schema or the
>> rest of the design?
> I really like to have a well defined binary scheme, packaged into nice
> tasks. Thank you for that.
More information about the dev