Dair, That last post was an interesting one. I liked some of your anaologies regarding material change.
I can think of three types of material changes that we would want contributed back to OSM: [1] Modifications that improve (not degrade) the accuracy of a Feature geometry. [2] Modifications that improve (not degrade) the topology of a Feature geometry. [3] Modifications that improve (not degrade) the quality of the Feature Tags (attributes) of a Feature. There are two other types of changes that would seem less critical to contribute back: [4] Modifications that add Feature Tags (attributes) to a Feature. [5] Modifications that add Features. It seems like #4 and #5 may be the type of modifications that make a derived database? Dair wrote: "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." I would think that this complies with the spirit of the OSM license, correct? I don't care if you are adding some useless bit of proprietary information as a feature tag. However, if you are making more accurate feature geometries, I would be interested in that. Landon On Thu, Oct 9, 2008 at 3:44 AM, Dair Grant <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/legal-talk
