Talk:Import/Catalogue

From OpenStreetMap Wiki
Jump to: navigation, search

Considered OK, Derived as new work. No ToS issue

Could someone explain "Derived as new work. " in the phrase "Considered OK, Derived as new work. No ToS issue" used alongside some of the imagery sources used in Haiti mapping. Dmgroom 11:31, 29 August 2010 (BST)

CanVec and GeoBase

Both CanVec and geoBase are okay for ODbL / CT per email from NRCan, http://lists.openstreetmap.org/pipermail/talk-ca/2010-August/003292.html Rw 18:46, 31 August 2010 (BST)

Geogratis

GeoGratis data is okay per email from NRCan, http://lists.openstreetmap.org/pipermail/talk-ca/2010-August/003235.html Rw 18:49, 31 August 2010 (BST)

SPOT Pakistan

Currently SPOT Pakistan images are listed as "OK" under the contributor terms. Can someone explain how the sentence "to integrate the DERIVATIVE WORKS in the OpenStreetMap database under CC-BY-SA licence (http://creativecommons.org/licenses/by-sa/2.0/) and/or Open Database licence (ODbL: http://www.opendatacommons.org/licenses/odbl/OpenDBL)" meets the conditions of Clause 3 of the CT? I.e. how does the express licensing of CC-BY-SA and ODbL allow for relicensing under any "free and open license"? Also "granted by Spot Image a limited, non-exclusive, non transferable, licence" feels incompatible with Clause 2 of the CT, although with the license being on the images rather than the derivative work, that part might not be as problematic.

Surrey Air Services

Surrey Air Services is currently listed as ODbL/DbCL only. This seems to preclude it from being OK with the CT. Is there a more broad license offered than just ODbL/DbCL?

That thought had crossed my mind too. The data was released under ODbL as it was believed this would be helpful to OSM, but technically that makes it incompatible with the CTs. I consider there is a loop hole in the licenses when ODbL is applied to aerial imagery tiles which were supplied: if the "database" is the file structure and the "contents" are the images themselves covered by DbCL, we can pretty much use the images as we please. However, we should verify the owners of the data are happy with that. --TimSC 20:12, 25 March 2011 (UTC)

Cleanup Request

We should transform the tables to a template approach to make it more understandable --!i! This user is member of the wiki team of OSM 12:55, 16 November 2010 (UTC)

Better to seperate from "Import done" and "Import in Progress" --Deltabrasil 15:40, 24 December 2010 (UTC)
I propose splitting each row in all tables using subpages, ench one containing a call to a template containing a ... statement to return a specific type of information. With those templates, it will be possible to categorize each import source, add new type of information if needed for the future, display each source in a summary presentation linked to a full presentation page.
My idea would use the following type of code :
<includeonly>{{#switch: {{{info|}}
| name = ...
| description = ...
<!-- and so on... for other information types -->
| #default = /?/[[Category:Import/Catalogue entry missing {{{info|}}} information]]
}}</includeonly><noinclude>
{{Import/Catalogue/entry}}
</noinclude>
The noinclude section calls a common utility template that will generate a detailed and readable view of the information exposed, it will test for the presence or absence of mandatory information fields, it will autocategorize the subpage containing this code into useful categories (according to the licencing status or approval, or conditions for using them).
As these subpages will be working effectively like templates (but not generic enough to be used as regular templates for every kinf of pages), it will be possible to generate with them several report pages, by just enumerating their subpages names (in the Import/Catalogue) using a report-specific presentation template which will present some fields, for example in a summary table (with a link to the complete subpage showing all details).
With specific report pages, it will be possible to add further information field types, validating their given value
For subpages where an information field is not specifying an explicit value, these will return a default value string starting by /?/ which is easily testable using the Mediawiki #titleparts ParserFunction as : {{#ifeq:{{titleparts:''value''|2|1}}|/?/|...}}).
As the missing info fields are subcategorizing each missing info field in a separate category, it is possible to create also a report page in this category, explaining what is the expected value and its usage policy. That report page may perform other validations on the list of subpages present in that category.
Note that a MediaWiki extension (Extension:PageAfterAndBefore) allows enumerating all pages in a specified category, using a processing loop (Extension:Loops), allowing for example to call a specified template for each page listed in a specified category, passing it a parameter for the name of a page found in that category, so the maintenance of lists of subpages may be simplified a lot.
  1. If those two MediaWiki extensions are not installed, you'll need to provide in each report page a list of the subpage names to report, and maintain those lists in every catalogue report page (such maintenance may be automated by using a bot). If there's only a single report page (the Import/Catalogue itself), it is acceptable and easy to edit it in a relevant section, to insert the catalogue entry, without much maintenance and without needing any bot (this method what is typically used, for example in most wikis for page deletion requests which use a subpage for each request).
  2. If those two MediaWiki extensions are used, the loop may become very long to process if the category containing all Import/Catalogue subpages becomes highly populated: in this case the import catalogue should be subdivided in separate subcategories. For this reason, the maximum number of loops should be limited (this should not be a problem is the Template:Import/Catalogue/entry (as used above) correctly performs some basic autocategorization by validating a few information fields using conditional #switch: or #if: tests, so that each subcategory will contain less than 200 catalogue entries).
In an initial version of the cleaned up page of the Import/Catalogue, I would simply use option #1 above, without using these MediaWiki extensions, even if there are a few other reports maintained (in the same page or in another report page).
As these will be separate subpages, each one will have its own talk page (containing also some decisions made by the community) about the status and conditions of use. And each subpage will also be categorizable manually (if this is not performed automatically by the call to {{Import/Catalogue/entry}} present in the noinclude section above for showing the full details specified in that catalog entry.
Verdy_p (talk) 20:22, 7 November 2012 (UTC)
This has been discussed for 2 years. Has anything been done? I support Verdy_p's proposal and suggest we step forward and do it. If it doesn't work, we can roll it back. Jeffmeyer 01:34, 7 December 2012 (UTC)
Pending Verdy_p's update, I'm trying to see if there's an easier way to do display this table on a typical wiki page: Import Catalog Draft Jeffmeyer 02:37, 21 December 2012 (UTC)
Please see this Google spreadsheet, which contains an attempt to clean up & standardize this data: https://docs.google.com/spreadsheet/ccc?key=0As7xcVwkvHhtdHRIUF9sSzlOdVQ5ZWZPZnlJUlU1S3c
General thoughts on this page right now:
* It's way too crowded & tries to fit too much information across the page
* It's probably too long for an individual page
* If we were to have a list, I'd suggest including only the following information: Name, Country, Contact, whether the import has been reviewed by others, and status of the import
* Other information that should be included on the import wiki page: Link to data Link to data license, Attempt to characterize the type of license (if not explicit), Have someone verify compliance with ODbL, Contributor Terms - etc. - not sure I understand what that means, Link to Contributors page statement when attribution is required, Copy of any correspondence related to permissions, etc. Jeffmeyer 18:08, 21 December 2012 (UTC)

Why do we have a column for compatibility with Contributor Terms?

Contributor Terms are an agreement between users of OSM and OSM. Why is this being applied to data? If there's something specific that ties the two together, we should add a description identifying why this additional compliance is required beyond the data having an appropriate license. Jeffmeyer 01:36, 7 December 2012 (UTC)

Should we link to the appropriate contributor license statements?

For example, if we have permission to use this data, we should have a quick link to proof of that permission, no? For example, http://wiki.openstreetmap.org/wiki/Contributors#Toronto Jeffmeyer 01:39, 7 December 2012 (UTC)

Why are images included on the import page?

It's not clear why digital orthophotos are included here - is map tracing considered a form of imports? If so, shouldn't Bing be listed on this page? Jeffmeyer 08:13, 27 December 2012 (UTC)