Peter Miller wrote: > 1) We clarify that a Derived Database is only deems to exist when the > martial changes have occurred to the content of the DB, but not if the > dataset has merely been processed into a different format.
On the face of it this sounds reasonable, although I can see there being some contention over what counts as a "material difference". To give a concrete example, similar to the routing service Frederik mentioned, I would like to be able to use OSM data for my company's (commercial) application. This would involve: 1. Split the planet dump into smaller units (individual countries). 2. Convert from OSM's XML format to shapefiles+Dbase files. The geometry is unchanged, but the database schema is simplified (e.g., units are made metric, highway tags are converted to a fixed set of values - this is lossy, as we might map multiple tags to the same value). 3. Convert the shapefiles+Dbase files to SQLite databases. The schema is unchanged, but each geometry is lossily compressed. 4. Build additional indices (R*Tree, full text, etc) in the SQLite database. 5. Build additional tables (for routing, more efficient rendering, etc) in the SQLite database. 6. Convert the SQLite database into our proprietary format (compressed and encrypted). Each of these steps does change the data from OSM, however none of them would be useful for improving OSM (tags are lost, node coordinates are less precise, tables get built that are no use to anyone else). Given that, providing documentation on our file format (or supplying a tool to go back from that format to XML) seems pointless. The final data is a lower-quality version of the data in OSM, so I would hope that publishing the source planet file would be sufficient. If _improvements_ are made to the data along the way (perhaps we employ someone to sit down and fix any typos in name tags) then I would like the licence to compel us to send those improvements back. I, as a mapper, don't really care if company X turns a planet file into whatever format is most appropriate for their medium (using whatever compression or proprietary format they need). What I would like to come back would be any improvements they made to the OSM data; either by merging it with another database, correcting the OSM data, etc. In (my) order of preference, those changes could be supplied as: A. Directly to OSM (if you ship data with positive improvements to OSM, you have N weeks to insert those into the OSM database and perhaps publish a list of what you changed/when/why). B. In an OSM-compatible format (if you ship data with positive improvements to OSM, you publish a .osm file at the same time so someone else can integrate them). C. In a machine-readable format (perhaps shapefiles+dbf files, after step 2 in the above). This is the worst case, since it's unlikely anyone will sift through these files and actually apply them to OSM unless a lot of new data was added over the source OSM data. You could argue that we need to publish our proprietary file format and that would avoid us having to do anything. That would be equivalent to C), and I think would make us less likely to want to use OSM data. Primarily because we want to keep that format private (since publishing it would allow decompilation of the commercial data we publish in that format), but also because I don't think it would really help OSM. I imagine any database that's optimised to minimise space would have the same problem, as your derived DB is a lower-quality version of the OSM DB. I'm not sure where you draw the line for a "material change" (if IDs are dropped to save space, do we even want that modified DB back? Or do we just want DBs that are a material improvement?), but thought it'd be useful to show exactly what our conversion process would look like. -dair ___________________________________________________ [EMAIL PROTECTED] http://www.refnum.com/ _______________________________________________ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/legal-talk
