[OSM-talk] [Osmf-talk] Attribution guideline status update

Simon Poole simon at poole.ch
Sun Sep 8 19:16:45 UTC 2019


Am 08.09.2019 um 20:37 schrieb Christoph Hormann:
> On Sunday 08 September 2019, Simon Poole wrote:
>> I think you are confusing potentially extractable information with
>> actual data. For example satellite imagery may have a potentially
>> high information content that could be with appropriate processing be
>> turned in to data, but each image in itself is at most one datum.
> I see - so you want to quantify by counting 'data objects' of some sort.  
> I assume for the OSM side you want to go with the quantification of one 
> OSM feature equals one countable object and a large lake multipolygon 
> for example can count a few thousand?
>
> You'd still loose by a huge margin in a map with contour line relief 
> rendering of course.
>
> And i would still hold the bet that i would be able to get the OSM 
> fraction of any map below 50 percent without too much effort.
>
>> Now waiting for the every image is a pixel database argument.
> You are aware that most satellite image layers used in visualizations 
> are produced from hundreds of thousands or even millions of individual 
> images, assembled pretty much in the same way as a map rendering is 
> assembled from multiple features.  It therefore seems your 'one datum' 
> concept is somewhat fragile.

I wrote "at most" one datum, I would argue that that an image is an
image (even if it is a composite image) and not a datum.

But in any case the guideline refers to theĀ  "visible map rendering". At
least in conventional use of the term, aerial imagery is not a map, but
if you so which we could surely add a definition for "map" that makes it
clear that we are referring to the rendering of map vector data and
similar and not image-like layers.

Simon

>
> I see exactly one possible quantification of data fractions in a map 
> that could not be easily circumvented.  That would be based on the 
> number of human work hours that went into producing the data.  This is 
> a rule i could support:  If more human work hours went into producing 
> the non-OSM source data used in a map than in the OSM data used 
> attribution that is hidden by default is acceptable.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20190908/968bd0a0/attachment-0001.sig>


More information about the talk mailing list